你有没有想过，如果给你一千个程序员，让他们同时开发同一个软件，会发生什么？
大概率是灾难。没有人知道别人在做什么，代码互相覆盖，进度混乱成一锅粥。所以现实里的软件公司，无论多大，永远都有项目经理、技术负责人层层管理，靠人来协调人。
但微软研究院最近做了一件挺反常识的事情：他们真的让1024个AI Agent同时工作，去做一件极其复杂的任务，从零开始重写一个叫pandoc的文档转换软件，不许看任何参考代码，只给6个小时。而且，这1024个Agent之间没有一个总指挥。
结果呢？最终测试通过率从单个Agent的33.89%，一路涨到了55.06%。
这个数字背后藏着一个更有意思的问题：为什么没有指挥官，一千多个AI反而能配合得更好？
**AI团队的老毛病：指挥官成了瓶颈**
先说说现在主流的多智能体系统是怎么工作的。Codex的子代理、Claude Code的子代理和团队模式、GitHub Copilot的fleet命令、月之暗面的Kimi Agent Swarm，这些框架有个共同点。
编排器（Orchestrator）：多智能体系统里负责拆解任务、分配给不同工作Agent、并管理整个流程的中心节点，类似项目经理的角色。
它们几乎全部采用"编排器-工作者"结构。一个主Agent负责规划、拆任务、分配给下面的工作Agent，再把结果汇总起来。这套逻辑听起来很合理，毕竟现实世界的项目管理也是这么干的。
问题出在规模上。
这个编排器本质上还是一个大语言模型，它的上下文窗口是有限的，它同时能盯住的工作Agent数量也是有限的。当工作Agent从8个涨到128个，编排器要读的进度汇报、要做的任务分配决策呈指数级膨胀，它自己先撑不住了。论文里提到，已有研究明确指出，这类系统的可扩展性"从根本上受限于编排器管理协调工作者、整合其贡献的能力"。
这就好比一家公司只有一个总经理，所有决策都要经过他签字。员工从10个涨到100个还勉强运转，涨到1000个，总经理的办公室门口天天排长队，他本人反而成了公司效率最大的瓶颈。如果不改变这种结构，公司规模越大，运转反而越慢，因为信息永远要绕一圈才能落地，而这一圈的时间成本会随着人数线性甚至超线性增长。
**没有指挥官，靠什么协调？**
微软团队给出的方案叫Agensh，核心思路很简单粗暴：去掉那个中心节点，让所有工作Agent地位完全平等，各自跑一套自我循环的协作流程，通过三个共享基础设施来同步信息。
多智能体协作循环：每个工作Agent独立执行的五步循环，包括收集上下文、认领子任务、执行动作、验证结果、合并进度，周而复始，直到目标达成。
这五步具体是怎么运作的？第一步，Agent先去看看共享的目标是什么，同伴们做到哪了，有什么新发现。第二步，它自己挑一个还没人做的子任务，在共享区域公开宣布"我要做这个"，如果两个Agent同时认领了重叠的任务，它们会互相发消息协调，谁转向、谁继续。第三步，动手干活，调用工具解决问题，中途发现有用的信息就随手记下来分享出去。第四步，检查自己的成果是否达标，不达标就返工。第五步，把成果合并进整个团队的共享代码库，写一段简短的更新说明，让别人能接着用。做完这一切，它立刻回到第一步，开始找下一个任务。
支撑这套循环运转的，是三样基础设施。
共享工作空间（Shared Workspace）：存放团队所有代码进展的地方，用Git这样的版本管理平台实现，支持多人同时写入、异步读取，还能记录谁改了什么、检测冲突。
消息接口（Message Interface）：Agent之间沟通用的通讯工具，分为面向全团队的频道广播和一对一的私信，私信优先级更高，能打断对方正在做的事情。
共享上下文（Shared Context）：一个只能追加、不能修改的公共笔记本，记录着"我观察到了什么"、"我确认了什么事实"、"我试过但失败了什么方法"、"我正在做什么"、"我刚完成了什么补丁"这五类标准化条目。
这个设计里最值得琢磨的是共享上下文里那条"FAIL"记录，也就是失败尝试的记录。论文特意点明它是"最高价值的条目，因为它能阻止同伴把预算浪费在同一件事上"。
这让我想起小时候做数学题，如果班里有个笔记本，专门记下"这道题我试过用A方法，走不通，别再试了"，那全班做题的效率会高多少？没有这个笔记本，每个人都要自己撞一次南墙才知道此路不通，时间全耗在重复试错上了。有了它，一个人踩过的坑，其他999个人绕道走。这不是锦上添花的细节，而是让"失败"本身变成一种可以被整个团队复用的资产，这在传统的编排器体系里几乎不可能实现，因为编排器只关心谁完成了任务，不太会主动去收集、分发"谁失败了、为什么失败"这种负面信息。
技术实现上，Agensh并没有重新发明轮子。共享工作空间用的是开源的Gitea，消息接口用的是开源聊天工具Mattermost，共享上下文的设计思路借鉴了一篇名为DeLM的论文。真正的创新点在于，这套协作循环不是硬编码进系统底层的，而是写在每个Agent收到的提示词（Prompt）里，所有工作Agent拿到的提示词一模一样，唯一区别是各自的编号。这意味着这套方案可以轻松套接到不同的底层Agent框架上，比如Claude Code或者Copilot，不需要改动核心协作逻辑。
**五个最难的编程任务，测试极限规模**
光有架构不够，得找足够硬的骨头来啃，才能看出规模化到底有没有用。
研究团队选用的测试基准叫ProgramBench，这是目前评估AI软件工程能力最严苛的基准之一。
ProgramBench：一套评测标准，要求AI Agent在完全断网、无法查阅任何现成代码的情况下，仅凭观察一个预编译好的参考程序的运行行为，从零把整个软件重新写出来，还要通过隐藏测试。
从ProgramBench的200个任务里，研究团队挑出了最难啃的五块骨头：视频处理软件FFmpeg、分子模拟软件gromacs、文档转换工具pandoc、PHP语言的官方源码PHP-src，还有代码索引工具ctags。这五个项目的参考代码库动辄成千上万个文件，代码行数从10万行到280万行不等，FFmpeg一个项目的源码体积就有75MB。这已经不是简单的编程练习，而是要在6小时内，靠"猜"和"试"重建一整套复杂系统的行为。
难度到底有多大？可以对比一下：这五个任务是ProgramBench全部200个任务里，当前最先进模型表现最差的那五个，属于"卡脖子"级别的难题。
实验用的模型是GPT-5.6-sol（高推理强度版本），底层框架用的是Copilot。结果显示，当Agent数量从1个增加到8个、32个、128个，五个任务的平均最终测试通过率分别是19.31%、20.68%、26.52%、28.78%。
从1个Agent到128个Agent，通过率提升了9.47个百分点，相对提升幅度接近49%。
这意味着什么？意味着原本100道题只能对19道，现在能对29道，多对出来的10道题不是靠模型变聪明了，模型完全没变，变的只是协作的人数。
更有意思的是时间维度上的表现。论文测量了前2小时内各个规模的通过率变化曲线，发现Agent数量越多，达到同样通过率所需的时间越短。以pandoc为例，128个Agent在30分钟这个时间点就突破了30%的通过率，32个Agent要到60分钟才达到这个水平，8个Agent要到90分钟，单个Agent则在整整2小时内都没摸到这条线。
这就像一群人合力搬一台钢琴上楼,如果只有一个人,他可能得歇好几次才能挪到目的地,而八个人一起抬,不仅最终能顺利搬上去,而且速度会快得多,因为负重被分摊了,单点的体力瓶颈消失了。如果只靠一个人硬扛,不仅慢,而且很可能中途累垮,前功尽弃。多智能体协作在这里起到的正是类似的作用,它把原本由一个Agent独自承受的探索、试错、验证全过程,拆分给了成百上千个并行的执行者,单点瓶颈被彻底稀释了。
紧接着，研究团队把测试规模再往上拉，专门在pandoc这个项目上，把Agent数量从128一路推到1024个。最终测试通过率从128个Agent的50.94%，涨到了1024个Agent的55.06%，比单Agent的33.89%整整高出21.17个百分点。
| Agent数量 | pandoc最终通过率 |
|---|---|
| 1 | 33.89% |
| 8 | 41.75% |
| 32 | 43.11% |
| 128 | **50.94%** |
| 1024 | **55.06%** |
这条曲线没有出现明显的天花板，虽然从128到1024的增幅比从1到128要平缓一些，但依然在持续上升，这暗示着Agent数量这个维度可能还没被压榨到极限。
**没有人下命令，分工是怎么自己长出来的？**
比通过率数字更让人好奇的是，研究团队回看了这些Agent的工作日志，发现随着团队规模扩大，Agent们自发演化出了越来越复杂的协作模式，而这一切完全没有人设计或指定。
在8个Agent的规模下，出现的是最基础的协调，比如在gromacs项目里，几个Agent商量好了一个统一的模块接口标准，然后各自独立去实现符合这个标准的功能模块；在FFmpeg项目里，两个Agent发现任务范围有重叠，私信沟通后，一个主动调整方向去做互补的工作。
到了32个Agent的规模，协作开始变得更立体。在PHP-src项目里，出现了这样的场景：几个同伴先批准了一份代码贡献，随后另一个Agent找出了一个具体的反例，证明这份代码有问题，之前的批准被撤回，作者修复问题后，同伴们重新审查，最终有人完成合并。这已经很接近真实软件工程团队里的代码审查（Code Review）流程了。
再往上到128个Agent，专业化分工开始显现。Agent们会根据以往的经验，倾向于挑选特定的同伴来做代码审查，并且这种审查关系会被重复使用，慢慢固化成一种默契的搭档模式。更值得注意的是，在pandoc项目里，两个Agent自发建立了一套标准化的集成流程：作者更新并测试好自己的分支，然后把提交的哈希值发给同伴做验证和合并，这套流程后来被其他Agent直接复用。经历了几次失败后，团队甚至进一步修订了协作协议，把整个更新、测试、检查、合并的流程都交由被信任的同伴一次性完成，其他Agent明确接受并执行了这个修订后的流程。
到了1024个Agent这个极端规模，出现的是角色专业化。多个Agent会共同承担起集成者（Integrator）的角色，一个Agent可以同时联系好几个候选的集成者，等第一个回应的人确认后，取消其他请求，只把代码交给被选中的那个人去合并。还有一种更有韧性的模式：如果某个Agent在处理某个技术领域时尝试失败了，另一个在同一领域有专长的Agent会主动接手，继续把工作完成，这大大降低了整个系统对单一个体的依赖。
这一系列变化,让我想起蚂蚁筑巢的过程。单只蚂蚁没有蓝图,也不接受谁的统一调度,但成千上万只蚂蚁按照简单的局部规则各自行动，最终却能建出结构精密的蚁穴，还能根据环境变化自我修复。如果强行给蚁群安排一个"总指挥蚂蚁"，让所有决策都先汇报给它再执行，蚁群的规模会立刻被这个总指挥的处理能力锁死，可能连原来蚁穴大小的十分之一都建不出来。Agensh展现出的正是这种"局部规则催生全局秩序"的现象，只不过这里的局部规则不是生物本能，而是一份完全一致的提示词，外加三样简单的共享基础设施。
从协调实现的角度看，这个提示词大有讲究。它明确告诉每个Agent，看到同伴发的FAIL记录要立刻停手，看到FACT或OBSERVED要直接拿来用，看到和自己重叠的CLAIM要用私信解决冲突，看到不重叠的CLAIM就继续干自己的活。这套简单的判断规则，配合"谁做完谁负责收尾"的原则，构成了整个自组织协作的底层逻辑。
**这套系统和别人比，差在哪、强在哪**
研究团队也梳理了一圈现有的相关工作，用来说明Agensh的位置在哪里。
Claude Code的子代理和团队模式，本质上还是围绕一个固定的主会话来调度其他Agent；Codex的子代理工作流，是把并行工作的结果统一路由回父节点做整合；Kimi Agent Swarm训练了一个专门的编排器来拆解任务、调度子Agent，虽然速度快，但骨子里还是编排器-工作者的老结构。这些系统的共同局限，正是Agensh想要绕开的那道墙。
另一条相关线索是共享上下文和去中心化协调的研究。DeLM把异步工作的Agent、任务队列、共享上下文结合起来，让Agent能在不经过中心控制器的情况下持续积累进展，Agensh的共享上下文设计正是从这里借鉴而来。还有一个挺有意思的对照案例，是安全研究者Nicolas Carlini做过的一次实验，他用16个Claude Agent，通过Git仓库和任务锁文件的方式来协调，让它们自己选任务、自己合并代码，全程没有编排Agent介入，这某种程度上验证了小规模去中心化协作的可行性，而Agensh要做的是把这个思路推向1024这个数量级。
**写在后面**
读完这篇论文，最触动我的不是那个55.06%的最终数字，而是那条自发演化出的协作阶梯：从最初简单的"你做这块我做那块"，到互相审查代码，到固定搭档、标准流程，再到最后角色分工、故障接管。这整个过程没有任何人事先设计，全靠1024份一模一样的提示词，在同样的基础设施上自己长出来的。
这让我想到一个更值得追问的问题：如果这种自组织能力在软件工程之外的领域也能复现，比如科研文献综述、法律案件分析、甚至城市交通调度，那我们现在习惯的"设一个总负责人来协调团队"的组织模式，会不会本身就是一种因为人类沟通带宽有限而被迫接受的次优解？当协调的成本可以被压得足够低，中心化的管理层级或许并不是必需品，而只是资源匮乏时代的权宜之计。
论文里也留了一个没细说的空白：1024到底是不是极限？曲线在128到1024之间已经开始放缓，如果继续推到1万、10万个Agent，通过率会继续爬升，还是会因为通信开销、冲突处理成本反噬而掉头向下？这个答案，恐怕要等下一篇论文才能揭晓。
Q&A
Q1：Agensh是什么？
A：Agensh是微软研究院提出的一种多智能体协作系统，特点是没有中心指挥Agent，靠共享工作空间、消息接口、共享上下文三个基础设施，让上千个AI Agent自己组织分工、协作完成复杂编程任务。
Q2：Agensh在实验里表现如何？
A：在ProgramBench最难的五个编程任务上，Agent数量从1个增加到128个，平均最终测试通过率从19.31%提升到28.78%。在pandoc项目上进一步扩展到1024个Agent，通过率从33.89%涨到55.06%。
Q3：为什么Agensh不需要一个总指挥Agent？
A：因为传统的编排器结构里，中心Agent的管理和协调能力会随着工作者数量增加而成为瓶颈。Agensh让每个Agent地位平等，各自执行认领任务、执行、验证、合并的循环，通过共享基础设施同步信息，避免了单点瓶颈，使系统能扩展到上千个Agent。
