子代理委派：让别人来装数据

一个编排器代理需要调查 36 笔支付交易、24 张发票和一份 15 页的合同。如果它直接读取所有这些，数千个数据点涌入上下文，退化它对真正决策的推理能力——是否批准账单争议。

修复：把每项调查委派给子代理。子代理在自己的上下文中吸收原始数据，提取关键内容，返回紧凑的摘要。编排器永远看不到原始数据。它的上下文保持干净，留给只有它能做的事——综合和决策。

核心机制

子代理委派实现上下文隔离的原理：每个子代理有自己独立的上下文窗口。原始数据进入子代理的上下文，不是编排器的。编排器只收到子代理的返回值——一个体积是原始数据几分之一的结构化摘要。

受控对比说明了这一点：

同样的代理，同样的任务。唯一变量是跨越子代理边界的数据量。摘要保留了 50 个百分点的上下文余量，产出了 24 个百分点的准确率提升。

子代理应该返回什么

摘要是关键的交接点。太冗长就失去了隔离的好处。太精简编排器就在不完整数据上做决策。

反模式：把所有东西倒回来。 一个子代理返回完整文件内容加全部推理过程，把委派本该隔离的所有原始数据都传回了。编排器的上下文填充情况和没有委派一模一样。

反模式：模糊的自由文本摘要。 一个账单子代理发现账户上有 $50 的信用额，但自由文本摘要只说”账户状况良好”。编排器永远不知道有这笔信用。在一个系统中，自由文本摘要导致了 15% 的错误率——全部发生在子代理原始数据中存在但摘要中缺失的事实上。子代理 98% 的时间检索到了正确信息；损失发生在摘要环节。

有效方式：带必填字段的结构化输出。 一个要求特定字段的模板——金额、日期、状态、文件路径、函数签名——确保关键细节在摘要步骤中存活。编排器得到恰好需要的数据，格式可预测。

好的返回格式：

• 分类的发现，每个类别附带 3-5 个顶级示例和精确文件位置
• 结构化 JSON，包含关键发现、置信度级别和编排器可用来重新读取特定文件的文件指针
• 按问题分行，带必填列（订单 ID、金额、状态、解决方案）

委派粒度：不能太细也不能太粗

600 文件跨 20 个模块的安全审计。用多少个子代理？

正确的粒度把子代理边界对齐到领域的逻辑单元：微服务项目中的服务、支持案例中的调查区域、长文档中的章节。

PR 代码审查的数据清晰展示了退化曲线：

把每个文件的审查委派给独立子代理并返回聚焦的发现摘要，消除了这条曲线。编排器在从不持有原始文件内容的情况下编译审查。

合同提取方面，单轮准确率从早期章节的 96% 降到后期章节的 78%。基于章节的委派维持了一致的准确率，因为每个章节获得新鲜、专注的上下文。

编排器的角色变了

没有委派时，编排器做所有事：读数据、分析、做决策。有了委派，它的角色缩窄到协调和综合：

1. 分派 — 给子代理分配有范围的任务和明确的输出要求
2. 接收 — 从每个子代理收集结构化摘要
3. 综合 — 合并摘要、检测跨领域模式、做决策

这就是为什么编排器需要上下文余量。85% 被原始子代理输出占据时，它无法综合。35% 被摘要占据时，它有充足的空间来推理跨模块依赖、检测跨调查区域的模式、或权衡来自多个来源的对立证据。

什么时候不委派

委派增加延迟和协调复杂度。不是总有必要：

• 小输入 — 子代理的三份 200 词摘要总共 600 词。在这个规模下上下文容量不是瓶颈。
• 简单任务 — 读一个文件或做一次快速查询不需要隔离。
• 紧密耦合的分析 — 当分析需要同时访问所有数据时（比如交叉引用两个特定段落），拆分到子代理可能丢失分析需要的关联。

阈值取决于上下文：当原始数据量会实质性退化编排器执行协调工作的能力时再委派。

与其他技巧结合

子代理委派自然地与 scratchpad 模式搭配。编排器可以把收到的摘要写到 scratchpad 文件，使它们免受编排器自身在后续综合阶段的上下文退化影响。如果后续需要 /compact，scratchpad 保留了压缩可能压缩掉的摘要。

在 Claude Code 工作流中，Explore 子代理承担了代码库发现的隔离角色。它在自己的上下文中探索文件并返回聚焦的摘要。Plan 模式则在发现和实现之间提供设计对齐阶段——没有 plan 模式，开发者面临编排器在确认方案正确之前就跳到实现的风险。

一句话总结： 把数据密集型任务委派给返回结构化摘要的子代理——编排器的上下文保持干净，留给只有它能做的工作：综合和决策。