现在，大家已经在用很多 Claude Code 一起 Coding。
然后，Token 开始蹭蹭往上涨。
谁改了接口，群里说一遍；前端、后端、测试分别确认；协调 Agent 再汇总一次，转给所有人。
好家伙，活还没干多少，进度倒是同步了三轮。
最近伦敦大学学院团队用 Claude Code 做了 1902 次实验，专门算了这笔账。在部分由 8 个 Agent 参与、消息密集的任务中，把重复沟通换成共享文件，输出 Token 少了约 42%。
https://arxiv.org/abs/2608.16801对，你没看错。
省 Token 的办法，不是再训练一个更聪明的协调 Agent，也不是上复杂的调度框架。
就是建个文件。
一、Agent 越能聊，为什么反而越贵
最直接的浪费，是同一条信息被说了很多遍。
比如一个 Agent 修改接口，它需要通知前端、后端和测试。三方收到后，又各自回复确认。Agent 数量一多，点对点消息很快就铺开了。
有些任务其实不需要这么多人旁听。
在“搜集资料—分析—执行—验收”这类流程里，搜集 Agent 把结果交给分析 Agent 就够了。它没必要继续跟着执行和验收，更不用反复接收后续进度。
协调 Agent 也容易变成传话筒。
它收进度、转消息，看起来一直在忙，实际上只是给团队多加了一层汇报。论文实验中，专门设置一个协调 Agent，并没有稳定提高成功率。
问题慢慢清楚了：
要反复使用的信息，被反复发送；只需要交接一次的结果，又发给了太多人。二、一份共享文件，Token直降 42%
论文验证的办法很直接：把多个 Agent 都会用到的信息，集中放进共享文件。
放到实际项目里，可以在根目录建一份 AGENT_STATUS.md。
任务目标、验收标准、Agent 分工、当前进度、已经确认的结论和阻塞问题，都写在这里。每个 Agent 开工前先读最新状态，做完自己的部分再更新。
这样一来，消息不再负责搬运整段背景，只需要告诉别人“哪里发生了变化”。
比如接口更新了，先改共享状态，再通知受影响的前端和测试 Agent。其他人用不到，就不用跟着收消息。
说白了，这份文件就是 Agent 团队的办公室白板。
大家都要看的内容写在白板上。真有急事，再单独喊人。
约 42%：这一降幅来自论文中的特定实验，不能直接外推到所有项目。42% 的数字很亮眼，但别把它当成固定折扣。
如果两个 Agent 只做一次交接，专门建文件、读文件、更新文件，反而可能更贵。真正影响收益的，是公共信息原本被重复了多少次。
三、不是所有消息，都该塞进共享文件
共享文件好用，也不能什么都往里扔。
只影响一个 Agent，就点对点发送；影响全员，再广播一次。
至于协调 Agent，也没必要接收和转发所有消息。
它真正该做的是拆任务、定输入输出、限制修改范围、检查结果。只有发生冲突、偏离目标或者验收失败时，再出来处理。
能由上下游直接完成的交接，就别再绕一次。
写在最后：哪些情况不适用
如果任务本来已经通过文件完成交付，就不用再加一份状态文件。
如果只有两个 Agent，发一条消息能说清楚，也没必要搭新的流程。
还有一种情况更麻烦：项目变化很快，状态却没人更新。
其他 Agent 读到旧内容，干得越快，返工越多。所谓“唯一事实来源”，最后会变成唯一的过期信息来源。
判断要不要共享状态，其实只需要问一句：
这条信息接下来，会不会被多个 Agent 反复使用？
会，就集中保存；不会，直接交给需要它的 Agent。
Claude Code 跨会话通信解决了“Agent 能不能聊”。接下来更现实的问题是：怎么让它们少说重复的话。
毕竟 Token 应该花在干活上，不是花在开会。
📖 相关推荐
资深互联网从业者，专注AI工具研究与实战应用。长期跟踪ChatGPT、Claude、Stable Diffusion等前沿AI技术，擅长将复杂的技术概念转化为通俗易懂的教程。运营颜资源小站，致力于为中文用户提供高质量的AI教程、开源项目推荐和数字资源整理。
评论(0)