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