Microsoft Research开源Agensh：支持1024个智能体的多智能体框架
Microsoft Open-Sources Agensh: A Multi-Agent Harness for 1,024 Agents
Microsoft Research 开源了 Agensh，一个去掉中心编排器的多智能体框架，每个 worker 自行认领子任务、共享发现并合并代码到同一个 Git 仓库。
原文给出无中心编排器的多智能体框架在 ProgramBench 上从 1 到 1024 个智能体的扩展数据，可对照现有编排式方案。
Microsoft Research 已开源 Agensh，这是一款用于大型编码代理团队的分布式工具。Agensh 多代理工具移除了大多数代理框架依赖的中心协调器。每个工作节点选择自己的子任务，共享发现结果并将代码合并到公共 Git 仓库中。在 ProgramBench 上，团队将设置规模从 1 个代理扩展到 1,024 个代理。
TL;DR
- 一个工具：测试范围从 1 到 1,024 个代理。每个工作节点获得 272,000 个 token 的输入和 128,000 个 token 的输出限制。
- 运行在：Linux with Docker Compose。默认单节点（8 个工作节点）。1,024 个代理的运行使用了 16 个节点，每个节点 64 个代理。工作节点有 64 GiB 的内存上限。
- 性能：更多代理在所有 5 个最难 ProgramBench 任务上提高了分数，并且更快地达到了这些分数。
- 最佳：在 GPT-6.1-sol 上使用 32 个代理时，pandoc 通过率为 79.59%。GPT-5.6-sol 使用 1,024 个代理时达到了 55.06%。
- 最差：5 个任务的均值在 128 个代理时仅为 28.78%。从 1 个代理增加到 8 个代理增加了 1.37 分。
Agensh 是什么？
Agensh 是 Microsoft Research 开发的一个多代理工具，它在不使用领导代理的情况下协调许多 LLM 代理。
目标问题是协调器上限。在协调器-工作节点设计中，一个领导代理计划、分配和合并所有工作。研究论文引用了 Claude Code 代理团队、Codex 子代理、Copilot 舰队和 Kimi Agent Swarm 作为例子。Agensh 让工作节点自己进行这种协调。
Agensh 协作循环是如何工作的？
每个工作节点运行相同的 5 步循环，并发和异步地执行：
- 收集上下文：读取目标、同伴进度、消息和发现结果。
- 声明子任务：发布 CLAIM，然后通过直接消息解决重叠。
- 采取行动：本地使用工具工作，并尽早发布有用发现。
- 验证结果：检查工作是否符合子任务的验收标准。
- 合并进度：合并到共享仓库，发布更新，然后重复。
三个服务连接工作节点。Gitea 托管共享工作空间，包含分支、PR 和合并冲突。Mattermost 承载团队频道和用于紧急冲突的直接消息。共享上下文板，改编自 DeLM，存储键入笔记：OBSERVED、FACT、FAIL、CLAIM 和 PATCH_SUMMARY。
循环存在于提示中，而不是运行时代码中。每个工作节点获得相同的提示，除了其 ID。Agensh 建立在单代理工具之上。实验使用了 GitHub Copilot CLI。研究论文指出，薄适配器可以连接其他工具，例如 Claude Code。
Agensh 在 ProgramBench 上的扩展性如何？
Microsoft 团队测试了 5 个最难 ProgramBench 任务：FFmpeg、gromacs、pandoc、PHP-src 和 ctags。代理根据观察到的行为重新构建每个程序。它们离线工作，在 6 小时内完成。参考仓库范围从 2,767 个文件（pandoc）到 26,266 个文件（PHP-src）。
在 GPT-5.6-sol 高推理努力下，平均最终测试通过率变化如下：
- 1 个代理：19.31%
- 8 个代理：20.68%
- 32 个代理：26.52%
- 128 个代理：28.78%
这是一个 9.47 分的提升，约 49% 的相对提升。仅在 pandoc 上，分数为 33.89%（1）、41.75%（8）、43.11%（32）、50.94%（128）和 55.06%（1,024）。
速度也有所提升：在 pandoc 上，128 个代理在 30 分钟的检查点时通过了 30%。32 个和 8 个代理分别需要 60 分钟和 90 分钟。
The README 添加了一个更新的模型。使用 GPT-6.1-sol，pandoc 从 56.19%（1 个代理）上升到 79.59%（32 个代理）。这是一个 41.64% 的相对增益。这些 GPT-6.1-sol 的数据不在 v1 论文中。
随着团队的增长，出现了哪些行为？
研究团队在每个规模下追踪了工作者的轨迹：
- 8 个代理： 同事们就接口达成一致，并自行解决重叠的声明。
- 32 个代理： 同事们审查了共享的工作；一个批准在出现反例后被撤回。
- 128 个代理： 工作者重用了可信的审查者，并标准化了一个集成协议。
- 1,024 个代理： 一些工作者充当了集成者，同事恢复了失败的工作。
这些角色都没有硬编码。
Agensh 与其他多代理 harness 相比如何？
| 功能 | Agensh | Claude Code agent teams | Kimi Agent Swarm | Copilot CLI /fleet |
|---|---|---|---|---|
| 协调 | 无协调器；同事自行声明工作 | 固定领导会话协调队友 | 协调器分解任务 | Copilot 将部分分配给子代理 |
| 显示的代理 | 1,024 个经过测试 | 无硬限制；推荐 3 到 5 个 | 最多 100 个子代理 | 未披露 |
| 共享状态 | Gitea 仓库 + 共享上下文板 | 共享任务列表带文件锁定 | 未披露 | 计划从计划模式 |
| 消息传递 | Mattermost 频道 + 直接消息 | 队友之间的邮箱消息 | 未披露 | 未披露 |
| 模型 | 模型无关；测试了 GPT-5.6-sol, GPT-6.1-sol | Claude 模型 | Kimi K2.5 | 未披露 |
| 速度声明 | 在 pandoc 上 30 分钟时通过 30%（128 个代理） | 未披露 | 比顺序快 4.5 倍（自我报告） | 未披露 |
| 可用性 | 开源，MIT | 在 Claude Code 中；实验性，默认关闭 | 顶级订阅者，研究预览 | 在 Copilot CLI 中 |
如何运行 Agensh？
发布包包括一个单节点 Docker Compose 团队和一个单代理基线。两者都使用原生 Copilot ACP 会话。您需要 Linux、Docker 引擎、Compose v2、systemd、cgroup v2 和 Python 3.11+。默认值是 8 个工作者，每个任务 6 小时，以及高强度的 gpt-5.6-sol。您还需要 ProgramBench（v1.2.5 已验证）和一个模型 API 令牌。完整步骤位于 重现指南 中。
主要要点
- Agensh 协调最多 1,024 个代理，无需中央协调器。
- 工作者通过 Gitea、Mattermost 和一个共享的发现板自行声明任务。
- 128 个代理将 5 任务 ProgramBench 的平均值从 19.31% 提高到 28.78%。
- 使用 32 个代理的 GPT-6.1-sol 在 pandoc 上达到 79.59%。
- 代码是 MIT 许可的，但令牌成本未披露。
查看 论文、GitHub 仓库 和 项目页面。此外，欢迎在 Twitter 上关注我们，别忘了加入我们的 15 万+ML SubReddit 并订阅我们的 新闻简报。等等！你用 Telegram 吗？现在你也可以加入我们的 Telegram。
需要与我们合作推广您的 GitHub 仓库 OR Hugging Face 页面 OR 产品发布 OR 网络研讨会等？联系我们
帖子Microsoft Open-Sources Agensh: A Multi-Agent Harness for 1,024 Agents首先出现在MarkTechPost上。
来源: MarkTechPost · marktechpost.com