多 Agent 系统的 Context 隔离
多 Agent 系统的 Context 隔离
第 6 章 解决「单 agent 怎么不爆 context」。还有另一种规模——主 agent 派 sub-agent 干活。Context 共享、独立、还是部分共享，决定系统能否 scale。
多 agent 系统的三种 context 拓扑
1. Shared context — 一个 LLM 跑全程
所有步骤在同一 messages array 里。
messages = [
user: "调研 Kubernetes 三个最流行的 ingress controller 各自优劣"
assistant: 我先列三个候选 → ingress-nginx, traefik, contour
tool_use: WebFetch ingress-nginx docs
tool_result: ...
tool_use: WebFetch traefik docs
tool_result: ...
... (累积 50K context)
assistant: 综合分析后, ingress-nginx 优在生态成熟, traefik 优在...
]
优点：最简单、零信息损失。缺点：context 线性增长，Lost in the Middle 在第 30 步开始严重；每步付累积的 token cost。
适合：< 10 步、步骤间强依赖。
2. Isolated context — Sub-agent 完全独立
Sub-agent 拿到全新 context——只含 task 描述 + 必要资料。跑完返回最终答案 + 简短摘要，过程不传。
主 agent context:
user: "调研 K8s 三个 ingress controller"
assistant: 我会派 3 个 sub-agent 并行调研
tool_use: spawn_subagent(name="research_ingress_nginx", task="...")
tool_result: { summary: "ingress-nginx 优在生态成熟...", refs: [...] }
tool_use: spawn_subagent(name="research_traefik", task="...")
tool_result: { summary: "traefik 优在配置灵活...", refs: [...] }
...
assistant: 综合三个 sub-agent 的总结...
# 每个 sub-agent 自己的 context（独立）：
user: "调研 ingress-nginx：架构、性能、生态、坑"
tool_use: WebFetch ingress-nginx docs
... (自己累积 30K context, 完成后丢弃)
assistant: 给主 agent 一段 500 字摘要
优点：主 agent context 永远小；sub-agent 可并行；单个爆了不影响其他。缺点：lossy handoff；主 agent 不知中间推理只能信结果；需要 spawn / coordinate 基础设施。
适合：sub-task 独立可并行；主 agent scale 30+ 步。
3. Partial sharing — 摘要回传 + 关键 raw data
Sub-agent 返回摘要 + 关键证据原文。主 agent 拿摘要 + 引用，能复核 sub-agent 判断。
Anthropic Multi-agent Research System blog pattern——主 agent 是 Lead Researcher，sub-agent 是 Search Subagents，回传附 source URL + 关键 quote 供验证。
代价：handoff payload 比纯摘要大 5-10 倍，trust 高很多。
Anthropic Multi-Agent Research System — 官方案例
Anthropic 2025-04 blog 描述 Claude.ai 的 multi-agent research feature：
架构：
LeadResearcher (主)
└─ 拆解用户 query → 决定派几个 sub-agent
└─ 派 SearchSubagent 1: "找 X 主题的最新 paper"
└─ 派 SearchSubagent 2: "找 Y 公司的官方文档"
└─ 派 SearchSubagent 3: "找用户评测和实际案例"
└─ 收集所有 sub-agent 摘要 → 综合写最终 report
Anthropic 工程经验（直接引用）：
- 「sub-agent context 不能共享——并行 sub-agent 互不知道对方做什么，反而避免重复工作和 group think」
- 「最佳 sub-agent 数 3-5 个；超过 5 个 lead 协调成本超收益」
- 「sub-agent 把 raw results 回传 lead 是错的——必须先 distill 成 finding」
- 「整个 system 比 single-agent baseline 多用 4× token，但质量提升远大于 token 成本」
Claude Code 的 Agent tool — 真实 sub-agent 实现
Claude Code 内置 Agent tool 就是 sub-agent 模式（这门课就是 Claude Code 写的，主 agent 派 Explore subagent 查 prompt-master 配置——主 agent 不看 200 行原文，只看返回的结构摘要）。
配置：
- subagent_type — 不同 sub-agent 不同 tool 集（Explore 只能 read，code-architect 能 design 不能 edit）
- isolation: "worktree" — 高破坏性 task 在独立 git worktree 跑，完成后 merge / discard
- Description 和 Prompt — 启动只看 prompt + 自己 tool list
「isolated context + lossy handoff」的产品化。
JR 真实案例：omni-report 17 个 routine 之间的隔离
JR omni-report 跑 17 个独立 routine（AI Visibility / Competitor Weekly / Marketing Topics / Growth Playbook / Daily Jobs ×4 等）。每个独立 cron job、context、git commit、Notion 同步。
为什么不合并 master agent？
- Context 隔离 — Competitor Weekly 50K context 不污染 Daily Jobs
- 失败隔离 — 一个挂不影响其他 16 个
- 可观测 — 每个单独 monitor
- 可重跑 — 单独触发（第 13 个 routine idle timeout 重跑只影响那一个）
Cross-routine 信息流通过 git commit 异步传递。Marketing Topics 周一写 marketing-topics/$DATE.md；Growth Playbook 周二 Read 进自己 context。「文件系统作为 handoff 通道」——git 就够。
Shared / Isolated / Partial — Trade-off
| 维度 | Shared context | Isolated + summary | Partial sharing |
|---|---|---|---|
| 主 agent context 增长 | 线性，30 步开始痛 | 几乎不增长 | 增长慢（摘要 + 少量原文） |
| 信息损失 | 0 | 大（只看摘要） | 中（摘要 + 关键引用） |
| Sub-agent 并行 | 不行（串行） | ✅ 完美并行 | ✅ 完美并行 |
| 基础设施 | 0（一个 LLM） | spawn / coordinate / 摘要器 | + 引用提取 |
| Token 成本 | 中（线性增长） | 高（多 LLM） | 较高（摘要 + 引用） |
| Trust（主 agent 能否验证 sub） | 完美 | 弱 | 中（能看 raw evidence） |
| 适合 | < 10 步、强依赖 | 30+ 步、可并行 | 严肃推理、要 traceability |
JR 内规：< 10 步 single LLM；10-30 步 partial sharing；30+ 步 isolated sub-agent。Anthropic 验证过的曲线。
一句话带走
多 agent 不是「拆得越细越好」。Sub-agent 数量 3-5 个最佳，超过 5 个协调成本吃掉收益。Sub-agent 必须自己 distill finding 后再回传，主 agent 拿到 raw 还是会爆。Anthropic 自己 build 的 research system 用了 4× token 但质量提升远大于成本——证明「多 token 但分层」比「少 token 但混淆」对。
引用来源
- Anthropic. (2025-04-15). How we built our multi-agent research system — Lead + Search subagent 架构 + 3-5 sub-agent 经验法则.
- Anthropic. Claude Code documentation — Agent tool — sub-agent type / isolation / handoff 实现.
- Anthropic. (2024-12-20). Building Effective Agents — orchestrator-workers pattern 原文.
- LangGraph. Multi-agent supervisor pattern — 开源生态对应实现.
- AutoGen. GitHub — Microsoft 多 agent 框架，对照参考.
Production case: JR Academy omni-report — 17 个独立 routine 之间通过 git commit 做异步 cross-agent handoff，filesystem 作 sub-agent 通信通道.
📚 相关资源
❓ 常见问题
关于本章主题最常被搜索的问题，点击展开答案
Sub-agent context 该独立还是共享？
按步数和并行需求分：< 10 步强信息依赖用 shared（一个 LLM 跑全程），30+ 步可并行用 isolated（sub-agent 独立 context + 摘要回传），严肃推理 + 要 traceability 用 partial sharing（摘要 + 关键引用原文）。Anthropic Multi-Agent Research System 用 partial sharing。
Sub-agent 数量越多越好吗？
不是。Anthropic 自建 research system 数据：3-5 个 sub-agent 最佳，超过 5 个 lead agent 协调成本超过收益。整个 system 比 single-agent 多用 4× token，但难题质量提升远大于 token 成本。
Sub-agent 之间怎么通信？
JR omni-report 用 filesystem 作 sub-agent handoff 通道：17 个独立 routine 通过 git commit 异步传信息（Marketing Topics 周一跑完写 marketing-topics/$DATE.md，Growth Playbook 周二 Read 进自己 context）。比 message queue 简单 10 倍，低频 cross-agent 通信够用。
多 agent 系统跑一天大概多贵？
按 Anthropic 自家 research system 数据：单次复杂 query lead agent + 4 sub-agent 总耗 ~80K input + ~15K output token = Sonnet $0.30/query。100 query/天 = $30/天 ≈ $900/月。比 single-agent 贵 4× 但难题正确率提升远超成本。
我没用 Claude Code 的 Agent tool，自己用 LangGraph 实现行吗？
完全可以：LangGraph 是 LangChain 官方的多 agent 框架，节点 = 单 agent、边 = handoff 协议、state 字典 = shared / partial / isolated context 都能配。OpenAI Swarm（轻量）、CrewAI（角色驱动）也是常见选择。三个都和模型解耦。
多 agent 最常见的失败模式是什么？
Sub-agent 信息丢失：lead agent 把 task 拆给 sub-agent，sub-agent 跑完只回一句「done」，lead 不知道做了什么、不能基于结果继续推理。强制要求每个 sub-agent 返回结构化结果（JSON：result + key_findings + sources），不收自由文本。Anthropic Multi-Agent Research System 的硬性约束。