【第一部分：认识 Agentic AI】4. 智能体的工作循环——从 ReAct 到 Plan-Execute

很多人第一次接触 AI Agent 时，会把注意力放在 Prompt、模型和工具调用上。

于是，一个最常见的理解是：

给模型一段系统提示，再提供几个工具，它就成为了 Agent。

这种理解只解释了 Agent"拥有什么"，却没有解释 Agent"如何工作"。

真正让大模型从一次性内容生成器，变成能够持续执行任务的智能体，是围绕目标不断运行的执行循环：

模型、工具、记忆和规划都被放在这个循环中使用。

因此，理解 Agent 的关键，不是先记住某个框架的 API，而是理解：

Agent 如何在一次次"决策—行动—观察"中推进任务。

一、从一次生成到持续执行：Agent Loop 的基础形态

普通大模型应用通常采用一次性调用：用户输入 → 模型生成 → 返回答案。这种方式适合摘要、翻译、改写和简单问答。

但当任务需要查询外部数据、执行多个步骤，或者根据中间结果不断调整时，一次模型调用通常不够。例如，用户要求"分析一个项目的主要性能瓶颈，并给出可验证的优化方案"，智能体可能需要：读取项目结构 → 检查配置 → 分析日志 → 运行性能工具 → 定位异常模块 → 提出优化方案 → 修改代码或参数 → 重新执行测试 → 比较优化前后的结果。整个过程不可能通过一次 Prompt 稳定完成。

它需要在执行过程中不断回答三个问题：

这三个问题构成了 Agent Loop 的核心。

最容易理解的 Agent 循环，可以概括为 Reason → Act → Observe：

随后，Agent 再次推理：Reason → Act → Observe → Reason……

这个循环看似简单，却完成了一个重要变化：

大模型不再只根据最初输入生成结果，而是可以根据外部世界的变化持续调整行为。

例如，一个文档分析 Agent 查询知识库后发现资料不足，它可以继续搜索；如果发现两份资料相互冲突，它可以进一步验证；如果无法确定用户真正需要什么，它还可以暂停执行并请求澄清。

因此，Agent 的智能并不只体现在单次推理能力上，也体现在能否正确利用观察结果更新下一步行动。

二、三种核心运行模式：ReAct、Plan-and-Execute 与 Reflect

2.1 ReAct：推理与行动交织

ReAct 是 Agent 领域最经典的运行模式之一，它将 Reasoning 和 Acting 交织在同一条任务轨迹中，典型过程为：

思考当前问题 → 选择行动 → 调用工具 → 观察返回结果 → 更新判断 → 继续或结束。

ReAct 的重要价值，是将原本相互分离的"推理"和"行动"组合起来：推理帮助模型跟踪和调整任务计划，行动则帮助模型获取外部信息、验证事实并减少仅依赖内部知识产生的错误。

例如，一个 Agent 需要回答某家公司最新产品的兼容性情况，它不会直接依靠模型记忆生成答案，而是：判断需要最新资料 → 调用搜索工具 → 打开官方文档 → 读取版本说明 → 对照用户环境 → 生成有依据的结论。

ReAct 的优点是灵活。 Agent 不需要提前知道全部步骤，可以根据每次观察结果决定下一步。

缺点同样明显： 容易陷入重复搜索；长任务中可能忘记整体目标；每一步都调用模型，成本较高；局部决策合理但整体路径未必最优；终止条件不清晰时可能过早结束或无限循环。

因此，ReAct 更适合探索性较强、步骤无法完全提前确定的任务。

2.2 Plan-and-Execute：先拆任务，再逐步执行

当任务较长、子任务较多时，只依赖即时 ReAct 容易出现"边走边看，但没有全局路线"的问题。

Plan-and-Execute 将任务分为两个主要阶段：制定计划（模型先分析目标，拆分出子任务）→ 执行计划（执行器依次处理各子任务并收集结果）。

例如，完成一份竞品分析报告：明确对比范围 → 收集产品资料 → 整理功能信息 → 整理价格与部署方式 → 验证信息时效性 → 完成横向比较 → 生成结论。

生产环境中的 Plan-and-Execute 通常演变为动态规划循环：

制定初步计划 → 执行部分任务 → 检查结果与状态 → 必要时调整计划 → 继续执行。

2.3 Plan–Execute–Reflect：执行之后增加检查

当 Agent 能够规划和执行后，另一个问题随之出现：Agent 如何知道自己做得对不对？

Plan–Execute–Reflect 在规划和执行之外，加入了反思或审查阶段：

Plan（制定计划）→ Execute（执行任务）→ Reflect（检查结果、发现问题并提出修正）→ Replan（必要时重新规划）。

例如，一个 Coding Agent 修改代码后，应该：运行构建 → 执行单元测试 → 检查代码差异 → 确认是否影响其他模块 → 根据错误继续修复。

这里的 Reflect 不应只是让模型说一句"请检查上面的答案"。更可靠的反馈来源包括：

现代 Agent 中的 Reflect 更接近"反馈驱动的质量闭环"，而非简单的模型自我反思。

但反思并非越多越好。每次行动后都让模型重复审查，可能带来 Token 消耗增加、响应时间变长、正确结果被反复修改、多轮反思形成新错误、系统陷入"分析而不行动"等问题。反思应有明确的触发条件： 工具执行失败时；结果与计划不一致时；置信度低于阈值时；输出未通过规则校验时；即将执行高风险操作时；到达阶段性检查点时。

三、进阶形态：事件驱动与状态机驱动

3.1 Event-Driven Agent：不一定要从聊天框启动

早期 Agent 大多由用户发送消息触发（用户提问 → Agent 执行），但在企业环境中，很多 Agent 由事件触发：

Event-Driven Agent 的基本流程：

事件发生 → 事件路由与过滤 → 加载相关状态 → Agent 分析事件 → 调用工具处理 → 更新业务状态 → 产生新事件或通知。

例如，代码仓库出现新的 Pull Request 后触发审查 Agent：读取代码变更 → 分析影响范围 → 运行静态检查 → 识别潜在问题 → 生成审查意见 → 将结果写回代码平台。

这种模式下，Agent 不再只是聊天助手，而是业务系统中的一个异步执行节点。但同时也带来新的工程问题：重复事件如何处理；任务是否幂等；多个事件如何排序；执行失败如何重试；长任务如何保存状态；多个 Agent 是否会相互触发形成循环。这说明 Event-Driven Agent 的关键，不只是模型推理，而是事件、状态和任务系统的整体设计。

3.2 状态机驱动：用确定性结构约束不确定性模型

完全自由的 Agent Loop 很灵活，但也可能不可预测。在真实业务系统中，一种越来越常见的方式是：

用状态机控制主流程，只在需要判断的节点调用模型。

例如，一个需求分析 Agent：接收需求 → 提取关键信息 → 检查信息是否完整，不完整则向用户补充提问，完整则生成需求条目 → 执行质量检查 → 人工确认并输出。

在这个流程中： 状态迁移由程序控制；模型只负责部分判断与生成；每个节点有明确输入和输出；失败可定位到具体步骤；任务可暂停和恢复。

LangGraph 等运行时将 Agent 工作流建模为由 State、Node 和 Edge 构成的图，其状态持久化机制可以在执行过程中保存检查点，使任务在暂停、进程中断或人工审批后继续运行，而不需要从头开始。

状态机驱动并不意味着 Agent 失去了自主性。 它只是将自主性限制在特定节点中：

• 程序决定：现在处于哪个阶段、允许进入哪些状态、哪些步骤必须执行
• 模型决定：如何理解输入、选择哪个工具、如何处理非结构化信息

这种"确定性外壳＋概率性决策"的组合，往往比完全自主循环更适合企业场景。

3.3 六种模式之间的关系速查

这些模式并不互相取代，而是适用于不同复杂度的任务：

现实中的 Agent 通常会混合使用这些模式。 因此，不必问哪一种模式"最先进"，更有价值的问题是： 任务中的哪些步骤需要模型自主判断，哪些步骤应该由程序明确控制？

四、运行时升级：从模型循环到完整执行系统

早期 Agent 的实现通常很简单：调用模型 → 如需工具则执行 → 再调用模型 → 直到返回答案。OpenAI Agents SDK 至今仍保留了这一核心循环。

但现代 Agent 的运行循环已经不再只有模型和工具。 它还包含：状态持久化、任务暂停与恢复、人工审批、模型切换、子 Agent 移交、Guardrails、事件触发、超时与重试、完整执行追踪。

OpenAI Agents SDK 将工具调用、Handoff、Guardrails 和 Tracing 纳入统一运行体系，并支持敏感工具调用暂停、人工批准后序列化状态并恢复任务。

因此，今天再谈 Agent Loop，不能只画成一个模型和工具之间的箭头。更加完整的结构是：

目标进入运行时 → 运行时加载状态和上下文 → 模型决定下一步 → 执行工具、工作流或任务移交 
→ 环境产生观察和反馈 → 运行时更新状态并执行安全检查 → 继续、暂停、恢复、失败或结束

Agent Loop 正在从一个 Prompt 技巧，变成一套完整的运行时机制。

五、长任务的关键支撑：Harness 与状态管理

一个短任务可以一直依靠上下文窗口运行。但任务持续几十分钟甚至跨越多个会话后，会出现：对话历史越来越长；模型忘记最初目标；已完成任务被重复执行；进程中断后无法恢复；新会话不知道之前做了什么；工具结果和文件状态不一致。

因此，长任务 Agent 需要 Harness 保存： 任务目标、当前计划、已完成步骤、待处理问题、关键文件、测试结果、失败原因、下一步行动。

Anthropic 在长时间 Coding Agent 实践中发现，Harness 的设计会显著影响 Agent 是否能够持续推进任务；其方案通过任务清单、阶段性交付物和跨会话上下文传递，让 Agent 在新的上下文窗口中继续工作。

这说明：

长任务的连续性不能只依赖模型记忆，而应由外部状态和执行系统保证。

六、一个完整案例：文档转换故障分析 Agent

假设一个企业文档转换服务出现故障：某个大型 PPTX 文件转换 PDF 时内存持续升高，最终任务失败。一个纯 ReAct Agent 可能会不断读取日志、搜索代码和尝试命令。

更可靠的循环设计如下：

这个例子同时使用了 Event-Driven、状态机、Plan-and-Execute、ReAct、Reflect、Human-in-the-Loop 多种模式。真实 Agent 很少只属于一种模式。

基于任务特征选择模式的参考：

最重要的原则是： 不要把所有决策都交给模型，也不要把所有流程都提前写死。确定性强的步骤交给代码和状态机，需要理解、判断和动态选择的步骤交给模型。

七、传统开发人员应该如何选择循环？

可以使用一个简单判断方法：

如果一个任务同时具备多个特征，可以混合使用。

最重要的原则是：

不要把所有决策都交给模型，也不要把所有流程都提前写死。

• 确定性强的步骤交给代码和状态机
• 需要理解、判断和动态选择的步骤交给模型

八、三个容易被忽视的问题

容易被忽视的三个问题

1. 终止条件 很多 Agent 只定义了"如何继续"，却没有定义"什么时候结束"。可靠的结束条件包括：任务达到明确完成标准；工具返回所需证据；测试全部通过；用户批准结果；达到最大步骤或成本预算；发现任务无法继续。没有结束标准，Agent 就容易过早返回或无限循环。

2. 状态是否可信 模型生成的任务摘要，不一定等于真实系统状态。例如，模型声称文件已经生成，但文件系统中可能并不存在。关键状态应来自数据库、任务系统、文件系统、工具返回、外部业务接口。模型负责解释状态，而不是凭空定义状态。

3. 反馈是否有效 "请检查你的答案"并不是高质量反馈。有效反馈应明确指出：哪里失败；为什么失败；预期结果是什么；是否允许重试；下一步可以采取什么行动。Agent 的可靠性，很大程度上取决于环境能否提供清晰、可验证的反馈。

总结

从 Reason–Act–Observe 到 ReAct，再到 Plan-and-Execute、反思、事件驱动和状态机，表面上看是不同的 Agent 模式。但它们解决的其实是同一个问题：

如何让模型在不断变化的环境中持续推进任务，而不是只生成一次答案。

Agent 的核心不是 Prompt。 Prompt 只是每一次模型调用的输入之一。

真正决定 Agent 能否工作的是：它如何读取状态；如何选择行动；如何获取反馈；如何修改计划；如何保存进度；如何判断任务已经完成。

可以用一句话概括 Agent 的本质：

Agent 是一个由目标驱动、以状态为基础、通过行动和反馈不断推进的运行循环。

未来模型会越来越强，单次推理也会越来越完整。但模型能力提升并不会让 Agent Loop 消失。相反，模型越有能力采取行动，越需要一个可靠的运行时来管理状态、工具、权限、反馈和终止条件。

对于传统开发人员来说，理解 Agent Loop 的最好方式，并不是把它想象成一个不断思考的数字人。而是把它看成：

状态机、工作流、事件系统与大模型决策能力结合后形成的新型软件运行机制。

上一篇回顾：

【第一部分：认识 Agentic AI】3.AI Agent 完整组成架构：5 层结构 + 11 个组件，从最小循环到工程化系统-腾讯云开发者社区-腾讯云

下一篇将进一步介绍：

【第二部分：大模型应用开发基础】开发 Agent 前需要掌握哪些大模型基础

​