Agent 架构全景图：从单次调用到多 Agent 协作，我盘点的 8 种设计！

admin@yesmiracle.net (万戈) — Fri, 14 Aug 2026 00:00:00 +0000

如果你最近在关注 Agent 圈，一定见过这些词：ReAct、Plan-then-Execute、Reflection、Graph、Multi-Agent、MCP……

看得越多，越容易懵：这些到底有什么区别？我该用哪个？它们是一回事吗？

这篇文章，我想用第一人称，把我做 Agent 基础设施这几年来理解的架构全景梳理一遍。从最简单的单次调用，到最复杂的图编排，一共 8 种设计。 每种我都会说清楚：核心循环长什么样、适合什么场景、工程上最头疼的问题是什么。

如果你更关心多 Agent 怎么协作，可以看我之前写的多Agent 系统架构设计系列（编排模式、通信层、演进路径、Agent 即服务共四篇）。这篇先讲「单 Agent 内部」的地基。

先给一张全景图

架构	核心循环	复杂度	典型场景
单次调用	问→答	★	翻译、结构化输出
ReAct	想→做→看→想	★★	通用工具调用
Plan-then-Execute	计划→执行	★★★	复杂任务拆解
Reflection	执行→反思→修正	★★★	高准确率要求
记忆增强	循环+记忆层	★★★★	长期任务、个性化
工具增强	发现→选→调	★★★★	工具密集场景
多 Agent	多循环协作	★★★★★	专业分工
图编排	节点+条件边	★★★★★	复杂工作流

复杂度不代表「高级」。很多生产系统，反而应该从最简单的开始。

1. 单次调用：最朴素，也最容易被低估

User → LLM → Response

没有循环。一次推理，模型自己决定要不要调工具，一次完成。

我刚做 Agent 的时候，总觉得要搞个复杂循环才叫 Agent。后来发现，大量真实需求（翻译、抽取、分类、结构化输出）一次调用就够了。 加循环反而引入不确定性。

工程难点反而是「简单」：怎么让输出稳定？怎么约束格式？答案通常是函数调用 + 强约束解码，而不是上循环。

2. ReAct：最经典的 Agent 循环

思考 → 行动 → 观察 → 再思考 → …

ReAct（Reasoning + Acting）是 Agent 圈的「Hello World」。模型每轮先想「我要做什么」，然后调用工具，观察结果，再继续思考。

这是绝大多数 Agent 框架的默认形态。它的精髓在于：把推理过程显式地写进上下文，让模型自己决定下一步。

工程难点有三个：

上下文膨胀：每轮对话都在累积，10 步之后 token 可能翻几倍
停止条件：什么时候该退出？步数上限、自洽性检查、还是用户确认？
错误恢复：工具调用失败，重试？换方案？还是直接放弃？

做过 Agent 的人都知道，ReAct 的坑几乎全在这三件事上。

3. Plan-then-Execute：先想清楚，再动手

[规划] 把任务拆成步骤 → [执行] 按步骤逐个做 → 汇总结果

ReAct 是「边想边做」，Plan-then-Execute 是「先想后做」。模型先输出一份完整的任务拆解，然后像执行清单一样逐个完成。

好处是可预测。每一步做什么都是预先规划好的，中途不会跑偏。而且每个子步骤可以用 ReAct 作为内层循环，形成「计划 + 行动」的两层结构。

我自己的经验：凡是涉及「多步骤、有依赖关系」的任务（比如写代码、做调研），先规划再执行，成功率明显高于裸 ReAct。 规划本身就是一次免费的「预演」。

4. Reflection：会自我反思的 Agent

执行 → 评估 → 发现问题 → 重新执行 → …

ReAct 跑完一轮就结束？Reflection 不这么认为。它加了一个「事后检查」环节：让模型评估自己的输出，发现问题，再迭代一轮。

典型实现是 Actor + Evaluator 分离：一个 Agent 干活，另一个 Agent 挑毛病，然后回到干活 Agent 手里修正。听起来简单，但效果往往出奇地好——很多「最后一轮质量差」的问题，其实就是缺一次反思。

代价是 token 消耗翻倍，而且反思轮次要有上限，否则会陷入自我怀疑循环。

5. 记忆增强：给循环加一个「硬盘」

循环 ←→ 短期记忆（当前上下文）
     ←→ 长期记忆（向量检索）
     ←→ 经验记忆（技能库）

前面的架构都假设「一次任务一次会话」。但真实世界的 Agent 需要记住：上次用户说过什么、这个项目的背景是什么、我上次踩过什么坑。

记忆增强架构把记忆拆成三层：

短期：当前会话上下文，随循环滚动
长期：跨会话的事实，用向量库检索
经验：从历史中沉淀的「技能」，下次直接复用

我做的 Hermes 就是这么设计的——memory 存长期事实，skills 存可复用的方法论，两者在每个循环里自动注入。记忆不是缓存，是 Agent 的「人格连续性」。

6. 工具增强：MCP 时代的主角

工具注册 → 发现 → 选择 → 执行 → 结果处理

当工具数量从 3 个涨到 300 个，问题就从「模型会不会调工具」变成了「模型怎么知道有哪些工具、该调哪个」。

这一层是我做 MCPZERO 的主场，也是这两年变化最大的地方：

MCP 把工具变成标准协议，Agent 不再为每个工具写适配器
渐进式发现（progressive discovery）让 Agent 按需加载工具，而不是启动时全部塞进上下文
安全网关 在工具调用节点上做校验——参数合法性、权限边界、危险操作拦截

工具增强的核心矛盾是：工具越丰富，Agent 越强大，但上下文越拥挤、攻击面越大。 这层架构的价值，就是在这三者之间找平衡。

7. 多 Agent：一群专家，还是一个全能？

Orchestrator → 派活 → Worker 们 → 汇总

当一个 Agent 的上下文装不下所有技能，就拆成多个专业 Agent：一个负责调研，一个负责写代码，一个负责审查，一个 Orchestrator 负责调度。

多 Agent 的复杂度是质的飞跃——状态一致性、死锁、谁做最终决策、Agent 之间怎么「说话」。我之前的系列文章用了四篇才讲完这块，这里不展开。

一句话总结我的观点：多 Agent 是最后的手段，不是第一选择。 单 Agent + 好工具，能解决 80% 的问题。

8. 图编排：把 Agent 变成状态机

[分析] → [路由] → [搜索] → [综合] → [校验]
              ↓           ↑
          [问用户] ────────┘

前面几种架构，流程都是隐式的——模型在循环里自己决定下一步。图编排反过来：用显式的有向图定义每一步。 节点是处理单元，边是条件路由，支持并行、分支、人工介入。

好处是可控、可预测、可审计。坏处是死板——图是预先画好的，模型只能在节点内部发挥，碰到图没覆盖的情况就抓瞎。

我的判断：图编排适合「流程已知、稳定性优先」的生产场景（比如企业审批流、风控流水线）；探索型任务（比如研究、写代码）更适合让模型自己走 ReAct。

混合架构才是现实

说了 8 种，但真实的生产系统几乎都是混合的：

底层是 ReAct 循环（核心引擎）
上层叠 Plan 或 Graph（编排层）
中间挂 记忆层（上下文管理）
外围接 工具层（MCP 注册）
复杂的再加 多 Agent 协作

比如我平时用的 Hermes：ReAct 驱动核心，memory + skills 提供持久化，cron + delegation 做编排，MCP 接外部工具。它不是一个「单一架构」，而是每层选最合适的模式。

写在最后

盘完这 8 种架构，我最大的感受是：架构是手段，不是目的。

不要因为「Graph 听起来高级」就用 Graph，不要因为「多 Agent 很酷」就强行拆。先想清楚你的任务特征：是线性的还是分支的？需要记忆吗？工具多不多？要不要人工介入？

从最简单的架构开始，遇到瓶颈再加复杂度——这是我在 Agent 基础设施这条路上，用无数个深夜换来的经验。

希望这份全景图，能帮你在架构选型时少走一点弯路。

如果你对 Agent 安全网关、MCP 渐进式发现这些底层架构感兴趣，欢迎关注 MCPZERO（mcpzero.io）——我正在做的开源 Agent 基础设施项目。

Plan-and-Execute on AI博士 万戈