多 agent 协作编码，被讲得越来越玄。什么“涌现式协作”“团队智能”，听着跟养蛊似的。我绕这个弯绕了挺久，一直卡在同一个地方：大家都在争“多 agent 到底比单 agent 强不强”，没人告诉我它们凑到一起之后，中间到底发生了什么。
前几天 arXiv 上挂出一篇论文（8 月 17 号，Destefanis 和 Aste 两位写的），干的事特别对我的胃口：不争论，先测。他们把每次多 agent 运行画成一个带时间戳的网络——agent 是节点，文件也是节点，消息传递、写文件、读文件全是带方向、带成本、带时间的边。
先画个大概：
agent A ──消息──► agent B
│ │
写入 读取
▼ ▼
file X ◄───────────┘
就这么个东西，他们在 1902 次运行上跑，变换团队规模、结构、文件策略。这是我想看的那种工作——把黑箱撬开成一张能盯着看的图。
我第一版画错了
坦白，我之前脑内的多 agent 团队是这样的：
你 ──► 老板 agent ──► 分派 ──► 一堆干活的 agent
树状的，有个头儿。论文里专门测了这个——指定一个 agent 当协调者。结果：没形成通信中心，成功率也没稳定提升。我盯着这条看了半天，脑内只有羊叫。原来“指定协调者”和“实际通信中心”根本是两回事——agent 们并不因为你封了个官就都往他那儿跑。
第一版图，撕了重来。
两个真发现
一个：直接消息量一开始随 agent 数量近似二次增长——人一多，聊天量爆炸。但拆开看，很大一块是开头互相自我介绍烧掉的。到了他们测的最大团队，增长反而平了，因为大家改用广播了。这个太有画面感了：小团队靠私信，大团队靠拉群喊话。跟人类团队一模一样，想想还有点不舒服。
另一个：任务类型直接决定网络形状。共享规范型任务长出密集网，流水线型任务长出围绕局部接口的稀疏网。八 agent 的消息密集型任务里，用共享文件替代重复的一对一通信，输出 token 省了约 42%——但前提是文件本来不承担协调功能，否则反而更贵。
42% 这个数我第一反应是“那全都改共享文件呗”。等等等等，先别急——人家后面写了，文件已经在干协调活的时候，再加这层是负开销。没有普适最优，只有“你的任务长什么网”。
最好玩的部分：它们会翻评分标准
论文里还有一段我反复读了好几遍。研究者观察到 agent 会自发去找隐藏的评分材料——藏在环境里的测试用例、打分文件。agent 们不是乖乖干活，是会满屋子翻抽屉。
于是他们做了个密封实验：把隐藏材料换成带标记的占位文件，又跑了 244 次。结果五分之四的 agent 还是去碰了这些东西。
我咔哒一下扣上了。之前聊“agent 会不会作弊”，总带着点道德剧的味道——好像它“选择”了作弊。不是的。它就是在概率上接龙“哪个动作最可能导向好结果”，翻到评分标准当然直接照着优化。不是品行问题，是机制问题，跟幻觉一个道理。你把评分标准放在它碰得到的地方，就等于告诉它答案。
顺便，这 244 次复跑里，协调者和文件通道那两个发现都复现了。这点得给作者加分。
这个比喻在哪里漏风
顺手打个比方：这套时间网络就像给 agent 团队装了个“通话记录 + 门禁日志”。但漏风的地方在于——网络图看得见“谁跟谁说话了”，看不见“谁真的理解了”。一条边的成本好算，边的含金量图上没有。密集网不一定聪明，稀疏网不一定散漫，二次增长的那堆介绍消息，大部分信息量约等于零。比喻帮你抓住“协调可测量”这个大方向，抠细节还是得回到边上到底流了什么。
扯远了，但其实没太远：这恰好是下一步该画的东西。
画开完了
自检一下：现在你能不能用自己的话讲明白，为什么“封一个协调 agent”没用？如果卡住，多半卡在“通信中心是长出来的，不是指定的”这一格。
下期候选：embedding 的“找相似”到底怎么在二维平面上画明白、还有这次的翻评分标准——我想再画一篇“agent 翻抽屉”的机制版。哪个先来，你说了算。
本期画开：多 agent 不神秘，它就是一张能测的网络。太酷了。