代理循环：三个嵌套循环的协同机制

背景

近年来，AI 代理（Agent）成为热门话题，许多开发者尝试构建能够自主执行任务的系统。然而，代理循环（Agent Loop）经常被过度简化，通常被描述为一个单一的循环。实际上，一个完整的“代理式”体验是由三个嵌套的循环构成的，它们像一件风衣下的三层结构一样协同工作。本文的作者（自称“疯狂”地写了又一篇关于代理循环的博客）通过伪代码和 Tom 与前任 Laney 的故事，生动地揭示了这三个循环的本质及其实现难点。

核心内容

1. 推理循环（Inference Loop）

推理循环是最外层的循环，也是构建代理时首先要创建的循环。它负责三个核心职责：

• 调用聊天补全 API（即让大语言模型预测下一个词/token）
• 将模型返回的工具使用请求传递给工具循环
• 管理聊天历史记录（包括工具结果和用户消息）的持久化

大语言模型本质上是“缸中大脑”——它们只负责预测文本，本身不产生功能价值。推理循环的工作方式如下：

• 每次调用时，开发者需要将系统提示、用户消息、助手消息以及可用工具的定义全部发送给 LLM 的聊天补全端点。
• LLM 返回消息后，开发者必须将新消息追加到聊天历史中，以便后续对话可以继续。这个历史可以是一个数组、数据库表、Redis 键值等。
• 由于大多数 LLM 提供商的 API 设计是无状态的，它们不知道之前的对话内容，因此每次请求都要发送完整的对话历史。这就是为什么“大对话会消耗更多 token”。

伪代码示例展示了推理循环的基本结构：循环调用 completeChat，将返回的助手消息（包含可能的工具调用请求）推入历史；如果没有工具调用请求，则退出循环，输出最终结果。

2. 工具循环（Tool Loop）

工具循环是第二层循环，负责处理 LLM 尝试使用的工具。当推理循环将工具定义传给模型后，模型可能会在响应中“使用”这些工具（即推断出工具调用）。工具调用本质上也是模型生成的文本，因此工具名称、参数都可能出现幻觉。

工具循环的核心工作：

• 根据模型返回的 tool_calls 列表，逐个取出工具调用请求；
• 查找对应的工具名称，并调用开发者自己的函数，传入模型提供的参数；
• 将工具执行结果（包括错误信息）以特定格式追加回聊天历史中，供模型下一步推理使用。

关键注意事项：

• 因为工具调用也是推理出的文本，所以需要对幻觉工具调用做防御性处理，例如返回“工具未找到”错误。
• 每个工具调用都有一个唯一的 tool_call_id（或 tool_use_id，取决于提供商），用于 API 关联请求与响应。如果后续请求中缺少该 ID，API 会报错。
• 对于某些提供商，工具结果没有专门的错误码，开发者需要用 XML 标签（如 <tool_call_error>）来标记错误。Anthropic 则提供了 is_error 字段。

伪代码中，工具循环内嵌在推理循环的 while 中，依次处理每个工具调用，并根据名称执行对应逻辑（如发送邮件），然后将结果推入消息历史。

3. 人类循环（Human Loop）

第三层是人类循环，作者也称之为“安全循环”或“理智循环”。这层循环并非程序意义上的循环，而是一个阻塞的函数调用，等待人或物（如审批者）自行决定是否批准工具调用。它位于代码边界之外，位于审批者的边界之内。

人类循环的作用：

• 在工具执行前，阻塞等待人工（或安全系统）的批准或重新定向。
• 根据批准结果，返回正常执行结果、带指令的拒绝（<tool_call_denied_with_instructions>）或错误（<tool_call_error>）。
• 将结果再次推入聊天历史，让模型继续推理。

实现难点：代码不能阻塞数小时，服务器可能重启，同时可能有成千上万个其他请求需要处理。因此，需要诸如 Temporal 这样的持久化执行框架来支持这种长时间等待。但人类循环是必要的，因为它是阻止 Tom 给前女友 Laney 发那条消息的唯一防线。

总结：三个循环的协作

• 推理循环：调用聊天补全 API，将工具调用请求委托给工具循环。
• 工具循环：处理模型试图使用的工具，并将审批请求交给人类循环。
• 人类循环：请求批准或给出新方向，结果作为工具结果反馈回去。

这三个循环构成了代理系统的基础构建块。

关键要点

• 代理循环并非单一循环，而是由推理循环、工具循环和人类循环三层嵌套组成。
• 推理循环负责与 LLM 交互、管理对话历史，并处理模型返回的工具调用请求。
• 工具循环负责执行模型请求的工具调用，必须处理幻觉（无效工具名称、错误参数），并正确返回结果 ID。
• 人类循环不是代码内的循环，而是一个阻塞的审批点，用于确保安全或人工干预，是架构中最难实现的部分。
• 大语言模型是无状态的，每次请求都要发送完整对话历史，导致 token 消耗与对话长度呈线性增长。
• 工具和人类循环的返回结果格式需要与提供商 API 兼容，通常使用 tool_call_id 关联，错误信息需用特定标记（如 XML 标签）。
• 人类循环的持久化依赖专门的框架（如 Temporal），因为简单异步等待无法应对服务器重启和并发请求。

意义与影响

这篇文章通过清晰的层级划分，揭示了当前 AI 代理架构中经常被忽视的复杂性。它将代理系统的实现从“一个简单的循环”提升为“三个必须协同工作的子系统”，为开发者提供了可操作的工程指导。尤其是人类循环的提出，强调了安全与人工控制的重要性——在自主性越来越强的 AI 系统中，人类的审批和干预是防止“代理失控”的关键。文中 Tom 与 Laney 的比喻生动地说明了，没有人类循环，代理可能会执行一些不理智的操作（如给前任发邮件），而人类循环正是那道“最后的防线”。

此外，作者对工具循环中幻觉、错误处理、ID 关联等细节的讨论，反映了实际工程中常见的陷阱，对构建可靠的生产级代理系统具有重要参考价值。最后，持久化执行框架的提及也暗示了当前基础设施的不足，未来可能需要更多专门工具来支持长时间阻塞的审批流程。总的来说，这篇文章不仅是一份技术教程，更是对代理系统设计哲学的深刻剖析。