# 9.3 多智能体上下文传递

## 9.3.1 多智能体系统概述

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

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

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

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

## 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 = 52K（下降 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-4：链式智能体协作

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

## 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

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

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

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

传统的智能体集成方式：

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

MCP 方式：

* 预构建的 MCP 服务器处理所有认证和 API 细节
* 智能体只需调用高级工具（如 `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-5：子智能体隔离架构

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

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

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

**系统组成**：

* **主智能体（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：改用异步架构以提升吞吐量（参考代码审查）
```

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET 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?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.