微软提出Agensh：去掉中心调度器，让1024个Agent自组织协作 - LOL赛事复盘

微软提出了一个名为Agensh的多Agent系统框架，其核心是移除中央调度器，让多达1024个Agent通过自组织方式进行协作。

相较于单个Agent的序列执行方式，多Agent系统能够通过并行处理降低整体任务延迟，从而提升处理复杂现实任务的效率。然而，当系统规模扩展到成百上千甚至上万个Agent时，如何让它们实现更高效、更有效的协同，依然是一个核心难题。

目前主流的多Agent框架（例如Codex sub-agent、Claude Code sub-agent等）普遍采用“编排者-工作者”架构，整个系统的可扩展性常常受限于编排器对工作者的管理、协调以及对其贡献的整合能力。

为了突破这一限制，微软团队提出了一种可扩展的自组织多Agent框架——Agensh。

论文链接：https://arxiv.org/pdf/2609.2678

根据论文描述，Agensh不包含中央编排器。自组织的工作者并发、异步地运行，通过轻量级的“Agentic组织基础设施”来共享状态和进展。每个工作者持续执行一个多Agent协作循环：收集上下文、认领子任务、执行动作并共享发现、验证结果、合并进展。

在ProgramBench基准测试中最难的5个任务上，当Agent数量从1个增加到128个时，平均最终测试通过率从19.31%提升至28.78%，相对提升了约49%。在pandoc任务上，当Agent数量从1个扩展到1024个后，测试通过率从33.89%提升到了55.06%。

研究团队表示，Agent数量将成为多Agent组织扩展通用智能边界的一个新的扩展维度，为存在硬延迟约束或时间预算的复杂任务提供了一种新的可行方案。

研究方法

Agensh由两部分耦合而成：一个引导所有工作者的多Agent协作循环，以及一个让积累的工作、发现和消息在整个组织内可用的组织基础设施。

五步协作循环

该框架的核心抽象是循环。在Agensh中，每个工作者并发且异步地执行五个步骤。如下图所示：

图｜Agensh多Agent协作循环。

收集上下文：工作者读取共享的用户目标、当前状态、同伴进展与消息以及累积的发现，弄清哪些已完成、哪些待做，并与环境交互，规划有效的下一步。

认领子任务：工作者提出一个要做的子任务，并以CLAIM条目的形式把范围公布到共享上下文中。如果两个工作者的认领发生重叠或冲突，鼓励它们通过直接消息自行解决。

执行动作：工作者借助可用工具在本地完成子任务。一旦得到对他人有帮助的发现，就通过共享上下文汇报中间进展。

验证结果：对照子任务的验收标准检查本地进展，不达标就持续修正。

合并进度：把贡献合并进共享工作区，并发布一条更新，说明改了什么、背后的思路和验证证据，方便同伴在此基础上继续工作；如果合并因冲突被阻塞，工作者需要吸收最新的同伴进展，解决冲突后再次合并。

合并完成后，工作者回到第一步，基于新整合的工作和同伴的最新更新收集下一轮上下文。通过自行提出并认领子任务，工作者在整个组织内自组织地完成子任务的发现与分配；由于所有工作者异步推进，任何人都不必等待同伴完成一轮迭代。

三件套基础设施

组织基础设施由共享工作区、消息接口和共享上下文三个协作机制组成。如下图所示：

图｜Agensh组织基础设施。

其中，共享工作区是一个文件系统，存放组织正在开发和已经整合的成果。它需要支持并发写入和异步读取，保留版本历史，支持合并贡献，并把合并冲突暴露给工作者，由其回溯和解决。Agensh使用Git平台管理这一工作区：工作者修改私有检出和分支，再把贡献整合进主分支。Git记录改动的来源，检测文本合并冲突，并为所有人托管issue和pull request。

消息接口用于协调进行中的工作、澄清归属重叠、解决依赖冲突。共享任务频道承载团队公告，直接消息用于紧急的一对一沟通。优先级较低的频道消息在每轮循环开始时送达，优先级较高的直接消息在每次基础设施工具调用结束时送达。接口同时保留对话历史并异步投递，因此，工作者可以及时消除认领重叠、协商依赖、请求协助，而同伴继续工作不受打断。

共享上下文用于保留可复用的发现和工作认领，思路借鉴自DeLM。工作者发布简洁、带类型的条目：

• OBSERVED：观察到的行为
• FACT：已确认的事实
• FAIL：失败的尝试
• CLAIM：当前的认领
• PATCH_SUMMARY：对已完成改动的描述

服务端保留一个仅追加的数据库，并提供上下文检索工具，让工作者可以搜索超出近期记忆的完整历史。新条目会作为较高优先级的更新，在其他每个工作者下一次基础设施工具调用返回时转发，使同伴的发现在组织内可见。

在单Agent框架之上

Agensh是叠加在Agent框架之上的组织层，而不是对它的替代。对每个工作者而言，底层单Agent框架拥有本地Agent循环——维护会话状态、调用模型、执行工具并产生工作者的下一步响应；Agensh在其外提供组织级行为，包括工作者身份、协作协议、事件路由、鲁棒分发、共享工作区访问、消息传递、共享上下文，以及恢复与存活性机制。

两者之间的接口刻意保持最小且即插即用：协作循环通过每个工作者提示词中的工作流指令来实现，而不是硬编码进运行时基础设施，所有工作者的提示词除工作者ID外完全相同。因此Agensh能通过轻量的框架适配器接入Claude Code、Copilot等不同底层，而不改变协作循环、共享服务或底层框架的Agent循环。

具体实现上，共享工作区采用Gitea，消息接口采用Mattermost，共享上下文沿用DeLM的核心思想并适配了工具格式与工作者指令。

实验结果

研究团队在ProgramBench上测试了Agensh的可扩展性。ProgramBench是面向Agent软件工程的挑战性基准之一，要求Agent组织在6小时预算内、断网条件下从零重建参考软件的行为。

他们从ProgramBench的200个实例中，选出以主流模型平均测试通过率衡量最难的五个任务：FFmpeg、gromacs、pandoc、PHP-src和ctags，涵盖多媒体处理、分子模拟、文档转换、语言解释和代码索引。参考仓库包含数千个文件，代码行数从数十万到数百万不等，是对长程多Agent协作的严苛检验。

随着Agent数量增加，五个任务的平均最终测试通过率与pandoc的最终测试通过率的变化如下：

可以看到，当Agent的数量从1个扩展到128个时，平均得分提升9.47个百分点，相对提升约49%。五个任务的最终得分总体随组织规模增大而上升。

而且，Agent数量变多，还能缩短达到同一水平所需的时间。在前两小时内，规模更大的组织更早达到相近的通过率。以pandoc为例：

• 128个Agent在30分钟检查点即超过30%的通过率；
• 32个和8个Agent分别在60分钟和90分钟检查点才首次超过该阈值；
• 单Agent在前两小时始终低于该阈值。

他们进一步在pandoc上把规模扩展到1024个Agent。同样是6小时预算，1024个Agent的结果比128个Agent高4.12个百分点，比单Agent高21.17个百分点。在模型和底层框架固定的前提下，增加工作者数量既提升了软件复现的质量，也加快了速度。

新的扩展维度

轨迹记录显示，所有工作者遵循同一个循环、收到同一份提示词（仅ID不同），但随着组织变大，新的自组织协作形式逐步出现。

8个Agent：与同伴协调实现。 工作者可以就具体的技术接口达成一致，再各自独立实现符合该接口的组件。在gromacs中，工作者先公布模块接口，再独立实现遵循该接口的命令模块。它们也能自行发现并化解认领重叠：在FFmpeg中，一名工作者与同伴讨论重叠问题后，调整了自己的工作范围，转而承担互补的工作。

32个Agent：管理多人之间的整合。 多名工作者可以共同完成一项技术贡献。在PHP-src中，数名同伴起初批准了某项贡献，随后另一名工作者找到具体的反例，之前的批准被撤回，作者修复问题后，同伴重新评审并完成合并。工作者在管理整合上更加主动，参与沟通的同伴范围也更广。

128个Agent：自组织的专业分工与流程标准化。 工作者会依据相关的过往经验选择评审者，并在之后复用这些评审关系；也能把整合某项贡献的责任转交给同伴，由后者解决冲突、验证合并后的成果并完成合并。

工作者还能协商、遵循并复用标准化的自组织流程。在pandoc中，两名工作者建立了一套整合协议：更新并测试分支，再把提交哈希发给同伴验证与合并。这套协议后来被其他工作者复用。经历若干次失败后，工作者进一步修订协议：约定授权同伴完成整个更新、测试、检查与合并的流程，同伴明确接受并执行了这一修订后的做法。

1024个Agent：组织规模上的角色分工。 多名工作者承担相同的专门角色，或在同一技术领域形成专长。在pandoc中，多名工作者担任整合者。一名工作者可以联系多个候选整合者，选择第一个有效响应者，取消其他请求，并在选定之后才移交待整合的代码。同一技术领域的专长者，也能在他人尝试失败后接手工作，避免组织依赖任何单个工作者。

总结来看，随着组织变大，多Agent协作的范围从协调实现，逐步扩展到管理整合、标准化流程，乃至组织规模上的角色分工。这些结果表明，Agent数量是多Agent组织的一个新的扩展维度。

本文来自微信公众号 “学术头条”（ID：SciTouTiao），作者：学术头条，36氪经授权发布。