Agent 之所以有用，是因为它们能通过在现实世界中采取行动来帮助我们实现工作自动化。但要让 Agent 可靠地完成有价值的工作，不仅需要一个好的模型：还需要一个经过精心设计、适合特定任务集的"操控系统"。
核心的 Agent 算法很简单：给 LLM 提供上下文，让它在循环中调用工具，直到任务完成。这是最基本的一个循环。但远非驱动 Agent 的唯一循环。@swyx 最近写了一篇很棒的文章，题为 "loopcraft: the art of stacking loops"，其核心思想是，你可以叠加和扩展这些循环，以构建更有效的 Agent。
以下是我们对这套循环栈的理解，以及如何使用 LangChain 的基本组件来为每个层级配备相应能力。
循环 1：Agent 循环
其核心是，Agent 只是一个在循环中调用工具直到任务完成的模型。
这就是 LangChain 的 create_agent 所提供的功能。选择任意模型，接入工具，你就拥有了一个可工作的 Agent 循环。工具赋予了 Agent 在现实世界中采取行动的能力。
以我们内部的文档 Agent 为例（本博客后续内容将以此作为贯穿性示例）。在第一层循环中，它接收一个文档改进请求，模型会进行规划并草拟修改，然后使用工具来克隆仓库、读取文件、编写文档、提交 PR 等。
层级 2：验证循环
Agent 循环可以完成工作，但并非总能在第一次就产出正确或一致的结果。当一致性很重要时，通常会将其包装在一个验证循环中，该循环会检查输出，并在输出不合格时将反馈信息发送回模型。
验证循环增加了一个评分器：它会根据评估标准检查 Agent 的输出，如果不符合要求，则将结果连同反馈一起发回。评分器可以是确定性的，也可以是 Agent 式的（LLM 作为评委就是一个经典例子）。
RubricMiddleware 处理这种模式，或者你也可以通过 create_agent 的 after_agent 钩子来配置它。
以我们的文档编写 Agent 为例，评分器会在每次尝试后运行测试，检查所有链接是否能正常解析、所有 CI 检查是否通过，以及代码差异是否严格限定在实际请求的范围之内。无需人工审核即可捕获这些类型的错误。
一个权衡：增加验证会提高每次运行的延迟和成本。当质量比速度更重要时（这适用于大多数生产用例），这是值得的。
层级 3：事件驱动循环
Agent 开发中最重要的部分之一是集成层：将你的 Agent 连接到你的生态系统，使其能够在后台运行。
事件驱动循环将你的 Agent 连接到你的生态系统。当一个事件被触发——例如一个新文档落地、一个定时任务启动、一个 Webhook 到达——Agent 就会运行。Agent 不是你手动调用的东西；它是作为一个组件在一个更大的系统中持续运行的。
LangSmith Deployment 支持触发器基础设施，包括对 Cron 调度和 Webhook 的支持。Cron 在实际应用中的一个流行例子是 openclaw 中的"心跳"功能，这能将你的 Agent 转变为一个始终在线、主动的助手。
我们的文档 Agent 由 Fleet 提供支持，这是我们自己的无代码 Agent 构建器。Fleet 的 channels 和 schedules 负责处理事件驱动和 Cron 型触发器。我们使用一个频道，每当我们的 Slack 频道 #docs 中有消息发送时，就会触发文档 Agent 运行。
层级 4：爬山算法循环
前三个循环使工作自动化。第四个循环（可以说是最重要的）使改进自动化！
每次 Agent 运行都会产生一个追踪记录：记录了模型做了什么、调用了哪些工具、评分器的反馈等。这些追踪记录包含了关于哪些有效、哪些无效的高价值信号。爬山算法循环会在这些追踪记录上运行一个分析 Agent，并利用分析结果来重写操控系统，进行改进配置。这可能包括对提示词/工具的调整或对评分器的调整。
在 LangSmith 中，你可以使用 Engine（我们的追踪分析 Agent）来装备这第四个循环。
回到文档 Agent 的例子，我们使用 Engine 来分析文档 Agent 的追踪记录，以检测任何问题。当多个追踪记录指示存在潜在问题时，就会提交一个 issue，请求对相关的提示词或工具进行更改。
这里的关键动作是，返回箭头不仅仅是循环回顶部——它会深入到内部，并直接更新 Agent 循环本身。外部循环的每一次迭代都会使内部循环更加有效。
展望未来：
提示词和工具配置是最容易改进的方面，但它们并非唯一的选择。对于运行开放权重模型的团队来说，爬山算法循环可以接入 RL（强化学习）微调，利用追踪记录或评估结果作为训练信号来改进模型本身。像记忆和检索技能这样的辅助上下文也可以同样方式改进。循环是一种模式；它优化什么由你决定。
人类监督与专业知识
自动化并不意味着将人类排除在循环之外。在每个层级，都存在人类监督能带来价值的自然节点。一个自动化的评分器可以检查链接是否能解析；但需要一个人类才能注意到框架对目标受众来说是不合适的。那种源于上下文、经验和品味的判断力，正是人类审查的价值所在。
某些专业知识应该被编码到提示词/工具本身中，但对于敏感操作，实时的人工审查至关重要（想想金融交易、数据库操作等）。LangChain 使得在每个循环中配备这些接触点变得简单直接：
- 在 Agent 循环中，要求在敏感操作/工具调用之前获得人工输入
- 在验证循环中，对于敏感工作流，人类可以充当评分器
- 在应用循环中，输出在返回给最终用户之前可以经过人工批准
- 在爬山算法循环中，操控系统的改进在部署前可以经过人工审查
LangChain 的所有开源框架都将添加"人在回路中"作为一个头等基础组件。
整合起来
如果你更喜欢表格视图，以下是这四个循环如何叠加在一起的：
循环
作用
影响
LangChain 基础组件
1: Agent 循环
（模型 + 工具）
模型反复调用工具，直到任务完成
自动化工作
create_agent， 任何 LangChain 支持的模型
2: 验证循环
（Agent + 评分器）
Agent 运行，输出根据标准评分，如果不合格则根据反馈重试
确保质量
RubricMiddleware
3: 事件循环
（验证 + 系统）
事件触发 Agent 运行，进而更新真实系统
规模化工作
LangSmith Deployment / Fleet channels
4: 爬山算法循环
（系统 + Engine）
生产追踪记录输入分析 Agent，后者改进操控系统配置
持续改进
LangSmith Engine
这就是循环工程——或者正如 @swyx 所说的 loopcraft——在实际应用中的样子。像 Steipete、Boris 和 Andrej 这样的 AI 领导者都得到了相同的结论：Agent 的潜力在于你围绕它们构建的循环。
我们已经思考循环 1 和 2 有一段时间了。但重点应该转向循环 3 和 4，那里的价值通过将 Agent 嵌入到你的生态系统中并使其根据你的标准持续改进而实现复合增长。
Satya 阐述了组织层面的利害关系：那些早期就构建学习循环的公司——在那里，人类判断力和 token 资本相互叠加——将会建立起难以复制的优势。
致谢
感谢 @Vtrivedy10、@masondrxy、@hwchase17 和 @huntlovell 提供的审阅意见。
