![[AI上下文 #5] 为什么使用子代理？AI代理的上下文隔离原理与委派标准 封面图](/assets/images/posts/6f12e091-1d37-4258-b659-1070e39916f1/1.jpg)
前几篇介绍了节省上下文的方法：在任务边界清空历史记录（第3篇），并将固定成本设计得简短（第4篇）。但仍有一些任务难以承受，例如“搞清楚这个代码库中的支付逻辑如何流转”。勤勉的代理会读取几十个文件；正如第1篇所见，读到的内容都会积累在上下文中。调查完成时，反而没有上下文用来利用这些知识修改代码。
本篇介绍子代理（subagent），它能从结构上解决这个问题。要点只有一个：上下文窗口不必只有一个。
在另一个上下文中工作，只带回结论
子代理是由主代理创建的独立代理实例。关键在于，这个实例会获得一个属于自己的全新、干净的上下文窗口。
流程如下。主代理向子代理传递一条指令：“调查并总结支付逻辑的流程”。子代理在自己的上下文中读取几十个文件、搜索并追踪调用关系。过程中会积累数万个 token，但它们都属于子代理的上下文。任务完成后，子代理返回一份整理好的报告并消失。主上下文只留下1条指令和1份报告，总共几百到几千个 token。
这是组织中常见的结构。经理不亲自做市场调研，而是交给调查员，再收取一页报告。重点是调查员浏览的100份资料不会堆在经理的桌上。经理的桌子，也就是主上下文，只保留决策所需的信息。
哪些工作应该委派？
适合委派的工作有一个共同点：过程很重，结论很轻。
第一，探索和调查。“所有使用这个函数的地方”或“弄清与这个 bug 相关的代码”等任务需要大量阅读，但最终答案只是一个列表或摘要。这是子代理的典型工作。Claude Code 设置专用探索代理也是出于同样原因。
第二，可以并行拆分的工作。如果要分别分析5个模块，5个子代理可以在各自的上下文中同时进行。这不仅能缩短时间，也能避免中间产物混在同一个上下文中造成混乱。
第三，需要新鲜视角的工作，性质略有不同。代码审查就是典型例子。刚写完代码的主代理，其上下文充满了实现过程中的假设和试错。在这种状态下审查自己的代码，很容易被自身假设束缚而过于宽容。只把代码交给没有上下文的子代理，它就会以陌生审查者的视角查看。此时隔离带来的是质量提升，而不是 token 节省。
反过来，有些工作委派反而会吃亏。读取一两个文件这类轻量任务，委派的往返成本更高。高度依赖现有对话上下文的任务也不适合。原因如下。
隔离的代价：子代理什么都不知道
子代理的干净上下文并非没有代价。“干净”也意味着它完全不知道此前的对话。
主会话中积累一小时的前提——这个项目必须保留旧版 API、不能修改测试，以及用户偏好的方式——子代理全都不知道。除非写进指令，否则这些信息对它不存在。因此，委派质量取决于指令质量。必须在一条指令中写明必要背景、约束条件和期望的产出格式，才能避免收到基于错误前提完成的报告。
返回方向也是如此。主代理收到的只有子代理的最终报告，因此报告中未包含的发现会随子代理消失。养成指定报告格式的习惯很有用，例如：“请包含影响判断的依据和已确认的文件列表”。第2篇讲过的 context poisoning 也会在这里再次出现。如果报告不准确，错误会以压缩形式移植到主上下文；主代理没有原始材料可验证，就会直接相信它。这就是重要结论必须同时要求依据的原因。
总结
- 子代理在独立的干净上下文中工作，只返回结论。关键是过程中的数万个 token 不会进入主上下文。
- 过程很重、结论很轻的工作（探索、调查、并行分析）适合委派。像审查这样需要新鲜视角的工作，隔离也能用于提升质量。
- 隔离的代价是上下文断裂。子代理不知道对话历史，因此指令必须包含背景和约束，报告必须要求提供依据。
系列还剩最后一块拼图。执行 /clear 会让对话消失，子代理也会在会话结束时消失，但项目仍会继续。即使会话结束也必须保留的知识应该放在哪里？下一篇将讨论上下文之外的存储，也就是记忆与外化。