AI Agent 架构设计：从 ReAct 到 Multi-Agent 协作

系统梳理 AI Agent 四大组件（规划/记忆/工具/行动），对比 ReAct、Plan-Execute、Multi-Agent 三种架构模式的工程取舍。

2026/06/226 分钟阅读1.0k 字

一、概述

2024 年以来，AI Agent 从论文概念迅速演化为工程落地热点。从单 Agent 的工具调用到多 Agent 的协作编排，架构选型直接决定了系统的可靠性、可观测性与成本。本文拆解 Agent 的四大核心组件，对比三种主流架构模式，给出实际落地的取舍建议。

二、Agent 四大组件

一个完整的 AI Agent 由四个正交组件构成，每层的实现深度决定了 Agent 的能力上限：

 TEXT34 行 
12345678910111213141516171819202122232425262728293031323334
┌────────────────────────────────────────┐
│              用户输入 / 任务              │
└────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────┐
│  ① Planning（规划）                     │
│  · 任务分解      · 路径选择              │
│  · 反思与修正    · 优先级排序              │
└────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────┐
│  ② Memory（记忆）                       │
│  · 短期记忆（上下文窗口）                 │
│  · 长期记忆（向量存储 + 检索）            │
│  · 工作记忆（当前任务状态）               │
└────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────┐
│  ③ Tools（工具）                        │
│  · Function Calling  · API 网关         │
│  · 代码执行沙箱    · 浏览器自动化         │
│  · 知识库检索      · 多模态工具           │
└────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────┐
│  ④ Action（行动）                       │
│  · 工具调用    · 生成回复                │
│  · 追问澄清    · 终止并返回               │
└────────────────────────────────────────┘

2.1 Planning（规划）

规划是 Agent 智能的核心。LLM 原生具备"思维链"能力，工程上需要把它结构化为可执行的动作序列。

策略	原理	适用场景
Zero-shot	直接执行，无显式规划	简单单步任务
Chain-of-Thought	`"Let's think step by step"`	需要推理的逻辑题
Tree-of-Thought	多路径探索 + 回溯	复杂决策（博弈、数学证明）
ReAct	思考-行动循环交替	生产环境首选
Plan-Execute	先生成完整计划再逐步执行	多步依赖任务

2.2 Memory（记忆）

 TEXT
123456789101112
短期记忆（Short-term）
  └─ 全量上下文：对话历史 + 工具调用结果
  └─ 限制：受 Context Window 约束（128K 仍不够用）

长期记忆（Long-term）
  └─ 向量数据库存储（Pinecone / Milvus / pgvector）
  └─ 检索策略：语义相似度 + 时间衰减 + 重要性评分

工作记忆（Working Memory）
  └─ 当前子任务状态机
  └─ 已完成步骤的中间结果

记忆管理的核心矛盾是上下文预算分配。推荐策略：

 TS
123456789
// 上下文预算分配（以 8K 窗口为例）
const CONTEXT_BUDGET = {
  systemPrompt: 800,        // 系统指令 + 工具描述
  workingMemory: 1200,      // 当前任务状态
  shortTermHistory: 3000,   // 最近 6 轮对话
  retrievedLongTerm: 1500,  // 向量检索到的相关记忆
  toolResults: 1500         // 最近工具调用结果
}

2.3 Tools（工具）

工具的可靠性直接决定 Agent 是否"能用"。三个关键工程点：

1. 工具描述质量

 JSON
12345678910111213141516
{
  "name": "search_knowledge_base",
  "description": "在内部知识库中搜索与查询相关的最新文档。",
  "parameters": {
    "query": {
      "type": "string",
      "description": "自然语言搜索查询。",
    },
    "top_k": {
      "type": "integer",
      "default": 5,
      "description": "返回结果数（1-20）",
    }
  }
}

2. 工具执行安全

代码执行工具必须走沙箱（Docker / Firecracker / WebContainer）
写操作（创建文件、发送消息）需增加人工确认步骤
API 调用需限流 + 熔断 + 超时（推荐 30s）

3. 工具错误处理

错误类型	处理策略
超时	返回部分结果，让 LLM 决定是否重试
参数错误	返回明确错误描述 + 参数格式提示
权限拒绝	返回替代方案建议，不暴露系统细节

三、三种主流架构对比

3.1 ReAct（Reasoning + Acting）

最成熟的单 Agent 模式。Agent 在"思考→行动→观察→思考"的循环中逐步接近目标。

 TEXT
12345678910111213141516
User: "查一下过去一周关于 React 19 的 GitHub Trending 项目"

Round 1:
  Thought: 需要查询一周内 React 19 相关项目
  Action: search_github_trending(language="javascript", since="weekly")
  Observation: 返回 25 个 JS 项目，其中 3 个提到 React 19

Round 2:
  Thought: 需要过滤和排序这些结果
  Action: filter_and_sort(topics=["react19", "react"], sort_by="stars")
  Observation: 返回前 3 个项目（stars: 1.2k, 890, 760）

Round 3:
  Thought: 已经拿到足够信息，可以总结回复
  Final Answer: "过去一周 React 19 相关 GitHub Trending TOP 3: ..."

ReAct 优势：每一步都有思考记录，可解释性强，适合生产调试。

ReAct 局限：串行执行导致时延高（每个 round 一次 LLM 调用），复杂任务需要 8-15+ 轮。

 TS
12345678910111213
// ReAct 循环伪代码
async function reactLoop(prompt: string, tools: Tool[], maxRounds = 10) {
  let context = prompt
  for (let i = 0; i < maxRounds; i++) {
    const { thought, action, actionInput } = await llm.think(context)
    if (action === 'Final Answer') return thought

    const observation = await executeTool(action, actionInput)
    context += `\nObservation: ${observation}`
  }
  throw new Error('ReAct loop exceeded max rounds')
}

3.2 Plan-Execute（先规划后执行）

先让 LLM 生成完整执行计划，再逐步执行每个步骤，执行期间不再调用 LLM 做规划决策。

 TEXT
123456789101112
Planner LLM:
  Step 1: search_docs("React 19 new features")
    └─ Expected: 3-5 篇官方文档链接
  Step 2: visit_page(step1.results[0].url)
    └─ Expected: React 19 新特性文本
  Step 3: visit_page(step1.results[2].url)
    └─ Expected: React 19 迁移指南文本
  Step 4: summarize([step2.result, step3.result])
    └─ Expected: 300 字精华总结

Executor（逐步执行 step 1-4，仅在遇到不确定时回调 Planner）

适用场景：步骤之间依赖明确的任务（代码审查报告、市场分析周报）。

风险：计划执行到一半发现信息不足时，需要"重新规划"机制。推荐在执行第 3 步后做一次 plan-check。

3.3 Multi-Agent（多 Agent 协作）

多个专业 Agent 各司其职，通过消息传递或共享状态协作。两种主流编排模式：

A. 层级编排（Supervisor Pattern）

 TEXT
1234567891011
              ┌──────────────┐
              │  Supervisor  │  ← 负责任务分配 + 结果汇总
              │    Agent     │
              └──┬───┬───┬──┘
         ┌──────┘   │   └──────┐
         ▼          ▼           ▼
   ┌──────────┐ ┌────────┐ ┌──────────┐
   │ Researcher│ │ Coder  │ │ Reviewer │
   │ Agent    │ │ Agent  │ │ Agent    │
   └──────────┘ └────────┘ └──────────┘

B. 对等编排（Debate / Collaboration Pattern）

多个 Agent 平等对话，各自提出方案后交叉评审，直到达成共识。

模式	适用场景	通信开销	一致性
Supervisor	任务可明确拆分的项目	低	高（Supervisor 仲裁）
Debate	需要多视角验证的决策	中	中（可能未收敛）
Sequential	流水线式任务（分析→编码→审查）	低	高（上下游明确）

3.4 架构选择决策树

 TEXT
12345678
任务是否可拆分为独立子任务？
  ├─ 否 → ReAct（单 Agent 足够了）
  ├─ 是 → 子任务间依赖是否明确？
            ├─ 是 → Plan-Execute
            └─ 否 → 需要不同专业能力？
                      ├─ 是 → Multi-Agent（层级编排）
                      └─ 否 → ReAct 循环 + 更丰富的工具

四、总结

维度	ReAct	Plan-Execute	Multi-Agent
开发复杂度	★★☆	★★★	★★★★★
可观测性	★★★★★	★★★★	★★★
任务适应性	通用	计划驱动型	多角色协作型
Token 消耗	高（多轮思考）	中	极高
推荐起点	默认首选	明确步骤时	复杂项目拆解

工程落地建议：

从 ReAct 起步 — 先跑通单 Agent + 工具调用的闭环，积累真实场景数据
工具先行于架构 — Agent 的能力上限取决于工具质量和 API 稳定性，而非架构复杂度
可观测性不可妥协 — 每个 Thought / Action / Observation 必须完整记录，LangSmith / Phoenix 等工具可大幅降低调试成本
Token 成本意识 — Multi-Agent 的 Token 消耗是指数级的；生产环境应设置 Agent 调用次数硬上限（如 50 轮）
Human-in-the-Loop — 涉及数据写入、对外发送、代码部署的操作必须有人工确认节点

延伸阅读：生产级 RAG 系统设计笔记 | LLM 架构演进史

版权声明 · CC BY-NC-ND 4.0

署名-非商业性使用-禁止演绎 4.0 国际

版权归属

本作品著作权归 窦长友 所有，首次发布于，受相关知识产权法律法规保护。

授权范围

可自由分享 — 在任何媒介以任何形式复制、转载本文
不得用于商业目的 — 未经书面授权禁止商用
禁止演绎修改 — 不得改编、转换或以本文为基础再创作

署名要求

转载或引用时须明确标注作者姓名、原文出处及本许可协议链接。不得以任何方式暗示或声称作者为您的使用背书。

查看完整许可证法律文本（英文）

由 GitHub Discussions 驱动