智能体 Planning 规划模式实战：先出计划再动手，成功率能提多少

Q: 规划会增加多少成本？

通常增加一轮模型调用，占比有限；但因为减少了无效步骤和重复劳动，复杂任务的总成本往往是下降的。

云上的幻象2026-09-286 分钟阅读2,272 字30

100%

先给结论

让智能体先写一份计划再动手，是提升复杂任务成功率性价比最高的一个改动：把「边想边做」（ReAct 式）改成「先规划、再执行、按反馈修订计划」（Plan-and-Execute 式），换来的是任务不跑偏、成本可预估、过程可审计。代价是多一轮模型调用和一定的延迟。经验法则：任务步骤少于三步不用规划，超过五步或涉及多个数据源必须规划。

Anthropic 在多智能体研究系统的工程总结里提到同一个关键点：主智能体要把计划写进记忆里持久化。原因是上下文一旦超限被截断，计划连同进度一起丢失，智能体就会从零开始、重复劳动。这条经验对单智能体同样成立。

两种模式的差别

维度	边想边做（ReAct）	先规划再执行（Plan-and-Execute）
决策时机	每一步临时决定下一步	开工前先列完整步骤
适合的步骤数	3 步以内	5 步以上
跑偏概率	随步骤数累积上升	低，有明确清单可对照
成本可预估性	差，可能无限循环	好，步骤数基本固定
延迟	首步快	多一轮规划时间
人在环上	难插入	天然可以在计划阶段卡一道审批

一个靠谱的规划循环长什么样

规划：模型读取任务描述与可用工具，输出结构化步骤清单，每步写清「做什么、用什么工具、产出什么」。
持久化：把计划存进记忆、文件或工作流变量，而不是只留在上下文里。
执行：逐步执行，每步完成后更新状态。
观察与修订：遇到计划外的结果（工具报错、数据缺失），回到计划层面修改，而不是原地打补丁。
收敛判断：明确「信息已足够」的停止条件，避免无限加步骤。

提示词怎么写

你是任务规划器。可用工具：search_web / read_file / run_sql / http_get

要求：
1. 先输出一个 JSON 步骤数组，每步含 id 、 goal 、 tool 、 expected_output
2. 步骤数控制在 3-8 步，不要拆分过度
3. 需要人确认的步骤标记 requires_approval: true
4. 如果某步失败，重新输出后续步骤，而不是重复失败的那一步
5. 当已获得足以回答用户的信息时，直接停止并输出 finish 标记

停止条件（满足任一即可收尾）：
- 所有原计划步骤完成
- 连续两次检索无新增信息
- 已花费步骤数到达 8 步上限

第四点和第五点是关键。没有「失败后重规划」的智能体会在同一个坑里循环；没有明确停止条件的智能体会无休止地「再查一次」。

把工作量与复杂度挂钩

Anthropic 在多智能体系统里踩过的坑很有代表性：早期版本对简单事实查询也会派出几十个子智能体。解决办法是把规则写进提示词——按查询复杂度分档投入资源：

简单事实：单步或少步工具调用，一次成型。
对比类：拆成 2-4 个并行子任务，各自独立执行。
深度研究：拆成十个以上子任务，明确分工边界，再由主智能体汇总。

为什么「改计划」比「补救代码」便宜

做完三步才发现方向错，返工成本是三步产出加全部 token；在计划阶段发现方向错，返工成本是一轮模型调用。这就是为什么把 human-in-the-loop 放在计划之后、执行之前，而不是放在最后验收。
实操建议：计划输出后暂停，让用户确认或修正，再开执行。这一个暂停能挡掉大部分无效工作。

和三种常见工作流怎么搭配

串行（Sequential）：步骤之间有依赖，规划清单天然就是串行管线。这是默认形态。
并行（Parallel）：规划时标出彼此独立的步骤，同时开跑，是压缩延迟的主力手段，但要预留结果合并策略。
评估-优化（Evaluator-Optimizer）：对质量有要求的步骤（写文档、生成代码）加一轮评审再放行。只有能量到质量提升时才加这个循环，否则纯粹烧钱。

组合顺序建议：先串行跑通，再针对瓶颈加并行，最后对特定环节加评估优化。反过来做，一上来就是复杂图结构，调试成本会吃掉全部收益。