←返回文章列表

Loop Engineering 的艺术:如何为 Agent 叠加有效循环

LangChain智能体AI 应用
9 分钟-阅读

Agent 的可靠性不只来自模型能力,更来自围绕模型搭建的多层循环:行动、验证、事件驱动和持续改进。

Agent 之所以有用,是因为它们能把模型能力连接到真实世界,替人完成需要行动的工作。但要让 Agent 稳定地产生价值,不能只依赖一个更强的模型,还需要为任务设计合适的 harness,并在 harness 周围叠加不同层级的循环。

最基础的 Agent 算法很简单:给大模型上下文,让它在循环里调用工具,直到任务完成。这是 Agent 的第一层循环,但远不是全部。Swyx 提到过 “loopcraft”,也就是通过堆叠和扩展循环来构建更有效的 Agent。沿着这个思路看,Agent 系统可以被理解成多层 loop 的组合:内层负责行动,外层负责验证、触发、学习和改进。

下面用一个内部 docs agent 作为例子,逐层看这些 loop 如何工作,以及 LangChain 里的哪些能力可以承接这些层级。

Loop 1:Agent Loop

Agent 的第一层循环,是模型不断调用工具,直到任务完成。

Agent loop

在 LangChain 中,create_agent 提供的就是这层基础循环。你选择一个模型,接入一组工具,就可以得到一个能运行的 Agent。工具让 Agent 能真正对外部世界采取行动,而不只是生成文本。

以 docs agent 为例,第一层 loop 中发生的是:

Docs writer agent loop

  1. Agent 收到一个文档改进请求。
  2. 模型理解请求并规划修改方案。
  3. Agent 通过工具克隆仓库、读取文件、写入文档。
  4. 修改完成后,它可以继续使用工具打开 pull request。

这层循环的价值是自动化工作本身。没有工具调用循环,Agent 只是一个回答器;有了工具循环,模型才开始变成一个能执行任务的组件。

Loop 2:Verification Loop

Agent loop 能把事情做完,但不一定第一次就做对。只要结果质量和一致性重要,就需要在外面再包一层验证循环。

Verification loop

Verification loop 会加入一个 grader。它检查 Agent 的输出是否符合 rubric:如果通过,结果就可以继续向外流转;如果失败,grader 会把反馈返回给模型,让 Agent 再试一次。

这个 grader 可以是确定性程序,也可以是 agentic grader。典型例子是 “LLM as a judge”。在 LangChain 体系里,可以用 RubricMiddleware 承接这类模式,也可以在 create_agent 的 after_agent hook 中自己接入验证逻辑。

放到 docs writer agent 里,这层 loop 可以这样工作:

Docs writer verification loop

  1. Agent 先生成文档修改。
  2. Grader 运行检查。
  3. 检查项包括链接是否可解析、CI 是否通过、diff 是否只覆盖用户实际请求的范围。
  4. 如果不满足 rubric,反馈会回到 Agent,触发下一轮修改。

这类错误不一定需要人工 review 才能发现。自动化验证可以把许多明确的质量门槛提前拦住。

代价也很明显:验证循环会增加每次运行的延迟和成本。但在质量比速度更重要的场景里,这通常是值得的,尤其是大多数生产 Agent 场景。

Loop 3:Event-Driven Loop

前两层 loop 解决的是“Agent 怎么执行任务”和“结果怎么被验证”。第三层 loop 关心的是:Agent 如何嵌入真实系统,并在后台持续运行。

Event driven loop

Event-driven loop 会把 Agent 接入组织的生态系统。事件发生时,Agent 被触发并运行。这个事件可以是新文档到达、定时任务触发、webhook 到来,也可以是某个业务系统里的状态变化。

这意味着 Agent 不再是需要手动调用的工具,而是大系统中持续运行的组件。

在 LangChain 生态里,LangSmith Deployment 支持触发器基础设施,包括 cron schedules 和 webhooks。openclaw 中的 “heartbeats” 是 cron 的一个例子:它们能让 Agent 变成始终在线、主动运行的助手。

docs agent 的事件驱动版本则依赖 Fleet:

Docs writer event loop

Fleet 的 channels 和 schedules 可以处理事件驱动和 cron 风格的触发。对于 docs agent,可以配置一个 channel:只要有人在 #docs-plz Slack 频道发送消息,就触发 docs agent 运行。

这层 loop 的影响是规模化。它让 Agent 不再停留在“我点一下它跑一下”的交互模式,而是进入真实业务流,在合适的事件发生时自动执行。

Loop 4:Hill Climbing Loop

前三层 loop 自动化的是工作。第四层 loop 自动化的是改进。

Hill climbing loop

每一次 Agent 运行都会产生 trace。Trace 记录模型做了什么、调用了哪些工具、grader 给了什么反馈、运行中出现了哪些问题。这些 trace 里包含高价值信号:哪些地方有效,哪些地方不稳定,哪些工具或 prompt 需要调整。

Hill climbing loop 会让一个分析 Agent 读取这些 trace,并用分析结果改写 harness 配置。可改进的内容包括 prompt、工具配置,也包括 grader 本身的规则。

在 LangSmith 中,Engine 就是用来承接这类 trace analysis 的 Agent。把它放回 docs agent 的例子里:

Docs writer hill climbing loop

  1. docs agent 在生产环境中运行。
  2. 每次运行生成 trace。
  3. Engine 分析这些 trace,检测潜在问题。
  4. 当多个 trace 指向同一个问题时,系统创建 issue,请求修改相关 prompt 或工具。

这层 loop 的关键,不只是把结果反馈给 Agent 重新跑一遍,而是让反馈进入 Agent loop 内部,改进 harness 本身。每一次外层循环,都会让内层循环变得更有效。

文章还提到,prompt 和工具配置只是最容易改进的对象。对运行 open-weight models 的团队来说,hill climbing loop 也可能把 trace 或 eval 结果作为训练信号,用于 RL fine-tuning,从而改进模型本身。辅助上下文,比如 memory 和 retrieved skills,也可以用类似方式优化。

换句话说,loop 是模式,具体优化什么取决于系统目标。

人类监督仍然重要

自动化并不意味着把人完全移出循环。每一层 loop 都有适合人类介入的位置。

自动化 grader 可以检查链接是否有效,但它未必能判断某段文档的叙述方式是否适合目标读者。后者需要上下文、经验和品味。这类判断正是人类 review 的价值所在。

有些专业知识应该被编码进 prompt 和工具里;但对敏感动作来说,实时人工 review 仍然必要,比如金融交易、数据库操作等。LangChain 让这些触点可以被接入不同层级的 loop:

Loop 层级 人类可以介入的位置
Agent loop 在敏感动作或工具调用前要求人工输入
Verification loop 在敏感工作流中让人类充当 grader
Application / event-driven loop 在输出返回给最终用户前加入人工审批
Hill climbing loop harness 改进进入部署前,先经过人工 review

LangChain 的开源框架把 “human in the loop” 作为一等能力提供,这让人类监督可以按任务风险嵌入到不同层级,而不是事后补救。

四层 Loop 放在一起看

四层 loop 可以整理成一张表:

Loop 做什么 影响 LangChain primitive
Agent loop 模型反复调用工具,直到任务完成 自动化工作 create_agent,任意 LangChain 支持的模型
Verification loop Agent 运行后,输出按 rubric 评分;失败时带反馈重试 确保工作质量和正确性 RubricMiddleware
Event-driven loop 事件触发 Agent 运行,并更新真实系统 规模化自动化工作 LangSmith Deployment 的 cron triggers / webhooks,或 Fleet channels
Hill climbing loop 生产 trace 交给分析 Agent,用结果改进 harness 配置 改进 harness LangSmith Engine

这就是 loop engineering,也就是 swyx 所说的 loopcraft:围绕 Agent 堆叠不同层级的循环,让它不仅能执行任务,还能被验证、被触发、被持续改进。

文章最后提到,Steipete、Boris、Andrej 等人都指向了类似结论:Agent 的潜力不只在 Agent 本身,而在围绕它构建的 loop。

过去大家已经花了很多精力思考第 1 层和第 2 层,也就是 Agent loop 和 verification loop。接下来,重点应该转向第 3 层和第 4 层:把 Agent 嵌入组织生态,让它响应真实事件,并根据组织标准持续改进。

Satya 对组织层面的意义有一个概括:越早建立学习循环的公司,越能让人类判断和 token capital 一起复利增长,形成难以复制的优势。

参考资料

YL

我是姚磊

大模型应用开发者,关注 RAG、Agent 和产品化工程。沉淀实践中的判断、踩坑记录和可复用方法。联系我:yaolei_agent@163.com

LLM AppsRAGProductEngineering Notes