子代理是独立的会话。它们不继承协调者的对话历史、工具结果或之前轮次的任何上下文。如果协调者没有在子代理的任务 prompt 中显式包含某条信息，子代理就不知道它的存在。这是多 agent 系统 bug 最常见的来源。
导致 bug 的误解
“子代理会看到协调者已经找到的东西。“不会。每个子代理都以全新会话开始。协调者通过搜索找到了 5 篇关键论文？子代理不知道它们存在，除非协调者把它们包含在任务 prompt 里。协调者确立了编码标准？子代理会无视它们，除非它们在 prompt 里。
典型症状：子代理重复做了协调者已经完成的工作（重新搜索论文、重新查客户数据）。根因：任务 prompt 说了”分析研究发现”但没有包含实际的发现。
传什么、怎么传
显式的、结构化的、任务专属的上下文。 不是协调者完整的 25,000 token 历史——只传和子代理任务相关的事实：
- 搜索子代理：查询 + 范围（500 token）
- 分析子代理：论文 + 标准（3,000 token）
- 综合子代理：全部发现（8,000 token）
某生产系统给 3 个子代理每个传 25,000 token（共 75,000），但实际三个加起来只需要 11,500 token。任务专属的筛选把 token 减了 85%。
质量和上下文完整度正相关
客服系统的数据：
- 账单子代理：92% 质量（收到了完整的客户 + 订单上下文）
- 物流子代理：71% 质量（只收到了订单号，缺少地址和配送偏好）
- 账户子代理：65% 质量（只收到了客户姓名，缺少账户等级和历史）
同样的架构，同样的模型，不同的上下文完整度 → 不同的质量。修复方法：丰富协调者传给物流（加上地址 + 偏好）和账户（加上等级 + 历史）的上下文。
规则和格式都要传
子代理 prompt 中常见的两个缺失：
- 领域规则：自定义安全规则、编码标准、业务策略——协调者知道但子代理也需要的东西
- 输出格式：发现应该如何结构化，这样协调者才能聚合
没有领域规则，子代理套用通用标准而不是项目专属标准。没有输出格式，协调者合并不同子代理的结果时会很吃力。
不需要共享状态
Agent SDK 的 Task 工具就是为通过 prompt 显式传递上下文而设计的。引入 Redis、共享数据库或消息队列为一个 prompt 传递已经解决的问题增加了基础设施复杂性。每个子代理在 prompt 中接收上下文时不存在竞态条件。
一句话总结： 子代理是独立会话，零继承上下文——协调者必须在每个 prompt 中筛选并传递任务专属上下文，质量与上下文完整度直接相关（生产数据 92% vs 65%）。