Agent 架构选型：RAG、ReAct、Multi-Agent 到底怎么选

去年下半年我接触过一个团队，他们在做一个客服 Agent 。一开始很简单，就是一个 Agent 接工单、查知识库、给答案。上线之后发现有些问题回答得不够准，于是加了一个 Planner 来拆解复杂问题；后来又觉得答案质量不稳定，加了一层 Reflection 让模型自己检查；再后来觉得客服、退款、投诉应该分开处理，拆成了三个专门的 Agent，又加了一个 Coordinator 来分发任务。

三个月下来，系统里跑着七个 Agent ，外加一个 Planner、一个 Reflection 模块、一个 Coordinator。架构图画出来，挺唬人的。

但实际效果呢？响应时间从两秒多变成了将近四十秒，调用成本涨了十几倍，而用户满意度几乎没有提升。

这不是个例。我见过不止一个团队走过类似的路：某个环节效果不够好，第一反应是「加一层」。RAG 不够就加 Agent，Agent 不够就加 ReAct，ReAct 不够就加 Planning，Planning 还不够就上 Multi-Agent。最后系统变成了一个谁都说不清楚内部到底在干什么的黑盒子。

问题不在于这些模式本身不好用，而在于大家默认「更复杂 = 更先进」。但真实情况恰恰相反——该用什么架构，取决于任务本身的不确定性和复杂度，不是取决于你想让系统看起来多「Agent」。

这篇文章想把 RAG、Tool Use、ReAct、Planning、Reflection、Multi-Agent 这几个经常被混在一起讲的概念重新捋一遍，搞清楚它们各自解决什么问题，以及最关键的——什么时候该用、什么时候不该用。

先纠正一个误区：RAG、ReAct、Multi-Agent 根本不是一个层级

很多资料喜欢把 RAG、ReAct、Multi-Agent 并列成「五种 Agent 模式」讲，这个分类方式本身就有点问题。

之所以经常被放在一起，是因为在企业场景里，「LLM + 私有知识库」几乎就等于「RAG」这个词的日常用法，而 RAG 又常常是 Agent 系统里的一个基础组件，久而久之大家就习惯把它们当成同类东西并排比较。

但仔细看，RAG 和 Agent 解决的其实是两类完全不同的问题。RAG 的核心问题只有一个：模型不知道的信息，怎么从外部找回来。它的路径基本是固定的——查询改写、检索、重排序、拼接上下文、生成答案，一条流水线走到底，模型自己没什么决策权。

Agent 不一样。Agent 面对的是任务问题，它的核心循环是「推理—行动—观察」，路径是动态的，模型可以自己决定下一步做什么、要不要换个方式再试一次。RAG 主要是「读」，Agent 可以「读 + 写 + 执行」。

顺带一提，这两年 RAG 本身也在往 Agent 化的方向走，业内管这个叫 Agentic RAG——简单说就是以前是系统帮模型去找资料，现在是 Agent 自己判断要不要查、去哪查、查一次够不够、不够要不要换个数据源再查。这个细节不用深究，知道有这么个趋势就够了。

把这一层理清楚之后，整篇文章的骨架其实就出来了：

RAG 解决「我知道什么」，Tool Use 解决「我能做什么」，ReAct 解决「边做边判断」，Planning 解决「复杂任务怎么拆」，Reflection 解决「做完怎么检查」，Multi-Agent 解决「不同角色怎么协作」。记住这句话，后面所有的内容都是在展开它。

能力底座：RAG 和 Tool Use

RAG 的流程前面已经说过，不用重复展开。真正值得多说几句的是 Tool Use，因为这是 Agent 系统里最容易被低估、也最容易在生产环境里翻车的一环。

工具大致可以分成三类。一类是数据类工具，比如搜索、RAG、查数据库、查 CRM；一类是动作类工具，比如发邮件、创建工单、更新数据库、执行部署；还有一类是计算类工具，比如跑代码、调计算器、执行 SQL。

类型	典型工具
数据类工具	搜索 · RAG · 查库
动作类工具	发邮件 · 建单 · 部署
计算类工具	跑代码 · 执行 SQL

以前大家理解的「工具」很简单，就是给 LLM 接一个 API，能调用就行。但放到生产环境里跑起来会发现，工具其实是 Agent 的「行动边界」——一旦 Agent 有权限调用一个能改数据、能发消息、能触发部署的工具，权限管理、参数校验、幂等性、审计日志、超时重试、人工审批这些问题就全来了。

举个具体的例子：假如你做一个自动退款的 Agent，用户点了退款按钮，网络抖动导致请求重试了一次，如果这个 Action Tool 没有做幂等性控制，系统可能会给用户退两次款。这种问题在 Demo 阶段基本不会暴露，因为演示的时候没人会去模拟网络重试、没人会连续点两次按钮。但一旦上线，这些边界情况迟早会出现。

所以很多团队做 Agent 卡在从 Demo 到生产环境这一步，往往不是模型能力不够，而是工具这一层的工程细节没做扎实。

执行机制三兄弟：ReAct、Planning、Reflection

这三个模式经常被放在一起讲，但它们解决的问题、付出的代价、适合的场景都不一样，搞混了很容易用错。

ReAct：边想边做

ReAct，说白了就是让模型边想边做：推理一步、行动一步、观察结果、再推理、再行动，循环下去直到给出最终答案。这个模式适合那种一次推理解决不了的任务。比如让 Agent 分析一家公司近三年的经营情况，它可能需要先查基本信息，再查财报，再查行业数据，算完增长率发现还得对比一下竞争对手，过程中发现某块数据缺失，又得回去再查一次，最后才能形成结论。这种走一步看一步、路径没法提前定死的任务，就是 ReAct 的用武之地。

但 ReAct 不是免费的。每多循环一轮就多一次模型调用，成本和延迟都在往上涨，如果某一步工具调用出了错，这个错误还会被带到后面的每一步里被放大。更麻烦的是，如果没有设计好终止条件，循环可能会一直转下去而收不了尾。用 ReAct 之前先想清楚这几个代价划不划算，而不是觉得「能自己判断下一步」听起来很聪明就无脑上。

Planning：先画地图再动身

Planning，解决的是 ReAct 解决不了的问题。ReAct 是走一步看一步，但复杂任务有时候更适合先把地图画出来再动身。典型的 Plan-and-Execute 结构是：先让一个 Planner 把大目标拆成几个子任务，然后依次执行，执行完检查一下，发现有问题再重新规划一版。

这里有个容易被忽略的细节：比较成熟的做法不是「一次性把计划写完、然后严格按计划执行到底」，而是动态规划——边执行边看结果，根据实际情况调整后面的计划。任务在执行过程中出现意外几乎是常态，死守最初的计划反而容易出问题。

Planning 适合长文档研究、数据分析、软件开发这类步骤多、周期长的任务，简单问答或者一次工具调用就能搞定的事，完全没必要上 Planning，那是杀鸡用牛刀，还得多付一份规划的成本。

Reflection：做完再检查

Reflection，或者说得更工程一点，叫 Evaluator-Optimizer 模式——生成一个结果，让另一层（或者同一个模型换个角度）去评估，发现问题就改，改完再评估，直到满意为止。

判断要不要上 Reflection，有个挺实用的标准：越容易定义「什么叫好」，越适合用 Reflection。写代码好不好，能不能跑通、有没有报错，这个是可以客观判断的；写 SQL 对不对，执行一下就知道；但如果是「这段文案够不够打动人」这种主观性很强的东西，Reflection 的效果就会打折扣，因为评估这一步本身就没有明确标准。

三个模式放在一起对比一下会更清楚：

模式	解决什么	代价	典型场景
ReAct	边做边判断	调用多、延迟高、错误容易被放大	路径没法提前确定的探索性任务
Planning	拆解复杂任务	前期规划有成本	长文档研究、多阶段流程
Reflection	保证输出质量	多一轮评估调用	有明确评判标准的产出类任务

一个 Agent 不够用了：Multi-Agent 的五种协作方式

很多人一想到「任务复杂」，第一反应就是拆成多个 Agent。这个思路本身没错，但前提理解错了。

上 Multi-Agent 不是因为「一个 Agent 太笨，所以多找几个来帮忙」，而是因为任务本身存在稳定的角色分工、上下文边界或者能力边界。这两者听起来差不多，实际差别很大——前者是在掩盖单个 Agent 设计得不好，后者才是真正需要拆分的信号。

怎么判断该不该拆？一个比较直观的自查方法是，看看你的单个 Agent 身上挂了多少不相关的职责。如果它既要查数据库、又要查知识库、还要写代码、做安全审查、生成报告、发邮件、处理客户投诉——这时候 Prompt 会越写越长，工具列表会越堆越多，上下文会越来越乱，模型很难在一个角色里把所有事都做好。这种情况才真正到了该拆的时候。

拆开之后，常见的协作方式大概有这几种。

串行（Sequential），几个 Agent 按固定顺序一个接一个执行，A 做完交给 B，B 做完交给 C。适合那种流程本身就是固定的场景，比如先做资料收集、再做内容生成、最后做审核，顺序天然就是这样，不需要动态调整。

并行（Parallel），多个 Agent 同时处理各自的子任务，最后汇总结果。适合子任务之间互不依赖、可以同时跑的情况，比如同时从几个不同数据源拉信息。并行能明显降低整体延迟，但代价是 Token 消耗会上去，而且最后怎么把几路结果合并成一个连贯的输出，本身也是个不小的工程问题。

中央协调（Coordinator），有一个中枢 Agent 负责判断任务该分给谁，动态调度。适合任务类型不固定、需要根据输入内容临时决定走哪条路的场景。

层级式（Hierarchical），类似公司的组织架构，上面有个 Manager，下面分几个 Lead，每个 Lead 再带一组 Agent。这种适合任务复杂到已经不是一层调度能管过来的程度。

群体协作（Swarm），Agent 之间可以互相通信，谁擅长接下来这一步就由谁接手，没有固定的中心节点。适合需要多个角色持续讨论、动态调整分工的场景，比如几个专家角色围绕一个问题反复交流意见。

这五种拓扑不是非此即彼，实际项目里经常会混用，比如一个大的 Coordinator 底下，某几步用并行，另几步用串行。关键不是记住这五个名字，而是先想清楚你的任务到底有没有稳定的角色边界——没有的话，拆出来的多个 Agent 很可能只是在互相传话，并不会让系统变聪明。

这里也提前说一句：多 Agent 协作会带来不少额外的成本，包括评估变难、安全边界变复杂、可靠性下降——具体展开放在下一节讲。

真正的架构选型：该怎么选

前面讲了这么多模式，回到最实际的问题——具体到一个任务，到底该用哪个？

选型第一原则：能用 Workflow 就别上 Agent，能用 Single Agent 就别上 Multi-Agent。

复杂度是要花代价的，能力越强的架构往往意味着越高的成本、越长的延迟、越难排查的问题，不要为了「看起来更 Agent」去多加一层。

具体怎么判断，可以顺着几个问题往下问：

1. 任务需不需要模型本来不知道的外部知识？需要的话，上 RAG。

2. 任务需不需要执行动作，比如查数据库、发消息、跑代码？需要的话，加 Tool Use。

3. 执行路径是固定的，还是要根据中间结果动态调整？固定的话用普通的 Workflow 就够了，不需要引入 Agent；动态的话才需要 ReAct 这类能自己判断下一步的机制。

4. 任务步骤是不是很多、周期很长？是的话上 Planning，把大任务拆成可执行的小任务。

5. 结果需不需要反复验证、有没有明确的「好坏」标准？有的话加一层 Reflection。

6. 最后，任务里是不是存在稳定的专业角色分工，而不是硬凑出来的？如果是，才考虑 Multi-Agent。

顺着这几个问题走一遍，一条决策路径基本就出来了：

之所以要强调「能不用就不用」，是因为多 Agent 真正落地之后，坑往往比预期多。

最直接的是成本，每加一个 Agent，基本就多一份模型调用的钱。其次是延迟，如果几个 Agent 之间是串行调用，链路会越拉越长，前面提到的那个客服 Agent 案例，延迟涨了将近二十倍就是这么来的。

再往下是上下文传递的问题——谁应该知道什么、哪些信息要在 Agent 之间共享、哪些不用，这个问题看起来简单，实际做起来经常一团乱麻，搞不好某个 Agent 该看到的信息没传过去，不该看到的反而全传了。

还有一个容易被忽视的风险是错误传播：前一个 Agent 出了错，后一个 Agent 会基于错误的结果继续往下做，越往后错得越离谱，最后追溯问题的时候很难判断到底是哪一步出的岔子。这也直接带来了最后一个麻烦——调试难度。单个 Agent 出问题，看一条执行轨迹基本就能定位；多个 Agent 协作出问题，得把 A→B→C→D 整条链路的执行记录全部拉出来一步步核对，排查成本完全不是一个量级。

顺带提一句，判断一个系统是不是「够自主」，不能光看它有几个 Agent。一个能自己规划、自己执行、自己观察结果、自己纠错、还能在异常情况下恢复执行的单 Agent，自主程度可能远超一堆互相调用但各自都很「笨」的多 Agent 系统。多不代表强，这是个挺容易被架构图的复杂程度带偏的误区。

不要问「哪个模式最先进」

写到这里，其实核心观点已经很清楚了：这些模式之间没有谁比谁「更高级」这回事。

RAG 不是 Agent 的简化版，Single Agent 也不是 Multi-Agent 路上必经的过渡阶段，ReAct 更不是所有场景的默认答案。它们解决的根本就是不同的问题——RAG 解决知识，Tool 解决行动，ReAct 解决动态执行，Planning 解决复杂任务的拆解，Reflection 解决输出质量，Multi-Agent 解决的是角色之间怎么协作。

真正成熟的 Agent 架构，不是把这些能力全部叠加上去，而是清楚知道什么时候不该用它们。

最好的 Agent，从来不是最复杂的那个，而是用刚刚好的架构，完成刚刚好的自主性。