Loop Engineering 与 Agent Harness：从任务执行到持续运转

6 月以来，Loop Engineering 开始在 coding agent 圈子里传开。Boris Cherny、Peter Steinberger、Addy Osmani 都在讨论这种工作方式，LangChain 在 6 月 16 日发了一篇《The Art of Loop Engineering》，把它整理成四层循环；swyx 也用 loopcraft 来概括类似实践。

这个概念容易和 Agent Harness 混在一起。两者都会涉及工具、验证器、状态管理、上下文、权限和观测机制。只看组件，很难说明差异。更适合的切入点，是任务的时间形态：Harness Engineering 更关注一次任务的受控执行；Loop Engineering 更关注任务如何持续进入系统、运行结果如何被测量、历史 trace 如何改进下一次运行。

LangChain 把 Loop Engineering 拆成四层。

第一层是基础执行循环（Agent Loop）。模型接收上下文，调用工具，读取结果，继续判断，直到任务完成。LangChain 的表述很直接：agent 的核心就是模型在循环中调用工具，直到任务完成。这一层对应大多数 Agent Runtime 或 Harness 已经具备的基础能力。

第二层是结果验证循环（Verification Loop）。它在 agent loop 外加一层 grader，检查输出是否符合要求；如果不符合，就把反馈送回模型重新执行。Grader 可以是测试、lint、CI、链接检查这类确定性工具，也可以是 LLM-as-judge。LangChain 的 docs agent 例子里，grader 会检查链接是否有效、CI 是否通过、diff 是否只覆盖被要求的范围。

第三层是事件驱动循环（Event-driven Loop）。LangChain 的重点在这里开始发生变化：agent 被接入外部系统，响应 webhook、cron、Slack 消息或文档更新。它不再只通过人工输入启动，而是成为更大系统中持续运行的组件。

第四层是轨迹改进循环（Hill-climbing Loop）。每次 agent 运行都会留下 trace，记录模型做了什么、调用了哪些工具、验证器给了什么反馈。LangChain 的做法是让分析 agent 读取这些 trace，发现失败模式，再改写 prompt、工具说明或 grader。它还特别强调，第四层的反馈箭头会进入 agent loop 内部，更新下一次运行方式。

这个四层拆解很有参考价值。基础执行循环和结果验证循环，主要处理一次任务内部的执行与验证；事件驱动循环改变任务入口；轨迹改进循环改变系统改进方式。LangChain 也判断，很多团队已经在做基础执行循环和结果验证循环，后续更值得关注的是事件驱动循环和轨迹改进循环。

我更倾向于从运行规则理解 Loop Engineering。

近期一篇预印本把这类设计称为 loop specification。可以把它理解成写给系统的一组运行规则：什么条件下启动 agent，要完成什么目标，用什么检查结果，满足什么条件就停止，过程记录写在哪里。作者也区分了三类对象：普通编程循环、harness 内部的 perceive-act-observe 循环，以及这种写在 harness 外层的运行规则。这个定义还很新，不适合作为行业共识，但有助于说明 Loop Engineering 具体在设计什么。

沿着这个视角看，Harness Engineering 解决的是受控执行环境问题。给定一个任务，系统需要为智能体准备工具、上下文、权限、状态、验证器和观测机制，让它在可控范围内执行。任务可以很复杂，也可以持续多轮，但通常存在验收节点：代码修改后测试通过，PR 提交；报告生成后格式检查通过；工单处理后状态关闭并回写记录。

Loop Engineering 的增量主要体现在这些运行规则上：任务从哪里触发，目标如何写清楚，结果用什么检查，什么时候停止，过程记录写在哪里，历史 trace 如何影响下一次运行。Addy Osmani 说Loop Engineering会比Harness处于更宏观的位置上，并把一个 loop 拆成 automations、worktrees、skills、plugins/connectors、sub-agents，以及外部 memory。这里的关键点在 memory：长期 loop 需要把已完成事项和下一步记录在上下文之外，可以是 Markdown 文件、Linear 看板或其他外部状态。

因此，基础执行循环和结果验证循环更接近 Harness 的能力范围。它们处理一次任务的执行和验证。事件驱动循环和轨迹改进循环更能体现 Loop Engineering 的增量：前者规定任务如何从外部事件进入系统，后者规定系统如何从历史运行中改进自身。

这个边界不是框架标准定义。它更像一种分析视角，用来解释两者为什么共享组件，以及为什么 Loop Engineering 这波讨论会集中在事件驱动和 trace 改进上。

把 Loop Engineering 放到持续运转场景里，工程问题会出现三类变化。

第一，验证逻辑从完成判断扩展到健康判断。LangChain 的结果验证循环里，grader 回答的是这次输出是否达标。Claude Code 的最佳实践也建议给 Claude 一个它能自己运行的检查，例如测试、构建、lint、脚本或截图对比；有了可运行检查，Claude 才能读取结果并继续迭代。

到了事件驱动循环，agent 开始无人值守地响应外部事件，验证问题会进入 measurement problem。LangWatch 对这一点说得很直接：verification loop 和 hill-climbing loop 本质上都是 measurement loops；在无人值守场景里，测量层决定了系统只能证明 agent 被触发过，还是能证明它正确运行了。

这和线上系统维护很接近。单次代码任务可以验收产物；长期运行的后端系统需要判断健康状态。错误率、延迟、SLO、error budget、回滚风险、变更影响范围，都会成为判断依据。Google SRE 的 SLO 告警实践也强调，告警应对应 significant events，并从 precision、recall、detection time、reset time 等维度评估告警策略。

第二，事件到任务的归因成为入口难点。LangChain 讲事件驱动循环时，描述的是事件触发后 agent 运行。但在生产系统里，事件通常密集涌入：日志异常、告警波动、工单创建、CI 失败、依赖更新、文档变更，都会产生信号。Loop 设计需要规定哪些信号可以进入系统，哪些信号需要合并，哪些信号只记录观察，哪些信号直接升级给人。缺少这一层，事件驱动循环容易变成看到变化就行动。

第三，人的介入需要成为分层升级策略。LangChain 在四层循环中都安排了 human oversight：敏感工具调用前确认，复杂验证由人担任 grader，输出进入业务系统前审批，harness 改动部署前 review。

长期运转场景里，人工介入点需要提前设计。低风险、可逆、证据充分的动作，可以由系统自动完成；中风险动作需要系统给出方案、证据和影响范围，再进入审批；高风险、不可逆或跨团队影响的动作，系统适合停在诊断和建议阶段。这里涉及风险分级、证据展示、责任记录和回滚预案。

从这些材料里，也能提炼出几条落地原则：触发条件要明确，验证信号要可运行，停止规则要显式，记忆要放在上下文之外，trace 要进入改进链路，人工介入点要提前设计。

其中 trace 改进是轨迹改进循环的关键。OpenAI Cookbook 的 agent improvement loop 从真实 traces 出发，加入人工和模型反馈，把反馈转成 evals，再生成给 Codex 执行的 harness 修改建议；LangChain 另一篇文章也强调，agent 系统里 code 只能说明系统被允许做什么，trace 才能说明它在具体输入和条件下实际做了什么。

这些原则共同指向一个判断：Loop Engineering 的价值集中在持续工作流控制。它把触发、验证、停止、记忆、trace 改进和人工升级写成系统规则，减少人逐轮提示 agent 的负担。

LangChain 的四层循环提供了一个清晰的观察框架。基础执行循环和结果验证循环更接近 Harness 的受控执行问题，事件驱动循环和轨迹改进循环更能体现 Loop Engineering 的增量。

这个增量可以落到一组运行规则上：任务如何触发，结果如何检查，什么时候停止，状态写在哪里，历史 trace 如何改进下一次运行。

Harness 和 Loop 会共享工具、上下文、状态、验证器和观测机制。两者的控制对象不同：Harness 控制一次任务执行，Loop 控制持续运转的工作流。一个成熟的生产 agent 系统，需要同时设计这两层。

参考资料

1. LangChain, “The Art of Loop Engineering”

https://www.langchain.com/blog/the-art-of-loop-engineering

2. Addy Osmani, “Loop Engineering”

https://addyosmani.com/blog/loop-engineering/

3. Sandeco Macedo, “Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting”

https://arxiv.org/abs/2607.00038

4. Anthropic, “Best practices for Claude Code”

https://code.claude.com/docs/en/best-practices

5. LangWatch, “Loop Engineering is a Measurement Problem”

https://langwatch.ai/blog/loop-engineering-is-a-measurement-problem

6. Google SRE Workbook, “Prometheus Alerting: Turn SLOs into Alerts”

https://sre.google/workbook/alerting-on-slos/

7. OpenAI Cookbook, “Build an Agent Improvement Loop with Traces, Evals, and Codex”

https://developers.openai.com/cookbook/examples/agents_sdk/agent_improvement_loop