微软开源Agensh 上千智能体无中心调度
时间:2026年10月24日,美国华盛顿(微软研究院总部所在地);论文本身于2026年9月22日挂网 arXiv,开源代码则在10月24日正式对外发布。
地点:微软研究院(Microsoft Research),代码托管于 GitHub 官方组织 microsoft/Agensh 仓库,采用 MIT 许可证。
人物:论文作者为微软研究院的 Zhi-Hao Zhan、Ting Song、Li Dong、Shao-Han Huang、Jian-Xun Lian、Yan Xia、Furu Wei(傅韡,腾讯优图实验室出身的微软研究院副院长)。由科技媒体 MarkTechPost 记者 Asif Razzaq 于10月24日首发报道。
事件详情:微软研究院开源了一套名为 Agensh 的多智能体协作框架,论文标题为《Agensh: Scaling Organizational Intelligence to 1,024 Agents》。与传统"主管—工人"式的智能体编排不同,Agensh 把中心调度器整个拿掉了:没有主智能体负责拆解任务、分派工作和验收成果,所有工作智能体地位完全平权,各自认领子任务、共享发现、合并代码。
每个智能体跑同一个五步循环,且全部异步并发执行。第一步是收集上下文,读取总目标、同伴进度、消息和共享看板上的发现。第二步是认领子任务,发布一条 CLAIM 声明,遇到任务重叠时通过私信与对方协商划界。第三步是动手干活,在本地调用工具工作,并尽早把有价值的发现分享出去。第四步是验证结果,对照子任务的验收标准逐条检查。第五步是合并成果,把改动合入共享仓库,并同步一条 PATCH_SUMMARY 记录。
支撑这套协作的只有三个开源组件:Gitea 提供共享工作区,负责分支、PR 和合并冲突;Mattermost 承担团队频道和私信,用于处理紧急的任务撞车;共享上下文看板则脱胎于 DeLM,存放 OBSERVED(观察)、FACT(事实)、FAIL(失败)、CLAIM(认领)、PATCH_SUMMARY(补丁摘要)五类带类型的短笔记。值得注意的是,整个协作循环是写在提示词里的,不是硬编码在运行时代码中。Agensh 本身是架在单智能体框架之上的一层,实验用的是 GitHub Copilot CLI,论文称加上薄适配层后也可以接入 Claude Code 等其他框架。
扩展规模上,每个工作智能体的输入上限为 272,000 token,输出上限 128,000 token,内存上限 64 GiB。运行在 Linux 加 Docker Compose 环境下,默认单节点 8 个工人;跑到 1024 智能体规模时用了 16 个节点,每节点 64 个智能体。
在 ProgramBench 最难的一批任务上,团队从 1 个智能体一路扩到 1024 个。这批任务是让智能体仅凭观察到的行为去重建完整软件:FFmpeg、gromacs、pandoc、PHP-src 和 ctags,参考代码库规模从 pandoc 的 2767 个文件到 PHP-src 的 26266 个文件。实验在离线环境、6 小时预算、高推理强度下进行。
用 GPT-5.6-sol 时,五任务平均最终测试通过率随规模递增:1 个智能体 19.31%,8 个 20.68%,32 个 26.52%,128 个 28.78%,整体提升 9.47 个百分点,相对增幅约 49%。在 pandoc 这一项上曲线更陡:1 个智能体 33.89%,8 个 41.75%,32 个 43.11%,128 个 50.94%,1024 个达到 55.06%。速度同样在改善,pandoc 任务上 128 个智能体在第 30 分钟就跨过 30% 通过率,而 32 个和 8 个分别需要 60 分钟和 90 分钟。仓库 README 另附了更新模型的成绩:换成 GPT-6.1-sol,pandoc 从单智能体的 56.19% 升到 32 个智能体的 79.59%,相对增幅 41.64%,但这组数字并未写进论文初版。
背景:过去两年智能体系统基本都在卷同一种结构——一个主智能体当"包工头",负责拆任务、派活、收结果,下面挂一排工人。Claude Code 的 agent teams、Codex 的 sub-agents、Copilot fleet、Kimi Agent Swarm 都是这个编排者—执行者套路。问题在于包工头盯不盯得住 1024 个工人。Agensh 的出发点正是所谓的"编排者天花板":系统扩展性不再受单个协调智能体能力的上限约束。
更值得注意的是轨迹分析里观察到的自发行为。8 个智能体时,同伴之间会自己就接口达成一致、解决重叠认领。32 个智能体时,同伴开始互相审查共享成果,出现反例时甚至会撤回已经给出的批准。128 个智能体时,团队开始复用信任过的审查者、标准化集成流程。到 1024 个智能体时,已经有若干工人自发承担起集成者的角色,而这个角色并没有人指派。协作形式是自己长出来的,没有人教。
这套结论的边界也需要说清楚:1024 智能体规模下只有 pandoc 一个任务真正跑到,团队没有披露大规模运行的 token 成本,实验用的还是单一智能体框架加提示词循环的组合。
影响:
- 多智能体系统的瓶颈第一次被量化成一个可扩展维度。论文证明在模型与底层框架完全不变的前提下,仅仅增加智能体数量就能带来接近 50% 的相对通过率提升,为"模型规模之外的第二条 scaling 路径"提供了实证。
- 智能体数量成为新能力维度。这提醒从业者,短期内提升智能体系统效果的杠杆可能不在换一个更强的模型,而在组织结构与协调机制本身。
- 协作规范由人工设计转为智能体自发涌现。智能体在无人指派的情况下演化出审查者、集成者等角色,对企业落地意味着必须为"角色自发现"留出治理空间,而不是预先写死所有分工。
- 中心调度器不再是必需品但也不能过早下结论。取消编排者降低了扩展天花板,却也把任务冲突、代码合并和上下文一致性这些最难的协调问题推给了共享基础设施和提示词工程。
总结:Agensh 的价值不在于提出一个新算法,而在于用一条可复现的实证路径回答了一个此前多靠架构直觉的问题——大规模智能体协作到底能不能不靠"包工头"。答案是能,但代价是协调逻辑被下沉到 Git 仓库、消息频道和一块共享看板里。论文标题里的"组织智能"是一个值得琢磨的提法:如果协作结构本身就是能力,那么未来的竞争可能不在谁的模型更大,而在于谁能把一群平权智能体组织得更好。仓库以 MIT 许可证开放,代码、模型配置与评测脚本均已公开,任何团队都可以在自己的 8 节点起步、向 1024 智能体规模复现这条曲线。
参考来源:
https://www.microsoft.com/en-us/research/publication/agensh-scaling-organizational-intelligence-to-1024-agents
https://arxiv.org/abs/2609.26781
https://github.com/microsoft/Agensh
https://digestai.news/story/microsoft-open-sources-agensh-a-multi-agent-harness-for-coding
https://tldrocket.com/story/microsoft-open-sources-agensh-a-multi-agent-harness-for-1024-agents
https://sifirincidakika.com/en/news/microsoft-open-sources-agensh-a-multi-agent-harness-scaling-to-1-024-agents
https://www.dogely.com/ai-agent/9617.html
https://www.aiboss88.com/en/news/project-agensh








