【系统学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 为什么"先规划"更好？

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

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

3.1 Planning阶段

python 复制代码

plan_prompt = """
你是一个任务规划器。给定一个任务，请生成详细的执行步骤。

任务：{task}

请输出步骤列表：
1. ...
2. ...
3. ...
"""

def planner(task, llm):
    steps = llm.generate(plan_prompt.format(task=task))
    return parse_steps(steps)

3.2 Execution阶段

python 复制代码

def executor(steps, llm, tools):
    results = []
    for i, step in enumerate(steps):
        # 根据当前状态执行步骤
        context = f"已完成: {results}\n当前步骤: {step}"
        action = llm.generate(context)

        # 执行工具调用
        result = execute_action(action, tools)
        results.append(result)

        # 可选：根据结果调整后续计划
        if need_replan(result):
            steps = replan(task, results, llm)

    return results

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场景差距这么大？

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 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支持

框架	P-t-E实现
LangGraph	StateGraph + Checkpoint，原生支持
Claude Agent SDK	Subagents模式 + 隐式Plan
OpenAI Agents SDK	Handoffs + Plan Tool
CrewAI	Hierarchical Process
smolagents	Multi-step Plan

python 复制代码

# LangGraph实现P-t-E
from langgraph.graph import StateGraph
from langgraph.prebuilt import create_react_agent

class PEState(TypedDict):
    task: str
    plan: list
    completed: list
    current_step: int

def planner_node(state):
    """Planner: 生成完整计划"""
    plan = llm.invoke(f"为任务生成步骤计划：{state['task']}")
    return {"plan": parse_plan(plan), "current_step": 0}

def executor_node(state):
    """Executor: 执行当前步骤"""
    step = state["plan"][state["current_step"]]
    result = execute_step(step)
    return {
        "completed": state["completed"] + [result],
        "current_step": state["current_step"] + 1
    }

def replan_check(state):
    """检查是否需要重规划"""
    if needs_replan(state):
        return "planner"
    elif state["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选型指南

场景	推荐	原因
Web操作	P-t-E	步骤多、不可逆，需要全局规划
数据查询	ReAct	简单搜索即可，不需要复杂规划
多步推理	P-t-E	需要全局视角避免走弯路
简单工具调用	ReAct	直接调用更快
开放探索	ReAct	目标不明确，无法提前规划
固定流程	P-t-E	流程确定，规划一次复用
代码重构	P-t-E + Subagents	2026工业最佳实践
长程任务（>1小时）	P-t-E + Memory Compaction	GLM-5.1实战验证

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。

总结

维度	ReAct	Plan-then-Execute
规划方式	逐步规划	一次规划
全局视角	无	有
执行灵活性	高	中（可重规划）
Web场景	成功率低	成功率高80%
简单任务	高效	过度工程
长程任务	容易死循环	GLM-5.1验证可达8小时
推理模型场景	显式循环	隐式Plan（Extended Thinking）
2026工业实践	单步任务	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)", 2025

Z.ai, "GLM-5.1: 8-Hour Autonomous Task Execution", 2026.04

OpenAI, "Codex Desktop Multi-Agent Architecture", 2026.04