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