一句话结论：微软研究院开源的 Agensh 用一套去掉中心编排器的协作协议，把编程智能体团队从 1 个扩到 1024 个，在 ProgramBench 最难的五项任务上把平均测试通过率从 19.31% 推到 28.78%，在 pandoc 任务上从 33.89% 推到 55.06%，换成 GPT-6.1-sol 后 32 个智能体就能做到 79.59%。
10 月 24 日，微软研究院在 GitHub 上开源了 Agensh，连同实验启动脚本与复现指南一起放出，MIT 许可，仓库名 microsoft/Agensh，论文预印本早在 9 月 22 日就挂上了 arXiv。它的自我定位是一句英文：A Decentralized, Scalable Multiagent Harness，去中心化、可扩展的多智能体框架。
这个选题长期搜索价值在于它回答的是一整个赛道的路线问题。Claude Code 的 agent teams、Codex 的子智能体、Copilot fleet、Kimi Agent Swarm，这些框架都共享一个前提：有一个中心编排器负责规划、分派、合并。智能体数量一多，编排器就成了天花板。Agensh 想验证的另一条路是让智能体数量本身成为一个新的扩展维度。
去掉编排器之后发生什么
Agensh 里每个 worker 跑同样的五步循环，全部并发且异步。第一步收集上下文，读目标、读同伴进度与消息。第二步发一条 CLAIM 消息认领子任务，重叠部分通过直接消息协商。第三步用工具在本地干活，并尽早同步发现。第四步按子任务的验收标准检查结果。第五步把进度合并进公共 Git 仓库。
论文把要解决的问题称作编排器天花板。带主控的设计里，lead agent 负责全部协调工作，它的容量和上下文长度限制了团队规模。Agensh 把这部分协调交还给 worker 自己做，基础设施只提供三件东西：共享工作区承载提议中、进行中、已完成的工作，消息接口让 worker 互相说话，共享上下文保留可复用的发现与工作意图。实验里共享工作区用 Gitea，消息接口用 Mattermost，共享上下文机制改编自 DeLM，整套东西架在 Copilot harness 的单智能体循环之上。
智能体越多分不一定越高
论文在 ProgramBench 最难的五项任务上做评估，用 GPT-5.6-sol 高推理档，六小时预算，断网，智能体要从行为观察和随附文档里重建参考程序。结果有点反直觉。
| 配置 | 任务 | 最终测试通过率 | 相对变化 |
|---|---|---|---|
| 1 个智能体 GPT-5.6-sol | 五项最难任务均值 | 19.31% | 基线 |
| 128 个智能体 GPT-5.6-sol | 五项最难任务均值 | 28.78% | 约 +49% |
| 1 个智能体 GPT-5.6-sol | pandoc | 33.89% | 基线 |
| 128 个智能体 GPT-5.6-sol | pandoc | 50.94% | 约 +50% |
| 1024 个智能体 GPT-5.6-sol | pandoc | 55.06% | 约 +62% |
| 1 个智能体 GPT-6.1-sol | pandoc | 56.19% | 基线 |
| 32 个智能体 GPT-6.1-sol | pandoc | 79.59% | 约 +42% |
换成更强的模型之后，最优规模反而往下掉了一截。GPT-6.1-sol 只需 32 个智能体就打到 79.59%，而 GPT-5.6-sol 需要 1024 个才到 55.06%。论文还记录了一个反直觉现象：从 1 个加到 8 个只多了 1.37 分，最差的一组是 128 个智能体时五项任务平均只有 28.78%，也就是说在较弱的模型上堆到 128 个反而是这条曲线的最低点，需要更多智能体才能爬上去。
另一个值得记的观察是更大的团队能更早达到相同的通过率，且 worker 轨迹显示，随着组织规模增长，不同形式的自组织协作会逐渐涌现并标准化。分工、集成流程这类原本要人来设计的东西，在规模上来之后自己长了出来。
规模、成本与部署门槛
实验用的资源上限写得很具体。每个 worker 输入上限 272000 token，输出上限 128000 token，内存上限 64 GiB。默认单节点跑 8 个 worker，1024 智能体那组用了 16 个节点，每节点 64 个智能体。
开源版本提供的是单节点团队配置，用 Docker Compose 编排，外加一个独立的单智能体基线，两者都跑原生 Copilot ACP 会话。仓库里给了完整的复现指南，覆盖前置条件、配置、镜像构建、启动命令、评估、恢复流程以及各发布版本之间的差异，同时附带团队启动脚本和单智能体启动脚本两个入口。
部署门槛主要卡在节点数量上，单节点算力反而不紧张。1024 智能体意味着 16 台机器的内存与调度开销，共享工作区和消息接口的吞吐也要跟上。GitHub 上另有第三方项目做了 Agensh 风格的改造，把 Codex 变成去中心化的对等节点，配一个本地 Compose 看板和仪表盘，这类周边生态说明核心思路确实可移植。
值得参考的对照物是站内上一篇 Vercel 开源 durable-harness，那篇拆解了五个编码智能体框架的崩溃续跑机制。两件事关注的是同一套工具链的不同侧面，Agensh 解决的是规模与组织结构，durable-harness 解决的是进程存活与状态恢复。
去中心化的代价由谁来付
把协调成本转嫁给 worker，代价写在论文里也更体现在工程上。没有中心编排器意味着没有全局视角，谁在做什么靠消息和共享上下文推断，子任务重复认领要靠协商化解，集成冲突的解决顺序不再确定。Agensh 的应对是让每个 worker 严格按验收标准自检，再把进度合并进 Git 仓库，用版本控制当最后一道收敛机制。
另一个数字更能说明这套方法的位置：32 个智能体配 GPT-6.1-sol 的 79.59% 是全场最好成绩，而 1024 个智能体配 GPT-5.6-sol 只有 55.06%。规模本身不产生智能，规模必须配合足够强的单点能力才兑现成成绩。这也解释了为什么模型迭代会直接改变框架的最优参数。
多智能体架构的横向对比可以看站内这篇 Kimi Code Desktop 深度，Swarm 与 Tower 双架构讲的是同一类问题在产品侧的做法。规模化的工程底座则可以看谷歌 Agent Compute Engine 那套，20 万智能体做到 500 毫秒挂起恢复，说明承载层和协同层是可以分开演进的。
常见问题
Agensh 能用在非编程任务上吗？论文只在 ProgramBench 上评估过，Agent 需要能从行为观察和文档里重建参考程序，这是编程任务特有的形态。框架本身不绑定领域，worker 循环里的工具调用是可替换的，但官方目前只给出编程场景的实验数据。
1024 个智能体是越多越好吗？答案是否定的。实测曲线的最优点在 32 到 128 之间，弱模型上堆到 128 个还会掉分。智能体数量应当按任务难度和单点模型能力来定，把预算全花在扩规模上往往拿不到最好结果。
Agensh 和 Claude Code 的 agent teams 差在哪？核心是协调权归属。带主控的设计由 lead agent 分派和合并工作，Agensh 让每个 worker 自己认领子任务、自己协商重叠、自己合并进度。前者易管理但编排器是瓶颈，后者扩展性强但集成顺序不确定。
小结
Agensh 把一个长期被当作架构前提的东西拿来当变量：编排器不一定要存在。1024 个智能体通过 CLAIM 消息、共享工作区和共享上下文自己组织起来，在 pandoc 任务上把通过率从 33.89% 推到 55.06%，换成 GPT-6.1-sol 后 32 个智能体做到 79.59%。
它同时给出了一条不太舒服的结论。智能体数量成了一个新扩展维度，只是它并非唯一维度，模型单点能力不足时规模会把分数拉下来。多智能体系统怎么用、编排层放不放、智能体加到多少合适，这三个问题在这份开源代码里都有了可复现的答案。
相关阅读
- Vercel 开源 durable-harness：5 个编码智能体框架崩溃续跑机制拆解
- Kimi Code Desktop 深度：Swarm 与 Tower 多智能体架构
- 谷歌 Agent Compute Engine：20 万智能体 500 毫秒挂起恢复
- 谷歌开源 Harness²：不用改权重让 AI 自我修补
延伸阅读
- 微软2027年多吉瓦级Maia部署：能效领先GPU 1.7倍2 周前
- Manus融资超5亿美元：博裕IDG领投，40亿美元估值重塑AI Agent格局2 周前
- Kimi K3.1 Pro 发布：Terminal-Bench 4.0 拿 65.7%2 天前
- 山大论文实测：换编码智能体框架，成本翻 3 倍成绩不动23 小时前
继续读
同一批更新里这几篇值得一看：