ReAct、Plan and Execute 等 Agent 模式如何选择？

核心回答

我主要看下一步有多依赖新观察、任务是否需要显式维护全局计划，以及延迟和费用预算来选择。

• ReAct 把推理、行动和观察交替起来：根据当前信息选择工具，执行后读反馈，再决定下一步。它适合搜索、排障这类路径难以预先确定的任务，优点是能及时适应新信息；代价是多轮模型与工具往返，长任务也容易重复探索或遗漏整体目标。
• Plan and Execute 先生成可检查的多步骤计划，再由执行器完成子任务，并根据结果判断继续、结束或重规划。它适合目标能拆解、依赖关系较清楚、需要跟踪多项交付的长任务；代价是规划与计划维护本身有开销，初始假设错误时也需要及时调整。

两者可以组合：例如产业调研先规划研究维度和报告交付项，每个维度内部用 ReAct 搜索、读取和补查，再根据执行结果更新计划。显式规划有助于管理全局目标，但不会自动保证更正确、更快或更便宜。如果步骤已经固定，用普通工作流就能完成，也不一定需要再让模型规划。

展开说明

1. ReAct 的关键是让新观察进入下一次决策

一个研搜 Agent 搜到某家企业的新产品后，可能发现问题真正需要比较的是产品发布时间、技术路线或应用场景。它可以据此修改搜索词，再调用工具取证。后一步动作受前一步返回的信息影响，这种反馈循环正是 ReAct 的价值。

ReAct 也可以分解目标、维护计划和跟踪进度；它并不意味着“完全不规划”。与显式 Plan and Execute 的区别，主要在于是否把全局计划作为单独的执行对象来维护，以及规划和执行的职责怎样分配。

工程中，工具执行器要真正调用外部工具，把结果或错误返回给模型；模型自己生成一段“工具已经成功”的文字不算观察。现代 Tool Calling Agent 可以用工具调用消息和工具结果消息实现这个循环，也不要求把完整的内部思考过程展示出来。

2. Plan and Execute 要交付能执行、能验收的计划

一份计划应能回答：子目标是什么，依赖哪些结果，要用哪些输入，预期交付什么，以及怎样才算完成。例如“查最新政策”过于宽泛，可以改成“查找指定行业最近一年的官方政策，输出发布机构、日期、适用对象和原文链接”。

执行器接收当前步骤和必要背景，调用工具或运行一个 Agent，并返回结果、状态、产物和缺失信息。规划器或评估逻辑再判断剩余步骤是否仍然适用。重规划可以在关键步骤后、发现新约束时或执行失败时触发，不必每次工具调用后都重新生成整份计划。

下面是一种带反馈的设计。执行器内部可以使用 ReAct，具体的重规划时机由任务需要决定：

flowchart TD
    P[生成或更新全局计划] --> E[执行待完成子任务]
    E --> V[检查结果与剩余目标]
    V -->|原计划仍适用且预算允许| E
    V -->|需要调整且预算允许| P
    V -->|达到验收条件| F[交付结果]
    V -->|预算耗尽或无法继续| X[返回已有结果与缺口]

计划负责组织目标，执行反馈负责检验假设。若实际资料证明某项比较没有可靠数据，系统应更新后续任务或说明证据缺口，而不是按原清单继续生成看似完整的内容。

3. 用同一个研搜任务判断取舍

假设用户要求“比较机器人产业近期的技术路线和典型应用，并形成一份报告”。

任务开始时，如果连有哪些路线、哪些资料可信都不清楚，可以先用 ReAct 做少量探索，确认范围和信息来源。范围明确以后，再生成研究维度、取证要求和报告结构，让显式计划防止遗漏。各维度中又可能需要边搜边判断，因此局部执行仍可采用 ReAct。

如果用户只要求查询一项已知指标，工具和参数已经确定，直接查询通常更合适；额外调用规划器只会增加步骤。如果是每周固定统计、校验和输出报表，主要依赖已定义的业务规则，固定工作流更容易控制。

并行能力也应按依赖判断。两个研究方向独立时可以并行；必须先获取企业名单再查各企业产品时就有先后顺序。选择 ReAct 或 Plan and Execute 本身，不决定系统必然串行或并行。

4. 选型要用运行结果验证

对同一批任务保留用户目标、工具条件和可比预算，分别观察是否完成要求、事实与引用是否准确、是否重复调用工具，以及总耗时、模型调用数和 Token 费用。对长任务，还要看漏掉多少子目标、重规划是否纠正了错误方向。

Plan and Execute 可能减少大模型反复做全局决策的次数，也可能因计划过细、执行质量不足和反复重规划而更慢。ReAct 可以较早得到局部结果，也可能因搜索无进展持续消耗预算。效果应由任务集验证，不能只按模式名称推断。

两种方式都需要明确的完成条件、最大步数和全局预算。工具参数校验、实际权限和外部操作的幂等由执行层落实；计划可读、轨迹可追踪，有助于发现问题，但不是正确性或安全性的充分保证。

常见追问

Plan and Execute 与 Plan-and-Solve 是一回事吗？

二者都强调先分解再解决，但讨论层次不同。Plan-and-Solve Prompting 通常指在推理中先制定计划再解答，并不天然包含外部工具、执行状态和重规划器。Plan and Execute 更强调显式计划与实际执行过程的分工。读资料时应看具体机制，不能只凭相似名称混用结论。

计划与现实不一致时，应该整体重做吗？

先定位哪项假设失效，以及它影响哪些后续步骤。已完成且依据仍有效的结果可以保留，只重新规划受影响的部分；若用户改变目标或关键前提失效，再扩大调整范围。重规划应带上执行回执和缺失项，否则只是再生成一份未经检验的清单。

短任务用 ReAct、长任务用 Plan and Execute，可以这样分吗？

长度只能作为线索。一个很长但步骤固定的任务适合工作流；一个不长但必须根据环境反馈改变动作的任务可能适合 ReAct。显式规划更有价值的条件是多项子目标、依赖或交付需要持续管理，而不是单纯文字多或耗时长。

对应教程

参考资料