微软Agensh框架：上千AI自主协作开发软件，测试成绩显著提升

让上千个AI协作开发软件时，任务拆分、工作分配与代码冲突处理的问题，一直是团队协作的核心挑战。近期一项实验展示了一种全新的协作模式，通过调整智能体的组织架构，实现了更高效的软件开发。

微软研究院开展的这项实验中，研究人员移除了传统协作模式中负责统筹的中心智能体，让1024个AI智能体自主认领任务、协商分工、编写与审查代码。实验设置了断网、限时6小时的条件，要求团队从零复现文档转换工具pandoc的功能。最终，这支无中心的智能体团队通过了55.06%的隐藏测试，而单个智能体的通过率仅为33.89%。

这项实验虽未完整重建pandoc工具，但凸显了协作模式调整带来的变化：在使用相同底层模型的前提下，增加参与者数量、优化协作方式，能让团队更快达到较高的测试成绩，且在时限结束时完成更多工作。

支撑这支无中心团队的是微软提出的多智能体框架Agensh。该框架摒弃了统一派活的主管角色，让每个智能体遵循相同的协作循环，通过代码仓库、即时消息与共享看板三类基础设施，自主寻找并推进工作。

一、AI团队的协作上限，可能受限于层级管理

单个智能体开发大型软件时，需依次完成阅读材料、调用工具、编写代码、验证结果等步骤，任务越复杂耗时越长。多智能体协作可实现部分工作并行，但也带来新的协调问题：谁负责哪部分工作？不同智能体修改同一段代码如何处理？完成的模块由谁整合？

常见的协作方案如Codex子智能体、Claude Code协作模式等，多采用“主智能体规划任务，其他智能体执行”的中心架构。这种模式分工明确，但随着参与者增加，主智能体需处理的任务安排、进度更新、成果整合工作也随之增多，团队扩展规模的上限可能受限于主管的协调能力。

Agensh则尝试将这些协调工作分散给所有成员：每个智能体既负责编写代码，也参与任务发现、依赖协调与成果整合。

左侧为主管统一分发的中心编排架构，右侧为依靠共享基础设施与协作循环自组织运转的Agensh架构。

二、从“主管派活”到“协商自治”的协作转变

Agensh将原本集中在中心主管的任务选择、分工协调、成果整合工作，交由所有成员共同完成。每个智能体遵循一套统一的五步协作循环：收集上下文、认领子任务、执行并分享发现、验证结果、合并进展。

智能体启动工作前，会先查看共同目标、现有代码与其他成员的进度，找出未完成部分，再在共享看板上发布认领声明，说明负责的内容。若出现任务重叠，相关成员可直接通过消息协商调整范围。完成开发后，智能体验证结果、合入共享代码并发布变更说明，随后继续寻找下一项任务。

整个过程异步推进，成员无需等待他人完成同一轮工作即可继续。

这种自主分工的前提是工作状态与成果可见，Agensh通过三类基础设施落地协作循环：

首先是代码仓库Gitea：智能体在各自工作目录与分支开发，成果整合到主分支，版本控制记录代码变化并暴露合并冲突。

其次是即时通讯工具Mattermost：公共频道发布团队公告，直接消息处理任务重叠、依赖冲突等需及时协商的问题，消息按优先级送达。

第三是共享上下文看板：成员记录观察到的行为、确认的事实、失败方案、处理中的任务与修改，供其他成员读取与搜索，减少重复探索。

这套协作循环的规则写在每个智能体的提示词中，除身份编号外，成员收到的操作说明一致。具体任务认领、协商对象由成员根据进度自行决定。

Agensh负责组织层面的通信与协作，底层单智能体框架则负责模型调用、工具执行与工作过程维持，协调工作由成员与共享系统共同承担，无需中心主管逐项派发任务、汇总进展。

三、组织规模成为AI能力的变量

在底层模型不变的情况下，AI团队的整体测试表现可随协作规模扩大而提升。研究团队选择了ProgramBench中最难的五项任务，包括FFmpeg、pandoc、PHP-src等大型开源软件，要求智能体在无法联网获取原始实现的条件下，从零编写程序复现参考软件行为。实验统一使用GPT-5.6-sol（high），底层单智能体框架为Copilot，总时限6小时。

从1个智能体增加到128个，五项任务的平均最终隐藏测试通过率从19.31%提升至28.78%，相对提升约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个智能体时，团队中出现了专门承担代码整合的成员，开发者可联系候选整合者移交代码，尝试失败后有经验的成员可接续工作。

这些记录展示了比“自主认领任务”更进一步的协作：成员会选择合作对象、形成稳定分工，并根据问题调整工作流程。不过，这种自组织仍建立在预设条件之上，研究者已提供协作循环、通信工具、任务认领方式与验证要求，成员自主形成的是具体合作关系、专业角色与整合流程。

写在最后

Agensh实验表明，在受控的软件重建任务中，使用相同底层模型，让更多智能体通过共享代码、消息与记录协作，可提高时限内的测试成绩，缩短达到一定成绩的时间。

规模扩大的收益仍需持续观察：在pandoc任务中，128到1024个智能体的通过率从50.94%提升至55.06%，更多参与者带来了进步，但人数增长与成绩增长并不同步。

未来需验证这套协作方式能否用于更广泛任务，以及所需的资源投入。进入实际开发后，团队还需解决需求判断、代码维护、错误追踪与责任明确等问题。

这项实验展示了上千个智能体自主分工的可行性，要将其转化为日常可用的开发方式，还需进一步验证协作效果、资源投入与维护成本的关系。