多 Agent 协作别共享上下文：子任务委派的隔离与交接实践

前言

上一篇《上下文窗口塞满了怎么办》讲的是单会话内部怎么省着用。多 Agent 场景把这个问题的另一个面暴露出来：主会话委派子任务时，子 Agent 该带多少上下文出发？干完活回来，怎么交接才不污染主现场？

我们最初的做法很朴素：把主会话的历史原样塞给子 Agent，"让它了解全貌再干活"。实践下来这条路在简单任务上能跑，任务一复杂就翻车。这篇把翻车原因和后来的做法讲清楚。

一、全量继承上下文，是第一个要改掉的直觉

"让子 Agent 知道一切"听起来安全，实际有三个连锁问题：

• 窗口爆炸：主会话已经有几万 token 的历史，再复制给每个子 Agent，多路并行时成本按倍数涨，而且每个子 Agent 自己的可工作空间被严重挤压；
• 注意力稀释：子 Agent 的任务是"跑测试并汇总失败项"，给它完整的需求讨论史，它会在无关细节上分配注意力，输出反而变差。上下文里 90% 的内容与子任务无关时，模型很容易被带偏；
• 目标漂移：主会话历史里可能埋着多个未完成的分支目标，子 Agent 会"好心"地把它们也做了——改了不该改的文件，主会话收回来一合并全是冲突。

结论：上下文不是遗产，是工具。子 Agent 拿到的应该是完成这个任务所需的最小集合，不是主会话的复印件。

二、出发时给什么：任务书模式

我们最终收敛成"任务书"格式，每次委派固定四段：

目标：为 src/auth 模块补充单元测试，覆盖率从 43% 提到 80%
边界：只新建 test/auth/ 下的文件；不改任何 src/ 代码；不装新依赖
返回格式：结论 + 新增文件清单 + 未覆盖原因列表
预算：最多 30 次工具调用，超了就带现状返回

四个字段各有用处：目标给方向，边界防越权（这是防目标漂移的关键——"不改 src"这一条直接杜绝了子 Agent 顺手重构），返回格式决定交接质量，预算防失控。

反例是我们早期最常写的："帮我看下这个项目的测试情况"。这种委派等于把"理解任务"的成本转嫁给了子 Agent，它理解的往往还不是你要的。

三、返回时交什么：结论加指针，不要过程回放

子 Agent 跑完 30 轮，历史里全是它读过的文件、跑过的命令。这些过程不该原样倒回主会话——那等于把窗口爆炸问题反向传染回来。

有效的交接只有两类内容：

1. 结论：任务书里要的返回格式，直接回答"干成了什么、没干成什么"；
2. 证据指针：关键结论指向可验证的位置——文件路径、commit hash、命令及其一行输出。主会话有疑问时按指针去查，而不是通读过程。

结构上固定成一段：

结论：新增 14 个测试文件，覆盖率 43% -> 82%，全部通过
关键产出：test/auth/*.test.ts（清单略，见 git status）
未覆盖：crypto.ts 的两个分支依赖硬件密钥，单测无法模拟
建议：下一步可考虑给 crypto 模块加 mock 层

主会话合并时有个纪律：把交接内容当作新信息追加，不重算已有结论。见过一种失败模式是主会话收到交接后把子 Agent 的全部输出又"总结"一遍，摘要滚雪球，细节衰减的问题在《上下文窗口塞满了怎么办》里说过了。

四、共享的边界：文件系统是对话之外的真相源

隔离不等于老死不相往来。多 Agent 真正该共享的不是对话历史，而是工作区本身：代码、文件、数据库。这带来两条实践纪律：

• 中间产物落盘，不进对话。子 Agent 生成的测试报告写进 reports/auth-test.md，交接时只给路径。任何需要"两个 Agent 都要看"的内容，放文件系统，不放消息；
• 写入划界，避免互踩。两个子 Agent 同时改一个文件是并行委派最常见的事故。任务书里的"边界"字段就是为此存在的——按目录、按文件划清各自的可写范围，宁可比并行度，不留合并冲突。

小结

多 Agent 的上下文管理三条：委派用任务书（目标/边界/返回格式/预算），交接只给结论加证据指针，共享走文件系统而不是对话。原则和单会话压缩一脉相承——每个上下文里只放"当前决策需要的信息"，其余的放外面。

Agent 系列写到这里，开发侧的主干基本讲完了。下一篇打算转向评估：怎么系统地判断一个 Agent 是变好了还是变坏了（任务成功率之外，还该看什么指标），有兴趣可以关注。

本文是 Agent 工程系列的一篇，前作：《Agent 记忆系统设计》《上下文窗口塞满了怎么办：长会话压缩的时机、策略与不能压的东西》。