多 Agent 协作中，真正稀缺的是主线程的工作记忆
BestBlogs 早报里推荐了一篇 Martin Fowler 的文章，作者 Rahul Garg 分享了他对编排层成本的思考，很值得一读。
文章从一次真实的 Claude Code 编程经历讲起。作者正在重构一个 .NET 项目的响应处理流程，同时启动了四个子 Agent。它们分别阅读代码、分析问题并返回结果，执行速度有所提升，但主线程逐渐变得难以梳理。作者因此暂停开发，开始复盘这次任务的委派方式，希望判断四个子 Agent 是否带来了过高的成本。
复盘发现，并行数量并非最突出的问题。三个子任务同时执行，把原本可能需要二十多分钟的工作压缩到了十二分钟左右，说明并行本身具有实际价值。更明显的浪费来自一次看似普通的状态检查：为了了解后台 Agent 的进度，工具把完整运行记录拉回主线程，其中包含大量 JSONL、工具输出和中间推理。类似操作执行两次后，数万 Token 的过程信息长期留在了主上下文。
这件事提醒我们，Token 消耗和上下文污染需要分开看。一次工具调用产生的 Token 成本会结束，但进入主线程的内容会继续参与后续对话。随着无关信息增加，模型需要在更多内容中寻找当前有效的约束、决策和任务状态。即使上下文窗口仍有充足空间，重要信息也可能被重复输出、过期结论和中间过程稀释。长任务真正需要关注的指标，除了上下文容量，还有信息的信噪比和可检索性。
文章还指出了另外两个常见问题。第一，两个子 Agent 虽然负责不同文件，却需要理解相同的架构、测试规范和响应流程。它们分别重建了一遍相似的代码认知，说明任务拆分过细。第二，有 Agent 在多个写入者共享同一工作区时执行了 git stash 和 git stash pop。这次没有造成破坏，但仓库级操作会影响所有参与者，在并发环境中很容易覆盖或扰乱其他人的修改。
作者由此提出了「认知局部性」的概念：需要依赖同一套领域知识、代码上下文和设计约束的工作，适合放在一起完成。拆分任务时，不能只看文件和步骤，还要判断各项工作是否共享同一个心智模型。如果两个任务需要阅读大量相同文件，或者其中一个结论会直接影响另一个的实现，合并给同一个 Agent 往往更有效。真正适合并行的任务，应当在知识边界和修改范围上都相对独立。
这也重新定义了子 Agent 的作用。它可以承担搜索、试错、重复读取和局部分析，并把这些过程保留在自己的临时上下文中。完成后只需返回结论、关键证据、修改文件、验证结果、风险和未决问题。主线程由此保持相对紧凑，继续承载跨阶段的设计理由、架构约束和用户决策。查看进度时也应优先读取简短状态，如运行中、已完成或遇到阻塞；只有诊断异常时，才按需查看详细记录。
针对这次经历，作者最终总结出几条克制的规则： - 一轮优先使用两到四个 Agent； - 多个任务共享文件和规范时先考虑合并； - 不要用完整运行记录回答轻量的状态问题； - 并发 Agent 不执行影响整个仓库的 Git 操作； - 文件所有权重叠时应重新划分任务。
这里的具体数量来自个人工作场景，不能直接当作通用标准。更值得借鉴的是规则背后的判断方式：先识别实际发生的成本，再做最小范围的调整。
文章后半部分对流程治理的反思同样重要。作者发现主线程启用的技能不会自动传递给子 Agent，最初准备增加「每次启动前人工确认」的审批环节。进一步思考后，他把解决方案缩小为：启动前说明每个 Agent 需要加载哪些技能，并提供对应文件位置；只有数量超过阈值或文件归属不清时才要求确认。这个选择避免了把一次信息缺失扩展成长期存在的流程负担。