上下文隔离的两种模式
------从 Manus 的实践，看多 Agent 架构的真实成本
引言：多 Agent 的真正难点，是"会不会协作"
在 Agent 系统刚流行时，很多团队都有一个直觉：
一个 Agent 不够强，那就多来几个。
但很快，另一个现实问题出现了。Cognition 等顶级团队都公开警告过：
多 Agent 系统的真正噩梦，不在于能力，而在于信息同步。
Agent 之间到底该如何共享上下文？共享多少？谁能写？谁能读？
Manus 联合创始人 Peak Ji 给出的判断非常清醒：
这不是 AI 特有问题，而是一个我们在计算机系统中早就见过的问题。
一、问题本质：这是一个"多线程通信"问题
Peak Ji 在分享中借用了并发编程领域的一句经典格言：
"不要通过共享内存来通信，而要通过通信来共享内存。"
原文也明确说了：这个类比并不完全适用于 Agent，甚至在某些情况下是"错误的"。但它有一个巨大价值------它非常清楚地引出了两种截然不同的协作模式。
二、模式一：通过通信隔离上下文
2.1 核心思想
上下文不共享，Agent 只通过结果通信。
在这种模式下，子 Agent 更像一个一次性的、黑盒的"工具型 Agent" 。它只接收指令，返回结果，不保留任何历史。
2.2 工作流程与架构
这是最轻量的协作模式，其架构如下：
arduino
┌─────────────────────────────────────────────────────────────┐
│ 通信模式架构图 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 主Agent上下文（完整历史） │
│ ├── 执行任务中... │
│ ├── 决定委派子任务："在代码库中搜索Auth模块的实现" │
│ └── 生成工具调用：code_searcher(query="Auth module") │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 子Agent实例（全新、干净） │ │
│ │ │ │
│ │ 系统提示：你是一个代码搜索专家... │ │
│ │ 用户指令：在代码库中搜索Auth模块的实现 │ │
│ │ （仅此一条，无其他历史） │ │
│ │ │ │
│ │ → 独立执行搜索 │ │
│ │ → 返回结果：{file: "auth.py", line: 45} │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 主Agent接收观察结果，子Agent销毁 │
└─────────────────────────────────────────────────────────────┘2.3 工程优劣势分析
| 维度 | 表现 | 工程意义 |
|---|---|---|
| 隔离性 | ⭐⭐⭐⭐⭐ | 子Agent错误不影响主Agent，故障边界清晰 |
| 上下文干净度 | ⭐⭐⭐⭐⭐ | 无历史干扰，专注单一任务 |
| Token 成本 | ⭐ 低 | 输入少，推理成本低 |
| KV-Cache | 高命中 | 无需重新计算历史，延迟极低 |
能力边界： 子 Agent 完全没有历史视野。这意味着它无法理解任务的演进，无法处理"上下文驱动型"的复杂任务。
适用场景：指令清晰、目标单一、只关心最终输出的子任务（如搜索、API调用、格式化）。
三、模式二：通过共享上下文隔离
3.1 核心思想
上下文是共享的（只读）；身份与能力是隔离的。
子 Agent 在这种模式下拥有完整历史背景，但以一个全新的系统提示和技能包 行动。你可以把它理解为：在同一时间线，分叉出一个"平行智能体"。
3.2 工作流程与构造细节
这是处理复杂任务的"重武器"，其核心在于Prompt的重新构造：
sql
┌─────────────────────────────────────────────────────────────┐
│ 共享上下文模式架构图 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 主Agent上下文（完整历史） │
│ ├── 已完成：需求分析、资料收集... │
│ └── 决定：需要专业写作能力来生成最终报告 │
│ ↓ │
│ 【分叉动作】创建子Agent（构造如下Prompt） │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 【System Prompt】 │ │
│ │ 你是一个专业的技术文档撰写专家...（全新身份） │ │
│ │ │ │
│ │ 【Complete History】（完整历史记录） │ │
│ │ User: 我们需要研究AI Agent的上下文工程... │ │
│ │ Assistant: 我来为您收集相关资料... │ │
│ │ ...（全部20轮对话历史，包含中间推理过程）... │ │
│ │ │ │
│ │ → 基于全量背景撰写报告 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 主Agent接收最终报告，子Agent销毁 │
└─────────────────────────────────────────────────────────────┘3.3 为什么这种模式"极其昂贵"？
Peak Ji 特别强调：这里的成本不是"有点高"，而是成倍增加。原因有二：
1. 输入 Token 成本爆炸 每个子 Agent 都需要预填充完整历史上下文。在 Agent 系统中，往往意味着输入/输出 Token 比例达到 50:1 甚至 100:1。
2. KV-Cache 几乎无法复用（致命伤） 这是很多文章没点透的地方。
- 子 Agent 的 System Prompt 不同（身份变了）。
- Action Space 不同（工具集变了）。
- 前缀不一致 → KV-Cache 直接失效。
这意味着：每一次子 Agent 调用，都是一次昂贵的"冷启动"。
3.4 为什么还要用它？
因为有些任务，没有完整上下文就是做不了。 例如：深度研究报告撰写、基于多轮讨论的复杂决策、需要理解用户偏好历史的个性化任务。
四、工程决策：如何在两种模式间选择？
4.1 决策判断法则
Peak Ji 给出的建议非常朴素：忠于任务本身，而不是迷恋架构的"高级感"。
你可以问自己三个问题：
markdown
1. 子任务是否可以被一句清晰指令描述？
2. 我是否只关心最终结果，而非中间推理？
3. 这个任务失败时，我是否能接受低成本重试？如果答案都是 YES 选「通信模式」（默认选择）。
如果任务高度依赖历史，且成本可接受 选「共享上下文模式」。
4.2 进阶策略：混合模式（降本增效）
如果必须使用共享模式，但又不想承担全量历史的成本，可以采用 "关键信息提取" 策略，将"共享模式"降级为"增强版通信模式"。
优化示例：
arduino
原始共享模式：
主Agent → 共享全部20轮历史 → 子Agent
优化后的混合模式：
主Agent → 提取关键摘要（500字）→ 嵌入指令 → 子Agent
指令构造示例：
"基于以下研究背景撰写报告：
- 核心发现：WSCI框架
- 关键案例：Manus的结构化摘要实践
- 用户偏好：偏好技术深度
...（而非全量历史）"效果：用通信模式的低成本，获得了接近共享模式的背景理解能力。
五、理论升维：与 WSCI 框架的融合
从 Context Engineering（WSCI）的更高视角看，这两种模式本质上是 Isolate（隔离） 操作的不同变体：
| Peak Ji 模式 | WSCI 对应操作 | 本质 |
|---|---|---|
| 通信模式 | Isolate + Select | 边界 = 单条指令。隔离新实例，仅传递精选指令。 |
| 共享上下文模式 | Isolate + Write (Pre-fill) | 边界 = 完整历史。隔离新实例，但预填充历史。 |
关键洞察 ： Context Engineering 的本质，是在隔离与共享之间，找到成本和收益的最优平衡点。
结语：默认轻量，谨慎共享
多 Agent 架构并不天然高级。不受控的上下文共享，只会放大复杂性。
Manus 给出的工程启示非常清晰：
- 默认使用通信模式
- 把共享上下文当作"重武器"
- 只在任务确实需要、且成本可接受时使用
当你开始认真思考上下文隔离时，你就已经从"Agent 使用者"，走向了"Agent 架构设计者"。每一个架构选择，都是一笔需要算账的工程投资。