微软提出Agensh：去掉中心调度器，让1024个Agent自组织协作
微软推出Agensh：摒弃中央调度器，实现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组织拓展通用智能边界的一个全新scaling维度，为存在严格延迟约束或时间预算的复杂任务提供了一种新的可行方案。
研究方法
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个百分点。在模型和底层框架固定的前提下，增加工作者数量既提升了软件复现的质量，也加快了速度。
新的scaling维度
轨迹记录显示，所有工作者遵循同一个循环、收到同一份提示词（仅ID不同），但随着组织变大，新的自主协作形式逐步出现。
8个Agent：与同伴协调实现。工作者可以就具体的技术接口达成一致，再各自独立实现符合该接口的组件。在gromacs中，工作者先公布模块接口，再独立实现遵循该接口的命令模块。它们也能自行发现并化解认领重叠：在FFmpeg中，一名工作者与同伴讨论重叠问题后，调整了自己的工作范围，转而承担互补的工作。
32个Agent：管理多人之间的整合。多名工作者可以共同完成一项技术贡献。在PHP-src中，数名同伴起初批准了某项贡献，随后另一名工作者找到具体的反例，之前的批准被撤回，作者修复问题后，同伴重新评审并完成合并。工作者在管理整合上更加主动，参与沟通的同伴范围也更广。
128个Agent：自主的专业分工与流程标准化。工作者会依据相关的过往经验选择评审者，并在之后复用这些评审关系；也能把整合某项贡献的责任转交给同伴，由后者解决冲突、验证合并后的成果并完成合并。
工作者还能协商、遵循并复用标准化的自主流程。在pandoc中，两名工作者建立了一套整合协议：更新并测试分支，再把提交哈希发给同伴验证与合并。这套协议后来被其他工作者复用。经历若干次失败后，工作者进一步修订协议：约定授权同伴完成整个更新、测试、检查与合并的流程，同伴明确接受并执行了这一修订后的做法。
1024个Agent：组织规模上的角色分工。多名工作者承担相同的专门角色，或在同一技术领域形成专长。在pandoc中，多名工作者担任整合者。一名工作者可以联系多个候选整合者，选择第一个有效响应者，取消其他请求，并在选定之后才移交待整合的代码。同一技术领域的专长者，也能在他人尝试失败后接手工作，避免组织依赖任何单个工作者。
总结来看，随着组织变大，多Agent协作的范围从协调实现，逐步扩展到管理整合、标准化流程，乃至组织规模上的角色分工。这些结果表明，Agent数量是多Agent组织的一个新的scaling维度。
本文来自微信公众号 “学术头条”（ID：SciTouTiao），作者：学术头条，36氪经授权发布。