LLM Agent 设计范式：从 ReAct 到多 Agent 协作

提到 Agent，很多人首先想到 ReAct：模型想一步、调用一次工具、看完结果再想下一步。它确实是重要的基本循环，但不是 Agent 设计的全部。一个系统还要决定：是否先规划、能否回溯、失败后怎样改进、任务怎样分工，以及什么时候结束。

本文把常见模式放进同一张地图，分别说明它们解决的问题、运行方式、代价和适用场景。文中的“模式”是工程上的可组合结构，不是互斥的产品类别；一个编程 Agent 完全可以同时使用规划、ReAct、测试反馈和任务委派。

先厘清：工作流与 Agent，以及三个设计维度

一种实用的区分是：工作流的执行路径主要由代码预先规定；Agent由模型在运行时选择下一步及工具。两者都可以调用模型，也都可能有循环。这是架构上的区分，并非“用了 LLM 就是 Agent”。Anthropic 对工作流与 Agent 的定义

选型时可以分别回答三个问题：

1. 下一步如何决定？ 固定步骤、先规划后执行、每步观察后决定，还是搜索多个候选路径？
2. 怎样判断做得对？ 工具返回值、测试、规则、独立评审或人工反馈？
3. 谁来执行？ 单 Agent、预设并行分支，还是由协调者动态分派给多个 Agent？

例如“ReAct + Reflexion + 多 Agent”没有概念冲突：工作 Agent 用 ReAct 调工具，失败后根据测试结果反思，协调 Agent 再汇总多个工作 Agent 的产出。

一、单 Agent 的决策模式

1. ReAct：边观察边行动

运行方式：模型根据当前任务和已有观察选择一个动作，系统执行工具，再把结果交回模型；这个循环持续到模型给出答案或达到停止条件。原始 ReAct 论文将推理与行动交错，借助外部环境的信息修正后续决策。ReAct 论文

用户目标 → 判断下一步 → 调用工具 → 观察结果
                   ↑                    │
                   └──── 更新判断 ──────┘

例子：用户问某项目为何构建失败。Agent 先读错误日志，定位出错文件，再检查依赖配置，修改后重新运行构建。第二步取决于第一步的结果，所以很难把全部路径写死。

优势是能利用新证据调整行动，适合开放式检索、代码修复、网页操作和环境探索。代价是串行工具调用多，延迟和费用可能上升；若缺少停止条件，模型也可能反复搜索或执行无效动作。工具结果还需要明确的可信边界，不能把网页或日志里的指令当成用户命令。

适用条件：下一步高度依赖当前工具结果，且工具能提供有用的环境反馈。若步骤固定，普通工作流通常更直接。

2. Plan-and-Execute：先规划，再执行与重规划

运行方式：先把目标拆成步骤，再逐步执行；遇到新信息或失败时更新计划。这里的 Plan-and-Execute 是一个工程模式；Plan-and-Solve 论文研究的是先制定计划再求解的提示方法，两者相关，但不等于所有规划执行系统都采用那篇论文的实现。

目标 → 计划 [步骤 A, B, C] → 执行 A → 检查 → 执行 B ...
                           └── 必要时重新规划 ──┘

例子：迁移一个前端项目时，先列出“盘点依赖、修改配置、替换 API、运行测试、修复回归”，每完成一项更新状态。如果盘点发现不兼容插件，再调整后续步骤。

它比纯 ReAct 更容易保持长期目标、展示进度和恢复中断；但计划可能建立在不完整的信息上，过度坚持初始计划反而会误导执行。适合长任务、可拆分目标、需要进度跟踪的场景。实践中常让计划只规定阶段目标，具体动作仍交给 ReAct 循环。

3. ReWOO：先生成工具计划，再统一求解

ReWOO（Reasoning WithOut Observation）将规划与工具观察分开：规划器先写出含变量依赖的工具调用计划，执行器按计划取得结果，求解器最后综合答案。它针对每次取回工具结果后都重新调用模型所带来的重复上下文开销。ReWOO 论文

问题 → 规划器：E1=搜索 A；E2=基于 E1 搜索 B
     → 执行器：取得 E1、E2
     → 求解器：结合证据作答

适用场景：工具调用之间的依赖大致能提前写出，比如多跳资料检索、批量资料收集。相较 ReAct，它减少了“每拿到一条结果就重新思考”的次数；相应地，计划对意外结果的适应性较弱。若工具反馈经常改变任务方向，就需要加入失败后的重规划或改用 ReAct。

4. Tree of Thoughts：搜索多条思路

Tree of Thoughts（ToT）把中间思路当作可扩展的节点：生成多个候选，评估潜力，继续扩展较好的分支，必要时回溯。它主要解决单一路径很容易走进死胡同的问题。Tree of Thoughts 论文

问题
 ├─ 思路 A → A1 → A2
 ├─ 思路 B → B1
 └─ 思路 C（评估后舍弃）

适合有明确约束、可以比较中间状态的规划或推理问题，例如复杂谜题、策略搜索。与 ReAct 的关键区别是：ToT 主要在候选思路空间里搜索；ReAct 主要通过真实工具或环境取得观察。ToT 的分支数、深度和评估调用都会增加成本；如果评估标准含糊，搜索也可能只是放大主观判断。结合工具观察和树搜索的研究方向可参见 LATS。

5. Reflexion：把失败经验带入下一次尝试

Reflexion 的重点是跨尝试改进：Agent 执行一轮任务，收到环境或评估反馈，写下对失败的文字总结，并在下一轮尝试时使用这段经验。这里的“反思”是上下文或记忆中的反馈，不意味着模型参数被训练更新。Reflexion 论文

尝试 1 → 测试失败 → 总结失败原因 → 尝试 2 → 再测试

例子：代码修复后测试仍失败，Agent 记录“此前只修了输入校验，忽略空列表路径”，下一轮针对遗漏路径修改。它适合可重复尝试、反馈明确的任务，如编程、游戏环境和具有自动评分器的任务。若反馈本身不可靠，反思可能固化错误判断；还应限制尝试次数，避免无止境地改写同一答案。

二、工作流与协作模式

以下五种是常见的系统编排结构；它们定义步骤之间的关系，而非要求某一种模型推理方式。Anthropic 的原始模式总结

6. 提示链：固定顺序，逐步加工

将任务拆成预先确定的步骤，前一步输出成为后一步输入，必要时在步骤之间加入格式或质量检查。例如“提取合同条款 → 转为结构化数据 → 生成人类可读摘要”。

适合步骤稳定、每一步输入输出容易定义的任务。它容易测试和定位问题，但上游错误会传到下游，且所有步骤串行执行会增加延迟。它与 Plan-and-Execute 的区别是：提示链的路径通常在设计时就确定，后者的计划可针对具体任务生成和修改。

7. 路由：先判断类型，再走专门路径

先把请求分类，再交给对应提示、模型或工具流程。例如客服系统将“订单查询”“退款申请”“技术故障”送入不同处理路径；简单问题也可交给较便宜的模型。

适合任务类型清晰且不同类型需要明显不同处理方式的系统。主要风险是入口误分类，因此要测分类质量，并为不确定输入提供兜底路径。路由只决定“去哪里”，不负责解决分支内部的复杂任务。

8. 并行化：独立分工或多次独立尝试

有两种常见做法：分片把独立子任务同时执行，例如分别审阅安全、性能和可维护性；多次尝试或投票让多个分支处理同一问题，再合并或比较结果。

适合分支之间依赖少、并发可缩短总等待时间，或确实需要多个独立视角的任务。它可能降低墙钟延迟，但通常会增加总模型调用量。合并结果必须有规则，且多个相似模型的输出不一定真正独立。与下面的协调者模式相比，并行化的分支通常由系统预先定义。

9. Orchestrator-Workers：动态拆分与委派

协调 Agent 根据具体输入决定需要哪些子任务，交给工作 Agent 执行，再整合结果。比如处理一个跨多个模块的代码需求时，协调者先确定要查哪些文件、哪些任务能并行、哪些修改有前后依赖。Anthropic 对协调者模式的说明

适合任务复杂度和分工边界随输入变化的场景，如大规模代码修改、跨来源研究。它比预设并行分支更灵活，但协调、上下文传递和结果合并都会增加成本。只有当子任务具有清晰边界时，委派才容易带来收益；共享文件或状态的并发写入还要处理冲突。多 Agent 对话式协作可参见 AutoGen 论文。

10. Evaluator-Optimizer：生成、评审、修改

一个组件产出候选结果，另一个组件按标准评审，生成者据此修改，直到达到验收条件或迭代上限。例如生成技术文档后检查是否覆盖指定接口、示例能否运行、术语是否一致。

适合质量标准能表达清楚，而且评审意见能推动改进的任务。与 Reflexion 相似处是都利用反馈；区别在于 Evaluator-Optimizer 强调生成者与评审者的职责分离及单个产物的迭代优化，Reflexion 强调把一次尝试的经验带入后续尝试。评审者如果只给空泛意见，循环会徒增费用。能使用测试、规则或人工验收时，优先把这些可核实信号接入评审。

三、把模式放在一起比较

模式	下一步由谁决定	对反馈的使用	主要收益	主要代价	典型场景
提示链	预设流程	步骤间校验	可控、易测	串行、路径僵硬	固定内容加工
路由	分类器或规则	分类后进入分支	专门处理不同输入	错误分类	客服分流、模型选择
并行化	预设分支	最后汇总或投票	缩短等待、增加视角	调用量与合并成本	多维审查
ReAct	Agent 逐步决定	每次工具结果都影响下一步	适应未知环境	串行调用、可能跑偏	检索、操作、调试
Plan-and-Execute	计划器决定阶段，执行器处理细节	检查后可重规划	长任务更有条理	初始计划可能失效	项目迁移、复杂交付
ReWOO	规划器预设工具依赖	执行后集中求解	减少重复推理	适应突发结果较弱	可预估的多跳检索
ToT / 搜索	搜索与评估器选分支	比较候选中间状态	可回溯、探索多方案	分支成本高	约束型推理与规划
Reflexion	Agent 基于上轮经验重试	跨尝试记忆反馈	从失败中调整	依赖可靠反馈	测试驱动的修复
Orchestrator-Workers	协调者动态分派	汇总各工作结果	适应动态分工	协调与冲突成本	跨模块任务
Evaluator-Optimizer	评审者决定是否再改	对当前产物迭代	提升可评价的质量	评审可能空转	文档、代码、翻译打磨

表中的“代价”是结构带来的通常趋势，并不是性能承诺。实际效果取决于模型、工具质量、任务数据、并发限制和验收方式。

四、怎样选：从任务结构倒推

1. 先看是否真的需要 Agent。 单次模型调用、检索增强或固定提示链能完成时，先使用这些结构；动态循环会带来额外延迟、成本和失误面。
2. 路径已知，用工作流。 固定顺序选提示链；输入类别差异明显加路由；子任务独立且有合并规则时再并行。
3. 路径未知，但环境会给线索，用 ReAct。 给工具清楚的输入输出说明，并设置步数、费用和完成条件。
4. 任务较长，加入计划与检查点。 计划用于保持目标和可见进度；让执行结果能触发重规划。若工具依赖可提前确定且重复推理昂贵，可考虑 ReWOO。
5. 一次尝试容易失败，选择合适的反馈循环。 有测试或评分器，用 Reflexion 让下一次尝试利用失败信息；有可表达的质量标准，用 Evaluator-Optimizer 审查和修改当前产物。
6. 确实需要探索多个解，才扩大搜索或分工。 对可评价的候选路径用 ToT；对子任务边界随输入变化的工作用 Orchestrator-Workers。二者都会增加调用和合并成本。

以“修复线上构建失败”为例：先由固定流程收集日志和仓库版本；由 Agent 按 ReAct 读取错误、检查文件和执行构建；任务横跨多个模块时由协调者分派检查；最后以构建和测试结果决定是否继续修复。这里每增加一层，都对应一个明确需求，而不是因为某种模式听起来更高级。

五、落地时比模式名称更重要的事

• 定义成功条件与停止条件：通过哪些测试算完成？最多调用几次工具、花多少时间？
• 让反馈尽量可核实：工具结果、测试和结构化校验通常比模型自行宣布“完成”更有说服力。
• 记录中间状态：计划、工具调用、输入输出、失败原因和最终证据应能追溯，长任务需要检查点与恢复机制。
• 控制动作边界：读操作、写操作和对外操作的权限分开设计；高影响动作设置明确的人工检查点。
• 用真实任务评估：比较完成率、人工接管率、总成本和端到端耗时。模式越复杂，越需要证明额外调用确实改善结果。

结论：ReAct 回答“拿到新观察后下一步做什么”；规划回答“怎样保持长期目标”；搜索回答“要不要尝试别的路径”；反思和评审回答“怎样利用反馈改进”；编排与多 Agent 回答“任务由谁做、如何汇总”。先明确任务中真正不确定的部分，再选择相应模式，通常比先挑一个框架更有效。

参考资料

• ReAct: Synergizing Reasoning and Acting in Language Models
• Plan-and-Solve Prompting
• ReWOO: Decoupling Reasoning from Observations
• Tree of Thoughts: Deliberate Problem Solving with Large Language Models
• Reflexion: Language Agents with Verbal Reinforcement Learning
• Language Agent Tree Search
• AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation
• Anthropic: Building effective agents