4.3 Plan-and-Execute：先规划后执行与重规划
4.3 Plan-and-Execute：先规划后执行与重规划
本节摘要：Plan-and-Execute 把"边想边做"的 ReAct 换成"先定全局计划、再逐条执行、异常才重排"。本节讲清它与 ReAct 的分工边界，给出带执行监控与重规划触发的循环实现，并用一次中途变更的任务演示重规划的收敛过程。
裸 ReAct 每一步都重新决策，好处是灵活，代价是全局感稀薄——走到第七步时，模型对"整体还剩几步、预算还剩多少"已经模糊。Plan-and-Execute（先规划后执行）把这件事颠倒过来：开头花一次重决策生成完整计划，之后执行器照单推进，只有在异常发生时才打扰规划器。决策成本从"每步全款"变成"一次首付加重排加价"。
图：执行监控与重规划循环——异常怎么触发、边界在哪里
循环实现：执行器为什么可以很"笨"
def plan_and_execute(goal: str, replan_budget: int = 2) -> dict: plan = decompose(goal) # 4.1 节的分解器 replans = 0 done_facts = {} # 已完成步骤的结论 while pending := next_steps(plan, done_facts): for step in topological_order(pending): # 按依赖排序推进 obs = run_tool(step) # 执行器照单干活 done_facts[step.id] = obs verdict = check(step, obs) # 监控器核对 if verdict.ok: continue if verdict.retryable and step.retries < 2: step.retries += 1 continue # 偶发失败先重试 if replans >= replan_budget: # 重规划额度用尽 return {"status": "escalate", # 上报人工 "at": step.id, "facts": done_facts} plan = replan(goal, done_facts, failure=verdict) # 只重排剩余部分 replans += 1 break # 回到调度重新排序 return {"status": "done", "facts": done_facts}
执行器刻意保持"笨"：它不做全局判断，只按当前步骤发起调用——全局判断权集中给规划器，是这套结构省钱的关键。对比裸 ReAct，同一个八步任务，决策类模型调用的次数从八次以上降到一次规划加重排若干次；单步执行甚至可以换成便宜的模型或纯代码调度。
与 ReAct 的分工边界
| 维度 | ReAct（边想边做） | Plan-and-Execute（先规划后执行） |
|---|---|---|
| 决策开销 | 每步全量决策 | 规划一次 + 重排加价 |
| 对变化的环境 | 天然适应 | 需要监控器与重排兜底 |
| 全局可控性 | 弱，走偏发现晚 | 强，计划即进度表 |
| 适合任务 | 探索式、路径未知 | 步骤可预见的结构化任务 |
| 典型场景 | 开放式调研、排障 | 流水线式处理、批任务 |
两条经验边界。任务能预先拆出八成以上步骤的，用 Plan-and-Execute；连第一步该干什么都要看结果的（开放式调研），老实用 ReAct。另外两者可以混合：全局走 Plan-and-Execute，其中某个探索性步骤内部再嵌一个小 ReAct 循环——分层嵌套是工程上的常见形态。
案例：一次中途变更的重规划过程
背景：目标是"把三个数据源的对账报表跑完并发给财务"。计划四步：拉取源一、拉取源二、拉取源三、汇总发送。
操作与结果：第一、二步顺利完成。第三步执行时，源三的接口返回"已迁移至新网关"的报错——监控器判定 verify 不通过且非偶发，触发重规划。重规划器拿到的事实：源一、二的数据已固化；失败现场：旧网关 404；剩余目标：取源三、汇总、发送。它输出的修订计划只有两步：改用新网关地址取源三、汇总发送——前两步的成果原封不动。
解读：这次重规划只花了一次规划调用的成本，且没有重跑已完成的步骤。"已完成即固化"是重规划的纪律核心：复用既有结论，重排范围仅限剩余路径。反例是很多实现一失败就整体从头再跑，预算直接翻倍。
变式：环境剧烈变化（比如目标本身被用户改掉）时，重规划不该自作主张——契约里写明"目标变更需回询用户确认"，规划器输出一份"新旧目标差异说明"供人拍板。变化的解释权在人，不在循环。
⚠️ 常见坑：把重规划当重试用。步骤级偶发失败（超时、限流）属于重试的管辖，进重规划通道是浪费；重规划只处理"计划与现实的偏差"，两者的触发条件必须分开写。
本节要点回顾
- 成本结构：决策从每步全款变成一次首付——执行器保持笨拙，判断权集中给规划器。
- 监控器是枢纽：每步核对 verify 与预算，区分"可重试的偶发失败"与"需要重排的偏差"。
- 重规划有纪律：额度上限（如两次）、已完成即固化、只动剩余步骤；额度用尽就上报人工。
- 与 ReAct 是分工不是替代：路径可预见用计划，路径未知用逐步探索，可分层嵌套。
到这里，单体智能体的四大件——工具、记忆、规划、循环——已经齐备。但有些任务单打独斗到不了终点：下一章讨论什么时候需要一支智能体团队，以及团队怎么把话说清楚。
计划质量的自检维度
一份交给执行器的计划好不好，可以在执行前就看出端倪。四个自检维度值得在评审时逐条过：完备性——目标里的每个可交付物是否都有对应步骤产出？（漏步骤的计划会在验收时才暴露）；依赖正确性——步骤间的 depends_on 是否构成有向无环结构？（成环的计划会让调度器死锁）；验证可行性——verify 描述的完成标志是否真的能被程序或模型判断？（"效果良好"这类验证等于没有验证）；预算合理性——步骤数乘以预估单步开销，是否落在任务预算内？（八步的计划配上三步的预算，执行到一半必然走样）。
四个维度都不达标也会有个共同征兆：执行初期的轨迹里出现大量"重新理解任务"式的思考——那是执行器在替规划器补课。看到这个信号，直接回炉计划比继续执行经济。
与人协作的计划呈现
计划不只是给执行器看的，也是给相关方看的。产品、运营或用户想知道"AI 接下来会做什么"时，一份按三层结构（目标、里程碑、步骤）渲染的计划页，比一句"正在处理"更能建立信任：里程碑是天然的进度条，步骤清单是可干预的明细——发现计划不对，人可以在步骤层面叫停或修改，而不必整体取消任务。把计划结构设计成对机器可执行、对人可阅读的双用途格式，是规划模块最划算的一次性投入。