从 ReAct 到 Plan-and-Execute：AI Agent 推理架构的理解与选择

最近在做一个企业办公 Agent 项目，过程中花了不少时间研究 Agent 的推理架构该怎么选。市面上最主流的两种模式——ReAct 和 Plan-and-Execute——看起来都能用，但深入了解后我发现它们的设计哲学完全不同，适用场景也差异很大。

一、先说一个最基本的问题：Agent 为什么需要"推理"？

LLM 本身就能回答问题，为什么还要给它加推理框架？

因为 LLM 只会"说"，不会"做"。当用户说"帮我创建一个明天截止的任务"，LLM 可以生成一段漂亮的文字描述应该怎么做，但它没有手去操作数据库。Tool（或者叫 Skill）就是给 LLM 装上了手脚——它可以调用接口、查询数据、执行操作。

但问题来了：LLM 什么时候该用哪只手？先用左手还是右手？用完之后下一步该干嘛？

这就是推理框架要解决的问题。它本质上是一套"决策流程"，告诉 LLM 如何思考、何时行动、怎么判断任务完成了没有。

ReAct 和 Plan-and-Execute 就是两套不同的决策流程。

二、ReAct：边想边做的演员

ReAct 的全称是 Reasoning + Acting，来自 2022 年 Google 和普林斯顿大学联合发表的论文（Yao et al., 2022）。

它的核心思想用一句话概括：让 LLM 交替进行"思考"和"行动"，每做一步就停下来想想，然后决定下一步。

工作流程

ReAct 的运行方式像一个循环：

思考 → 行动 → 观察 → 思考 → 行动 → 观察 → ... → 完成 

拿一个具体的场景来说，用户问：“张三这周有多少个未完成的任务？”

• 思考：用户要查张三的任务，我需要先知道张三的用户 ID。
• 行动：调用用户查询工具，搜索"张三"。
• 观察：返回了 user_id = 12345。
• 思考：好，现在我有了 ID，需要查他本周的未完成任务。
• 行动：调用任务查询工具，参数是 user_id=12345, status=未完成, 时间=本周。
• 观察：返回了 8 个任务。
• 思考：信息够了，可以回答了。
• 输出：“张三这周有 8 个未完成的任务。”

整个过程就像一个人在自言自语——“我现在知道了什么？还缺什么？下一步该做什么？”——每一步都是临时决定的。

为什么 ReAct 能流行起来

ReAct 的优雅之处在于简单。它不需要任何复杂的架构设计，只需要在 Prompt 里告诉 LLM 三件事：

1. 你可以思考（Thought）
2. 你可以使用这些工具（Action）
3. 工具会给你返回结果（Observation）

LLM 天然就会按照这个模式运行。这也是为什么几乎所有 Agent 框架的入门示例都是 ReAct——它的概念直觉、实现简单、容易理解。

而且 ReAct 的适应性很强。如果某一步工具调用失败了，LLM 可以立即反应："这个工具报错了，让我换一种方式试试。"这种灵活性是其他架构不容易做到的。

ReAct 的致命缺陷

但当我真正在项目中使用 ReAct 时，问题开始暴露。

第一个问题：它没有全局视野。

ReAct 是"走一步看一步"的。它优化的是"下一步做什么最好"，而不是"整个任务怎么做最优"。这就像一个人在迷宫里，每到一个路口只看眼前的三条路选一条，从不翻看地图。

当任务简单时（比如"查一下张三的任务"），这没有问题——两三步就完事了，不需要地图。但当任务复杂时（比如"生成本周的团队工作总结"），ReAct 可能走出一条非常曲折的路径：先查了任务列表，然后突然想起还要查项目进度，查完项目进度又忘了还要统计延期情况，最后生成的总结遗漏了关键信息。

第二个问题：上下文污染。

ReAct 的每一步"思考"都需要把之前所有的历史（包括思考过程、工具调用、返回结果）全部发送给 LLM。执行 5 步之后，上下文里充斥着各种中间数据、报错信息、调试噪声。LLM 的注意力被这些无关信息稀释，推理质量明显下降。

这在业界有个形象的说法叫"上下文越长，模型越笨"。我在实际测试中观察到，同一个 LLM 在 3 步以内的任务上表现优秀，但超过 6 步后，它开始"忘记"最初的目标，或者在几个相似的状态之间反复跳转。

第三个问题：成本失控。

每一步"思考"都是一次完整的 LLM 调用，而且每次调用都要携带越来越长的历史上下文。一个 10 步的任务，到第 10 步时，prompt_tokens 可能已经是第 1 步的 5 倍以上。更要命的是，这些 token 大部分花在了"让 LLM 重新理解之前发生了什么"上——这是纯粹的浪费。

第四个问题：链式崩塌。

这是知乎上有人提到的一个很直观的数学问题。假设每一步的成功率是 95%（已经很高了），连续 10 步全部成功的概率是 0.95 的 10 次方，等于 59%。也就是说，即便每一步都很靠谱，走完一个 10 步任务的成功率还不到六成。一旦中间某一步产生了微小的幻觉（LLM 编造了一个不存在的参数），后面所有步骤都会基于这个错误继续执行——雪球越滚越大。

三、Plan-and-Execute：先计划再行动的指挥官

Plan-and-Execute 的思路完全不同：先想好要做什么，再一步一步去做。

它的思想受到了 Wang et al., 2023 的论文"Plan-and-Solve Prompting"的启发——该论文证明了让 LLM "先规划再解决"能显著提升推理准确率。但 Plan-and-Solve 本身只是一种提示词技术（单次 LLM 调用，无工具），而 LangChain 团队将"先规划再执行"这个理念重新设计为完整的 Agent 架构——独立的 Planner、Executor、Replanner 节点，支持多模型协作和工具调用——并内置到了 LangGraph 框架中。

工作流程

Plan-and-Execute 把一次任务拆成三个角色：

Planner（规划者）→ Executor（执行者）→ Replanner（重规划者） 

还是那个场景：“生成本周的团队工作总结”。

Planner 先思考全局，生成一个计划：

步骤 1：查询团队所有成员的本周任务列表 步骤 2：统计每个成员的完成率 步骤 3：查询延期未完成的任务 步骤 4：汇总以上数据，生成工作总结 

Executor 拿到计划后，逐步执行：

• 执行步骤 1：调用任务查询工具 → 拿到任务列表
• 执行步骤 2：调用统计工具 → 拿到完成率
• 执行步骤 3：调用延期查询工具 → 拿到延期列表

Replanner 在执行过程中或执行完毕后检查：

• 原始计划的步骤都完成了吗？
• 执行结果和预期一致吗？需要调整计划吗？
• 如果某一步失败了，怎么修正后续步骤？

这三个角色背后的设计哲学

Planner 是"大脑"。它只负责战略决策——把一个复杂的需求拆解成可执行的步骤序列。它不关心每一步具体怎么实现，只关心"应该做哪些事、按什么顺序做"。

Executor 是"手脚"。它拿到一个具体的步骤描述（比如"查询本周延期任务"），然后选择合适的工具去执行。它不需要知道全局，只需要把当前这一步做好。

Replanner 是"复盘者"。它站在全局视角，回顾已经完成的步骤和结果，判断是否需要调整后续计划。如果步骤 2 的结果显示某个成员一个任务都没有（可能是数据异常），Replanner 可以插入一个"确认该成员是否在职"的步骤。

这种分离带来的好处是深刻的。

为什么 Plan-and-Execute 在复杂任务上更强

第一，它有全局视野。

Planner 在开始执行之前就已经想好了整个路径。这意味着它不会像 ReAct 那样走到第 5 步突然发现"哦，我忘了还要查延期情况"。所有需要做的事情在一开始就被识别出来了。

用之前那个迷宫的比喻：Plan-and-Execute 是先看地图规划好路线，再沿着路线走。即使走的过程中发现某条路不通（工具调用失败），Replanner 也会重新规划路线而不是瞎撞。

第二，上下文更干净。

这是我认为最被低估的优势。

在 ReAct 中，执行到第 8 步时，LLM 需要处理一个巨大的上下文——包含前 7 步的所有思考过程和工具返回值。但在 Plan-and-Execute 中，Executor 在执行第 3 步时，它的上下文只包含"当前步骤的描述"和"必要的上下文信息"，不需要看到步骤 1 和步骤 2 的完整执行细节。

信息是隔离的。每个步骤的执行环境是相对干净的。这大幅减少了"上下文污染"问题。

第三，成本更可控。

Planner 只调用一次（或者加上 Replanner 的几次），它消耗的 token 是固定的。Executor 的每次调用只需要处理当前步骤的少量上下文。相比 ReAct 那种"每一步都要重新发送完整历史"的模式，Plan-and-Execute 的总 token 消耗通常低 40-60%。

而且，由于 Executor 的任务更简单（只需要根据步骤描述调用正确的工具），理论上可以用更小、更便宜的模型来执行，进一步降低成本。虽然在实际项目中出于简化考虑，我选择了全部使用同一个模型，但这个优化空间始终保留着。

第四，可追溯、可审计。

Plan-and-Execute 天然产出一份"计划书"。这在企业场景中非常有价值——用户甚至可以在 Agent 开始执行之前审核计划：“你打算这么做？好，我同意"或者"不对，你不需要查项目进度，直接查任务就行”。

ReAct 没有这个能力。它的推理过程是隐式的、即兴的，你只能事后从日志里拼凑出它的决策路径。

第五，链式崩塌被缓解。

Replanner 的存在让系统具备了"自我纠错"的能力。即使步骤 3 执行失败或者返回了异常结果，Replanner 可以选择跳过、重试或者修改后续计划。这打断了错误累积的链条——不再是"一步错、步步错"，而是"一步错、纠正、继续"。

UC 伯克利的研究显示，通过 Plan-and-Act 框架（Plan-and-Execute 的增强版），在长任务上的规划能力提升了 54%。

四、Plan-and-Execute 不是银弹

公平起见，我也要说说它的不足。

对简单任务过度设计。

如果用户只是说"帮我建个任务"，Plan-and-Execute 会先规划（“步骤 1：创建任务”），再执行，再检查——对于一个一步就能完成的操作，这多出了两次 LLM 调用（规划 + 检查），纯粹浪费。

我的解决方式是在 Planner 中加入判断：如果任务足够简单，直接生成一个单步计划甚至跳过规划阶段。

规划质量依赖模型能力。

Planner 需要很强的任务分解能力。如果模型的推理能力不够，生成的计划可能本身就有问题——步骤遗漏、顺序错误、粒度不当。而且这种错误比 ReAct 的错误更隐蔽：ReAct 的错误通常在执行中就会暴露，但一个"看起来合理但实际上有缺陷"的计划可能执行到最后才发现方向错了。

这也是为什么 Planner 必须用最强的模型。规划是整个系统的基石，如果基石有裂缝，上面的一切都不稳固。

适应性不如 ReAct。

ReAct 的"边想边做"让它对意外情况的反应非常快——这一步失败了，下一步立刻换策略。Plan-and-Execute 则需要等到 Replanner 介入才能调整，响应不够即时。对于那些环境高度不确定、每一步的结果都可能彻底改变后续方向的任务，ReAct 可能更合适。

五、真正的智慧：不是选择一个，而是理解何时用哪个

在我的实际项目中，我的结论是：Plan-and-Execute 作为主架构，在 Executor 内部保留 ReAct 的能力。

具体来说：

• 全局层面，用 Plan-and-Execute 管理任务的整体流程
• 每个步骤的执行中，Executor 本身可以是一个轻量的 ReAct Agent——它在执行当前步骤时，可以思考、调用工具、观察结果，如果需要的话甚至可以多步完成一个子任务

这不是我独创的思路。LangGraph 官方的 Plan-and-Execute 示例就是这么做的——Planner 用一个强模型规划全局，Executor 本身就是一个 ReAct Agent 执行每个步骤。

这种混合架构结合了两者的优势：有全局规划的稳定性，也有局部执行的灵活性。