The Art of Loop Engineering：用多层循环构建更可靠的 agent

Agent 之所以有用，是因为它们能在真实世界中采取行动，帮助我们自动化完成工作。但要让 agent 可靠地完成有价值的工作，光有一个好的模型还不够：还需要一个经过精心设计、适配特定任务集合的 harness。

核心的 agent 算法很简单：向 LLM 提供上下文，让它在循环中调用工具，直到任务完成。这是最基础的循环。但驱动 agent 的循环远不止这一种。Swyx 最近写了一篇很精彩的文章，谈到“loopcraft：堆叠循环的艺术”，也就是通过堆叠和扩展循环来构建更高效的 agent。

下面是我们对这套堆栈的理解，以及如何用 LangChain 的基础组件为每一层添加 instrumentation。

从根本上说，agent 就是一个不断在循环中调用工具、直到任务完成的模型。

这正是 LangChain 的 create_agent 提供的能力。选择任意模型，接入工具，你就有了一个可运行的 agent 循环。工具赋予了 agent 在现实世界中采取行动的能力。

以我们的内部文档 agent 为例（本文后续也会用它作为贯穿示例）。在第一层循环中，它会接收一个文档改进请求，模型进行规划并起草修改，然后使用工具克隆仓库、读取文件、编写文档、发起 pull request 等。

agent 循环能够完成工作，但它并不总是在第一次尝试时就产出正确或一致的结果。当一致性很重要时，通常可以在外层包一层验证循环：检查输出，如果不达标，就把反馈发回给模型。

验证循环会加入一个 grader：它会根据 rubric 检查 agent 的输出，如果未通过，就把结果连同反馈一起发回。Grader 可以是确定性的，也可以是 agentic 的（这里的经典例子就是用 LLM as a judge）。

RubricMiddleware 可以处理这种模式，你也可以在 create_agent 上通过 after_agent hook 自行接入。

在我们的文档写作智能体示例中，grader 会在每次尝试后运行测试，检查所有链接是否可访问、所有 CI 检查是否通过，以及 diff 是否限定在实际请求的范围内。捕捉这类错误不需要人工审查。

一个取舍是：加入验证会增加每次运行的延迟和成本。当质量比速度更重要时，这么做是值得的，而大多数生产用例都属于这种情况。

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

事件驱动循环会把你的 agent 连接到整个生态系统中。一个事件被触发——新文档到达、定时任务启动、webhook 到来——agent 随即运行。agent 不是需要你手动调用的东西；它是在更大系统中持续运行的一个组件。

LangSmith Deployment 支持触发器基础设施，包括对 cron 定时任务和 webhook 的支持。cron 的一个热门实践案例是 openclaw 中的“heartbeats”，它能把你的 agent 变成一个始终在线、主动工作的助手。

我们的文档 agent 由 Fleet 驱动，这是我们的无代码 agent 构建器。Fleet 的 channels 和 schedules 负责处理事件驱动和 cron 风格的触发。每当有人在我们的 #docs-plz Slack channel 中发送消息，我们就会通过一个 channel 触发文档 agent。

前三个循环是在自动化工作。第四个循环（也可以说是最重要的一个）则是在自动化改进！

每次 agent 运行都会产生一条 trace：记录模型做了什么、调用了哪些工具、grader 的反馈等。这些 trace 包含了关于哪些做法有效、哪些无效的高价值信号。爬山循环会让一个分析 agent 处理这些 trace，并根据分析结果改写 harness，生成改进后的配置。这可能包括调整 prompt/工具，也可能包括调整 grader。

在 LangSmith 中，你可以使用我们的 trace 分析 agent Engine，来实现这第四个循环。

回到 docs agent 的类比，我们会让 Engine 处理 docs agent 的 trace，以发现其中的问题。当多条 trace 都指向某个潜在问题时，系统会提交一个 issue，请求修改有问题的 prompt 或工具。

这里的关键在于，回箭头并不是简单地回到起点——它会深入内部，直接更新 agent 循环。外层循环每迭代一次，都会让内层循环变得更有效。

往前看：prompt 和工具配置是最容易改进的部分，但并不是唯一选择。对于运行开放权重模型的团队，爬坡循环可以接入 RL 微调，把 trace 或评估结果作为训练信号，用来改进模型本身。记忆、检索到的技能等辅助上下文，也可以用同样的方式改进。循环是一种模式；它要优化什么，由你决定。

自动化并不意味着把人从循环中移除。在每一层，都有一些自然的节点，人的监督能够带来价值。自动评分器可以检查链接是否可访问；但只有人才能发现面向这个受众的叙事角度是否不对。这种来自上下文、经验和品味的判断，正是人工审核不可替代的地方。

有些专业知识应该被编码进 prompt 或工具本身，但对于敏感操作，实时人工审核是必要的（比如金融交易、数据库操作等）。LangChain 可以很方便地在每个循环中埋设这些触点：

在 agent 循环中，在执行敏感操作或工具调用前要求人工输入

在验证循环中，人类可以作为敏感工作流的评判者。

在应用循环中，人类可以在输出返回给最终用户之前进行审批。

在爬坡循环中，harness 的改进可以先经过人工审查，再进入部署。

LangChain 的所有开源框架都把加入“人在回路中”作为一等基础能力。

如果你更喜欢表格化的视图，下面是这四个循环如何叠加在一起：

这就是循环工程（或者按 swyx 的说法，loopcraft）在实践中的真实样子。Steipete、Boris 和 Andrej 等 AI 领域的领导者都得出了同样的结论：agent 的潜力，在于你围绕它们构建的循环。

我们已经思考循环 1 和循环 2 有一段时间了。但现在重点应该转向循环 3 和循环 4：把 agent 嵌入你的生态系统中，让它们持续根据你的标准改进，价值会在这里复利增长。

Satya 从组织层面指出了其中的利害关系：那些尽早构建学习循环的公司——让人类判断与 token 资本共同复利增长——将建立起一种难以复制的优势。

感谢 Vivek、Mason、Harrison 和 Hunter 的细致审阅。

LangSmith 是我们的 agent 工程平台，帮助开发者调试每一次 agent 决策、评估变更，并一键部署。