模式矩阵 /模式白皮书/A2

A2 · Plan-and-Execute · 规划-执行

它解决什么问题

长任务里，逐步反应式（ReAct）的 agent 几乎注定翻车。一个 HR 招聘 agent 把 17 个工具全开放给模型自由决定每一步，结果是：把没面试通过的候选人薪酬发给了招聘经理、跳过背景调查直接发 offer、反复查同一份薪酬数据 50 次。根因是 agent 没有完整 plan——context window 装不下 12 步招聘流程的全貌，模型只能基于"上一步刚发生什么"决定下一步，没有全局视图。

Plan-and-Execute 把动作端拆成两个阶段：先 plan，后 execute。规划阶段一次性把任务排成有序的多步，标清依赖、资源、必须人审的节点；执行阶段按 plan 推进。它的价值在于把宏观顺序从模型的临场判断里拿出来，钉死在一份可审计的计划里。

为什么坐标是「行动 × 链式」

• 纵轴 · 行动：agent 不是单步执行，而是把一个目标变成一连串对外动作。"先想后干"的两阶段属于行动端的编排，不是推理端的单点思考。
• 横轴 · 链式：planning 和 execution 是显式的两个 chain 段——规划链产出 plan，执行链消费 plan，前段输出就是后段输入。这与提示链（A3）同属链式，区别在 A2 链上传的是结构化的 plan，A3 链上传的是逐段的文本输出。

核心机制

Plan-and-Execute 的核心不是复杂，而是三件事：分家、审批闸门、context reset。Aider 的 architect mode 核心只有 9 行代码就把这三件事占全了——architect 出 plan，editor 清空上下文后执行 plan，中间默认要用户确认。

落到工程上有几个关键设计：

• 异构模型：plan 阶段需要深度推理，用强模型；execute 阶段是结构化、可验证的，用中等模型就够，便宜 5 到 15 倍。Aider 在 SWE-bench 实测，强模型规划加中等模型执行，比单用强模型准确率高 3 到 5 个点，成本降 40%。
• plan 是 user-owned artifact：Claude Code 把 plan 写文件而不是留在 prompt 里。文件天然是审计日志，可以多人 review、版本化、diff，用户从文件读、agent 也从文件读。
• 局部 replan：plan 走到一半与现实冲突时，只改受影响的部分，已 commit 的步骤不动。Anthropic 的工程经验值是每 5 步检查一次 plan 是否还成立，每次 replan 预算不超过总预算的 10%。

研究数据印证了这套范式的经济性。ReWOO 把 plan-execute 的 LLM 调用压到 2 次（一次规划加一次综合），中间所有工具调用并行执行不走模型，相比 ReAct 范式 token 效率高 5 倍、准确率还高 4 个点。

适合的生产场景

• 目标明确、步骤可枚举、副作用敏感三者叠加：HR 招聘、信贷审批、运维变更。三件全占不用 plan 是失职，一件不占硬上 plan 是过度工程。
• 有硬性流程约束的合规场景：比如"背景调查必须在发 offer 之前"。这类约束可以编码进 plan validator，规划阶段就拦下违规的 plan。
• 需要崩溃恢复的长任务：每步写 checkpoint，崩溃后从 checkpoint resume，把 plan-execute 当可恢复事务来设计。

容易出错的地方

• plan ossification（计划僵化）：plan 写好后执行器一路跑，中途某步返回意外结果（候选人撤回、schema 变更、外部 API 改协议），规划器没及时介入，后续步骤全是无效计算。应对是每 N 步把当前子任务和原始目标做一次对齐检查。
• plan thrashing（计划震荡）：replan 触发太频繁，每次失败都重写，agent 永远在规划从不执行。应对是设 replan 硬上限加 replan 预算封顶。
• stale context 悄悄累积：长任务的 state 用自由格式笔记容易"看起来还能解析但语义已坏"。应对是 state 用 JSON schema 严格化，让 partial corruption 早暴露。
• cache 友好性被忽略：plan-execute 每步若 invalidate 缓存，成本可飙升约 10 倍。Manus 重写 todo.md 时做结构性 update 而非 append-only，正是为了保 prefix 稳定、命中缓存。

关键指标

• 长任务成功率 / 错误率（健康区错误率 <1%）：HR 招聘案例从 8.3% 降到 0.4%。这是 plan 是否起作用的直接信号。
• 每任务 LLM 调用次数（越低越好，且要稳定）：案例从平均 47 次/候选人降到 13 次。次数失控通常意味着 replan 在震荡。
• replan 频率（健康区每 5 步一次左右）：过高是 thrashing，长期为零是 ossification 的前兆。
• 缓存命中率（健康区越高越好）：被 Manus 团队称为生产 agent 单一最重要的指标，直接决定单 token 成本。

最小骨架

plan = planner(goal, context)        # 强模型，一次
若用户不批准 → 返回
while plan 未完成:
    ready = plan 中依赖已满足的步骤   # 拓扑序
    并行执行 ready:
        成功 → 标记 completed，写 checkpoint
        失败 → replan（受限于 MAX_REPLANS）
    每满 N 步 → adaptive replan 检查 plan 是否仍成立
返回 plan + 完整执行 trace

工程落地要点：Planner、Executor、Approval 用依赖注入，由业务决定具体模型和 prompt；destructive 步骤登记 saga inverse；plan 写文件加版本化。

企业落地一例

梁博团队把"战略层计划"与"战术层执行"显式拆开。Plan-Exec 模式下，计划一旦由规划层写入 Workspace 的 DAG，调度器就按依赖关系推进，不再依赖 LLM 逐步重新选择路径。这正面解决了 ReAct 的结构性问题——ReAct 每一步都要再调一次 LLM 来决策，宏观执行顺序无法被工程化地钉死，长任务里随时可能跑偏。把顺序固化进 DAG 之后，模型只在单步内填参数和解读结果，宏观流程交给确定性的调度器，长任务的可靠性和成本才同时可控。落到 HR 招聘案例：重写成 Planner 加 Executor 加 Approval Gate 三段后，月度账单从 18 万降到 6 万，招聘周期从 23 天压到 16 天。

与其他模式的关系

• 提示链（A3）：一对对偶模式，一重一轻。A2 是完整 plan 加 DAG 并行加 replan，A3 是线性串联无 replan。生产里最常见的形态是 A2 在外、A3 在内——每个被规划出来的子任务内部跑一条 prompt chain。
• 工具调度（A1）：A2 的每个执行步骤内部都要做一次 A1 的工具选择。Planner 和 Executor 用异构模型的思路，与 A1 的 Programmatic Tool Calling 同源。
• 守卫三明治（A5）：plan 里的审批节点和合规校验，落地时常由 A5 的 pre-check 实现。两者都把控制权交还给用户。
• 迭代假设验证（R4）：R4 是推理端的"边做边调"，A2 是行动端的"先定后调"。A2 的局部 replan 借鉴了 R4 的反馈调整思路。

一句话记住它

Plan-and-Execute 不是"列 todo"，而是把人类几十年的项目管理工程沉淀（WBS、PERT、Saga、DAG 调度）原样复刻到 LLM 上——它之所以比单 agent ReAct 更耐用，是因为它站在成熟工程的肩膀上，而且把控制权交还给了用户。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。