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

文档状态：本页为公开评审稿。模式定义与分类可供讨论和引用；未附来源链接的数字与应用示例只用于说明机制，不作为行业基准。

问题

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

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

分类依据：行动 × 编排

• 纵轴 · 行动：agent 不是单步执行，而是把一个目标变成一连串对外动作。"先想后干"的两阶段属于行动端，不是推理端的单点思考。
• 横轴 · 编排：Plan-and-Execute 的中心是一个编排者——它持有完整 plan，按依赖图调度每一步、维护全局状态与检查点、在偏离时做局部 replan。这跟提示链（A3）的纯链式不同：A3 是前一段输出喂给后一段的线性传递，A2 是一个中心节点统筹多步，独立步骤可并行展开、关键节点落 checkpoint、出错可回退重规划。统筹与回收这一层，正是编排区别于链式的地方。

解决方案与机制

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 招聘、信贷审批、运维变更。
• 有硬性流程约束的合规场景：比如"背景调查必须在发 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 同源。
• 护栏三明治（A4）：plan 里的审批节点和合规校验，落地时常由 A4 的 pre-check 实现。两者都把控制权交还给用户。
• 迭代假设验证（R4）：R4 是推理端的"边做边调"，A2 是行动端的"先定后调"。A2 的局部 replan 借鉴了 R4 的反馈调整思路。

设计结论

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

企业证据

以下现场记录说明该模式在具体业务约束下如何实现。案例结论只在文中声明的系统边界内成立。

• 东方屹腾 · 规划执行落地 — ReAct 跨步漏步逼出来的任务 DAG + 状态机，把执行顺序从模型判断里拿出来钉进任务图。

案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则。