> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/09_agents/9.3_multi_agent.md).

# 9.3 多智能体上下文传递

## 9.3.1 多智能体系统概述

**多智能体系统** 由多个协作的智能体组成，每个智能体专注于特定能力或任务。

```mermaid
graph TB
    O["协调者"] --> A["研究智能体"]
    O --> B["编码智能体"]
    O --> C["测试智能体"]

    A --> |"研究结果"| O
    B --> |"代码"| O
    C --> |"测试报告"| O
```

图 9-2：多智能体协作架构

## 9.3.1.1 Agent SDK 中的子智能体上下文隔离

在 Agent SDK 中，子智能体（Subagents）不仅是任务分解工具，更重要的是 **上下文隔离机制**。每个子智能体有自己的独立上下文窗口，只有必要的信息会返回给父智能体。

**上下文隔离的核心机制**：

```mermaid
graph TB
    M["主智能体<br/>上下文：5K tokens"]

    M -->|"委派: 搜索日志中的异常"| S1["子智能体 A<br/>上下文：200K tokens<br/>处理完整日志"]

    M -->|"委派: 分析代码性能"| S2["子智能体 B<br/>上下文：300K tokens<br/>处理完整代码库"]

    S1 -->|"返回: 3 个异常摘要"| M
    S2 -->|"返回: 2 个性能瓶颈"| M

    style M fill:#fff3e0
    style S1 fill:#e3f2fd
    style S2 fill:#e3f2fd
```

**关键特性**：

1. **独立上下文窗口**：子智能体的处理细节完全隔离，不污染主智能体的上下文
2. **摘要返回**：子智能体只返回精选的摘要结果（通常 1-2K tokens），而非全部处理过程
3. **并行执行**：多个子智能体可以同时工作，加快总体速度

**隔离如何降低上下文成本**：

示例：处理一份 100 页的 PDF 文档

```
❌ 不使用子智能体（单智能体方案）：
- 将 100 页 PDF 加载到上下文：50K tokens
- 模型逐页分析：产生大量中间输出（日志、临时结论等）
- 总体上下文膨胀至 150K+ tokens
- 注意力分散，效率低

✅ 使用子智能体（隔离方案）：
- 主智能体：定义分析任务（1K tokens）
- 启动子智能体：处理 100 页 PDF（子智能体内部上下文 50K）
- 子智能体内部进行详细分析、生成中间输出（子智能体内消化）
- 子智能体返回摘要：5 个关键发现（返回 2K tokens）
- 主智能体接收摘要：总上下文仅 3K tokens
- 成本：原方案 150K vs 隔离方案 50K + 2K + 1K = 53K（下降约 65%）
```

**何时创建子智能体**：

创建子智能体有成本（额外的 API 调用、延迟增加），只在以下情况使用：

| 场景          | 决策    | 理由       |
| ----------- | ----- | -------- |
| 并行处理多个独立任务  | ✅ 创建  | 充分利用并行加速 |
| 子任务产生大量中间数据 | ✅ 创建  | 隔离数据污染   |
| 需要专用的工具或提示词 | ✅ 创建  | 专业化处理    |
| 简单的信息查询     | ❌ 不需要 | 延迟得不偿失   |
| 顺序依赖的任务     | ❌ 不需要 | 并行无益     |

## 9.3.2 上下文传递的挑战

* **上下文膨胀**：如果每个智能体都接收完整上下文，Token 消耗会快速增长
* **信息干扰**：无关智能体的信息可能干扰当前智能体的判断
* **一致性维护**：多个智能体需要对共享信息有一致的理解

## 9.3.3 上下文共享机制

### 1. 共享黑板模式

引入一个共享记忆库或“黑板”，所有智能体都可以读取和写入这个公共空间。

* **工作方式**：智能体 A 将发现的证据写入黑板，智能体 B 读取并推理。
* **一致性**：通过访问控制和版本管理维护一致性。
* **优点**：信息同步快，避免点对点通信的复杂度。
* **缺点**：需要处理并发写入冲突。

### 2. 通信对话模式

智能体之间直接发送消息交换上下文。

* **工作方式**：智能体 A 发送消息给智能体 B：“请根据这些数据生成图表”。
* **优点**：明确的责任链，点对点隔离。
* **缺点**：通信链路可能复杂，长链条导致信息衰减。

## 9.3.4 高级协作模式：链式智能体协作

一种常见的思路是使用“链式协作”（Chain-of-Agents, CoA）：让多个智能体以“接力”的方式分段阅读和处理长上下文任务。

```mermaid
sequenceDiagram
    participant Doc as 长文档
    participant W1 as 工人A
    participant W2 as 工人B
    participant M as 经理

    Note over Doc: 分割为片段 1, 2
    W1->>Doc: 读取片段 1
    W1->>W2: 传递要点/中间状态
    W2->>Doc: 读取片段 2 + 结合要点
    W2->>M: 汇总最终信息
    M->>M: 生成最终答案
```

图 9-3：链式智能体协作

这种模式让上下文在智能体链中逐步传递和累积，而非一次性填满单个智能体的窗口，有效突破了单模型上下文限制。

## 9.3.5 上下文传递策略

### 最小必要原则

只传递智能体完成任务所需的最小信息：

```python
def prepare_context_for_agent(agent, task, full_context):
    relevant = extract_relevant(full_context, agent.expertise)
    task_specific = format_task(task)
    tools = agent.available_tools

    return compose(relevant, task_specific, tools)
```

### 角色专属记忆

为每个智能体维护结构化的角色专属记忆。

* **私有记忆**：只保存与自身角色相关的对话和结论。
* **视角隔离**：智能体 A 看到的上下文强调数据分析视角，智能体 B 强调代码实现视角。
* **优势**：减少干扰，保持角色一致性。

### 接口抽象

定义清晰的信息传递接口：

```jsonc
{
  "from": "researcher",
  "to": "coder",
  "message_type": "task_handoff",
  "content": {
    "summary": "用户需要一个日历功能",
    "requirements": ["添加事件", "提醒功能"],
    "constraints": ["使用 Python", "无需数据库"]
  }
}
```

## 9.3.6 共享状态管理

多智能体需要共享的状态：

```jsonc
{
  "global_state": {
    "task_id": "task_123",
    "overall_progress": "50%",
    "key_decisions": [...],
    "artifacts": [...],
    "blocking_issues": []
  }
}
```

## 9.3.7 调试与追踪

多智能体系统交互复杂，需要完善的追踪机制：

**1. 消息日志**

记录所有智能体间的通信。每一个消息的发送者、接收者、时间戳、内容类型和 Payload 都应被完整记录。这不仅用于排查错误，也是分析智能体协作模式和效率的重要数据源。

**2. 上下文快照**

关键节点的上下文状态。在任务的关键转折点（如子任务完成、决策变更时），保存各个智能体的上下文快照。这允许开发者“时光倒流”，查看系统在特定时刻的全局状态，复现 Bug。

**3. 决策追踪**

每个智能体的决策依据。智能体为什么采取这个行动？是基于哪条上下文信息？使用了哪个 Prompt？记录 ReAct 循环中的 “Thought” 过程，使智能体的行为透明可解释。

**4. 性能指标**

上下文大小、传递延迟。监控上下文在传递过程中的膨胀情况，以及智能体之间的通信延迟。通过可视化图表识别瓶颈：是某个智能体处理太慢，还是上下文过大导致传输耗时。

## 9.3.8 主流多智能体框架

现代多智能体开发通常基于成熟的框架：

| 框架            | 核心特点            | 适用场景      | 上下文管理       |
| ------------- | --------------- | --------- | ----------- |
| **LangGraph** | 基于图的控制流，强大的状态管理 | 企业级工作流    | 显式状态机，支持检查点 |
| **CrewAI**    | 角色驱动，极易上手       | 快速原型，团队协作 | 角色专属记忆      |
| **AutoGen**   | 对话驱动，代码执行能力强    | 复杂问题解决    | 会话历史管理      |
| **Swarm**     | 轻量级，Handoff 模式  | 探索性实验     | 最小化手动管理     |

**选择建议**：

* 需要精细控制 → LangGraph
* 快速构建 → CrewAI
* 代码密集型任务 → AutoGen
* 简单探索 → Swarm

> 注：OpenAI Swarm 现已不再积极维护，仅作为教学参考；其生产级继任者是 OpenAI Agents SDK（2025 年 3 月发布，沿用 Handoff 模型并补充护栏、追踪、会话等能力）。

## 9.3.8.1 MCP 服务器与上下文开销优化

**Model Context Protocol (MCP)** 是一个标准化的协议，用于智能体与外部服务（如 Slack、GitHub、Asana 等）的集成。从上下文工程的角度，MCP 具有重要意义。

**MCP 的上下文优势**：

传统的智能体集成方式：

* 手动编写每个 API 集成代码
* 处理认证、错误处理、结果格式化等细节
* 这些细节会占用上下文空间，或增加工具定义的复杂度

MCP 方式：

* 预构建的 MCP 服务器可以封装服务侧 API 调用和常见认证适配，但受保护的 HTTP MCP 服务仍需按规范配置授权服务器发现、token 传递、scope 与权限边界
* 智能体只需调用高级工具（如 `search_slack_messages`、`get_asana_tasks`）
* 减少上下文中的工具定义和说明文本

**上下文成本对比**：

```
❌ 手动集成（假设 10 个集成）：
- 每个 API 的认证逻辑：200-500 tokens
- 每个 API 的错误处理：200-300 tokens
- 每个 API 的结果解析：150-250 tokens
- 总计：4000-8000 tokens 仅用于集成代码和说明

✅ MCP 方式（同样 10 个集成）：
- MCP 服务器处理所有细节（不占用上下文）
- 工具定义：`tool: search_slack_messages`, `tool: get_asana_tasks` 等
- 总计：500-1000 tokens 仅用于工具列表

示例结果：工具定义与认证细节越标准化，上下文开销越低；具体节省比例需按工具 schema 长度实测
```

**MCP 在多智能体中的应用**：

当构建多智能体系统时，MCP 服务器特别有价值：

```
场景：构建一个团队协作系统

主智能体
├─ 能力 1：规划任务（不需要外部API）
├─ 能力 2：分配给 Asana（通过 MCP）
├─ 能力 3：发送 Slack 通知（通过 MCP）
└─ 能力 4：查阅 GitHub（通过 MCP）

无需在上下文中重复编写这些集成代码。
每个集成通过标准的 MCP 工具接口暴露。

子智能体
├─ 搜索子智能体：可访问 Google Drive MCP（搜索文档）
├─ 代码子智能体：可访问 GitHub MCP（分析代码）
└─ 研究子智能体：可访问 Web Search MCP（网络搜索）

每个子智能体只加载相关的 MCP 工具，进一步细化上下文。
```

**MCP 生态的发展意义**：

从上下文工程的角度，MCP 服务器的标准化是一个重要的基础设施发展：

1. **可重用性**：一个 MCP 服务器可以被多个智能体和框架使用
2. **上下文节省**：集成逻辑不再占用智能体的上下文
3. **快速扩展**：添加新的 API 集成无需修改智能体提示词
4. **社区驱动**：GitHub 上的 MCP 服务器生态不断增长，降低自定义成本

**使用 MCP 的最佳实践**：

1. **优先使用现有的 MCP 服务器**，而非自定义集成
2. **为 MCP 工具提供清晰的描述**，即使在 MCP 层已定义
3. **监控 MCP 工具的实际使用**，移除不必要的工具以保持上下文精简
4. **在多智能体中分配工具**，让每个智能体只访问相关的 MCP 工具

## 9.3.9 子智能体架构与上下文隔离

子智能体架构不仅是任务分解工具，更是 **上下文管理策略**。

### 上下文隔离的价值

**问题**：单一智能体执行复杂任务时，上下文会被多个子任务的细节污染，导致：

* 上下文腐烂（Context Rot）
* 注意力分散
* 决策质量下降

**解决方案**：将独立子任务委派给专用子智能体，每个子智能体有自己的上下文窗口。

```mermaid
graph TB
    M["主智能体"] -->|"委派: 分析日志"| A["日志分析子智能体"]
    M -->|"委派: 生成报告"| B["报告生成子智能体"]

    A -->|"返回: 3个异常"| M
    B -->|"返回: PDF 路径"| M

    style A fill:#e1f5fe
    style B fill:#e1f5fe
```

图 9-4：子智能体隔离架构

**关键洞察**：主智能体只接收子任务的 **摘要结果**，而非全部细节。

### 多智能体研究系统案例（示意）

一种常见的多智能体研究系统会包含主智能体与若干专用子智能体，以展示这一架构的实际应用：

**系统组成**：

* **主智能体（Lead）**：规划研究方向、综合结果、撰写最终报告
* **搜索子智能体**：执行网络搜索，返回关键发现
* **阅读子智能体**：深度阅读文档，提取相关段落

**上下文隔离效果**：

* 搜索智能体处理数百个搜索结果 → 只返回 10 个最相关的
* 阅读智能体处理 100 页 PDF → 只返回 3 段关键内容
* 主智能体上下文保持清晰，专注于高层决策

**数据对比（示意）**：

| 场景        | 单智能体上下文 | 多智能体架构 |
| --------- | ------- | ------ |
| 研究 10 个网站 | 更易膨胀    | 更易控制   |
| 分析 5 份报告  | 更易膨胀    | 更易控制   |
| 综合生成报告    | 上下文溢出风险 | 轻松完成   |

### 何时使用子智能体

* **并行探索**：需要同时调研多个方向
* **专门技能**：特定子任务需要专用工具或提示词
* **上下文隔离**：子任务产生大量中间数据
* **风险控制**：子任务失败不应影响主任务

> **重要提示**：子智能体增加了系统复杂度和延迟。只在上下文污染成为问题时使用，避免过度设计。

## 9.3.10 并行智能体的上下文编排实践

在 Claude Code 等 AI 编程工具中，开发者通过同时运行 4-6 个并行会话来最大化效率。每个会话对应一个独立的智能体实例，拥有各自隔离的上下文窗口。

### 上下文隔离策略

并行会话的上下文天然隔离——一个在执行代码实现、一个在做技术调研、一个在规划新特性、一个在修复 Bug。这种隔离避免了单一超长会话中多任务上下文相互干扰的问题。

相比于在单一会话中顺序处理多个任务，并行智能体架构带来了质的改变：

| 维度    | 单会话顺序处理     | 并行智能体架构     |
| ----- | ----------- | ----------- |
| 上下文膨胀 | 任务堆积，急速增长   | 各会话独立控制     |
| 注意力分散 | 需要在多任务间频繁切换 | 每个智能体专注单个目标 |
| 恢复成本  | 一处中断影响全局    | 中断隔离在单个会话   |
| 总耗时   | 顺序累积        | 并行大幅缩短      |

### 共享计划文件作为协调机制

多个并行会话通过文件系统中的计划文件（plan.md）进行协调。一个会话的调研结果写入计划文件，另一个会话基于该计划执行实现。这是 9.3.3 节讨论的共享黑板模式（Blackboard Pattern）在实际开发工作流中的自然应用。

例如：

* **调研会话**：调查最新的框架最佳实践，将发现整理到 plan.md 的“技术选型”部分
* **规划会话**：读取调研成果，生成详细的实现计划
* **实现会话**：按照计划逐步编码
* **测试会话**：验证实现是否符合验收标准

### Research → Plan → Build 循环

高效的并行协作遵循一个明确的工作流循环：

```mermaid
graph LR
    R["研究会话<br/>调查社区方案<br/>技术对比"] --> |"结果写入plan.md"| P["规划会话<br/>生成结构化计划<br/>分解子任务"]
    P --> |"计划更新plan.md"| B["实现会话<br/>按计划编码<br/>逐步完成"]
    B --> |"进度更新plan.md"| T["测试会话<br/>验证实现<br/>标记完成"]
    T --> |"反馈写入plan.md"| R
```

这个循环展示了多智能体上下文传递的完整链路：从开放式调研收集事实，到结构化计划明确方向，再到具体实现和验证。

### 多源上下文融合

实际工作流中，计划文件通常融合了多个上下文源——社区调研数据、代码库结构、历史战略决策、会议记录等。这种上下文的累积和融合使得每一份新计划都比上一份更丰富。

例如，一份成熟的 plan.md 可能包含：

```markdown
# plan.md - 性能优化项目

## 调研会话的贡献

研究了 4 篇最新论文，对比了 3 个开源方案...
（来自 Research 会话）

## 规划会话的贡献

基于调研成果，选择方案 A，理由：...
分解为 5 个子任务：Task 1, Task 2, ...
（来自 Planning 会话）

## 实现会话的贡献

已完成 Task 1, Task 2，遇到 Bug X，已解决...
当前进度：60%
（来自 Build 会话）

## 历史决策

2026-03-15：选择了 Python 而非 Go（参考会议记录）
2026-03-18：改用异步架构以提升吞吐量（参考代码审查）
```

这对应了本章讨论的上下文共享机制在真实场景中的表现——通过结构化的中间文件，让多个智能体的贡献有机融合，形成逐步精化的任务描述和执行状态，最大化了并行工作的协同效率。