Plan-and-Execute
Plan-and-Execute 是先规划后执行：模型先把任务分解成完整的步骤清单，再逐项执行。名字来自 LangChain 2024 年的 agent 模板，但血缘更早，2023 年的 Plan-and-Solve 提示法就验证了显式规划的价值，在十个推理数据集上全面超过 zero-shot CoT。
它的定位一句话能说清：ReAct 是“走一步看一步”，Plan-and-Execute 是“先画地图再走路”。
动机：ReAct 的三个问题
ReAct 每走一步都要完整推理一次，任务一长就暴露三个问题：
- 没有全局视野。 模型每次只看眼前一步，复杂任务里容易跑偏。本想查 A，查到一半被 B 带跑了
- 成本线性涨。 每一步都是一次完整的 LLM 调用，历史上下文越滚越长，Token 消耗随步数增长
- 容易死循环。 弱模型经常在“再查一次”里绕不出来，任务保持度差
Plan-and-Execute 的解法是把思考和行动解耦：规划集中做一次，执行交给便宜的机制。
三组件架构
Planner-Executor-Replan 循环
- Planner：把任务分解成有依赖关系的子任务清单，这一步用推理能力最强的模型。计划的质量决定整个任务的上限
- Executor：按清单逐项执行，每项内部可以是一个小型 ReAct 循环，也可以直接调工具。执行器只做执行不做全局推理，所以可以用便宜快的小模型
- Replanning：执行中发现前提不成立、工具返回异常，带着中间结果回到 Planner 修订剩余计划。没有重规划的 Plan-and-Execute 就是一条道走到黑
和 ReAct 的关系：同一个刻度盘
这两个范式经常被当成二选一的竞争方案，其实它们是同一个刻度盘的两端。刻度是“在执行前承诺多少”：
- ReAct 每步重新决策，承诺为零，适应性最强
- Plan-and-Execute 开局承诺全局，换来成本可预测和并行能力
- 生产里的 plan-and-execute 系统几乎都带 re-plan 步骤，执行一批、观察、修订计划。把批次缩到一步，它就变回 ReAct
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 规划方式 | 边走边想 | 先想全再走 |
| LLM 调用 | 每步都推理，次数多 | 规划一次，执行用小模型 |
| 全局视野 | 无，容易跑偏 | 有，任务保持度强 |
| 成本 | 随步数线性涨 | 可预测 |
| 并行 | 无并行概念 | 无依赖子任务可并行 |
| 灵活性 | 高，随时改道 | 中，要触发重规划 |
| 失败模式 | 跑偏、死循环 | 计划僵化、重规划退化 |
选型没有标准答案，答案在任务形状里：下一步依赖上一步结果、需要边做边探索的任务用 ReAct；步骤多、结构可预判、追求成本可预测的任务用 Plan-and-Execute。生产系统通常加一个便宜的任务分类器做路由，简单任务走 ReAct，复杂多步任务走 Plan-and-Execute。一句话概括取舍：ReAct 以每步推理的代价换适应性，Plan-and-Execute 以刚性的代价换成本可预测。
两个变体
ReWOO（Reasoning Without Observation）。规划阶段只调用一次大模型，计划步骤用占位符变量表达依赖：
#E1 = Search["LangGraph latest version"]
#E2 = Search[f"LangGraph {#E1} changelog"]执行时把变量替换成真实结果，后续步骤不再重新生成上下文。执行阶段零 LLM 调用，是三种方案里最省 Token 的。
LLMCompiler。把规划建模成有向无环图（DAG），三个组件分工：Planner 流式生成任务及其依赖，Task Fetching Unit 在前置依赖完成的那一刻立即调度后续任务，Executor 并发执行，Joiner 汇总结果或触发重规划。论文报告相对 ReAct 延迟最高提速 3.7 倍、成本最高节省 6.7 倍、准确率提升约 9 个百分点。它把“哪些任务能并行”从模型的手里接过来，变成编译器的活。
生产实践
- 规划用强模型，执行用便宜模型。 Planner 决定上限，Executor 只跑不思考。预算敏感时这是最划算的分工
- 计划是审批点。 计划本身就是天然的 HITL 闸门：先给人看计划，确认后再执行。高风险任务在计划确认和关键步骤之间插入人工确认
- 计划要校验。 Executor 启动前用一个 plan validator 检查计划本身是否合理，拦住 Planner 幻觉出的步骤，而不是等到执行到一半才发现
- 重规划要有边界。 Replan 逻辑写不好会退化成“反复重排计划却不干活”，给重规划次数设上限，超过就交给人
落地案例都是这个模式：Claude Code 的 Plan Mode 先出计划再执行，各类 Deep Research 产品规划搜索路径再逐路深入，Devin 把软件工程工单分解成几百步的计划，内部用 ReAct 式执行加 Reflexion 式质检。
面试追问
- ReAct 和 Plan-and-Execute 怎么选？ 它们是同一个刻度盘的两端，刻度是执行前承诺多少。任务短、路径不确定用 ReAct；步骤多、可预判、要成本可预测用 Plan-and-Execute。生产通常加任务分类器路由，或外层规划、内层 ReAct
- 规划器和执行器能用同一个模型吗？ 可以，但生产建议分工：Planner 用推理强的模型，Executor 用便宜快的模型
- Plan-and-Execute 会不会浪费 Token？ 会。一个只需要一次工具调用的任务，规划本身是浪费的推理。解法是任务分类器把关，简单任务直接走 ReAct
- ReWOO 和 Plan-and-Execute 哪个更省？ ReWOO。它的规划集中在开始阶段一次完成，执行阶段不再调用大模型，Token 消耗更可预测
- 什么情况下 Plan-and-Execute 反而不如 ReAct？ 任务高度探索性、目标模糊、中间结果对后续路径影响大的时候。开放式任务预先规划，计划基本是废纸