The Agent Loop: How AI Goes From Answering Questions to Doing Things

代理循环：AI如何从回答问题到执行任务

ByteByteGo

2026年7月8日

开源模型刚刚达到前沿代码审查水平（赞助）

PR-AF是一个开源代码审查代理，在Martian的Code-Review-Bench基准测试中排名42个中的第2位，领先于CodeRabbit、Copilot和Devin，仅使用单个开源模型。关键在于其框架：它为每个PR制定审查策略，生成并行的审查代理，将每个发现与您的源代码进行验证，并丢弃无法证明的任何内容。这使得每次审查的成本比闭源工具低约10倍。一次API调用，即可作为GitHub Action直接使用。如果开源模型能够撰写前沿级别的审查报告听起来有用，请给该项目加星。

立即分叉并部署！

聊天机器人回答问题，而代理完成任务。这似乎是一个巨大的差异。然而，两者之间的差距并没有看起来那么大。

代理是将LLM置于一个循环中，模型本身决定何时停止循环。所有关于代理的有趣特性都源于这一转变。正是这种转变带来了它们的实用性、高昂的成本以及构建时的设计挑战。

在更宏观的图景中看到这一转变的位置会有帮助。

围绕语言模型构建的软件已经经历了可识别的演进过程。它始于单次LLM调用，输入产生输出。随后出现了函数调用，使模型在需要信息或执行操作时能够调用工具。之后，开发者开始在代码中串联调用，每一步的输出作为下一步的输入，以处理单次调用无法处理的复杂问题。最近的进展是代理，开发者将循环本身的控制权交给模型，让其自行迭代直到决定工作完成。

在本文中，我们将逐步探讨这一演进过程。我们还将探讨代理的结构、模型在每一步做出的选择、支撑其运行的框架，以及何时应选择代理作为解决方案。

免责声明：本文基于来自多个来源的公开信息。如果您发现任何不准确之处，请在评论中指出。

基础

在循环变得有趣之前，循环内部的单元必须明确。

一个单纯的大型语言模型调用是一个无状态函数。文本输入，文本输出，每次调用在模型看来通常是独立的。如果我们希望它获取今天的天气或更新数据库中的记录，单纯的模型缺乏实现这些功能的手段。它可以泛泛地描述天气，谈论数据库记录的变化，但要获取实际的天气预报或操作实际的数据库，需要更多东西。

使模型在实际系统中发挥作用的是增强功能。

换句话说，我们赋予它调用我们定义的函数的能力，通常称为工具使用或函数调用。我们给予它访问一个检索层的能力，可以在运行时提取相关文档。我们还给予它一种记录信息的方式，使其在调用之间携带信息，这相当于记忆。

Anthropic将这些能力的组合称为增强型LLM，并将其视为每个代理系统的基本单元。增强型LLM是构建所有其他功能的基础模块。

这是大多数开发者已经使用过的单元，即使他们可能给它起了其他名字。示例包括运行 Python 代码的聊天助手、连接到你服务的函数调用 API，以及从你文档中提取信息的 RAG 应用。这些系统很有用，但它们仍然只是一次调用。模型生成输出，系统返回结果，交互结束直到下一次请求到来。

工作流

当问题超出单次调用的处理能力时会发生什么？

自然的应对方式是将调用按我们设计的顺序串联起来，这种模式称为提示链（prompt chaining）。链中的每一步都是独立的 LLM 调用，前一步的输出成为下一步的输入。我们可能用一次调用来起草大纲，第二次调用将大纲扩展为段落，第三次调用将段落翻译成另一种语言。链条在提前设定好，开发者编写哪些步骤运行、运行顺序以及每一步的提示内容。

这就是 Anthropic 将其归类为工作流（workflows）的一系列模式。

工作流是一个系统，其中 LLM 及其工具通过开发者设计的代码路径进行编排。除了提示链之外，还有其他工作流模式：

• 路由（Routing）对输入进行分类并发送到专用处理程序。
• 并行化（Parallelization）同时运行子任务。
• 管理员-工作者（Orchestrator-worker）模式中，管理 LLM 将任务委托给专业 LLM。
• 评估器-优化器（Evaluator-optimizer）模式中，一个调用生成内容，另一个调用进行批评，循环迭代直到质量达标。

细节有所不同，但每个工作流都共享相同的特性。步骤数量和路径由开发者在设计阶段决定，模型在看到输入之前就已经确定。今天基于 LLM 构建的大多数生产系统都是工作流。它们可预测、可调试，通常比完整的代理系统更便宜。

循环

当我们将 LLM 包裹在循环中并让模型决定何时退出循环时，就得到了代理（agent）。循环本身是普通代码。运行时调用 LLM，读取输出，执行输出指定的操作，将结果反馈给模型的视角，并再次调用模型。这个过程持续到模型生成一个表示最终答案的响应为止。

每次迭代包含四个步骤，我们可以将其称为感知（perceive）、推理（reason）、行动（act）和观察（observe）：

• 感知（Perceive）是循环向模型传递当前状态的时刻，状态包括原始任务、到目前为止发生事件的历史记录以及任何新输入。
• 推理（Reason）是模型的回合，模型生成一个响应，说明下一步该做什么，无论是提问、调用工具还是给出最终答案。
• 行动（Act）是运行时执行模型请求的操作。
• 观察（Observe）是捕获该操作的结果并将其重新整合到状态中，以便模型在下一次感知步骤中看到它。

最重要的细节是：谁决定循环何时停止。在工作流中，开发者在设计阶段决定运行多少步骤。在代理中，模型在运行时决定。模型通过生成运行时解释为最终答案的输出来退出循环。开发者通常会设置迭代次数的硬性上限，通常称为最大轮数（max-turns）参数，但这个上限主要是安全网。主要的停止信号来自模型本身。

Observation 作为首要步骤的重要性源于相同的原因。

模型需要在决定下一步行动前看到其行为的结果。移除观察环节会将循环简化为链条，模型将基于先前的预期而非来自现实世界的新鲜结果运行。正是这种每个动作后都紧跟观察的闭环机制，使模型能够边执行边调整。

建立循环后，下一个问题是每次循环中究竟会发生什么。

决策

每次循环迭代中，模型的输出会从四个分支中选择一个，运行时会根据选择执行对应操作。这种分支结构让循环显得智能，因为大型语言模型（LLM）在选择采取何种行动。四个分支如下：

• 最终答案：模型生成相当于对原始任务的完整回复。运行时将其视为循环的退出信号，返回结果并终止流程。

• 工具调用：模型生成指令要求运行时调用特定函数并传入特定参数。运行时执行工具，捕获返回结果，将其追加到对话状态中，并将控制权交还模型以继续循环。

• 交接：模型判定当前任务应由其他代理处理，通常是拥有独立提示词和工具集的专业代理。运行时切换执行代理，将相同状态传递给新代理，循环在新身份下继续。

• 持续思考：模型生成仅包含思考过程的推理步骤。运行时捕获该思考，将其反馈至状态中并重新运行模型。这个分支在即将看到的 ReAct 风格实现中最为常见。

OpenAI 的代理 SDK 将前三个分支定义为循环的一等行为。第四个分支更多是特定提示词写法的属性，而非独立的代码路径。

ReAct

ReAct 是代表推理（Reasoning）加行动（Acting）的提示模式。该模式要求模型在同一个响应中交替进行推理步骤和行动步骤，使模型能够思考该做什么、执行操作、观察结果并进行调整。

ReAct 追踪记录看起来像结构化日志。模型先生成思考，然后执行动作，接着从运行时接收观察结果，再生成新思考，如此往复，直到得出最终答案。

设想一个处理客户支持的代理：

• 用户询问最近订单的状态。

• 模型首先生成思考，推理需要找到该订单且应查询订单服务。

• 然后通过调用 get_recent_order 函数并传入用户ID执行操作。

• 运行时执行调用并反馈观察结果，告知模型订单编号为9152，下单日期为5月14日。

• 模型生成新思考，推导出现在需要查询该特定订单的运输状态。

• 调用 get_shipping_status 函数并传入订单ID。观察结果返回显示订单正在运输中，预计5月29日送达。

• 此时模型已获得所需信息，生成最终答案向用户总结订单状态。

请参见下图：

从该流程中需要考虑的两点如下：

• 首先，每个动作都基于观察，这使前一部分提到的闭环概念变得具体而明确。

• 其次，推理步骤是真正执行工作的部分，因为它们决定了模型在已学习内容的基础上，判断下一步采取什么行动是合理的。

ReAct 是实现这一循环的一种方式，目前在我们使用的智能体框架中，这是最常见的一种模式。

安全防护

安全防护应设置在循环与外部世界交互的关键节点上。它们是架构本身的一部分，与循环设计同步进行。

作为参考，OpenAI 的 Agents SDK 文档中定义了三类安全防护，其分类依据是它们在循环中的运行位置。

• 输入防护在循环的第一轮运行，此时智能体的主模型尚未处理任何内容。这是拦截提示注入尝试、违反政策的请求或超出智能体范围的输入的合适位置。常见模式是使用小型快速模型作为防护，这样只有当输入通过验证时，才会调用成本更高的主模型。

• 工具防护围绕每个函数工具的调用进行。工具输入防护在工具执行前运行，可以阻止调用或向模型返回消息。工具输出防护在工具执行后运行，可以在结果返回对话状态前对其进行修改或阻止。工具防护至关重要，因为工具是循环与我们关注的系统交互的途径，这种交互需要监督。

• 输出防护在循环决定终止后、用户看到结果前对最终响应进行处理。它们是政策执行的最后防线，用于拦截敏感数据泄露或智能体应避免以公司名义做出的声明。

结构上的关键点是，安全防护位于循环与外部世界交互的每个接口上。

权衡

将循环控制权交给模型虽然强大，但使用该模式前开发者必须理解其带来的三个成本：

• 错误累积：当步骤串联在一起时，每步的可靠性会显著下降。数学计算并不乐观。如果模型在循环的每一步有 95% 的成功率，那么在十步循环中所有步骤都正确的联合概率约为 60%。扩展到二十步时，联合成功率会降至约 36%。智能体的自主性带来了更高的成本和错误累积风险。编码智能体比开放式任务智能体表现更好的原因在于，测试反馈能提高每步的可靠性，从而缩短必须成功的链式长度。

• 循环的支撑结构：循环的支撑结构与内部模型同样重要。例如，Anthropic 分享了一项内部实验，即使使用 Claude Agent SDK 的前沿模型，也难以仅凭高级提示构建生产级的网页应用。解决方案是增加支撑结构而非使用更优模型。他们构建了初始化智能体（在任何功能开发前列出功能清单）、编码智能体（每会话只处理一个功能）、跨会话传递的进度文件，以及智能体可用来恢复的 Git 历史记录。

• 选错工具：代理往往不是最佳选择。找到最简单的解决方案至关重要，只有在必要时才增加复杂性，有时甚至需要完全避免使用代理系统。工作流能提供可预测性和一致性，而代理虽然灵活，但需要付出延迟、成本和更不可预测的故障表面作为代价。许多问题通过链式处理能更高效地解决。

结论

代理循环位于一个清晰的发展路径的末端。

我们从一个简单的LLM调用开始，该调用接收文本并返回文本。随后我们添加了工具、检索和记忆，从而得到增强型LLM。当单一调用无法满足需求时，我们将其串联成工作流。代理是下一步，是开发者将控制流本身交给模型的阶段。

在循环内部，四个步骤不断重复：模型感知当前状态，对其进行推理，采取行动并观察结果。在每一轮中，模型的输出会从四个分支中选择一个：最终答案、工具调用、交接或继续思考。ReAct是最常见的填充循环的提示模式，其特点是推理与行动交替进行。防护措施存在于循环与外部世界交互的每个节点。

该设计带来了三个实际成本：跨步骤的可靠性累积、生产循环所需的框架支撑，以及是否可以通过工作流更经济地解决问题的疑问。

参考文献：

• Building effective agents — Anthropic Engineering
• Effective harnesses for long-running agents — Anthropic Engineering
• Running agents — OpenAI Agents SDK documentation
• Guardrails — OpenAI Agents SDK documentation
• ReAct: Synergizing Reasoning and Acting in Language Models