Datawhale干货
最新研究：微软研究院
让上千个 AI 一起开发软件，谁来拆任务、分工作、处理代码冲突？
微软研究院在一项实验中，拿掉了负责统筹的中心智能体，让 1024 个 AI 自己认领任务、协商分工、编写和审查代码。在断网、限时 6 小时的条件下，这支队伍从零复现文档转换工具 pandoc 的行为，最终通过了 55.06% 的隐藏测试；单个智能体的成绩则是 33.89%。
这项实验尚未完整重建 pandoc，但它展示了一种值得关注的变化：使用相同的底层模型，调整协作方式、增加参与者，也能让团队更快达到一定的测试成绩，并在时限结束时完成更多工作。
支撑这支队伍的是微软提出的多智能体框架 Agensh。它没有设置统一派活的主管，而是让每个智能体遵循相同的协作循环，通过代码仓库、即时消息和共享看板，自主寻找下一项工作。
一、AI 团队的上限，可能卡在层级管理上
单个智能体开发大型软件，需要不断阅读材料、调用工具、编写代码和验证结果。许多步骤只能依次推进，任务越复杂，耗时就越长。
多智能体可以把部分工作并行展开，但也带来了新的协调问题：谁负责哪一块？两个智能体修改了同一段代码怎么办？各自完成的模块，最后由谁整合？
论文将 Codex 子智能体、Claude Code 的相关协作模式和 Copilot fleet 等列为常见方案：由一个主智能体规划任务，再交给其他智能体执行。
这种结构分工明确，但随着参与者增加，主智能体需要处理的任务安排、进度更新和整合工作也随之增多。团队能扩展到多大，可能受到主管协调能力的限制。
Agensh 尝试把这些工作分散给团队成员：每个智能体既负责写代码，也参与发现任务、协调依赖和整合成果。
左侧为主管统一分发的中心编排架构，右侧为依靠共享基础设施与协作循环自组织运转的 Agensh 架构。
二、AI团队从「主管派活」，转向「协商自治」
Agensh 把原本集中在主管身上的任务选择、分工协调和成果整合，交给成员共同完成。每个智能体都遵循同一套五步协作循环：收集上下文、认领子任务、执行并分享发现、验证结果、合并进展。
一个智能体开始工作前，先查看共同目标、现有代码和其他成员的进度，找出尚未完成的部分，再在共享看板上发布认领声明，说明自己准备负责什么。
如果两项认领发生重叠，相关成员可以直接发消息协商，调整各自的范围。完成开发后，智能体验证结果、合入共享代码，再发布变更说明，继续寻找下一项任务。
整个过程异步进行，成员不需要等其他人完成同一轮工作，便能继续推进。
成员能够自主分工，前提是彼此的工作状态可见，已经完成的成果也能被其他人接着使用。Agensh 用三类基础设施，把这套协作循环落到具体操作上。
首先是代码仓库 Gitea。智能体在各自的工作目录和分支中开发，再将成果整合到主分支。版本控制记录代码的变化，也暴露需要处理的合并冲突。
其次是即时通讯工具 Mattermost。公共频道用于发布团队公告，直接消息用于处理任务重叠、依赖冲突等需要及时协商的问题。两类消息按不同优先级送达。
第三是共享上下文看板。成员把已经观察到的行为、确认的事实、失败方案、正在处理的任务和完成的修改，分别记录下来。其他成员既能读取近期更新，也能搜索历史记录，减少重复探索。
这套协作循环写在每个智能体的提示词中，除身份编号外，成员收到的操作说明相同。认领任务、处理冲突和交接成果都有共同的操作规则；具体认领哪项任务、与谁协商，则由成员根据工作进度自行决定。
Agensh 负责组织层面的通信和协作，底层单智能体框架则负责调用模型、执行工具和维持各自的工作过程。协调工作由成员和共享系统共同承担，无需中心主管逐项派发任务、汇总进展。
三、组织规模，也成了 AI 能力的一个变量
研究团队选择了 ProgramBench 中最难的五项任务，包括 FFmpeg、pandoc 和 PHP-src 等大型开源软件。
任务要求智能体在无法联网获取原始实现的条件下，从零编写程序，复现参考软件的行为。实验统一使用 GPT-5.6-sol（high），底层单智能体框架为 Copilot，总时限为 6 小时。
从 1 个智能体增加到 128 个，五项任务的平均最终隐藏测试通过率由 19.31% 提升至 28.78%，增加了 9.47 个百分点，相对提升约 49%。
在 pandoc 任务上，研究团队进一步扩大了规模：单个智能体的最终通过率为 33.89%，128 个智能体达到 50.94%，1024 个智能体达到 55.06%。
更大的队伍也更早达到了一定的测试成绩。在 pandoc 任务中，128 个智能体在第 30 分钟的检查点已超过 30% 通过率；32 个和 8 个智能体分别到第 60 分钟、第 90 分钟的检查点才超过这一水平，单智能体在前两小时内始终未达到。
四、岗位不必预先设定，专业分工也能自行形成
除了最终分数，研究团队还查看了智能体的运行记录，观察它们如何组织协作。
在 8 个智能体的队伍中，成员已经会协商技术接口，再分头实现相关模块；遇到任务重叠，也会沟通后调整范围。
到了 32 个智能体，多个成员开始共同参与同一项代码贡献的审查和整合。一次 PHP-src 任务中，一项修改起初获得了认可，随后另一名成员发现反例，先前的认可被撤回，作者修复问题后再次接受审查。
在 128 个智能体的队伍中，成员开始根据相关经验选择审查者，并重复使用已经建立的合作关系。pandoc 任务中，一些成员还约定了更新分支、测试、交给同伴验证和合并的流程，其他成员随后沿用并调整了这套做法。
当规模扩大到 1024 个智能体，团队中出现了多名专门承担代码整合工作的成员。开发者可以联系候选整合者，确定接手者后再移交代码；某项尝试失败后，具备相关经验的成员也能接续工作。
这些记录展示了比「自己认领任务」更进一步的协作：成员会选择合作对象、形成相对稳定的分工，并根据遇到的问题修改工作流程。
不过，自组织仍建立在预设条件之上。研究者已经提供协作循环、通信工具、任务认领方式和验证要求；成员自主形成的是更具体的合作关系、专业角色和整合流程。 论文第 2、3 节及附录 A（https://arxiv.org/html/2609.26781v1）
写在最后
Agensh 的实验说明，在这些受控的软件重建任务中，使用相同的底层模型，让更多智能体通过共享代码、消息和记录协作，可以提高时限内的测试成绩，也能缩短达到一定成绩所需的时间。
规模扩大的收益也值得继续观察。在 pandoc 上，从 128 个增加到 1024 个智能体，最终通过率由 50.94% 提升至 55.06%。更多参与者带来了进步，但人数增长与成绩增长并不同步。
接下来需要回答的，是这套方式能否用于更广泛的任务，以及获得这些进步需要付出多少资源。进入实际开发后，团队还需要判断需求、维护代码、追踪错误，并明确谁对最终结果负责。
这项实验已经展示了上千个智能体如何自主分工。要把它变成日常可用的开发方式，还需要进一步验证协作效果、资源投入与维护成本之间的关系。