多智能体系统有个越长越歪的宿命：两个智能体配合默契，加到八个开始有人读不过来，加到几十个，有价值的信息被一堆质量未知的共享产出冲淡，再有个成员中途掉线，整条协作链说断就断。10 月 12 日提交 arXiv 的 ScaleMAS（编号 2610.16120）把这三个毛病拆开归因，结论有点叛逆：问题不在智能体太笨，在协调被焊错了位置。
论文十位作者，跨计算语言与多智能体系统两个分区，尚未经同行评审。它的诊断是：主流设计都是「智能体中心」的——协调结构要么织进固定工作流，要么挂在中央协调者身上，要么走点对点私聊；晚近的黑板式方法把协调挪进共享介质，已经是对了一半，但只治好了「成员掉线」这一个毛病，读取负担与信息掺水没人管。ScaleMAS 的做法是把协调整个搬进一个共享消息库：异步智能体不互相私聊，只跟介质打交道，全部交互收敛成三个动作。
介质里只做三件事
发布：新消息可以挂引用，指向它基于的旧消息，协作关系因此可追溯。检索：按内容搜，最多回 k 条——群再大，每个智能体的阅读量永远有界；排序同时看相关度和被引用次数，论文实测引用次数是质量的有效代理。到访：知道地址就能直接取，顺着引用链摸瓜，不必重放全部历史。
两条边界比三个动作更值钱：消息比生产者活得久——有人掉线，他留下的消息还在介质里，队伍接着转；读取量有硬顶——规模上去的前提不是智能体变乖，是介质替每个人守住了注意力。论文报告在四个智能体任务上，这套基座中心设计以更低的推理开销胜过智能体中心与黑板式基线，并且能一路扩展到 128 个智能体，中途损失成员仍可继续。
放进台谱里看
「把共享记忆当协调介质」这条线站点攒了几篇姿态迥异的样本：1939 的 GitSwarm 让中间成果以原子提交落进可分支仓库，治的是单智能体的复合推理复利；1706 的 Bad Monkey AgentSpaces 走无中心服务器的点对点，让不同团队的 agent 互相补位；1260 那篇测试时通信，靠共享目录让 k 个智能体顶四倍规模的散兵游勇。ScaleMAS 的差异在它把「规模」本身设为头号敌人——128 这个数字和「读有界」的设计，都是冲着规模化去的，前几篇并没有正面回答这个问题。
它和 1706 也构成一组有意思的对位：同样松散耦合，1706 保留智能体之间的直接发现与接管，ScaleMAS 干脆抽掉私聊通道，只留介质。哪种更接近工程现实，可能要等两边都放出代码才判得清。
几盆该浇的冷水
引用次数当质量代理，逻辑上顺，工程上有偏：早期消息更容易被引用，热门会自我加强，一个开头错了但传得广的判断，可能被引用数一路护送成「共识」。k 的上限同样是把双刃剑——读有界是靠牺牲召回换的，任务需要冷门旧线索时，这个边界就是天花板。摘要层面既没点名四个任务是什么，也没给具体数值，「更低推理开销」的幅度要等全文。异步介质还留了一个没人答的问题：协调延迟算进智能体的决策时钟里，会不会把「快而错的私聊」重新变成香选择。十人团队、预印本，代码情况摘要页未说明。
给正在堆多智能体的团队一个对照实验：把你们系统的协调通道画出来，数一数每个智能体平均每轮要读多少条同伴消息。如果这个数字随人数线性上涨，你们缺的不是更聪明的 prompt，是一个有界的介质。