跳到主要内容

Agent Planning Patterns

学到 Agent Engineering 之后，下一步一个很自然的问题就是：

Agent 到底应该怎么规划和推进任务？

因为真实系统里，Agent 并不是只有一种长相。

有些系统非常简单：

  • 看到目标
  • 想一步
  • 做一步
  • 看结果

有些系统则更复杂：

  • 先整体拆计划
  • 再按计划逐个执行
  • 遇到问题时回退、重规划

所以如果想真正理解 Agent，不只是要知道“它会多步执行”，还要知道：

它的多步执行模式到底是怎么设计出来的。

这篇文档就专门整理 Agent 里最常见的一批 Planning Patterns。

1. 为什么要学 Planning Pattern​

因为很多 Agent 的差异，不在于模型本身，而在于：

  • 任务是怎么拆的
  • 下一步是怎么决定的
  • 什么时候该探索
  • 什么时候该收敛
  • 什么时候该停止

Planning Pattern 决定的是 Agent 的运行形态。

如果不理解这些模式，你很容易出现两个问题：

  • 把不需要复杂规划的任务做得过重
  • 把需要稳定规划的任务交给随意的即时推理

2. 什么是 Planning​

这里说的 Planning，不是只指“先列一个计划”。

在 Agent 系统里，它更广义地指：

  • 如何把目标变成可执行步骤
  • 如何在执行中决定下一步
  • 如何根据结果调整路径

所以 Planning 可以发生在：

  • 执行前
  • 执行中
  • 执行后复盘时

3. 最基本的模式：ReAct​

ReAct 是最常见、也最基础的 Agent 模式之一。

它的核心节奏是：

Thought -> Action -> Observation

也就是：

  1. 先想一下
  2. 做一个动作
  3. 看结果
  4. 再决定下一步

3.1 它适合什么场景​

适合：

  • 信息需要边做边拿
  • 工具调用顺序不固定
  • 任务规模中等
  • 决策依赖实时反馈

3.2 它的优点​

  • 简单
  • 灵活
  • 容易和工具调用结合

3.3 它的缺点​

  • 容易短视
  • 容易局部最优
  • 长任务里可能反复绕圈

所以 ReAct 适合做“轻量动态决策”，但不一定适合特别长链路的大任务。

4. 先规划再执行：Plan-and-Execute​

Plan-and-Execute 是另一个非常常见的模式。

它的思路是：

  1. 先根据目标生成一个整体计划
  2. 再按计划逐步执行
  3. 必要时再重规划

4.1 它适合什么场景​

适合：

  • 目标明确
  • 任务规模较大
  • 子任务之间有明显顺序
  • 希望过程更可解释

4.2 它的优点​

  • 结构更清晰
  • 过程更容易追踪
  • 更便于做中间检查

4.3 它的缺点​

  • 前期计划可能不准
  • 计划过细会很脆
  • 外部环境变化快时容易失效

所以它适合中长任务，但不能假设初始计划永远正确。

5. 路由型模式：Router / Dispatcher​

有些系统并不是让一个 Agent 从头做到尾，而是先判断：

  • 这类任务该交给谁
  • 该用哪套流程
  • 该走哪个工具链

这类模式通常叫：

  • Router
  • Dispatcher
  • Classifier + Executor

5.1 它的核心​

先做“任务分流”，再做“具体执行”。

5.2 它适合什么场景​

适合：

  • 任务类型差异大
  • 每类任务有明显不同流程
  • 希望控制成本和稳定性

比如：

  • 简单 FAQ 走固定问答流
  • 代码问题走代码分析流
  • 调研问题走搜索和总结流

5.3 它的优点​

  • 可控性高
  • 易于扩展
  • 适合和 Workflow 结合

5.4 它的缺点​

  • 路由错了，后面全错
  • 分类边界不清时容易抖动

6. 反思型模式：Reflection / Self-Critique​

这类模式会让 Agent 在执行后再做一轮检查：

  • 我漏了什么
  • 这个答案是否站得住
  • 是否应该再查一次
  • 是否需要修正

6.1 它适合什么场景​

适合：

  • 结果质量比速度更重要
  • 任务容易漏关键点
  • 需要一定自我校验能力

6.2 它的优点​

  • 能减少明显遗漏
  • 能提高开放式任务质量

6.3 它的缺点​

  • 增加成本和延迟
  • 有时只是“看起来在反思”，并不真正变好

所以这类模式最好配合评估来验证是否真的有效。

7. 树状探索：Search / Tree-of-Thought​

更复杂一点的模式，会让系统同时考虑多条路径，再从中选优。

比如：

  • 同时生成多种方案
  • 比较它们
  • 保留更优分支

这类思路更接近：

  • 搜索
  • 树状推理
  • 多分支探索

7.1 它适合什么场景​

适合：

  • 方案空间较大
  • 单一路径容易早早走偏
  • 需要比较多个候选解

7.2 它的缺点​

  • 成本高
  • 工程复杂度高
  • 很容易变成“看起来很高级，实际上收益不稳定”

所以除非任务确实需要，不然不要轻易上太重的搜索式 Agent。

8. 单 Agent 和多 Agent​

很多人学 Planning 时还会继续问：

是不是多个 Agent 一定比一个 Agent 更强？

其实不一定。

8.1 Single-Agent​

一个 Agent 负责整个任务。

优点：

  • 简单
  • 好调试
  • 状态一致性更容易维护

缺点：

  • 容易上下文膨胀
  • 对复杂任务负担较重

8.2 Multi-Agent​

多个 Agent 分工合作，比如：

  • 一个做规划
  • 一个做检索
  • 一个做写作
  • 一个做评审

优点：

  • 职责更清晰
  • 某些复杂场景下更容易分治

缺点：

  • 协调复杂
  • 成本更高
  • 错误传播链更长

对大多数团队来说，Single-Agent + 明确工具 + 良好状态管理 往往比急着上 Multi-Agent 更实用。

9. Tool-first 和 Reason-first​

还有一类很常见的差异，是：

  • 先推理，再决定要不要调工具
  • 还是先按规则优先调工具，再推理

9.1 Reason-first​

先理解问题，再判断工具是否必要。

优点：

  • 更灵活
  • 更接近人类思考

缺点：

  • 容易过度思考
  • 容易在该查数据时还在猜

9.2 Tool-first​

对某些问题，优先使用可靠工具，再基于结果推理。

优点：

  • 更稳
  • 更容易减少幻觉

缺点：

  • 有时会增加不必要调用
  • 规则设计不好时会显得僵硬

真实系统里经常是混合模式：

  • 事实类问题偏 Tool-first
  • 开放分析类问题偏 Reason-first

10. 如何选择合适的模式​

可以从下面几个维度来判断。

10.1 任务路径是否固定​

如果路径比较固定，优先 Workflow 或 Router。

10.2 任务长度是否很长​

如果任务很长，单纯 ReAct 可能容易失控，更适合 Plan-and-Execute。

10.3 结果质量是否需要额外校验​

如果需要，就考虑 Reflection。

10.4 是否真的需要多角色分工​

如果没有明显分工收益，不要急着上 Multi-Agent。

11. 一个很实用的搭建顺序​

对大多数团队来说，更实用的顺序通常是：

  1. 先从固定 Workflow 起步
  2. 对复杂节点引入 ReAct
  3. 当任务链路变长时，再补 Plan-and-Execute
  4. 需要分流时，再加 Router
  5. 对高价值输出，再考虑 Reflection
  6. 最后才认真评估是否值得 Multi-Agent

这个顺序的好处是：

  • 复杂度增加更可控
  • 每一步都容易验证收益

12. 常见误区​

12.1 把 ReAct 当成唯一 Agent 模式​

ReAct 很经典，但不是所有场景都适合它。

12.2 一开始就做重规划​

很多任务其实不需要复杂 Planning，过早引入会增加系统负担。

12.3 看到复杂任务就上 Multi-Agent​

多 Agent 带来的不是只有能力，还有协调成本、状态同步和评估难度。

12.4 不给模式设置停止条件​

不管哪种模式，如果没有：

  • 最大步数
  • 重试上限
  • 明确结束标准

系统都很容易失控。

13. 一句话总结​

如果说 Agent Engineering 研究的是“如何让系统围绕目标多步执行”，那么 Planning Patterns 研究的就是：

这个多步执行到底按什么形态展开。

真正实用的经验通常不是追求“最聪明的模式”，而是：

根据任务的不确定性、长度、风险和评估难度，选一个刚好够用的规划模式。