第 6 章 Planning 机制设计¶

当 Agent 只处理简单问答或单步工具调用时，规划问题并不突出。模型看见输入，做出判断，给出答案或调用工具，任务就结束了。但只要任务开始变长、变复杂、涉及多个工具和多个阶段，Planning 就会迅速成为决定系统可用性的关键环节。

很多团队一提 Planning，第一反应是“让模型先列个步骤”。这当然是最直观的形式，但并不是 Planning 的全部。真正的 Planning 问题是：系统是否需要显式管理任务结构，如何管理，管理到什么粒度，以及在执行过程中是否允许修正原计划。

因此，本章的重点不是展示几种流行名词，而是帮助读者建立一个工程判断：什么时候需要 Planning，Planning 应该如何与执行系统耦合，以及不同模式各自的收益和代价。

6.1 ReAct 模式¶

ReAct 可以说是最有代表性的 Agent 基础模式之一。它的核心思想并不复杂：模型在推理与行动之间交替推进，一边根据当前上下文做判断，一边调用工具获取信息或执行动作，再把工具结果纳入下一轮判断。

从系统角度看，ReAct 的价值有三点。

第一，它把“思考”和“行动”串成了闭环。模型不再只做静态推理，而是在行动结果的反馈下逐步修正路径。

第二，它天然适合信息不完整的环境。系统不需要一开始就拥有完整计划，而是可以边走边看，根据外部反馈决定下一步。

第三，它实现成本相对较低。很多单 Agent 系统在初期都会以某种简化版 ReAct 作为起点，因为它不要求先建立完整任务树或复杂状态机。

但 ReAct 也有明显边界。由于它是逐步前进的，系统往往更关注“下一步做什么”，而不是“整个任务结构是什么”。这带来几个常见问题：

容易陷入局部最优。
在长任务中逐渐偏离目标。
重复执行相似动作。
缺少全局视角下的阶段控制。

因此，ReAct 更适合以下场景：

信息需要逐步获取。
工具调用链路不算很长。
任务允许边试边修正。
全局计划不是刚性要求。

对于复杂但开放的任务，ReAct 往往是一个很好的起点；但当任务结构越来越长、失败成本越来越高时，仅靠 ReAct 往往不够。

工程提示¶

ReAct 的关键不是让模型输出“Thought/Action”，而是让系统真正接住行动反馈，并据此更新下一轮决策。

6.2 Plan-and-Execute 模式¶

与 ReAct 相比，Plan-and-Execute 更强调先有整体结构，再进入执行。系统通常会先让模型根据目标生成一个相对明确的计划，然后再由执行器按计划逐步推进，必要时把中间结果回传给控制层。

这种模式最大的优势，是它为复杂任务提供了一个更清晰的全局框架。尤其在以下场景中，显式计划会非常有帮助：

任务包含明显的阶段依赖。
工具调用成本较高，不希望频繁试错。
需要人工审批某些关键节点。
需要让外部系统或用户看见当前执行计划。

Plan-and-Execute 还能提升可调试性。因为相比“边想边做”的系统，一个显式计划更容易被观察、评审和修改。系统也可以更方便地判断失败究竟来自计划本身，还是来自某个具体执行步骤。

但代价同样明显。计划一旦写得过细，就容易在真实环境变化时迅速失效；写得过粗，又起不到足够的约束作用。此外，先规划再执行还会带来额外时延和上下文成本。

因此，Plan-and-Execute 并不是一套总能优于 ReAct 的高级方案。它更像是一种适合复杂任务的控制增强手段。真正关键的问题不是“要不要计划”，而是“计划是否真的能为执行提供有效约束”。

一个常见误区是，让模型一开始就生成非常长的步骤清单，然后把这个清单当成不变真理。现实中的复杂任务通常无法完全预测，计划必须为执行服务，而不是反过来绑死执行。

6.3 Reflection 与 Self-Critique¶

无论采用 ReAct 还是 Plan-and-Execute，Agent 都可能在执行中走偏。此时，一个很自然的补充机制就是 Reflection 或 Self-Critique，也就是让系统在某些节点回头检查自己当前的路径是否合理。

Reflection 的作用不在于“让模型再想一次”这么简单，而在于给系统引入一种显式的误差检查能力。它通常可以出现在几个位置：

工具调用结果异常后，判断是否应该换路径。
某个阶段完成后，检查当前结果是否满足目标。
最终输出前，检查是否遗漏关键约束。
多步任务执行中，识别是否已经偏离初始目标。

Reflection 的价值主要体现在两个方面。

第一，它可以降低错误的级联传播。很多 Agent 系统不是一开始就错，而是第一步小偏差没有被发现，后面越走越远。

第二，它可以提高复杂任务中的稳健性。尤其在多工具任务里，只要中间结果质量稍差，后续步骤就很容易建立在错误基础之上。

但 Reflection 也不是免费的。它会增加额外调用成本和延迟，而且如果设计不当，还可能只是让模型在原有错误上“自信地再说一遍”。因此，Reflection 最适合被放在高价值节点，而不是每一步都机械重复。

工程上可以把 Reflection 理解为一种“阶段性校验器”，而不是一种魔法增强器。

工程提示¶

Reflection 最有价值的地方，不是生成更长的自我分析，而是给系统创造“及时刹车和修正”的机会。

6.4 何时需要显式规划，何时不需要¶

Planning 最容易被滥用的地方，在于团队把它当成 Agent 的标配能力。实际上，并不是所有任务都值得引入显式规划。

通常来说，以下场景更需要显式规划：

任务目标复杂且步骤较多。
工具之间存在强依赖顺序。
单步错误成本较高。
系统需要把执行意图暴露给用户或其他系统。
任务跨越较长时间，需要中间状态与阶段控制。

与之相对，以下场景往往不需要显式规划：

简单问答。
单轮知识检索与总结。
一次性低风险工具调用。
执行路径短且反馈快速的任务。

如果把本来只需要一步就能完成的任务硬套进多步规划框架，常见结果通常是：

延迟变高。
成本上升。
错误来源变多。
调试面扩大。

所以，Planning 不是“有没有更高级”，而是“当前任务复杂度是否值得引入额外控制层”。这和传统软件设计里是否要引入状态机、任务调度器、本地缓存、本地索引，本质上是同一个判断逻辑。

6.5 计划粒度与执行耦合¶

即使已经决定引入 Planning，另一个很快会遇到的问题是：计划应该细到什么程度？

计划太粗时，系统虽然看起来有规划，但实际执行阶段仍然要临场决定大量细节，导致计划的约束价值不高。比如“先分析问题，再选择工具，最后给出结论”这样的计划，几乎无法真正指导执行。

计划太细时，系统又会变得脆弱。因为现实任务中的环境和反馈很容易发生变化，过细的计划往往在第二步或第三步就不再成立，最后要么强行执行一个过时方案，要么频繁整段重规划。

一个更实用的原则是：计划粒度应该与执行单元粒度一致，或者略高于执行单元。也就是说，一个计划步骤应该足够具体，能指导一次明确的执行行为；但又不要细到把所有微操作都提前写死。

此外，计划与执行之间的耦合方式也很关键。常见做法包括：

强耦合：执行器严格按计划推进，偏离必须重新审批或重规划。
弱耦合：计划只提供方向，执行器可根据反馈自行调整。
分层耦合：高层计划稳定，低层步骤动态调整。

从工程实践看，分层耦合通常最稳。它既能保留全局目标约束，又不会让系统因为局部变化而频繁崩盘。

6.6 Planning 失败的常见模式¶

Planning 设计不好时，系统会表现出一些非常典型的失败模式。

第一种是“有计划，但计划不影响执行”。模型先生成一段漂亮计划，执行时却完全无视它。这个问题通常说明计划只是展示层产物，没有真正进入控制逻辑。

第二种是“计划过细导致脆弱”。系统对每一步都提前写死，一旦外部反馈和预期稍有不同，后续步骤就全部失效。

第三种是“计划过粗导致失控”。系统表面上有规划，实际上关键判断仍然被推回执行阶段，结果和没有规划差别不大。

第四种是“重规划没有边界”。每遇到一点阻碍就整段重规划，结果系统一直在计划，迟迟不进入有效执行。

第五种是“计划与状态脱节”。系统表面维护了一份计划，但状态层并不知道哪些步骤完成了、哪些失败了、哪些需要回滚。最终计划无法成为可操作对象。

这些问题说明，Planning 从来不是独立模块，而必须与状态管理、执行控制和反馈机制一起设计。只讨论“模型会不会列步骤”，几乎无法解决真正的规划问题。

工程提示¶

判断 Planning 是否真的生效，最简单的方法不是看计划写得多漂亮，而是看失败发生时系统会不会基于计划做出不同处理。

6.7 Planning 与 Workflow 的关系¶

在很多 Agent 系统里，Planning 和 Workflow 会被混为一谈。实际上，两者有明显区别。

Workflow 是系统预先定义好的控制结构。它的阶段、路径和分支通常由工程师明确指定，系统执行的是“按规则推进”。

Planning 则是 Agent 在任务运行过程中，基于当前目标和上下文临时生成或调整的任务结构。它关注的是“当前这个具体任务应该怎么走”。

两者最好的关系通常不是互斥，而是协同：

Workflow 负责稳定主干。
Planning 负责不确定节点。
Workflow 决定系统可以进入哪些阶段。
Planning 决定在某个阶段里先做哪些动作。

举例来说，一个代码修复系统可以用 Workflow 固定“分析问题 -> 修改代码 -> 运行验证 -> 生成说明”四个主阶段；但在“分析问题”阶段内部，Agent 仍然可以通过 Planning 决定先读哪些文件、先查哪些报错、先跑哪些命令。

这种设计比“全靠 Agent 自己想”更可控，也比“所有路径都硬编码死”更灵活。

6.8 本章小结¶

Planning 的核心价值，不在于让 Agent 看起来更聪明，而在于为复杂任务提供合适粒度的结构化控制。ReAct 强调边行动边判断，适合开放任务和逐步获取信息的场景；Plan-and-Execute 强调先建立整体结构，再推进执行，适合高复杂度和高约束任务；Reflection 则在关键节点提供误差检查和路径修正能力。

真正成熟的 Planning 设计，必须回答四个问题：要不要规划，规划到多细，计划是否真正影响执行，以及执行中何时允许修正计划。只有把这些问题和状态、执行、反馈系统一起考虑，Planning 才会成为任务控制能力，而不是演示用的步骤生成器。

下一章会继续往执行层推进，讨论 Agent 系统中最核心的行动能力之一：Tool Use，也就是模型如何选择、调用并控制外部工具。