为什么给 Agent 分工太细，反而会拖慢你 GitHub 最近有一篇文章讨论度很高，讲 Copilot CLI 怎么变得更「克制」。 不是更会写代码。 是更少乱派活。 这个点我觉得对我很有启发意义。 很多人一听到 agent workflow，就会本能地想多搞几个角色。一个负责搜索，一个负责改代码，一个负责测试，一个负责 review，一个负责写总结。 听起来很像团队协作。 但你真用久了会发现，有些任务一拆开，反而变慢了。 比如你只是想改一个按钮文案。 主 Agent 明明自己读文件、改一行、跑一下测试就结束了。结果它先派一个子 Agent 去搜索组件位置，再等子 Agent 回来，再自己判断，再派另一个子 Agent 检查样式。 本来一步能做完，硬是走成了三步。 这不是智能。 这是过度转包。 GitHub 这篇文章里有一个很好的判断，delegation isn’t free--委派不是免费的。每一次交接都会产生协调成本、工具调用、等待时间和误解空间。 这句话放到普通 AI 使用里也成立。 我们现在太容易把「多 Agent」当成高级感了。 好像一个任务只要拆成五个角色，系统就更专业。 但真实项目不是这样。 真实项目里，很多麻烦就死在交接上。 一个人查到的信息，另一个人没读懂。 一个 Agent 排除过的方向，另一个 Agent 又重新排一遍。 主 Agent 本来已经有判断了，子 Agent 又带回来一堆噪音。 最后你坐在屏幕前，看它们非常忙，心里越来越虚。 我自己现在判断要不要派子 Agent，会看三件事。 第一，这个任务能不能独立完成。 如果一个子任务不依赖主线判断，也不会频繁打断当前上下文，那它适合外包。比如让一个 Agent 去跑一组长测试，或者单独检查无障碍问题，或者检索某个模块的历史改动。 第二，它有没有专业增益。 安全审计、性能分析、可访问性检查、数据库迁移，这些确实适合专门的 Agent。因为它们有独立标准，有固定工具，也有一套和普通改代码不一样的判断方式。 第三，交接结果能不能被验证。 子 Agent 不能只回来一句「我查过了」。它必须带着文件、命令、结论、风险和下一步动作回来。否则主 Agent 拿到的不是帮助，是一团雾。 这三个条件其实都挺朴素。 能独立。 有增益。 可验证。 不满足这三条，就不要急着拆。 少派活，有时候真的会更快。 这对我们平时写 prompt 很有启发。 以后别再一上来就说： 「请你调用多个专家 Agent 分别分析。」 这句话看着专业，但很容易制造无效协作。 更好的说法是： 「先判断这个任务是否需要委派。只有当子任务独立、专业性强、结果可验证时，才交给子 Agent。否则由主 Agent 直接完成。每次委派前说明为什么值得委派，委派后返回证据和下一步决策。」 尤其是代码任务，过度委派很容易带来两个问题。 一个是上下文碎裂。 主 Agent 本来知道用户目标、历史决策、风险边界。子 Agent 如果只拿到局部任务，很容易做出局部正确、整体添乱的事。 另一个是责任漂移。 出了问题以后，主 Agent 说子 Agent 查过了，子 Agent 说自己只负责局部。最后没有一个角色真正对结果负责。 这在真实团队里也一样，人多不一定快。 交接多，反而容易把责任磨薄。 所以我现在更喜欢一种轻一点的 Agent 组织方式： 主 Agent 负责目标、边界和最终判断。 子 Agent 只负责明确的、可验证的、可以并行的任务。 所有子 Agent 输出都必须回到主线，被主 Agent 消化，而不是直接变成最终结论。 可以把它想成一个简单规则： 不要为了分工而分工。 只为了减少不确定性而分工。 如果委派之后，不确定性变少了，值得。 如果委派之后，只是多了一段看起来很努力的过程，不值。 很多时候，效率不是来自更多角色。 是来自更少没必要的交接。