微软开源去中心化多智能体协作框架

让 1,024 个 AI 编程代理一起干活，最难的未必是分配算力，而是谁来拆任务、处理冲突、合并代码。Microsoft Research 开源的 Agensh 给出了一种做法：撤掉统一指挥的主代理，让工作代理自行认领任务、交流发现，并向同一个 Git 仓库提交成果。

原文展示了规模扩大后的收益，也暴露了收益的边界。值得程序员关注的，是它如何组织协作，以及为什么「代理更多」还不能直接等同于「开发更划算」。

没有主代理，任务靠什么推进

常见的多代理框架由一个主代理规划、派工并整合结果。Agensh 针对的是这种结构的协调瓶颈：团队越大，集中处理信息和决策的压力越大。

它让所有工作代理执行同一套循环：

1. 读取目标、其他代理的进展、消息和发现。
2. 发布 CLAIM 认领子任务，遇到重复认领就直接沟通。
3. 在本地调用工具执行任务，尽早分享有用发现。
4. 按子任务的验收条件检查结果。
5. 合并到共享仓库，发布进展，再进入下一轮。

这里的 harness，可以理解为包在模型外面的执行与协作环境。Agensh 建立在单代理 harness 之上，实验使用 GitHub Copilot CLI；论文称，其他 harness，例如 Claude Code，可以通过轻量适配器接入。

Agensh 把协作规则写进提示词，让代理自己执行。

除 ID 外，每个代理拿到的提示词相同。支撑协作的是三个服务：Gitea 管理仓库、分支、PR 和合并冲突；Mattermost 提供群聊及处理紧急冲突的私信；改自 DeLM 的共享上下文板记录 OBSERVED、FACT、FAIL、CLAIM、PATCH_SUMMARY 等类型的笔记。

这些组件分别解决代码放哪里、分歧怎么谈、发现如何留存的问题。撤掉主代理之后，协调工作仍然存在，只是分散给了参与者。

1,024 个代理，究竟多做对了多少

实验使用 ProgramBench 最难的 5 个任务：FFmpeg、gromacs、pandoc、PHP-src 和 ctags。代理需要根据程序表现重建实现，离线运行，每个任务限时 6 小时。参考仓库从 pandoc 的 2,767 个文件，到 PHP-src 的 26,266 个文件不等。

这与给现有项目修复一个明确的 bug 差别很大：任务空间大、可拆分部分多，也有统一的测试通过率衡量进展。

使用 GPT-5.6-sol、high reasoning effort 时，5 项任务的平均最终通过率从单代理的 19.31%，提高到 128 个代理的 28.78%，增加 9.47 个百分点，相对提升约 49%。但从 1 个增加到 8 个，只增加了 1.37 个百分点。原文称，扩大规模改善了全部 5 项任务的成绩和达成速度，但没有完整列出各规模的平均成绩。

pandoc 的数据更完整：

代理数量	最终通过率
1	33.89%
8	41.75%
32	43.11%
128	50.94%
1,024	55.06%

速度也有改善：pandoc 达到 30% 通过率，128 个代理在第 30 分钟的检查点已经做到，32 个和 8 个分别需要 60、90 分钟。不过，从 128 个增至 1,024 个，最终通过率只再增加 4.12 个百分点。

README 还补充了 GPT-6.1-sol 的结果：pandoc 从单代理的 56.19%，提升到 32 个代理的 79.59%，相对增长 41.64%。这组结果不在 v1 论文中。

模型能力与并行规模需要一起评估，代理数量不能单独解释成绩。

至少在所列 pandoc 数据中，GPT-6.1-sol 单代理的结果已经高于 GPT-5.6-sol 的 1,024 代理结果。但缺少成本和完整实验条件，不能据此计算哪种配置更划算。

自发分工很有意思，运行门槛也很具体

研究团队追踪到了不同规模下的协作行为：8 个代理会自行协商接口、解决重复认领；32 个代理开始相互审查，甚至出现收到反例后撤回批准的情况；128 个代理形成了可信审查者和统一集成协议；1,024 个代理中，一些成员承担整合工作，其他成员接手失败任务。

这些角色没有硬编码。这是有价值的观察，但原文没有给出这些行为的发生频率，也没有证明它们在不同项目中都能稳定出现。

Agensh 与其他方案的主要差别也在这里。按原文比较，Claude Code agent teams 由固定主会话协调，共享任务列表并使用文件锁，推荐 3 到 5 个成员；Kimi Agent Swarm 由主代理拆任务，使用 Kimi K2.5，最多 100 个子代理；Copilot CLI 的 /fleet 也负责把工作分给子代理。Kimi 的 4.5 倍提速属于自报数据，不能与 Agensh 的 ProgramBench 结果直接横比。

复现 Agensh 需要 Linux、Docker Engine、Compose v2、systemd、cgroup v2、Python 3.11+，以及模型 API token。发布内容包含单节点 Docker Compose 团队和单代理基线，两者都使用原生 Copilot ACP sessions；ProgramBench 已验证版本为 v1.2.5。

默认配置是 8 个工作代理、每任务 6 小时、gpt-5.6-sol 和 high effort。每个代理的输入上限为 272,000 token，输出上限为 128,000 token，内存上限为 64 GiB。1,024 代理实验使用 16 个节点，每节点 64 个代理。输入输出上限并不等于实际消耗，内存上限也不等于实际占用。

代码采用 MIT 许可证，token 成本没有披露。

我的判断

我认同 Agensh 对共享状态和协作协议的重视。多代理开发很容易停留在「同时开几个会话」，而认领、验收、审查、合并才决定并行成果能否积累下来。它提供了一套具体、可研究的组织方式。

但「去掉主代理就更好」目前仍需要打问号。原文给出了扩大规模后的结果，没有提供同模型、同预算、同任务下与集中协调方案的充分对照。能够运行到 1,024 个代理，证明了这种组织方式可以支撑大规模实验；它还没有证明普通团队应该采用这个规模。

对前端和全栈团队来说，ProgramBench 的适用前提尤其重要。重建大型程序有大量可拆分工作，真实业务中的需求澄清、跨模块约束和人工验收，未必能获得相同收益。5 项任务平均通过率最高只到所列的 28.78%，也提醒我们：规模改善了结果，距离完整交付仍可能很远。

能拿来做什么

• 在日常 AI 编程中，可以先借鉴认领协议：让并行代理写清任务范围、验收条件和当前状态，重叠时先协商接口，再继续修改代码。
• 多个代理共同修改前端或 Node 项目时，可以把发现、失败尝试和补丁摘要分开记录，减少后来者重复踩坑，也方便审查者追溯依据。
• 评估并行代理时，应同时记录测试通过率、达到目标的时间和实际 token 用量，再与更强模型的单代理结果比较。
• 确有大型、可拆分且有自动验收的任务时，可以从默认 8 个代理和单代理基线开始复现，观察协作收益能否覆盖运行与整合成本。