【译】循环工程的艺术

原文：The Art of Loop Engineering 作者：Sydney Runkle 发布日期：2026 年 6 月 16 日

Agent 之所以有用，是因为它们能在真实世界里执行操作，帮我们把工作自动化。但要让 Agent 稳定产出有价值的工作，光有一个好模型是不够的：还需要一套针对具体任务精心设计的 harness。

Agent 的核心算法很简单：给 LLM 提供上下文，让它在一个循环里不断调用工具，直到任务完成。这是最基础的循环，但远不是支撑 Agent 的唯一循环。Swyx 最近写了一篇很好的文章《loopcraft: the art of stacking loops》，核心观点是：你可以把循环堆叠、扩展起来，构建出更有效的 Agent。

下面是我们对这个循环栈的理解，以及如何用 LangChain 的原语去实现每一层。

循环 1：Agent

本质上，Agent 就是一个模型在循环里调用工具，直到任务完成。

这就是 LangChain 的 create_agent 提供的能力。选一个模型，接上工具，你就有了一个能跑起来的 Agent 循环。工具赋予了 Agent 在真实世界中采取行动的能力。

以我们内部的文档 Agent 为例（本文后面会一直拿它举例）。在第一层循环里，它接收一个改进文档的请求，模型规划并起草修改内容，然后用工具去 clone 仓库、读文件、写文档、开 pull request 等等。

第 2 层：验证循环

Agent 循环能把活干完，但第一遍产出的结果未必正确，也未必稳定。当你在意一致性时，通常值得在外面再套一层验证循环：检查输出，不达标就把反馈送回给模型。

验证循环引入了一个打分器（grader）：它按一套评分标准检查 Agent 的输出，如果不通过，就把结果连同反馈一起退回。打分器可以是确定性的，也可以是 Agent 式的（LLM as a judge 就是这里的经典例子）。

RubricMiddleware 实现了这个模式，你也可以用 create_agent 上的 after_agent hook 自己接起来。

在文档 Agent 这个例子里，打分器会在每次尝试后跑测试，检查所有链接是否可访问、CI 是否全部通过、diff 是否只覆盖了请求范围内的改动。这几类错误不需要人工 review 就能发现。

这里有一个取舍：加上验证会提高每次运行的延迟和成本。当质量比速度更重要时，这笔开销是值得的——大多数生产场景都属于这种情况。

第 3 层：事件驱动循环

Agent 开发中最重要的部分之一是集成层：把 Agent 接入你的生态系统，让它能在后台运行。

事件驱动循环负责的就是这件事。一个事件触发——新文档落地、定时任务到点、webhook 到达——Agent 就跑起来。这时的 Agent 不再是你手动调用的东西，而是一个在更大系统里持续运行的组件。

LangSmith Deployment 提供了触发器基础设施，包括对 cron 定时任务和 webhook 的支持。cron 的一个常见用法是 openclaw 里的 “heartbeats”（心跳），它能把你的 Agent 变成一个常驻在线、会主动做事的助手。

我们的文档 Agent 跑在 Fleet 上，这是我们的无代码 Agent 构建工具。Fleet 的 channels 和 schedules 负责处理事件驱动和 cron 式的触发。我们用一个 channel，在 Slack 的 #docs-plz 频道里一有消息就触发文档 Agent。

第 4 层：爬山循环

前三个循环把工作自动化了。第四个循环（可以说也是最重要的一个）自动化的是「改进」本身。

每次 Agent 运行都会产生一条 trace：记录模型做了什么、调用了哪些工具、打分器给了什么反馈等等。这些 trace 里包含了高价值的信号，能说明什么有效、什么无效。爬山循环让一个分析 Agent 去跑这些 trace，再根据分析结果改写 harness 的配置。改动可以是 prompt 和工具的调整，也可以是打分器的调整。

在 LangSmith 里，你可以用 Engine——我们的 trace 分析 Agent——来实现这第四层循环。

回到文档 Agent 这个例子：我们让 Engine 跑文档 Agent 的 trace，找出其中的问题。当多条 trace 同时指向某个潜在问题时，系统就会提一个 issue，要求修改出问题的 prompt 或工具。

这里的关键在于：那条返回的箭头不只是绕回顶部，而是伸进内部，直接更新了 Agent 循环本身。外层循环每转一圈，内层循环就变得更有效一些。

往前看： prompt 和工具配置是最容易改进的部分，但不是唯一的选项。对于跑开源权重模型的团队，爬山循环可以接入 RL 微调，把 trace 或 eval 的结果当作训练信号，去改进模型本身。记忆、检索到的 skill 这类辅助上下文，也可以用同样的方式改进。循环是这个模式本身，至于它优化什么，取决于你。

人的监督与专业判断

自动化并不意味着把人从循环里拿掉。每一层都有天然适合人来监督的节点。自动打分器能检查链接是否可访问；但要发现「这个表述对目标读者来说不合适」，还得靠人。这种建立在上下文、经验和品味之上的判断，正是人工 review 的价值所在。

有些经验应该固化进 prompt 和工具本身，但对于敏感操作，实时的人工 review 是必需的（比如资金交易、数据库操作等）。LangChain 让你在每一层循环里都能方便地加上这些人工介入点：

1. 在 Agent 循环里，在执行敏感操作或工具调用之前要求人工输入
2. 在验证循环里，敏感流程可以由人来充当打分器
3. 在应用循环里，输出返回给最终用户之前可以先由人审批
4. 在爬山循环里，harness 的改进可以先经过人工 review 再上线

LangChain 所有的开源框架都把「human in the loop」做成了一等公民级别的原语。

汇总

如果你更喜欢表格形式，这四个循环是这样堆叠起来的：

这就是循环工程——或者按 swyx 的说法叫 loopcraft——在实践中的样子。Steipete、Boris、Andrej 这些 AI 领域的人都得出了同一个结论：Agent 的潜力，在于你围绕它构建的那些循环。

循环 1 和 2 我们已经琢磨了一段时间。但重心应该转向循环 3 和 4：把 Agent 嵌入你的生态系统，让它按你的标准持续改进，价值会在这里累积起来。

Satya 从组织层面描述了其中的利害：那些早早建起学习循环的公司——人的判断力和 token 资本在其中一起累积——会建立起难以复制的优势。

参考资料

• deepagents quickstart
• create_agent docs
• rubric middleware
• cron jobs、webhooks
• langsmith engine
• fleet channels

欢迎关注我的其它发布渠道

WeChat