【系统学AI】08 Plan-then-Execute范式：先想好再做，比ReAct强在哪

ReAct是"边想边做"，Plan-then-Execute是"先想好再做"。看起来只是顺序差异，但实际效果差距巨大——特别是在Web Agent场景。

一句话总结

Plan-then-Execute把规划和执行解耦：Planner先生成完整计划，Executor逐步执行。在Web Agent场景中，P-t-E比ReAct的成功率高80%。

1. ReAct的问题

ReAct的"边想边做"有一个结构性缺陷：局部最优。

ReAct执行示例： Step 1: Thought: 我需要订一张机票 Action: search("机票") Step 2: Thought: 搜索结果太多了，我需要精确搜索 Action: search("北京到上海机票 2026-06-01") Step 3: Thought: 找到了几个平台，我先看携程 Action: click("携程链接") Step 4: Thought: 携程页面打开了，我要选日期 Action: fill("日期", "2026-06-01") ...

问题在哪？每一步的决策只基于当前观察，缺乏全局视角。Agent可能在中途发现前面走了弯路，但已经浪费了步骤。

2. Plan-then-Execute的核心思想

2.1 两阶段架构

阶段1: Planning（规划） 输入任务 → Planner生成完整步骤列表 阶段2: Execution（执行） 逐步执行计划，每步根据结果微调

2.2 与ReAct的架构对比

ReAct: Task → [Think → Act → Observe] → [Think → Act → Observe] → ... → Done ↑______________循环_______________↑ Plan-then-Execute: Task → Planner → [Step1, Step2, Step3, ...] ↓ Executor → 执行Step1 → 执行Step2 → ... → Done

关键区别：ReAct在每一步都做"规划+执行"；P-t-E先把规划做完，再专注执行。

2.3 为什么"先规划"更好？

1. 全局视角：Planner能看到任务全貌，规划出最优路径
2. 避免死胡同：提前发现不可行路径
3. 执行效率：Executor不需要每步都"想"，执行更快
4. 可调试：计划可以人工审核，执行过程更透明

3. P-t-E的详细流程

3.1 Planning阶段

plan_prompt=""" 你是一个任务规划器。给定一个任务，请生成详细的执行步骤。 任务：{task} 请输出步骤列表： 1. ... 2. ... 3. ... """defplanner(task,llm):steps=llm.generate(plan_prompt.format(task=task))returnparse_steps(steps)

3.2 Execution阶段

defexecutor(steps,llm,tools):results=[]fori,stepinenumerate(steps):# 根据当前状态执行步骤context=f"已完成:{results}\n当前步骤:{step}"action=llm.generate(context)# 执行工具调用result=execute_action(action,tools)results.append(result)# 可选：根据结果调整后续计划ifneed_replan(result):steps=replan(task,results,llm)returnresults

3.3 动态重规划

P-t-E不是死板地执行预设计划。当执行遇到意外时，可以触发重规划：

Plan: [搜索航班 → 选最低价 → 填写信息 → 支付] 执行Step 2时发现：最低价航班已售罄 → 触发重规划 New Plan: [搜索航班 → 选次低价 → 填写信息 → 支付]

4. 实战效果：Web Agent场景

4.1 论文结论

“Web Agents Should Adopt the Plan-Then-Execute Paradigm” (2026) 发现：在Web Agent任务中，P-t-E的成功率比ReAct高80%。

4.2 为什么Web场景差距这么大？

4.3 典型Web Agent任务对比

任务：在Amazon上找到最便宜的蓝牙耳机并加入购物车 ReAct (9步，2次走弯路): 1. search("蓝牙耳机") → 结果太多 2. search("便宜蓝牙耳机") → 找到Amazon链接 3. click(Amazon链接) → 进入Amazon 4. sort_by_price() → 排序 5. 点击第一个 → 已售罄 6. 返回 → 回到列表 7. 点击第二个 → 有货 8. add_to_cart() → 加入购物车 9. 完成 Plan-then-Execute (5步，0次弯路): Plan: [搜索Amazon蓝牙耳机 → 按价格排序 → 找有货的 → 加入购物车] 1. search("site:amazon.com 蓝牙耳机") → 直接进入Amazon 2. sort_by_price() → 排序 3. filter_in_stock() → 筛选有货 4. click_first_available() → 选择第一个有货的 5. add_to_cart() → 加入购物车

5. RP-ReAct：融合方案

2025年提出的Reason-Plan-ReAct，试图结合两者优势：

Phase 1: Reason（理解任务） → 分析任务需求，确定策略 Phase 2: Plan（制定计划） → 生成高层步骤列表 Phase 3: ReAct（执行+微调） → 每步执行时允许局部调整

核心思想：高层用P-t-E保全局最优，底层用ReAct保执行灵活。

6. 2026工业实践案例 ⭐ 新增

6.1 OpenAI Codex的Plan-Execute模式

OpenAI Codex 桌面端（2026.04全面升级）采用了显式P-t-E架构：

用户："重构整个src/auth/目录的代码风格" ↓ Codex Planner： 1. 扫描src/auth/目录结构 2. 识别所有需要重构的文件（共12个） 3. 制定文件级重构计划 4. 把每个文件分配给一个Subagent ↓ Codex Executor (多Subagent并行): - Subagent 1: 重构auth.ts - Subagent 2: 重构session.ts - ... ↓ Codex Reviewer: 汇总所有变更，统一风格审核 ↓ 用户审阅diff并批准

关键工程实践：

• Planner用强推理模型（GPT-5.5 Thinking）
• Executor用轻量模型（GPT-4.1 mini）批量处理
• Reviewer用Claude Opus 4.7 Judge做交叉验证

6.2 Claude Opus 4.7的扩展思考作为隐式Planner

Claude Opus 4.7（2026.04发布，1M上下文）的Extended Thinking机制本质上是隐式P-t-E：

用户输入复杂任务 ↓ <thinking> 模型先生成几千Token的"思考"： - 分析任务需求 - 列出执行步骤 - 评估每步风险 - 制定Plan </thinking> ↓ 基于Plan执行（带工具调用）

这种"思考时规划+执行时引用"是2026年推理模型的标准做法。Claude Opus 4.7在SWE-Bench Verified达到87.6%，有相当一部分功劳来自隐式Plan。

6.3 GLM-5.1 的8小时长链 P-t-E

GLM-5.1（智谱AI 2026.04）创下了单任务1700步/8小时的工业纪录，其架构核心就是P-t-E：

任务："把这个废弃的Python 2项目迁移到Python 3.13并通过所有测试" ↓ Planner (GLM-5.1 Thinking): 生成顶层计划: 1. 扫描代码库结构 2. 识别Python 2语法（print、unicode、字典dict.iteritems等） 3. 用2to3工具批量转换 4. 处理2to3无法转换的复杂case 5. 重写依赖（pickle/urllib等） 6. 修复测试用例 7. 跑测试 + 修bug循环 8. 生成迁移报告 ↓ 分解为子计划，每个子计划再细分 （迁移1700步，跨8小时持续执行）

支撑8小时长链的工程：

• Memory Compaction：自动压缩中间步骤的上下文
• 持久化State：用文件系统作为State存储
• 重规划触发：每50步重新评估，必要时调整后续计划

6.4 主流框架的P-t-E支持

# LangGraph实现P-t-Efromlanggraph.graphimportStateGraphfromlanggraph.prebuiltimportcreate_react_agentclassPEState(TypedDict):task:strplan:listcompleted:listcurrent_step:intdefplanner_node(state):"""Planner: 生成完整计划"""plan=llm.invoke(f"为任务生成步骤计划：{state['task']}")return{"plan":parse_plan(plan),"current_step":0}defexecutor_node(state):"""Executor: 执行当前步骤"""step=state["plan"][state["current_step"]]result=execute_step(step)return{"completed":state["completed"]+[result],"current_step":state["current_step"]+1}defreplan_check(state):"""检查是否需要重规划"""ifneeds_replan(state):return"planner"elifstate["current_step"]>=len(state["plan"]):return"end"else:return"executor"graph=StateGraph(PEState)graph.add_node("planner",planner_node)graph.add_node("executor",executor_node)graph.add_edge("planner","executor")graph.add_conditional_edges("executor",replan_check,{"planner":"planner",# 触发重规划"executor":"executor",# 继续执行"end":END,})graph.set_entry_point("planner")app=graph.compile()

7. P-t-E vs ReAct选型指南

8. 面试高频问题

Q1：P-t-E的最大风险是什么？

规划错误。如果Planner生成的计划本身有问题，Executor再精确执行也是南辕北辙。解法：(1) 人工审核计划；(2) 执行时检测异常触发重规划；(3) Planner用更强的模型（推理模型）。

Q2：P-t-E如何处理动态环境？

通过重规划机制——执行过程中发现环境变化或步骤失败，触发Planner重新制定后续计划。但重规划频率不能太高，否则退化为ReAct。实战经验：每50-100步评估一次是否需要重规划。

Q3：ReAct什么时候仍优于P-t-E？

(1) 任务步骤少（1-3步），规划是多余的；(2) 目标不明确，需要探索；(3) 环境高度动态，计划很快失效。

Q4：2026年推理模型如何改变了P-t-E？

推理模型（Claude Opus 4.7 Thinking、GPT-5.5、o3）通过Extended Thinking机制把Plan从显式步骤变成隐式思考——模型在思考阶段就完成了规划，再用工具调用执行。这是"P-t-E + ReAct"的天然融合形态。

Q5：P-t-E在长程任务上如何不爆炸？

GLM-5.1的1700步任务靠三大工程支撑：(1)Memory Compaction自动压缩历史；(2)State持久化到文件系统；(3)分层Plan——顶层Plan只有10-20步，每步再细分子Plan。

总结

P-t-E不是ReAct的替代，而是补充。在步骤多、路径长的场景中，P-t-E的优势不可忽视。2026年的工业实践已经把P-t-E的边界推到了"8小时1700步"——这在2024年是不可想象的。最佳实践是根据任务复杂度动态选择——简单的用ReAct，复杂的用P-t-E + Subagents组合。

路易乔布斯 © 2026 | AI Agent & RAG学习计划 · 模块01-Agent · 第三篇

参考文献：

• Del Rosario et al., “Plan-then-Execute: A Guide to Secure Implementations”, 2025
• “Web Agents Should Adopt the Plan-Then-Execute Paradigm”, 2026
• “Reason-Plan-ReAct (RP-ReAct)”, 2025
• Z.ai, “GLM-5.1: 8-Hour Autonomous Task Execution”, 2026.04
• OpenAI, “Codex Desktop Multi-Agent Architecture”, 2026.04