多Agent协作：如何减少重复沟通以节约Token

现在很多团队在用Claude Code协同开发，但很快就会发现一个问题：Token消耗蹭蹭往上涨。改个接口要在群里通知一遍，前后端、测试分别确认，协调Agent还要汇总一次转给所有人，活还没干多少，进度同步就做了三轮，大量Token都花在了无效沟通上。

据行业观察，伦敦大学学院的研究团队针对这个问题开展了1902次实验，专门核算了多Agent协作的Token成本，最终找到了一个简单有效的降本方法。在包含8个Agent、消息密集的协作任务中，将重复沟通替换为共享文件后，输出Token用量减少了约42%。

多Agent协作的Token浪费源头

最直接的浪费来自同一条信息被反复发送。比如一个Agent修改接口时，需要分别通知前端、后端和测试团队，三方收到消息后还要各自回复确认，随着Agent数量增加，点对点的消息会快速铺开，形成大量重复的信息传递。

很多任务其实不需要全员参与。在“搜集资料—分析—执行—验收”的标准流程中，搜集Agent只需要把结果交给分析Agent即可，不需要跟进后续的执行和验收环节，也没必要反复接收后续的进度更新。

协调Agent也容易变成单纯的传话筒。这类Agent负责接收进度、转发消息，看起来一直在忙碌，但实际上只是给协作流程多加了一层汇报环节。实验数据显示，专门设置一个协调Agent，并没有稳定提升任务的成功率。

总结来看，多Agent协作的核心浪费在于：需要反复使用的公共信息被反复发送，而只需要一次性交接的结果却被分发给了太多不需要的参与者。

共享状态文件：把Token花在干活上

研究团队验证的解决方案非常直接：将多个Agent都会用到的公共信息集中存放到共享文件中。

在实际项目中，可以在根目录创建一份AGENT_STATUS.md文件，将任务目标、验收标准、Agent分工、当前进度、已经确认的结论和阻塞问题都记录在这里。每个Agent在开始工作前，先读取这份文件的最新状态，完成自己的工作后再更新文件内容。

这样一来，协作消息不再需要搬运完整的背景信息，只需要告知其他参与者“哪里发生了变化”即可。比如接口更新时，先修改共享状态文件，再通知受影响的前端和测试Agent，其他不需要该信息的Agent则不用接收相关消息。

这份共享文件就像团队的办公室白板，所有需要全员知晓的公共信息都写在上面，只有真正紧急的事项才需要单独一对一沟通。

需要注意的是，42%的Token降幅来自特定的实验场景，不能直接套用到所有项目中。如果只有两个Agent进行一次交接，专门创建、读取和更新共享文件的成本可能反而更高，真正影响收益的是公共信息原本被重复传递的次数。

不是所有消息都适合放进共享文件

共享状态文件虽然好用，但也不能不分场景地使用。

如果消息只影响单个Agent，采用点对点发送的方式效率更高；如果信息会影响全员协作，再通过广播或者更新共享文件的方式传递。

对于协调Agent来说，也没有必要接收和转发所有消息。它们真正的职责应该是拆分任务、明确输入输出边界、限制修改范围、检查最终结果，只有当协作中出现冲突、任务偏离目标或者验收失败时，再介入处理即可。

上下游Agent之间可以直接完成的交接，不需要再通过协调Agent绕一次流程。

哪些情况不适合使用共享状态文件

如果任务本身已经通过现有文件完成交付，就不需要再额外创建一份状态文件。

如果只有两个Agent进行协作，发一条消息就能说清楚所有事项，也没必要搭建专门的共享状态流程。

还有一种情况需要特别注意：如果项目变化很快，但没有人及时更新共享文件的状态，其他Agent读到的会是过期信息，干活越快返工越多，所谓的“唯一事实来源”反而会变成唯一的过期信息来源。

判断是否需要使用共享状态文件，只需要问一个简单的问题：这条信息接下来会不会被多个Agent反复使用？如果答案是肯定的，就集中保存；如果只是单次交接，直接交给需要它的Agent即可。

Claude Code的跨会话通信功能解决了多Agent“能不能聊”的问题，而接下来更现实的课题是如何让它们少说重复的话。Token成本应该花在实际的开发工作上，而不是无效的同步沟通中。