从 ReAct 到 Multi-Agent：我对 AI Agent 架构演进的一次完整梳理

引言

2023 到 2025 这两年，AI Agent 大概是被讨论得最多、也最容易被误解的一个概念。

很多人对 Agent 的认知还停留在「会调用工具的聊天机器人」，但如果你真正动手做过一个能跑起来的 Agent，就会发现事情远没这么简单——它要会思考、会规划、会用工具、会从失败里爬起来，还得在跑了几十步之后不把自己绕晕。

这篇我想把 Agent 架构这两年的演进脉络完整捋一遍：从最早的 ReAct，到解决短视问题的 Plan-and-Solve，再到突破单体瓶颈的 Multi-Agent，最后聊聊把它们推上生产环境要补哪些课。

不堆术语，尽量讲清楚「每一代架构到底解决了上一代的什么痛点」。理解了这条因果链，你再去选型就不会盲目跟风。

一、AI Agent 到底比聊天机器人多了什么

在进入架构之前，得先把一个最基础的问题说清楚：Agent 和普通的对话模型，差别到底在哪？

1.1 Agent 的三个核心要素

我习惯把一个 Agent 拆成三件套：

大脑（LLM）：负责推理和决策，是整个系统的中枢；
工具（Tools）：让 Agent 能真正「动手」——查数据库、调 API、读写文件、执行代码；
记忆（Memory）：让 Agent 记得住上一步干了什么、跨会话还能想起之前的上下文。

普通聊天模型只有「大脑」，输入一句、输出一句，本质是一次性的问答。而 Agent 的关键在于它有一个闭环：观察环境 → 思考 → 行动 → 再观察，循环往复直到任务完成。

1.2 从 Prompt Engineering 到 Agent Engineering

这是一个常被忽略的认知升级。

维度	Prompt Engineering	Agent Engineering
交互模式	单轮请求-响应	多轮自主循环
上下文管理	一次性塞进 prompt	动态裁剪、检索、压缩
工具使用	几乎没有	核心能力
错误处理	重新问一遍	自我反思、重试、降级

一句话总结：Prompt Engineering 是在「调一句话怎么问」，Agent Engineering 是在「设计一个能自主完成任务的系统」。后者是前者的工程化进化。

二、ReAct：把「想」和「做」第一次拧到了一起

2.1 核心思想

ReAct 这个名字是 Reasoning + Acting 的缩写，2022 年由 Google Research 提出，可以说是后来一切 Agent 架构的奠基范式。

它的思路朴素得近乎直觉：让模型在每一步先「想一下」，再「做一下」，然后看看结果，再决定下一步。 这个循环长这样：

Thought（我现在该干什么）
   ↓
Action（调用某个工具）
   ↓
Observation（看工具返回了什么）
   ↓
Thought（根据结果，下一步该干什么）
   ↓
   ......（循环，直到得出最终答案）

伪代码层面，一个最小的 ReAct 循环大概是这样：

python

def react_loop(query, tools, max_steps=10):
    context = [query]
    for _ in range(max_steps):
        thought = llm.think(context)          # 生成思考
        if thought.is_final():                # 模型认为可以收尾了
            return thought.answer
        action = thought.action               # 决定调哪个工具
        observation = tools.run(action)       # 执行
        context.append((thought, action, observation))  # 拼回上下文
    return "超出最大步数"

ReAct 最大的贡献，是把过去黑箱式的「输入→输出」拆成了可观测、可干预的一步步。你能看到模型每一步在想什么，这对调试 Agent 太重要了。

2.2 ReAct 的三个硬伤

但 ReAct 用多了就会撞墙，主要是三个问题——而后面几代架构，基本都是在补这三刀：

短视：它每一步只做局部最优决策，没有全局规划。任务一复杂，就容易走着走着跑偏。→ 催生了 Plan-and-Solve。
串行慢：一步一步顺序执行，哪怕有几个工具其实可以同时调，它也只能排队。→ 催生了并行工具调用。
没长期记忆：循环一结束，上下文就丢了，跨会话完全失忆。→ 催生了向量数据库做长期记忆。

三、Plan-and-Solve：先画好地图，再上路

3.1 从「走一步看一步」到「先规划再执行」

ReAct 的短视问题，本质是因为它没有事先想清楚整条路。Plan-and-Solve 的解法很直接：在动手之前，先让模型把整个任务拆解成一张计划图，然后再按图施工。

它的分层结构通常是这样：

用户请求
   ↓
任务分解器（拆成若干子任务）
   ↓
依赖分析器（理清子任务先后关系，生成 DAG 有向无环图）
   ↓
调度执行器（能并行的并行，该串行的串行）
   ↓
结果整合器（把各步结果拼成最终答案）

和 ReAct 最大的区别在于：ReAct 是「走一步看一步」，Plan-and-Solve 是**「先画图，再执行」，而且引入了依赖管理和拓扑排序**——它知道哪些任务必须等前面的做完，哪些可以并行抢跑。

3.2 一个例子：代码审查 Agent

假设你要做一个自动审查 Pull Request 的 Agent。用 Plan-and-Solve 的话，它会先 plan() 出一张审查清单：

json

{
  "steps": [
    {"id": 1, "task": "检查代码风格", "depends_on": []},
    {"id": 2, "task": "扫描安全漏洞", "depends_on": []},
    {"id": 3, "task": "分析测试覆盖率", "depends_on": []},
    {"id": 4, "task": "综合生成审查报告", "depends_on": [1, 2, 3]}
  ]
}

注意第 1、2、3 步的 depends_on 都是空的——它们可以并行跑；而第 4 步必须等前三步都完成。执行器拿到这张 DAG 后，自动做拓扑排序，该并行的并行，效率比 ReAct 一步步串着跑高得多。

四、Multi-Agent：单个 Agent 的天花板，得靠分工来突破

4.1 为什么单 Agent 不够用了

Plan-and-Solve 解决了短视，但还有个根本限制：所有事都压在一个 Agent 身上。 这会带来四个瓶颈：

能力边界：一个 Agent 的 system prompt 和工具集是有限的，什么都想干，结果什么都干不精；
上下文塞爆：任务一长，上下文窗口很快就满了，模型开始「忘事」；
单点故障：一步崩了，整个任务跟着崩；
难以扩展：想加新能力，只能往同一个 Agent 里硬塞，越塞越乱。

解法很自然——别让一个人干所有活，组个团队。

4.2 三种协作模式

Multi-Agent 的精髓在于「怎么分工」。常见的有三种模式：

模式	结构特征	适用场景
层级协作 Hierarchical	一个 Orchestrator 总指挥，下面带若干各司其职的子 Agent	任务能清晰拆成独立子任务
对等协作 Peer-to-Peer	Agent 之间通过消息总线 / 共享状态互相通信、协商	需要多轮博弈的复杂决策
流水线协作 Pipeline	提取 → 分析 → 生成，像工厂传送带一样顺序传递	数据处理、内容生产

4.3 一个直观的例子：内容生产流水线

最好理解的是 Pipeline 模式。比如做一套「自动写技术博客」的系统，可以配三个角色：

Researcher：负责查资料、整理素材；
Writer：拿着素材写初稿；
Reviewer：审稿、挑错、提修改意见。

三个 Agent 各用最适合自己任务的模型，前一个的输出作为后一个的输入，串成一条流水线。这其实就是把人类团队「研究→写作→审核」的协作方式，原样搬给了 AI。

4.4 三代架构的关系：叠加，不是替代

很多人误以为 Multi-Agent 出来了，ReAct 就该淘汰了。其实恰恰相反，它们是层层叠加的补强关系：

ReAct 解决「单个 Agent 怎么边想边做」；
Plan-and-Solve 解决「单个 Agent 怎么不短视」；
Multi-Agent 解决「单个 Agent 的能力和容量天花板」。

在一个真实的 Multi-Agent 系统里，每个子 Agent 内部往往还跑着 ReAct 循环，整体又用 Plan-and-Solve 来编排。三者是套娃式共存的。

五、推上生产环境，你还得补这三门课

Demo 跑通和上生产，中间隔着一条鸿沟。下面这三块，是我认为最容易被低估、却最致命的。

5.1 可靠性

LLM 调用天然不稳定——会超时、会限流、会偶尔抽风。生产级 Agent 至少要做到：

超时重试：给每次工具调用加重试装饰器，别一次失败就全盘崩溃；
熔断降级：某个工具连续失败时自动熔断，切到备用方案，而不是无限重试拖垮系统；
可观测性：每一步的 Thought、Action、Observation 都要能追溯。Agent 出问题时，没有日志你根本无从下手。

5.2 成本控制

Multi-Agent 很爽，但每个 Agent 都在烧 token。不加控制的话，一个复杂任务跑下来的账单可能吓你一跳。常见手段：

简单任务用小模型，复杂推理才上大模型；
上下文做压缩和裁剪，别把整个历史无脑塞进去；
给单次任务设 token 预算上限，超了就强制收尾。

5.3 安全与权限

这点在企业落地时是红线。Agent 能调用工具，就意味着它能对真实世界产生副作用——删数据、发请求、花钱。所以：

给 Agent 做细粒度的权限校验，能读的不一定能写，能查的不一定能删；
高危操作（删除、支付、对外发送）必须有人工确认环节；
把工具调用关在沙箱里，限制它的实际作用范围。

六、写在最后

回头看这条演进线：ReAct → Plan-and-Solve → Multi-Agent，其实是一个不断「补短板」的过程——每一代都在解决上一代撞墙的地方。

但我想强调的是：这世上没有「最优架构」，只有「最适合你场景的架构」。

任务简单、链路短，一个朴素的 ReAct 循环就够了，上 Multi-Agent 纯属过度设计；任务复杂、需要多角色协作，才值得搭多 Agent 系统。盲目堆架构，只会让你的系统又贵又难调。

真正的功夫，是在理解每种范式「解决什么、代价是什么」之后，做出克制而合理的选择。说到底，架构是手段，让 AI 真正解决实际问题、创造价值，才是目的。

如果你也在做 Agent，欢迎交流你踩过的坑——这个领域变化太快，互相印证才能少走弯路。