没有总指挥，1024个智能体如何自组织协作？微软研究院提出新框架Agensh

背景：多智能体扩容为何遇到协调瓶颈

把一个开发任务分给更多智能体，看起来就能更快完成。但人数增加以后，谁来发现还没做的工作？两个人同时修改一个模块怎么办？各自写好的代码，最后能否拼成一个能运行的程序？

如果这些问题都交给一个主智能体，它很容易忙于分配任务、接收汇报和处理冲突。微软研究院提出的 Agensh，把这些责任交给并发工作的智能体，让它们通过共享设施自行认领任务、交换证据、验证并合并成果。

论文把组织规模推到了1024个智能体。这引出了另一个问题：增加人数的收益来自并行尝试，还是协作本身？换成简单任务，扩容是否可能适得其反？

论文标题：Agensh: Scaling Organizational Intelligence to 1,024 Agents

论文链接：https://arxiv.org/abs/2609.26781v1

代码：https://github.com/microsoft/Agensh

创新点：用共享设施支持成员自主协作

Agensh 在单智能体运行框架之上增加组织层。底层框架仍负责一个成员的会话、模型调用和工具执行；组织层提供工作区、消息和共享上下文，让成员能够知道同伴做了什么，并在此基础上继续推进。

三类设施可以理解成一个团队的代码仓库、沟通渠道和共享笔记。

共享工作区用 Gitea 和 Git 保存代码、分支及合并历史。成员在自己的检出目录里开发，再把贡献集成到主分支。

消息接口用 Mattermost 提供团队频道和私信，让成员协调接口、处理任务重叠和请求帮助。

Mattermost 是可私有化部署的开源团队即时通讯协作工具，类似能自己搭服务器的 Slack

共享上下文保存可复用的发现与工作意图。条目会区分已经观察的行为、确认的事实、失败的尝试、正在认领的工作和完成补丁的说明。这里的失败记录很有价值：一个成员证伪某条路线后，其他成员可以据此停止重复试错。

每个成员遵循同一循环：先观察目标和同伴进展，再声明自己要做的子任务，随后执行、验证、合并，最后重新观察。任务认领用 CLAIM 条目表达。它是一份工作声明，不是自动排除其他写入者的强互斥锁；发现重叠后，成员仍需沟通。Git 能发现文本合并冲突，逻辑兼容性则需要进一步验证。

这一循环通过提示词约定，运行时负责事件传递、排队、恢复和活性提醒。各成员的提示词除了身份编号外相同。因此，无中央调度者并不意味着没有共同规则，也不意味着共享服务消失了。

实验：软件重建任务中的扩容收益

实验使用 ProgramBench 的五项最难任务：FFmpeg、gromacs、pandoc、PHP-src 和 ctags。成员可以运行预编译的参考程序，通过输入输出了解行为，但不能读取其程序字节、反编译或联网获取原始实现。交付的是能重新构建、接受隐藏测试的代码。

在相同模型 GPT-5.6-sol（high）、底层 Copilot 框架和六小时组织预算下，从1个增加到128个成员，五项任务的平均最终测试通过率由19.31%升至28.78%。这是增加9.47个百分点，相对提升约49%。

pandoc 单项继续扩展到1024个成员，通过率从单成员的33.89%，升到128个成员的50.94%，再升到55.06%。最后一次扩容增加了4.12个百分点，说明千级组织仍有收益，但增量已经趋缓。

规模较大的组织还更早达到相近的通过率。但六小时是统一的墙钟预算，成员错峰启动，并非每个成员都运行完整六小时。55.06%也只是评测中的测试通过率，不能理解为已经完整复刻 pandoc。

机制观察：自组织分工如何形成

论文还分析了记录下来的协作轨迹。8个成员的组织会协商技术接口，再分别实现符合接口的模块。gromacs任务中出现了这样的模块协调；FFmpeg任务中，成员通过讨论发现认领重叠，并调整为互补的工作范围。

在32个成员的PHP-src组织中，一项贡献先得到同伴认可，另一位成员随后发现反例，原来的认可被撤回。作者修复问题后，同伴再次审查，再由另一位成员合并。轨迹同时显示，更多成员开始参与集成管理和沟通。

128个成员的组织出现了依据既往经验选择审查者、持续复用审查关系和转交集成工作的分工。pandoc中的成员建立了一套协议：作者先更新并测试分支，再发送提交哈希，请同伴验证和合并。经历失败后，他们进一步修改协议，让接手者完成更新、测试、检查和合并的整个过程。

在1024个成员的pandoc组织中，多人承担集成角色。发起者会联系几位候选集成者，选定首个有效回应者后取消其他请求，再交接代码。相同领域的成员还会在同伴尝试失败后接手工作。

这些角色与协议来自运行轨迹中的观察。各成员收到相同的协作提示词，自行选择协作者、分配责任并修改工作流程；论文据此描述了协作从接口协调向集成管理、流程标准化和角色分工的扩展。

编者碎碎念

我觉得Agensh最扎实的贡献，是把发现、失败和补丁接成可延续的共同工作。前文PHP-src那次撤回认可、修复后重新审查的过程，给“协作”提供了具体证据。这样的组织能跑到千人规模，工程上确实值得重视。

但1024这个数字也容易抢走对实验的注意。pandoc从128扩到1024，成员数增加到八倍，通过率多了4.12个百分点；六小时墙钟相同，实验却没有固定组织总token或调用预算，也没有完整报告用量和费用。它展示了时间受限时扩容可以换来更高分，却还没交代这4.12个百分点究竟有多贵。效率如何，不能靠人数和分数替它回答。

同样，取消中央编排者，把任务发现、依赖协调和成果合并交给成员，组织方式的差异很清楚。但原文没有与同等成员规模的委派式团队直接对照。“中央编排会成为瓶颈”是设计动机，谁的协调更有效，还没有被实验比出来。

固定人数本身并不奇怪，扩容实验需要这个变量。问题在于，Agensh展示了自主分工，却没有展示自主扩缩容：连启动节奏也是预设的。任务快做完、可并行工作变少时，还需要那么多人吗？它引用的《Towards a Science of Scaling Agent Systems》^[1]在控制计算预算的实验中发现，协作收益依赖任务，有些任务反而退化。Agensh只测了五项最难任务，简单但需要推理的任务会不会因重复工作、协调和干扰掉点，仍需分难度实验，不能顺着扩容曲线默认“人越多越好”。

协作的贡献也需要拆开看。《Debate or Vote》^[2]在七个NLP基准上发现，多数投票解释了多智能体辩论的大部分增益。这项研究不能直接外推到软件重建，但它提醒我们：多人带来的涨分，不能全算成交互的功劳。独立采样集成（Ensembling）通常生成多份答案，最后再选择；Agensh则在工作过程中共享发现、接续同伴的成果并整合补丁。对代码任务，答案投票并不直接适用。我更想知道固定人数、保留同一代码库和测试条件，分别移除共享上下文或消息协调的消融，观察性能、重复劳动和集成失败怎样变化。再配合模型、人数与组织总计算预算对齐的委派式对照，才能检验共享机制和组织方式各自有没有带来额外收益。