动手学 Agent：Agent 设计模式 (1)

发表于 更新于 分类于 本文字数： 5.6k 阅读时长 ≈ 5 分钟
本文深入解析五种经典Agent设计模式的核心思想与优缺点。ReAct模式强调边想边做的闭环控制；Plan-and-Execute模式先规划后执行的开环控制；ReWoo通过并行执行提升效率；Reflexion引入反思机制实现自我改进；ReflAct将反思细化到每一步。文章从控制论视角分析各模式特性，为开发者选择适合场景的Agent架构提供了清晰的决策依据。

无论是学术研究还是业界落地，Agent 的设计玲琅满目，但追根溯源，核心的思想其实是没那么多，今天我们就将深挖一下各种不同 Agent 设计思路的来源。

ReAct

ReAct 是一种非常经典点的设计模式，最早是由普林斯顿大学、Google Research 团队的研究人员于 2022 年 10 月在论文 ReAct: Synergizing Reasoning and Acting in Language Models 中提出的，这也是顶会 ICLR 2023 的论文。

核心思想其实很简单：回答用户的问题，不能闷着头想，而应该边想（Though）边做（Act）边看（Obs）。

典型的执行流程如下：

1
2
思考 -> 行动 -> 观察 -> 思考 -> ... -> 最终答案

ReAct 总体来看，可以理解为一种 “自底向上” 的科学思维范式，从控制论的角度来看，它是一种闭环控制系统，也就是说，它会根据自己的输出，获得反馈，来进行自我调整，这意味着它的环境适应能力比较强。

这种设计模式提出时，并没有明确说这是一种 Agent 设计模式，虽然文中作者是以 Agent 来命名这个程序的，但所测评的一些数据集，基本上也都是偏文档问答的，像下方示例中的 HotpotQA，就是一个有名的多跳问答数据集，不过这种思想是非常重要的，就是要关注环境反馈，并根据环境反馈来调整执行动作。 现在很多 Agent 产品做不好，很重要的一个原因就是没有想清楚什么是 Agent 所处的环境，什么是环境的反馈，Agent 一旦开始执行任务，一定得有一个反馈能够知道，现在离任务完成更近了，还是更远了，这个过程，本质上是通过与环境交互，增加信息量的过程。

作者在论文中给出了 2 个示例，我们详细介绍一下第一个示例，Query 是 “除了苹果遥控器，还有什么设备可以控制那些最初设计用来使用苹果遥控器进行交互的程序？”，这个问题就是一个典型的多跳问题，首先要通过苹果遥控器来找到它最初设计用来控制什么程序，也就是下图中根据（苹果遥控器，控制，Front Row）这个关系找到 Front Row，然后再去查找（x, 控制，Front Row）里面的那个 x，论文示例中之所以看起来耗费了那么多步，是因为实际搜索时，不可能像我们现在这样有上帝视角——清楚地知道搜索的关键词，只能观察搜索结果然后思考，对搜索关键词做出调整，在这个过程中，环境反馈就是搜索返回结果，大模型负责思考、观察、并发起动作（搜索）。

文中对比了另外三种方法，分别是标准、CoT、Act-Only。

其中标准就可以理解为 LLM 直接回复了；CoT 就是在那个没有推理模型的年代，通过加 Let’s think step by step 强迫 LLM 输出中间过程的方法，就跟我们解决复杂的数学题时要把中间过程写出来一样，LLM 也是一样的，受限于注意力带宽，它能把文字通顺地生成出来已经不容易了，额外还能兼顾一点简单的逻辑推理，要是非常复杂的运算或者推理，只能通过中间计算结果（打草稿），然后聚沙成塔，最终回答一个相对复杂的问题；而 Act-Only 可以理解成闷头干，不思考。

对于论文中的第一个例子，ReAct 中的 Act 是为了补充信息，文章是 2023 年发布的，站在当前 LLM 的发展水平，如果这个知识 LLM 本身在预训练阶段是训练进去的，那只靠 Reasoning 是有可能把这个多跳关系构建出来的，也就是那对于 o1、R1 这种推理模型，是有很大概率可以回答出来的。

优缺点

优点

  • 透明度高：可以很容易的追溯每一步的思考、行动、观察，在一些对可解释性有要求的场景比较适用

  • 增强可靠性、缓解 LLM 幻觉：通过与外界环境交互，减少 LLM 闷头想的清况，可以引入外部信息，有助于缓解 LLM 幻觉，例如规划到某地的旅游行程，基于 LLM 现有知识可能认为坐飞机合适，但基于外部工具发现近期恶劣天气较多，坐飞机容易延误，将出行方式调整为高铁，会使得整个结果更加可靠

  • 适应性强：由于行动很大程度是基于环境反馈做出的，因此比较适应动态环境，例如在编程 Agent 中，可能面临所依赖的基础程序（Python、gcc 等）缺失、库缺失、版本不匹配、路径错误等等问题，ReAct 能够基于错误提示灵活调整下一步行动

  • 可扩展性强：要扩展 Agent 能力时，增加工具配合一些 Prompt 调整就可以实现，而无须重新训练模型

缺点

  • 缺乏全局观：由于它 “贪婪” 的原理，没有长期规划机制，只能走一步看一步，因此容易陷入局部最优，可能会在某些问题上反复兜圈子，或者遗忘最初的任务，这也就是所谓的 “漂移” 问题

  • 延迟高：每调用一次工具，都需要与 LLM 交互

  • Token 消耗多：每一步都需 LLM 交互，随着交互的次数增多，token 消耗成倍增加，成本高、响应慢

  • 错误易累积：一旦某个环境引入错误，后续环节都将带着这个错误，例如在所给工具比较容易混淆时，选择了错误的工具，后续都将带着错误的结果，逐步放大，由此导致整个执行路径跑偏

  • 终止条件难控制：LLM 可能在没有完成任务的情况下，过早地给出结果，也有可能一直循环下去，因此在实践中一般会设置最大迭代次数

适用场景

除了一些明显不适合使用 ReAct 的场景，例如实时交互场景、基于文本直接总结等，剩下的场景，其实很大程度上取决于 LLM 自身的能力，因此没有一刀切的准则判断，需要在实践中摸索。

例如对于一个长上下文能力弱的 LLM，随着任务的推进，它可能会忘了最初的任务设定，最终无法完成任务，但对于长上下文能力强的 LLM，则可以一直记着最初的任务设定，从顺利完成任务。

Plan-and-Execute

Plan-and-Execute 是一种更为经典的设计模式，其基本思想甚至在基于 LLM 的 Agent 兴起之前就已经有了，后又经过了不断完善，形成了现在大家公认的一种设计模式。

它的核心思想是将任务分为 “规划（Planning）” 与“执行（Execution）”两大阶段。Agent 先由 LLM 生成完整的多步计划，再由执行器严格按计划逐步完成每一步，任务的结果，按照当前的实现，通常是隐式实现的，也就是把执行结果给到 LLM，有 LLM 根据任务描述生成答案，比如说问题“北京的平均海拔比上海的平均海拔高吗”，规划为 [“获取北京平均海拔”, “获取上海平均海拔”] 两步，最终隐式比较两者的值，没有单独的模块做最终结果的求解。

典型的执行流程如下：

1
2
Plan → Execute Step 1 → Execute Step 2 → ... -> 最终答案

需要注意的是，部分在介绍 Plan-and-Execute 的文章有提到有 Re-plan 的过程，这通常是融合了其他设计模式的思想

从它的原理可以看出，Plan-and-Execute 可以看作是一种 “自顶向下” 的思维范式，一开始从全局制定计划，然后按部就班开始执行，这种模式要想取得好的效果，它需要规划阶段有一个顶尖高手，把任务拆解好，执行时不容有失，一旦执行结果与规划时的设定出现偏差，最终结果很可能会不理想。

从控制论的角度来讲，它缺乏根据执行结果反馈调整自身行为的机制，因此属于开环控制系统，这也就意味着不能在环境多变的场景下使用这种模式。

优缺点

优点

  • 高效执行：冗余思考少，执行更直接

  • 结构清晰：拥有明确的长期 / 全局规划，结构清晰，不容易陷入局部最优

  • 复杂任务表现优异：由于规划时能够站在全局视角考虑问题，对于步骤数量众多、问题复杂的问题，通常表现较好

缺点

  • 缺乏灵活性: 计划一旦制定，就不会轻易改变。环境变化适应性差，计划一旦脱节易全盘失败

  • 脆弱性: 如果初始计划有任何瑕疵，或者在执行过程中遇到任何预料之外的情况（比如 API 调用失败、环境变化、工具返回错误信息），整个任务链很可能会中断并最终失败。它缺乏从失败中恢复和调整的能力

  • 缺乏学习能力: 即使任务失败了，下一次遇到同样或类似的任务，它还是会制定出同样错误的计划，因为它没有记忆和反思过去失败的机制

适用场景

这种模式适合那种可以确的规划步骤，并且在执行的时候，不会出现预料之外情况的场景，例如资料分门别类整理，流水线式的数据处理等，不适合那种环境可能随时在变的场景，例如编程，随时面临依赖缺失、版本不匹配、路径错误等问题。

ReWoo

ReWoo 是 2023 年 5 月由论文 ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models 所提出的一种设计模式，论文的动机是说现有的 Agent 系统存在大量的冗余 Prompt（没点名，但其实说的就是 ReAct，因为越往后执行，要带着之前所有的历史观察、思考、执行记录）。论文的成果 “ReWOO achieves 5× token efficiency and 4% accuracy improvement on HotpotQA” 中比较显著的地方也是 token 消耗的显著减少。

它跟 Plan-and-Execute 类似，也是一种 “自定向下” 的模式，如下图所示，它也是先对任务过规划，先拆解成一系列步骤，然后开始执行，但与 Plan-and-Execute 的核心区别在于两点：

  • 在执行阶段（Worker 模块），是并行执行的，而不是像典型的 Plan-and-Execute 那样串行执行，因此总体延迟会比较低

  • 有一个单独的 Solver 模块，它是一个单独的综合各 Worker 执行结果来获取最终答案的模块，是一种显式获取最终结果的设计模式

典型的执行流程如下：

1
2
3
Plan → 并行执行[Step 1, Step 2 → ...] -> Resolve -> 最终答案


下图是它与 ReAct 的对比，从左图最左侧的图标大小可以看出，越到后面，图标越大，意味着累积的上下文越多，消耗的 token 也就越多，而右侧则是规划好了一把执行，然后再做整体聚合汇总。

由于 ReWoo 也不会根据执行结果来调整自身行为，因此也属于一种开环控制系统。

优缺点

优点

  • 极高的效率潜力： 与 ReAct 先比， 大大减少 Token 消耗，工具调用可以并行执行，延迟较低

  • 职责清晰： 模块化设计，规划、执行、结果求解各司其职

缺点与 Plan-and-Execue 类似。

Reflexion

Reflexion 是 2023 年 10 月由论文 Reflexion: Language Agents with Verbal Reinforcement Learning 所提出的一种新的设计模式，也是 NeurIPS 2023 论文。

如下图，它的基本流程是如下：

  • 生成策略：其实就是规划了一系列步骤

  • 使用初始化的策略开始执行，形成初始化轨迹（也就是这一系列步骤的执行历史）

  • 使用评估器（一般通过 Prompt 方式让 LLM 评估）评估这个轨迹，形成文字总结（标题中的 Verbal Reinforcement），例如 “这轮执行时忘记使用绝对路径；Python 解释器没有使用 3.11 版本” 等，通过对过往执行经验的总结，期望再下一次执行时能够得到改进

  • 如果评估没通过，或者没有达到最大重试次数，则循环执行上述步骤

我们依然与 Plan-and-Execute 做对比，它的生成策略步骤，其实跟 Plan-and-Execue 的规划步骤是一样的，核心区别在一下两点：

  • 会对整个执行轨迹进行反思，总结经验

  • 基于总结的经验，会持续迭代，以期望达到更好的效果

从上面的描述可以看出，它能基于执行结果的反馈来自我改善，是一个典型的闭环控制系统。不仅有生成策略时的宏观视角，也有具体执行后反思的微观视角，所以，可以看成是一种 “自顶向下”和 “自底向上” 思维范式的结合。

优缺点

优点

  • 具备学习与适应能力：通过反思改进策略，模拟试错学习

  • 无需外部标注数据：自我监督，适合少样本场景

  • 提升鲁棒性：对初始错误有容错和恢复能力

缺点

  • 实现复杂：由于增加了反思机制、记忆模块等，实现的复杂度增加

  • 资源消耗多：由于需要对行为轨迹做评估，并进行反思，计算量增加，token 消耗较多

  • 评估、反思对 LLM 能力要求高：若 LLM 能力不强，可能已经完成的任务会被认定为未完成，陷入循环，LLM 能力不强时，反思的加入也可能反而适得其反，可能会误导后续迭代

ReflAct

ReflAct 是 2025 年 5 月在论文 ReflAct: World-Grounded Decision Making in LLM Agents via Goal-State Reflection 中提出的新的设计模式，下图是文章与 ReAct 的对比，可以看出 ReflAct 最大的特点，是在每一步动作执行后，都会进行反思，ReflAct 并不会反思下一步该干什么，而是反思当前的状态与任务目标是什么关系，是离完成任务更进了，还是更远了。

跟 Reflexion 相比，Reflexion 是对一次执行的所有结果综合起来进行反思，也就是 step 1 ~ T 所有的步骤（这在 Reflexion 中称为一个 Trajectory，轨迹）进行反思，而 ReflAct 改为每一步对与目标做个对齐，提高了反思的频率，同时减小了反思的粒度。换句话说，ReflAct 是将 Reflexion 的执行后反思，变成了执行中反思，这样在大多数情况下可以减少 Token 消耗，也能提高效果。另一个区别是，ReflAct 没有显式的步骤规划。

从直观上来看，ReflAct 应该是能 Work 的，就好比一个编程 Agent，在运行程序时报 Python 版本不对，则当下立即就可以进行反思，从而调整动作，而不是等着一连串执行完了憋大招，一个是反馈周期长，一个是累积的上下文长了，反思可能反而容易丢失信息。

总结

上面介绍的这 5 种典型的设计模式，基于他们的核心贡献大致可以分为以下三类：

  • 感知环境并与环境互动：ReAct

  • 复杂任务执行之前先规划一下：Plan-and-Execute、ReWoo

  • 反思与迭代优化：Reflexion、ReflAct

基于他们之间的核心差异，可以构建如下的关系图：

实际落地的 Agent，不可避免要与外部环境进行互动，因此 ReAct 的思想一般都会有，为了能够提高适应性，对尽可能多的任务种类都能够完成，因此一般会有规划的部分，而为了提高和保证效果，一般还会有反思模块。