从 1 个到 128 个智能体，得分一路涨：无主管团队的账没算完
这篇论文最有价值的不是「团队越大越好」，而是它把「谁来协调」这个问题换了个问法。微软的研究发现，不设中央管理者的编程智能体团队，规模越大得分越高、完成越快。结论听起来反直觉，但读细节会发现，真正的变量是协调机制。
一、论文讲了什么
- 在 ProgramBench 的 200 个任务中，取最难的 5 个做实验。
- 无主管团队从 1 个扩展到 128 个智能体，每一步的平均得分都在提升。
- 方案名 Agensh：每个智能体自行认领子任务、自主构建测试，并把结果合并到共享 Git 仓库。
- 所有运行使用同一个模型——也就是说，增益来自组织方式，而不是更强的模型。
二、为什么「无主管」反而更快
- 有中央管理者时，调度器本身就是串行节点：任务分派、结果汇总、冲突裁决都要排它的队。规模一大，管理者成为瓶颈。
- 改成「自认领 + 共享仓库」后，协调被下沉到共享状态上。Git 的合并语义天然充当了冲突检测器：两个人改同一处，合并时就会暴露。
- 「自主构建测试」是这套方案真正的关键。没有测试，自认领就退化成各写各的、没人能判断对错。
- 换个角度看，这更像开源社区的协作模型，而不是公司组织的管理模型——约定 + 可见的状态取代了逐级审批。
三、对读者的实际影响与建议
- 做 Agent 工程的团队：可以先把「任务队列 + 共享产物仓库 + 自动测试」这套最小骨架搭起来，再考虑是否加编排层。很多时候编排层是在替一个设计不当的共享状态打补丁。
- 评估方案时：重点问三件事——子任务如何避免重复认领、冲突如何检测、失败如何回溯。论文没有回答这些工程细节，但生产环境必须先回答。
- 成本意识：论文未报告大团队的成本。128 个智能体并行意味着 token 与时间开销同步放大。把「每任务成本」和「每任务得分」放在一起看，才是有意义的指标。
- 可迁移的判断：任何多智能体系统的收益，都要用「边际智能体的边际贡献」来衡量，而不是看总分曲线的斜率。
四、边界与提醒
- 实验规模是 200 个任务中挑出的 5 个最难任务，样本很窄，不能直接外推到所有编程任务。
- 全部使用同一模型意味着结论不能推广到异构模型混合编排的场景。
- 论文没有比较「无主管」与「有主管」在同一预算下的表现。缺少预算对齐，效率结论只能算初步。
参考来源
- X：Rohan Paul (@rohanpaul_ai)：《微软论文：无主管编程智能体团队规模越大得分越高》 https://x.com/rohanpaul_ai/status/2106950188011258367
延伸阅读：多个智能体同时改一个仓库：Git 要补的不是速度，是边界 · WebMCP 已铺到近 3000 个站点：给智能体开的口子，安全团队还没看见 · 6700 万篇文章被爬：当智能体的「探索」落在别人的账单上