考察点
继 ReAct 之后的高频题，考察你是否知道 ReAct「局部贪心」的短板以及对应的解法。追问通常往两个方向走：Replan 机制怎么设计、和 ReAct 怎么选型。面试官想听的是你处理过「计划赶不上变化」这个工程现实。
参考答案
原理：先想清楚再动手
Plan-and-Execute 把 Agent 拆成两个角色：
- Planner（规划器）：拿到任务后一次性生成完整的分步计划，比如「1. 查订单表拿到近 30 天数据；2. 调用统计工具算留存；3. 生成对比图表；4. 写结论」。
- Executor（执行器）：逐条执行计划，每步可以是工具调用，也可以内嵌一个小的 ReAct 循环。
这个思路对应的是 BabyAGI、LangChain 的 Plan-and-Execute 实验链，以及 LangGraph 里的 plan-execute 模板。它解决的是 ReAct 的两个痛点：一是 ReAct 每步都重新读全量轨迹，长任务 token 爆炸；二是 ReAct 只看眼前一步，做到第八步可能已经忘了最初要干嘛，长程任务容易漂移。有了显式计划，执行器每步只需要看「当前步骤 + 必要的前序结果」，上下文小得多，目标锚点也一直在。
关键问题：计划失效了怎么办
这是真实项目里百分之百会遇到的事。比如计划第三步是「调用 A 接口拿库存」，执行时发现 A 接口下线了，后面四步全成了空中楼阁。成熟的方案是引入第三个角色 Replan，几种触发方式：
- 每步执行完检查：把「原计划 + 已完成步骤 + 最新观察」喂回 Planner，问它「计划还有效吗？需要修订吗？」这是 LLMCompiler 和 LangGraph 模板的做法。稳妥但每步多一次 LLM 调用，成本高。
- 失败时触发：只有某步执行抛异常或结果明显偏离预期（比如返回为空）才 Replan。便宜，但可能晚发现——计划在第二步就过时了，第五步才暴雷。
- 混合：失败必触发 + 每 N 步例行检查一次。我在项目里用的是这种，N 取 3 左右，是成本和鲁棒性的平衡点。
Replan 时要给 Planner 明确的约束：已完成的步骤不要推翻重来，尽量在原计划基础上做最小修改，否则会出现「执行五步、重规划、又从头执行」的死亡循环。
进阶：DAG 化和并行
朴素的 Plan-and-Execute 是串行链，但很多计划天然是 DAG——「查 A 库」和「查 B 库」互不依赖，可以并行。LLMCompiler 的思路是让 Planner 输出带依赖标注的任务图，调度器按拓扑序执行，无依赖的任务并发跑。这一步能把多分支任务的端到端延迟砍掉一半，但调度复杂度上来了，除非延迟敏感，否则先把串行版做稳再说。
和 ReAct 的选型对比
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 规划粒度 | 每步现想 | 开局全局规划 |
| Token 消耗 | 随步数线性膨胀 | 规划一次贵，执行便宜 |
| 长程任务 | 易漂移 | 目标锚定好 |
| 环境突变 | 每步自适应，天然抗变化 | 依赖 Replan，反应滞后 |
| 典型场景 | 探索型、路径未知 | 流程型、可分解 |
经验法则：任务能提前画出步骤骨架的用 Plan-and-Execute；必须边走边摸的（比如不熟悉的代码库排障）用 ReAct；超长任务用「Plan-and-Execute 做骨架、每个节点内嵌 ReAct」的两层结构，这也是很多 Deep Research 类产品的实际架构。
可能的追问
- 「Planner 生成的计划质量不行怎么办？」 规划能力主要靠模型本身，工程上能做的是：给 Planner 用更强的模型、执行器用便宜模型；计划落成结构化 JSON 先校验再执行；给几个同类任务的历史成功计划做 few-shot。
- 「Replan 会不会陷入无限重规划？」 会，所以要给 Replan 也设次数上限（我一般设 3 次），超过就放弃当前计划整体失败退出，转人工或走兜底流程。
- 「和 Workflow 比呢？」 Workflow 的计划是人写的、编译期固定的；Plan-and-Execute 的计划是模型运行时生成的。前者可审计可测试，后者灵活但不确定。