Agent 架构模式完全指南：从 ReAct 到 Graph 的多维度解析与选型决策

引言

如果你搜索"AI Agent 架构模式"，会看到 ReAct、Multi-Agent、Graph、RAG、MCP 等各种概念被混在一起讨论。但很少有人指出一个关键问题：它们并不属于同一维度。

把 ReAct 和 MCP 放在同一张表里对比，就像把"发动机排量"和"车身颜色"放在一行 — 它们描述的是 Agent 的不同侧面。

这篇文章基于 Andrew Ng（2024）、Lilian Weng、LangGraph 官方文档等权威来源，提出一个四维度分类框架，将 Agent 模式拆解为：

• 推理模式 — Agent 怎么"想"
• 能力模式 — Agent 能"做什么"
• 编排模式 — 多个 Agent 怎么"协作"
• 基础设施 — Agent 怎么"连接外部世界"

最终你会看到：一个完整的 Agent 系统 = 推理 × 能力 × 编排 × 基础设施。

一、四维度分类总览

graph TB
    subgraph AgentInternal[Agent 内部]
        R[推理模式 Reasoning<br>怎么想？]
        C[能力模式 Capability<br>能做什么？]
        R -->|drives| C
    end
    subgraph SystemLevel[系统层面]
        O[编排模式 Orchestration<br>怎么协作？]
        I[基础设施 Infrastructure<br>怎么连接？]
        O -->|uses| I
    end
    C -->|coordinates| O
    R -->|selects| O

💡 Andrew Ng 在 2024 年提出的四大 Agentic Design Pattern — Reflection、Tool Use、Planning、Multi-Agent — 正好对应了本文的推理模式（Planning + Reflection）、能力模式（Tool Use）和编排模式（Multi-Agent）。这从侧面验证了该分类框架的合理性。

二、维度一 — 推理模式（Agent 怎么"想"）

推理模式定义了 Agent 的内部认知循环：面对一个任务，Agent 如何组织思考、决定行动、处理反馈。

Lilian Weng 在其经典文章《LLM-powered Autonomous Agents》中将 Agent 的核心组件归纳为 Planning、Memory、Tool Use、Action，其中 Planning（规划）就是推理模式的核心。

2.1 ReAct — 边想边做

核心思想：推理与行动交替进行，每一步都"先想再做"。

由 Yao et al. (2022) 提出，是最经典的 Agent 推理模式。

flowchart LR
    Q[User Query] --> T[Thought 推理]
    T --> A[Action 行动]
    A --> O[Observation 观察]
    O -.->|4| T
    T -->|5| Ans[Answer 回答]

适用场景：简单工具调用、单轮问答、步骤较少的任务

优点：实现简单（几十行代码）、推理透明可调试

缺点：长链条容易迷失（Lost in the Middle）、缺乏全局规划、Token 随步骤线性增长

2.2 Planner-Executor — 先想清楚再做

核心思想：将规划与执行分离，先制定完整计划，再逐步执行。

flowchart TB
    U[User Task] --> P[Planner 制定计划]
    P --> S1[Step 1]
    S1 --> S2[Step 2]
    S2 --> S3[Step 3]
    S3 --> S4[...]
    S4 --> Out[Output 汇总结果]

适用场景：多步骤任务（5+ 步骤）、软件开发、数据处理流水线

优点：全局视角、Planner/Executor 可用不同模型（省钱）、可复用执行结果

缺点：规划阶段无法预见执行问题、执行失败需重新规划、两阶段缺乏动态交互

2.3 Reflection — 做完再反思

核心思想：Agent 生成结果后，通过自我评估发现不足并修正。

由 Shinn et al. (2023) 在 Reflexion 中形式化，Agent 维护一个失败经验记忆池，避免重复犯错。

flowchart TB
    Agent[Agent 生成] --> Critic[Critic 评估]
    Critic -->|pass| Output[Output 最终输出]
    Critic -.->|feedback| Agent
    Agent -->|log failures| Memory[Memory 失败经验]
    Memory -.->|avoid| Agent

适用场景：代码生成、内容创作、数学推理等需要质量把控的场景

优点：输出质量显著提升（15-30%）、可积累经验、与 ReAct/Planner 正交组合

缺点：Token 消耗 2-3 倍、弱模型可能"越改越差"、延迟增加

推理模式对比

💡 选型建议：简单任务用 ReAct；复杂任务用 Planner-Executor；对质量要求高时叠加 Reflection。三者可以自由组合：Planner-Executor + Reflection 是最常见的高质量组合。

三、维度二 — 能力模式（Agent 能"做什么"）

能力模式定义了 Agent 除了纯语言生成之外，还能与外部世界交互的方式。

Andrew Ng 在 2024 年的演讲中特别强调：Tool Use 是 Agentic 的核心能力，是区分"Chat"和"Agent"的关键分界线。

3.1 Tool Calling — 调用外部工具

核心思想：LLM 通过 Function Calling 将自然语言意图转化为结构化的 API 调用。

用户: 帮我查北京到上海的机票

LLM 输出:
{
  "function": "search_flights",
  "arguments": {"origin": "北京", "destination": "上海", "date": "2026-05-10"}
}

工具返回 → LLM 生成自然语言回复

所有主流模型（OpenAI、Anthropic、Google）都原生支持。

适用场景：对话式助手、API 编排、企业内部系统的自然语言入口

优点：原生支持、JSON Schema 标准化、是其他所有能力的基础

缺点：工具 >20 个时选择准确率下降、复杂参数组合容易出错

3.2 RAG — 检索增强生成

核心思想：生成回答前先从知识库检索相关文档，注入上下文。

由 Lewis et al. (2020) 在 RAG 论文中提出。

flowchart LR
    Q[User Query] --> E[Embedding 向量化]
    E --> V[(Vector DB 向量数据库)]
    V -->|Top-K docs| Aug[Augment 拼接上下文]
    Q -.->|query| Aug
    Aug --> LLM[LLM 生成回答]

适用场景：知识问答、客服系统、合规审查

优点：解决知识过时和幻觉问题、来源可追溯、成熟度高

缺点：检索质量决定回答质量、固定流水线无法按需调整、多轮上下文管理复杂

3.3 Agentic RAG — 自主检索决策

核心思想：让 Agent 自主决定何时检索、检索什么、是否需要再次检索，打破固定流水线。

flowchart TB
    Agent[Agent<br>ReAct 推理] -->|检索 1| DB[(Vector DB 知识库)]
    DB -->|docs A| Agent
    Agent -->|检索 2| DB
    DB -->|docs B| Agent
    Agent -->|检索 3| DB
    DB -->|docs C| Agent
    Agent -->|done| Out[Output 综合报告]

Agentic RAG 本质上是 RAG 能力 + ReAct 推理的组合。

适用场景：复杂研究问题、深度分析报告、需要多源交叉验证的场景

优点：检索更精准、支持多轮迭代检索、可处理多跳推理

缺点：延迟高（多轮检索 + 多次 LLM 调用）、Token 消耗大、实现复杂

能力模式对比

💡 关键洞察：Tool Calling 是"做事"的能力，RAG 是"知道"的能力。Agentic RAG 不是 RAG 的替代品，而是 RAG + 推理模式的组合体。这就是为什么说"它们不属于同一维度" — Agentic RAG 跨越了能力和推理两个维度。

四、维度三 — 编排模式（多 Agent 怎么"协作"）

编排模式定义了当系统中有多个 Agent 或多个步骤时，它们之间的协调和组织方式。

LangGraph 官方文档将编排模式分为三大类：单 Agent 工作流、多 Agent 协作、层级式管理。

4.1 Graph 模式 — 图结构编排

核心思想：用有向图定义整个执行流程，节点是 Agent/函数，边是流转规则。

Graph 本质上是一个有限状态机（FSM），支持循环、分支、并行、汇合等所有控制流。

flowchart TB
    U[User Query] --> P[Planner]
    P --> C[Coder]
    C --> T[Test Runner]
    T -->|Pass| R[Reviewer]
    T -->|Fail| C
    R -->|Approve| Out[Output]
    R -->|Need Fix| C

核心概念：Node（节点）、Edge（边）、Conditional Edge（条件边）、State（共享状态）

适用场景：任何需要条件分支和循环的复杂工作流

优点：最灵活的编排方式、状态统一管理、可调试、其他模式都可以用 Graph 实现

缺点：学习曲线陡峭、简单场景过度设计

💡 Graph 的特殊地位：Graph 是编排模式的"基础设施层"。Multi-Agent 和 Hierarchical 都可以用 Graph 来实现。但它本身也是一个独立的编排模式 — 当你的流程需要循环和条件分支时，即使只有一个 Agent，Graph 也是最佳选择。

4.2 Multi-Agent 协作 — 多角色协同

核心思想：多个 Agent 扮演不同角色，通过消息传递协同完成任务。

flowchart TB
    subgraph Division[分工型]
        Planner[Planner] --> FE[Frontend]
        Planner --> BE[Backend]
        Planner --> DBA[DBA]
        FE --> Reviewer[Reviewer]
        BE --> Reviewer
        DBA --> Reviewer
    end

    subgraph Manager[管理型]
        M[Manager] --> W1[Worker 1 搜索]
        M --> W2[Worker 2 分析]
        M --> W3[Worker 3 撰写]
    end

    subgraph Debate[辩论型]
        A[Agent A 正方] --> J[Judge 裁决]
        B[Agent B 反方] --> J
    end

适用场景：需要多种专业能力的复杂任务

优点：突破单 Agent 能力天花板、可并行、角色清晰

缺点：Token 消耗 N 倍、协调开销大、调试困难

4.3 Hierarchical Agent — 层级式管理

核心思想：树状层级组织 Agent，上层决策下层执行。

flowchart TB
    CEO[CEO Agent] --> CTO[CTO]
    CEO --> CMO[CMO]
    CEO --> COO[COO]
    CTO --> Dev[Dev Lead]
    CTO --> Ops[Ops Lead]
    Dev --> Coder[Coder]
    Dev --> Tester[Tester]

适用场景：企业级 Agent 系统、大型项目自动化、需要多层级管理的场景

优点：可扩展性极强、关注点分离、故障隔离

缺点：设计复杂度最高、层级通信开销大、调试极其困难

编排模式对比

💡 三者的关系：Hierarchical 是 Multi-Agent 的特例（层级式分工）。Graph 可以实现 Multi-Agent 和 Hierarchical，但 Graph 也独立适用于单 Agent 的复杂工作流。三者是递进关系：Graph → Multi-Agent → Hierarchical，复杂度逐级递增。

五、维度四 — 基础设施（Agent 怎么"连接"）

5.1 MCP — 标准化工具协议

核心思想：定义一套标准化的 Agent-工具通信协议，实现工具的即插即用。

由 Anthropic 于 2024 年底提出，被称为 “AI 的 USB 接口”。

flowchart LR
    Agent[Agent Client] <-->|MCP| Proto{{MCP Protocol}}
    Proto --> S1[MCP Server 1<br>文件系统]
    Proto --> S2[MCP Server 2<br>数据库]
    Proto --> S3[MCP Server 3<br>API]

三种核心能力：Tool（可调用的工具）、Resource（可读取的数据源）、Prompt（可复用的提示模板）。

适用场景：工具生态建设、跨平台集成、企业级 Agent

优点：工具与 Agent 解耦、支持动态发现、社区生态快速增长（Cursor、OpenClaw 已支持）

缺点：协议仍在快速迭代、额外抽象层带来开销、调试复杂度高

MCP 与其他维度的关系

MCP 是跨维度的基础设施：

flowchart LR
    subgraph 推理模式
        R[ReAct / Planner]
    end
    subgraph 能力模式
        T[Tool Calling / RAG]
    end
    subgraph 编排模式
        M[Multi-Agent / Graph]
    end
    R -->|调用| T
    T -->|通过| M
    subgraph 基础设施
        MCP[MCP 协议]
    end
    T -.->|标准化| MCP
    M -.->|共享| MCP

这也是为什么不能把 MCP 和 ReAct 放在同一维度对比 — MCP 是底层的连接协议，其他模式是上层的架构模式。

六、全维度对比矩阵

以下矩阵按四个维度组织，每个维度内部的对比才有意义：

推理模式对比

能力模式对比

编排模式对比

七、选型决策树

基于四维度框架，选型不再是"选一个模式"，而是每个维度选一个模式，然后组合。

第一步：选择推理模式

你的任务需要多步推理吗？
├─ 否 → 直接用 LLM（不需要 Agent）
└─ 是 → 需要全局规划吗？
         ├─ 否，边做边想就行 → ReAct
         └─ 是 → 对输出质量要求高吗？
                  ├─ 一般 → Planner-Executor
                  └─ 很高 → Planner-Executor + Reflection

第二步：选择能力模式

Agent 需要哪些外部能力？（可多选）
├─ 调用 API / 执行操作 → Tool Calling
├─ 查询知识库 → 简单查询用 RAG，复杂多跳查询用 Agentic RAG
└─ 都不需要 → 纯语言生成

第三步：选择编排模式

有多少个 Agent / 步骤？
├─ 1个 Agent → 需要循环/条件分支吗？
│              ├─ 否 → 不需要编排模式
│              └─ 是 → Graph
│
├─ 2-5个 Agent → 需要动态分工吗？
│                ├─ 否 → Graph 编排固定流程
│                └─ 是 → Multi-Agent（分工型）
│
└─ 5个以上 Agent → 是层级管理吗？
                   ├─ 是 → Hierarchical
                   └─ 否 → Multi-Agent（管理型）+ Graph

第四步：选择基础设施

工具数量 > 10 个，或需要跨平台复用吗？
├─ 是 → MCP
└─ 否 → 直接 Tool Calling 即可

八、组合配方

基于四维度框架，以下是经过验证的组合方案：

🥇 入门：ReAct + Tool Calling

推理: ReAct（边想边做）
能力: Tool Calling（3-10 个工具）
编排: 无（单 Agent）
基础设施: 无（直接 Function Calling）

适合: 个人助理、客服机器人
框架: LangChain + OpenAI

🥈 进阶：Planner-Executor + RAG + Reflection

推理: Planner-Executor（先规划后执行）+ Reflection（质量把关）
能力: Tool Calling + RAG（知识检索）
编排: 无或简单 Graph
基础设施: 无

适合: 代码生成平台、内容创作工具
框架: LangGraph + LlamaIndex

🥉 高级：Planner-Executor + Multi-Agent + MCP

推理: Planner-Executor + Reflection
能力: Tool Calling + Agentic RAG
编排: Multi-Agent（分工型）
基础设施: MCP

适合: AI 开发团队、企业级 Agent
框架: LangGraph + CrewAI + MCP SDK

🏆 终极：Graph + Hierarchical + Agentic RAG + MCP

推理: 各层不同（高层 Planner，低层 ReAct + Reflection）
能力: Tool Calling + Agentic RAG
编排: Graph + Hierarchical
基础设施: MCP

适合: 需要最高可靠性的生产系统
框架: LangGraph 全家桶

九、总结

💡 一句话总结：不要问"该用 ReAct 还是 Graph"，而要问"我的推理该用 ReAct 还是 Planner-Executor，编排该用 Graph 还是 Multi-Agent，能力需要 Tool Calling 还是 RAG"。这才是正确的选型思路。

参考资料

• Andrew Ng, “Agentic Design Patterns”, DeepLearning.AI, 2024
• Lilian Weng, “LLM-powered Autonomous Agents”, lil-log, 2023
• Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models”, ICLR 2023
• Shinn et al., “Reflexion: Language Agents with Verbal Reinforcement Learning”, NeurIPS 2023
• Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS 2020
• Anthropic, “Model Context Protocol (MCP) Specification”, 2024
• LangGraph Documentation, “Agent Patterns: ReAct, Plan-and-Execute, Multi-Agent”, 2025
• Microsoft, “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation”, 2023
• Liu et al., “Lost in the Middle: How Language Models Use Long Contexts”, 2023