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 为什么先规划更好全局视角Planner能看到任务全貌规划出最优路径避免死胡同提前发现不可行路径执行效率Executor不需要每步都想执行更快可调试计划可以人工审核执行过程更透明3. P-t-E的详细流程3.1 Planning阶段plan_prompt 你是一个任务规划器。给定一个任务请生成详细的执行步骤。 任务{task} 请输出步骤列表 1. ... 2. ... 3. ... defplanner(task,llm):stepsllm.generate(plan_prompt.format(tasktask))returnparse_steps(steps)3.2 Execution阶段defexecutor(steps,llm,tools):results[]fori,stepinenumerate(steps):# 根据当前状态执行步骤contextf已完成:{results}\n当前步骤:{step}actionllm.generate(context)# 执行工具调用resultexecute_action(action,tools)results.append(result)# 可选根据结果调整后续计划ifneed_replan(result):stepsreplan(task,results,llm)returnresults3.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场景差距这么大Web Agent特点ReAct的问题P-t-E的优势步骤多10步局部决策导致走弯路全局规划找最优路径页面结构复杂每步都要理解页面规划时已分析路径操作不可逆点错链接难以回退提前规划避免误操作依赖DOM状态观察DOM耗Token规划阶段减少无效观察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 ThinkingExecutor用轻量模型GPT-4.1 mini批量处理Reviewer用Claude Opus 4.7 Judge做交叉验证6.2 Claude Opus 4.7的扩展思考作为隐式PlannerClaude Opus 4.72026.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-EGLM-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支持框架P-t-E实现LangGraphStateGraph Checkpoint原生支持Claude Agent SDKSubagents模式 隐式PlanOpenAI Agents SDKHandoffs Plan ToolCrewAIHierarchical ProcesssmolagentsMulti-step Plan# LangGraph实现P-t-Efromlanggraph.graphimportStateGraphfromlanggraph.prebuiltimportcreate_react_agentclassPEState(TypedDict):task:strplan:listcompleted:listcurrent_step:intdefplanner_node(state):Planner: 生成完整计划planllm.invoke(f为任务生成步骤计划{state[task]})return{plan:parse_plan(plan),current_step:0}defexecutor_node(state):Executor: 执行当前步骤stepstate[plan][state[current_step]]resultexecute_step(step)return{completed:state[completed][result],current_step:state[current_step]1}defreplan_check(state):检查是否需要重规划ifneeds_replan(state):returnplannerelifstate[current_step]len(state[plan]):returnendelse:returnexecutorgraphStateGraph(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)appgraph.compile()7. P-t-E vs ReAct选型指南场景推荐原因Web操作P-t-E步骤多、不可逆需要全局规划数据查询ReAct简单搜索即可不需要复杂规划多步推理P-t-E需要全局视角避免走弯路简单工具调用ReAct直接调用更快开放探索ReAct目标不明确无法提前规划固定流程P-t-E流程确定规划一次复用代码重构P-t-E Subagents2026工业最佳实践长程任务1小时P-t-E Memory CompactionGLM-5.1实战验证8. 面试高频问题Q1P-t-E的最大风险是什么规划错误。如果Planner生成的计划本身有问题Executor再精确执行也是南辕北辙。解法(1) 人工审核计划(2) 执行时检测异常触发重规划(3) Planner用更强的模型推理模型。Q2P-t-E如何处理动态环境通过重规划机制——执行过程中发现环境变化或步骤失败触发Planner重新制定后续计划。但重规划频率不能太高否则退化为ReAct。实战经验每50-100步评估一次是否需要重规划。Q3ReAct什么时候仍优于P-t-E(1) 任务步骤少1-3步规划是多余的(2) 目标不明确需要探索(3) 环境高度动态计划很快失效。Q42026年推理模型如何改变了P-t-E推理模型Claude Opus 4.7 Thinking、GPT-5.5、o3通过Extended Thinking机制把Plan从显式步骤变成隐式思考——模型在思考阶段就完成了规划再用工具调用执行。这是P-t-E ReAct的天然融合形态。Q5P-t-E在长程任务上如何不爆炸GLM-5.1的1700步任务靠三大工程支撑(1)Memory Compaction自动压缩历史(2)State持久化到文件系统(3)分层Plan——顶层Plan只有10-20步每步再细分子Plan。总结维度ReActPlan-then-Execute规划方式逐步规划一次规划全局视角无有执行灵活性高中可重规划Web场景成功率低成功率高80%简单任务高效过度工程长程任务容易死循环GLM-5.1验证可达8小时推理模型场景显式循环隐式PlanExtended Thinking2026工业实践单步任务Codex/Claude Code/GLM-5.1主流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)”, 2025Z.ai, “GLM-5.1: 8-Hour Autonomous Task Execution”, 2026.04OpenAI, “Codex Desktop Multi-Agent Architecture”, 2026.04