跳转至

别只盯着模型：Agent 真正的护城河，是这四层循环

Ch01.576 别只盯着模型：Agent 真正的护城河，是这四层循环

📊 Level ⭐⭐ | 10.8KB | entities/别只盯着模型agent-真正的护城河是这四层循环.md

别只盯着模型：Agent 真正的护城河，是这四层循环

来源: 高可用架构

发布日期: 2026-06-17

原文链接: https://mp.weixin.qq.com/s/jjJqu-Rtah7HDzEiY7z_cQ

导读：本文由 LangChain 开源开发者 Sydney Runkle 发布，指出循环设计能显著提升 AI agent 的有效性和自主性。

文章详细介绍四种循环：代理循环、验证循环、事件驱动循环和爬山循环，并展示如何用 LangChain 原语组合实现。这些循环通过自验证、事件响应和轨迹优化等机制，帮助开发者在不更换模型的情况下改进 agent 表现。

Agent 的核心：模型在循环中调用工具

Agent 之所以有用，是因为它们能通过在现实世界中采取行动，帮助我们自动化工作。但要让 Agent 可靠地完成有价值的工作，不能只靠一个好模型，还需要一个精心设计、适配一组任务的运行框架。

Agent 的核心算法很简单：给 LLM 上下文，让它在循环中调用工具，直到任务完成。这是最基础的循环。但驱动 Agent 的循环远不止这一种。 @swyx 最近写了一篇很好的文章，讨论 "loopcraft: the art of stacking loops"，也就是通过叠加和扩展循环来构建更有效的 Agent。

循环 1：Agent 循环

Agent 的核心，其实就是模型在循环中调用工具，直到任务完成。

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

以内部文档 Agent 为例，在第一层循环中，它会收到一个改进文档的请求，模型进行规划并起草修改，然后用工具克隆仓库、读取文件、编写文档、打开 pull request，等等。

第 2 层：验证循环

Agent 循环可以完成工作，但它第一次产出的结果并不总是正确或一致。当一致性很重要时，通常值得在外面包一层验证循环，用来检查输出，并在结果不达标时把反馈发回给模型。

验证循环会加入一个评分器：它根据评分标准检查 Agent 的输出。如果检查失败，就把结果和反馈一起发回。评分器可以是确定性的，也可以是 Agent 式的。经典例子就是用 LLM 作为裁判。

回到文档写作 Agent 的例子，评分器会在每次尝试后运行测试，检查所有链接是否可访问，所有 CI 检查是否通过，diff 是否只覆盖实际请求的范围。捕获这几类错误不需要人工审核。

第 3 层：事件驱动循环

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

事件驱动循环会把 Agent 连接到你的生态系统。一个事件触发了，新文档落地、定时任务启动、webhook 到达，然后 Agent 开始运行。Agent 不再是一个需要你手动调用的东西，而是在更大系统中持续运行的组件。

LangSmith Deployment 支持触发器基础设施，包括 cron 定时任务和 webhook。cron 的一个常见例子是 openclaw 中的 "heartbeats"，它们会把你的 Agent 变成一个始终在线、主动工作的助手。

第 4 层：爬坡循环

前三个循环自动化的是工作。第四个循环，也可以说是最重要的循环，自动化的是改进。

每次 Agent 运行都会产生一条 trace：它记录模型做了什么、调用了哪些工具、评分器反馈是什么，等等。这些 trace 里包含很有价值的信息，能说明哪些地方有效，哪些地方无效。爬坡循环会让一个分析 Agent 读取这些 trace，并根据发现重写运行框架，给出改进后的配置。这可能包括调整 prompt、工具或评分器。

这里的关键动作是，返回箭头没有只是回到最上层，而是伸进内部，直接更新 Agent 循环。外层循环每跑一轮，都会让内层循环更有效。

人类监督与专业判断

在每一层，都有一些自然的位置适合加入人类监督。自动评分器可以检查链接是否可访问；但要发现表达方式是否适合目标读者，需要人来判断。

有些专业知识应该被固化进 prompt 和工具本身，但对于敏感操作，实时人工审核是必要的。LangChain 的所有开源框架都把 "human in the loop" 做成了一等公民。

深度分析

循环栈：Agent 系统熵减的工程模式

四层循环的本质是一套分层熵减系统：Agent 循环产生熵（自由探索产生不稳定输出），验证循环消除输出熵，事件循环消除集成熵，爬坡循环消除配置熵。每一层都解决了上一层引入的不确定性。LangChain 用 create_agent → RubricMiddleware → LangSmith Deployment → Engine 这四层原语，构建了一个从任务执行到系统自优化的完整反馈链路。

验证循环的计量经济学

加入验证循环会增加每次运行的延迟和成本，但在多数生产场景中，质量比速度更重要。验证循环的实际 ROI 取决于错误修正成本比：如果一次错误输出的下游修复成本 > 验证循环的边际成本，验证循环就是正收益的。文档 Agent 的例子中，检查链接可访问性和 CI 状态几乎零成本，但修复一个已合并的坏 PR 成本极高。

事件驱动：从 API 调用到生态嵌入

第三层循环标志着 Agent 从"工具"到"基础设施"的转变。当 Agent 不再需要手动调用，而是通过 cron、webhook 和 channel 持续响应事件，它就从被动工具变成了主动服务。这种转变的核心设计约束是事件粒度与响应延迟的平衡：太粗粒度的事件（每天一次 cron）可能错过关键更新，太细粒度（每次文件变更）可能产生过多冗余响应。

爬坡循环是 Agent 系统的自指进化机制

第四层循环最具突破性——它让 Agent 系统具备了自指改进能力。分析 Agent 读取生产 trace，调整底层 Agent 的 prompt、工具和评分器，这意味着系统今天的表现会直接改进它明天的表现。Satya Nadella 描述的"组织层面的利害关系"核心就在此：早建立学习循环的公司，让人类判断和 token 资本一起持续累积，将建立一种很难复制的优势。

开源开放权重团队的额外维度

对运行开放权重模型的团队来说，爬坡循环的 scope 可以进一步扩展——不仅是 prompt 和工具配置的调整，还可以接入 RL 微调，把 trace 或 eval 结果作为训练信号改进模型本身。这意味着开源模型团队拥有比闭源 API 用户多一个优化维度：模型本身而非仅模型配置也可以进入学习循环。

实践启示

  1. 不要在模型层解决所有问题：遇到 Agent 表现不佳时，第一反应应该是检查循环设计而非更换模型。四层循环的每一层都有优化空间——调整 prompt（循环 4）往往比升级模型更高效。

  2. 从验证循环开始建立质量基线：哪怕只是最简单的确定性检查（链接可达性、CI 状态、diff 范围），验证循环也能显著降低输出方差。通过 RubricMiddleware 等框架，验证成本远低于错误修复成本。

  3. 事件驱动是规模化瓶颈：尽早接入：Agent 从原型到生产的最大跨越不是模型精度提升，而是从手动调用到事件驱动的转变。cron 和 webhook 不应是事后附加功能，而应在 Agent 架构之初就设计进去。

  4. 爬坡循环需要长期观察耐心：第四层循环的效果不会立刻显现——需要足够多的生产 trace（通常数百条）才能提取有意义的改进信号。建立 trace 分析机制并持续运行，而非一次性项目。

  5. Human-in-the-loop 的位置决定系统的可信度：在每层循环中合理安排人工审核触点——敏感操作放循环 1，质量盲区放循环 2，输出审批放循环 3，配置变更放循环 4。不做一刀切的全自动或全人工。

相关实体

→ 原文存档