ReAct 与 Plan-and-Execute：Agent 规划模式如何选

两种规划方式解决的是不同问题

Agent 收到复杂目标后，通常需要决定“下一步做什么”。最常见的两类模式是 ReAct 与 Plan-and-Execute。它们没有绝对优劣，区别在于决策发生的时机，以及系统愿意为全局规划支付多少成本。

ReAct 可以理解为“观察一步，思考一步，行动一步”。模型读取当前状态，选择一个工具，拿到结果后再继续判断。它适合信息不完整、环境变化快、每一步都可能改变后续路径的任务。

Plan-and-Execute 则先生成一个相对完整的计划，再由执行器逐项完成。它适合目标稳定、步骤依赖清楚、需要提前估算资源或向用户展示进度的任务。

ReAct：灵活，但容易走弯路

一个简化的 ReAct 轨迹如下：

目标：定位线上订单失败的原因
观察：只有错误时间和订单号
动作：查询订单日志
观察：支付回调超时
动作：查询支付服务指标
观察：特定区域延迟升高
动作：查询该区域网络事件
观察：运营商链路抖动
结论：给出证据和处置建议

它的优势是每一步都利用最新信息，不需要在一开始假装知道完整路径。工具返回意外结果时，Agent 可以立即换方向。这非常适合排错、研究和开放式数据探索。

代价也很明显。模型每一步都重新决策，容易重复查询、忘记原目标，或者在低价值分支上耗尽预算。解决办法不是把 Prompt 写得更长，而是让控制器维护结构化状态：已验证假设、已调用工具、未解决问题和剩余预算。相同参数的只读调用可以直接命中缓存；连续多步无新增信息时，控制器应触发重新规划或停止。

Plan-and-Execute：可预测，但计划会过期

Plan-and-Execute 通常先产生一个带依赖关系的计划：

[
  {"id": "s1", "task": "读取事故时间窗口内的订单日志"},
  {"id": "s2", "task": "按错误码聚合", "dependsOn": ["s1"]},
  {"id": "s3", "task": "关联支付指标", "dependsOn": ["s2"]},
  {"id": "s4", "task": "形成结论并引用证据", "dependsOn": ["s2", "s3"]}
]

计划显式化以后，系统可以并行执行无依赖步骤，预估工具调用数量，也可以让人工在高风险节点前审批。长周期任务尤其受益，因为进度不再藏在一段对话里。

但初始计划只是基于有限信息的假设。真实环境里，第一步结果可能让后续三步全部失效。如果执行器机械地跑完整个旧计划，只会稳定地产生错误。因此计划必须可版本化，每个步骤执行前检查前置条件，出现关键新事实时允许重新规划。

选择模式的四个判断维度

第一是环境可预测性。读取固定目录、生成迁移方案等任务结构较稳定，适合先规划；线上排错、网页研究的路径高度依赖实时结果，更适合 ReAct。

第二是错误代价。涉及外部发送、资金或生产写入时，应先产生可审查计划，并在真正执行前设置审批点。只读查询可以给 ReAct 更大自由。

第三是任务长度。三五步以内的任务，用完整规划可能徒增一次模型调用；几十步、跨小时运行的任务则需要计划、检查点和依赖管理。

第四是并行价值。如果子任务可以独立完成，计划能暴露并行机会。如果每一步都依赖前一步观察，并行化只是表面上的快。

更实用的是混合模式

生产系统常用“粗计划 + 局部 ReAct”。规划器先定义阶段和完成条件，执行器在每个阶段内部自由选择少量工具：

阶段一：收集证据
  - 局部 ReAct，最多 6 次只读工具调用
阶段二：验证假设
  - 必须产生至少两类独立证据
阶段三：形成交付物
  - 按固定模板生成，并通过格式验证

这种模式保留全局可见性，又允许局部适应环境。重新规划也不应该由模型随意触发，可以定义明确条件：关键前提不成立、连续两步无进展、预算消耗超过阈值，或执行结果产生新的必选任务。

规划输出也需要 Schema

不要让规划器只返回自然语言列表。一个可执行计划至少应包含步骤 ID、目标、依赖、允许的工具、完成条件、风险等级和预估成本。执行器只接受通过 Schema 校验的计划；不合法时要求规划器修复结构，而不是猜测文本含义。

同样，步骤状态应明确区分 pending、running、blocked、failed 和 completed。completed 只能由验证器写入，模型最多提出完成申请。被阻塞的步骤需要记录缺少的输入，避免重试时重复消耗。

一个简单选择原则

当下一步强烈依赖未知观察时，用 ReAct；当任务可以提前描述、需要审计或可以并行时，用 Plan-and-Execute；当任务既长又不确定时，用分阶段计划包住局部 ReAct。

无论选择哪一种，可靠性都来自循环外部的约束：显式状态、步骤预算、工具权限、结果验证和失败恢复。规划模式只是决策策略，不是替代工程控制的魔法。