Plan-and-Execute 和 ReAct 的适用场景有什么不同？何时混用

1️⃣ 考察意图

面试官想看你能否区分"先规划再执行"和"边想边做"两种 Agent 范式，并在实际场景中做出正确选型。刁钻点在于：很多人认为 Plan-and-Execute 一定比 ReAct"更高级"，但实际上对于不确定性强、需要探索的任务，Plan-and-Execute 的计划可能完全失效。答好了能展示你对 Agent 规划策略的工程理解，以及"没有最好只有最合适"的架构思维。

2️⃣ 标准答

1. Plan-and-Execute：先规划全局，再逐步执行

核心流程：Planner LLM 接收用户请求，生成完整的步骤列表（如"Step1: 搜索财报 → Step2: 提取关键数据 → Step3: 生成分析报告"）
Executor LLM 逐步执行每个步骤，调用工具或生成文本
如果某步失败或结果偏离预期，可以 Re-plan（重新规划剩余步骤）
优势：全局视角——Planner 能看到任务全貌，避免"走一步看一步"的短视
可审计——计划可以人工审核后再执行，适合高风险场景
并行潜力——无依赖的步骤可以并行执行劣势：
计划可能基于错误假设——如果用户的请求模糊，Planner 生成的计划可能完全偏离
僵化——如果 Step 2 的结果与预期不同，Step 3-5 的计划可能全部失效
延迟——Planning 阶段需要 1 次 LLM 调用（3-5s），加上执行阶段，总延迟较高适用场景：任务步骤可预见、信息充分、需要审计。如数据分析流程（明确知道要先获取数据、清洗、分析、可视化）、ETL 流程

2. ReAct：边执行边思考，动态调整

核心流程：每一步都 Think（推理当前状态）→ Act（选择并执行动作）→ Observe（观察结果），根据观察结果决定下一步。无预定义计划
优势：灵活——每步根据实际观察调整策略，适应不确定性
快速启动——不需要 Planning 阶段，直接开始执行
自然探索——可以"试探性"地调用工具，根据返回值决定是否深入劣势：
短视——只看当前一步，可能选择局部最优但全局次优的路径
步数不可控——没有计划约束，可能走很多弯路（10 步能完成的任务走了 20 步）
难以审计——没有预定义计划，事后难以判断"Agent 是否走了正确的路径" 适用场景：信息不确定、需要探索、任务路径不可预见。如网页浏览（不知道页面结构）、客服对话（用户问题千变万化）、故障排查（需要根据错误信息逐步定位）

3. 混合架构：Plan-then-ReAct

流程：Planner 生成粗粒度计划（3-5 个大步骤，而非详细到每步工具调用）
每个大步骤内用 ReAct 执行——Executor 在步骤内有完全的灵活性，根据工具返回值动态调整
步骤间有"检查点"——完成一个大步骤后，评估结果是否符合预期，决定是否 Re-plan
优势：兼顾全局规划（大方向不偏）和局部灵活（小步可调整）
实现：plan = planner_llm(user_request) # ["收集数据", "清洗数据", "分析趋势", "生成报告"] for step in plan: result = react_executor(step) # 每步用 ReAct 执行 if not is_expected(result, step): plan = replanner_llm(user_request, completed_steps, result)

3️⃣ 答题模板（30 秒电梯版）

"Plan-and-Execute 先全局规划再逐步执行，优势是全局视角+可审计，劣势是计划可能基于错误假设且僵化，适合步骤可预见的场景（数据分析）。ReAct 边想边做动态调整，优势是灵活+快速启动，劣势是短视+步数不可控，适合信息不确定的场景（网页浏览）。生产环境用混合架构——Planner 生成粗粒度计划（3-5大步），每步内用 ReAct 灵活执行，步骤间设检查点决定是否 Re-plan。"

4️⃣ 高频追问 & 应对

追问 1：什么时候需要 Re-plan？怎么判断计划失效了？

三个 Re-plan 触发条件：(1) 工具返回值与预期严重不符——如计划 Step 2 是"从 API 获取 100 条数据"，但 API 只返回了 3 条。用规则检测"返回值是否在预期范围内"；(2) 步骤执行失败超过 2 次——同一个步骤重试 2 次都失败，说明计划可能有问题（如选了错误的工具或错误的参数）；(3) 用户改变了请求方向——用户在执行过程中说"不对，我其实想要的是..."。Re-plan 时需要把已完成步骤的结果作为上下文，避免重复执行。关键：Re-plan 不要太频繁——每次 Re-plan 增加 3-5s 延迟，频繁 Re-plan 等于退化成 ReAct。建议设阈值——整个任务最多 Re-plan 2 次。

追问 2：多 Agent 系统中，Planner 和 Executor 是同一个 LLM 还是不同 LLM？

推荐用不同 LLM。Planner 用大模型（如 GPT-4o，需要强推理能力做全局规划），Executor 用小模型（如 GPT-4o-mini，执行具体步骤不需要全局视角）。理由：(1) Planner 的 prompt 包含完整任务描述和所有可用工具，需要大 context window 和强推理——GPT-4o 在规划质量上比 GPT-4o-mini 高 15-20%；(2) Executor 的 prompt 只包含当前步骤和上一步结果，不需要全局视角——GPT-4o-mini 的执行质量与 GPT-4o 差异 <5%，但成本低 10 倍；(3) 成本优化——Planning 1 次用大模型（0.05），Execution 10 次用小模型（0.05），总成本 $0.10。如果全用大模型则 $0.55。

追问 3：Plan-and-Execute 的计划可以并行执行吗？怎么处理步骤间依赖？

可以并行，但需要依赖分析：(1) 依赖图构建——Planner 生成计划时，标注每个步骤的依赖（如"Step 3 依赖 Step 1 和 Step 2 的结果"）。构建 DAG（有向无环图）；(2) 拓扑排序 + 并行执行——无依赖的步骤并行执行。如 Step 1（搜索新闻）和 Step 2（搜索股价）无依赖，可以并行。Step 3（分析相关性）依赖 1 和 2，等两者完成后执行；(3) 并行度控制——限制最大并行度（如 3），避免同时调用过多 API 触发限流。实测：有依赖的 5 步计划，串行执行 25s，并行执行 12s（2 步可并行）。实现：用 LangGraph 的并行节点或 asyncio。

5️⃣ 避坑 · 常见错误答法

❌ "Plan-and-Execute 一定比 ReAct 好，因为有全局规划" → ✅ "对于信息不确定的任务，Plan-and-Execute 的计划可能完全失效。ReAct 的动态调整更适合探索性任务。两种架构没有绝对的优劣，只有适用场景的不同。"
❌ "ReAct 没有规划，所以效率低" → ✅ "ReAct 的'规划'是隐式的——每步的 Think 就是局部规划。对于简单任务（3-5 步），ReAct 的隐式规划已经足够，显式规划反而增加了不必要的延迟。"
❌ "混合架构就是把 Plan-and-Execute 和 ReAct 串联起来" → ✅ "混合架构的核心是'粗粒度规划 + 细粒度灵活'——Planner 只规划大方向（3-5 步），每步内的具体执行交给 ReAct。还需要检查点机制判断是否需要 Re-plan。不是简单的串联。"

6️⃣ 简历呼应

如果你有 Agent 项目：从"架构选型实验"切入，描述你在同一任务上对比 Plan-and-Execute 和 ReAct 的结果（如"数据分析任务 P&E 完成率 92%、ReAct 78%；网页浏览任务 P&E 65%、ReAct 89%"），展示你的数据驱动选型能力
如果你只做过工作流引擎：用"DAG 工作流"类比——Plan-and-Execute 类似于预定义 DAG，ReAct 类似于动态路由。混合架构类似于"DAG + 动态路由"的混合工作流
如果你是校招无项目：用 LangGraph 实现三种架构（P&E / ReAct / 混合），在 3 种任务类型上对比，写一篇博客分析 trade-off
"Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought" (Wang et al., 2023)
"ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022)
"LangGraph: Stateful Multi-Actor Agent Orchestration" (LangChain, 2024)

—— 本场面试完 ——