相比于单 Agent 的序列执行，多 Agent 系统可以通过并发执行降低整体任务延迟，进而提升复杂真实任务的处理效率。然而，当系统规模扩展至成百上千、甚至上万个 Agent 时，如何让它们更高效、更有效地协同，仍是一项核心挑战。
当前主流的多 Agent Harness（如 Codex sub-agent、Claude Code sub-agent 等）普遍采用“编排者-工作者”结构，整个系统的可扩展性，往往受限于编排器管理、协调工作者并整合其贡献的能力。
为突破这一限制，微软团队提出了一个可扩展的自组织多 Agent Harness——Agensh。
论文链接：https://arxiv.org/pdf/2609.2678
据论文描述，Agensh 不包含中央编排器，自组织的工作者并发、异步地运行，通过轻量的“Agentic 组织基础设施”共享状态与进展，每个工作者持续执行一个多 Agent 协作循环：收集上下文、认领子任务、执行动作并共享发现、验证结果、合并进展。
在 ProgramBench 最难的 5 个任务上，当 Agent 数量从 1 增加到 128 时，平均最终测试通过率从 19.31% 提升至 28.78%，相对提升约 49%；在 pandoc 任务上，把 Agent 数量从 1 扩展到 1024 后，测试通过率从 33.89% 提升到 55.06%。
研究团队表示，Agent 数量将是多 Agent 组织扩展通用智能边界的一个新的 scaling 维度，为硬延迟约束或时间预算下的复杂任务提供了一个新的可行方案。
研究方法
Agensh 由两部分耦合而成：一个引导所有工作者的多 Agent 协作循环，以及一个让积累的工作、发现和消息在整个组织内可用的组织基础设施。
五步协作循环
Harness 的核心抽象是循环。在 Agensh 中，每个工作者并发且异步地执行五个步骤。如下图：
图｜Agensh 多 Agent 协作循环。
收集上下文（Gather context）：工作者读取共享的用户目标、当前状态、同伴进展与消息以及累积的发现，弄清哪些已完成、哪些待做，并与环境交互，规划有效的下一步。
- 认领子任务（Claim sub-task）：工作者提出一个要做的子任务，并以 CLAIM 条目的形式把范围公布到共享上下文中。如果两个工作者的认领发生重叠或冲突，鼓励它们通过直接消息自行解决。
- 执行动作（Take action）：工作者借助可用工具在本地完成子任务。一旦得到对他人有帮助的发现，就通过共享上下文汇报中间进展。
- 验证结果（Verify results）：对照子任务的验收标准检查本地进展，不达标就持续修正。
- 合并进度（Merge progress）：把贡献合并进共享工作区，并发布一条更新，说明改了什么、背后的思路和验证证据，方便同伴在此基础上继续工作；如果合并因冲突被阻塞，工作者需要吸收最新的同伴进展，解决冲突后再次合并。
合并完成后，工作者回到第一步，基于新整合的工作和同伴的最新更新收集下一轮上下文。通过自行提出并认领子任务，工作者在整个组织内自组织地完成子任务的发现与分配；由于所有工作者异步推进，任何人都不必等待同伴完成一轮迭代。
三件套基础设施
组织基础设施由共享工作区（Shared Workspace）、消息接口（Message Interface）和共享上下文（Shared Context）三个协作机制组成。如下图：
图｜Agensh 组织基础设施。
其中，共享工作区是一个文件系统，存放组织正在开发和已经整合的成果。它需要支持并发写入和异步读取，保留版本历史，支持合并贡献，并把合并冲突暴露给工作者，由其回溯和解决。Agensh 用 Git 平台管理这一工作区：工作者修改私有检出和分支，再把贡献整合进主分支。Git 记录改动的来源，检测文本合并冲突，并为所有人托管 issue 和 pull request。
消息接口用于协调进行中的工作、澄清归属重叠、解决依赖冲突。共享任务频道承载团队公告，直接消息用于紧急的一对一沟通。优先级较低的频道消息在每轮循环开始时送达，优先级较高的直接消息在每次基础设施工具调用结束时送达。接口同时保留对话历史并异步投递，因此，工作者可以及时消除认领重叠、协商依赖、请求协助，而同伴继续工作不受打断。
共享上下文用于保留可复用的发现和工作认领，思路借鉴自 DeLM。工作者发布简洁、带类型的条目：
- OBSERVED：观察到的行为
- FACT：已确认的事实
- FAIL：失败的尝试
- CLAIM：当前的认领
- PATCH_SUMMARY：对已完成改动的描述
服务端保留一个仅追加的数据库，并提供上下文检索（grep）工具，让工作者可以搜索超出近期记忆的完整历史。新条目会作为较高优先级的更新，在其他每个工作者下一次基础设施工具调用返回时转发，使同伴的发现在组织内可见。
在单 Agent 框架之上
Agensh 是叠加在 Agent Harness 之上的组织层，而不是对它的替代。对每个工作者而言，底层单 Agent Harness 拥有本地 Agent 循环——维护会话状态、调用模型、执行工具并产生工作者的下一步响应；Agensh 在其外提供组织级行为，包括工作者身份、协作协议、事件路由、鲁棒分发、共享工作区访问、消息传递、共享上下文，以及恢复与存活性机制。
两者之间的接口刻意保持最小且即插即用：协作循环通过每个工作者 Prompt 中的工作流指令来实现，而不是硬编码进运行时基础设施，所有工作者的 Prompt 除工作者 ID 外完全相同。因此 Agensh 能通过轻量的 Harness 适配器接入 Claude Code、Copilot 等不同底层，而不改变协作循环、共享服务或底层 Harness 的 Agent 循环。
具体实现上，共享工作区采用 Gitea，消息接口采用 Mattermost，共享上下文沿用 DeLM 的核心思想并适配了工具格式与工作者指令。
实验结果
研究团队在 ProgramBench 上测试了 Agensh 的可扩展性。ProgramBench 是面向 Agent 软件工程的挑战性基准之一，要求 Agent 组织在 6 小时预算内、断网条件下从零重建参考软件的行为。
他们从 ProgramBench 的 200 个实例中，选出以主流模型平均测试通过率衡量最难的五个任务：FFmpeg、gromacs、pandoc、PHP-src 和 ctags，涵盖多媒体处理、分子模拟、文档转换、语言解释和代码索引。参考仓库包含数千个文件，代码行数从数十万到数百万不等，是对长程多 Agent 协作的严苛检验。
随着 Agent 数量增加，五个任务的平均最终测试通过率与 pandoc 的最终测试通过率的变化如下：
可以看到，当 Agent 的数量从 1 个扩展到 128 个时，平均得分提升 9.47 个百分点，相对提升约 49%。五个任务的最终得分总体随组织规模增大而上升。
而且，Agent 数量变多，还能缩短达到同一水平所需的时间。在前两小时内，规模更大的组织更早达到相近的通过率。以 pandoc 为例：
- 128 个 Agent 在 30 分钟检查点即超过 30% 的通过率；
- 32 个和 8 个 Agent 分别在 60 分钟和 90 分钟检查点才首次超过该阈值；
- 单 Agent 在前两小时始终低于该阈值。
他们进一步在 pandoc 上把规模扩展到 1024 个 Agent。同样是 6 小时预算，1024 个 Agent 的结果比 128 个 Agent 高 4.12 个百分点，比单 Agent 高 21.17 个百分点。在模型和底层框架固定的前提下，增加工作者数量既提升了软件复现的质量，也加快了速度。
新的 scaling 维度
轨迹记录显示，所有工作者遵循同一个循环、收到同一份提示词（仅 ID 不同），但随着组织变大，新的自组织协作形式逐步出现。
8 个 Agent：与同伴协调实现。工作者可以就具体的技术接口达成一致，再各自独立实现符合该接口的组件。在 gromacs 中，工作者先公布模块接口，再独立实现遵循该接口的命令模块。它们也能自行发现并化解认领重叠：在 FFmpeg 中，一名工作者与同伴讨论重叠问题后，调整了自己的工作范围，转而承担互补的工作。
32 个 Agent：管理多人之间的整合。多名工作者可以共同完成一项技术贡献。在 PHP-src 中，数名同伴起初批准了某项贡献，随后另一名工作者找到具体的反例，之前的批准被撤回，作者修复问题后，同伴重新评审并完成合并。工作者在管理整合上更加主动，参与沟通的同伴范围也更广。
128 个 Agent：自组织的专业分工与流程标准化。工作者会依据相关的过往经验选择评审者，并在之后复用这些评审关系；也能把整合某项贡献的责任转交给同伴，由后者解决冲突、验证合并后的成果并完成合并。
工作者还能协商、遵循并复用标准化的自组织流程。在 pandoc 中，两名工作者建立了一套整合协议：更新并测试分支，再把提交哈希发给同伴验证与合并。这套协议后来被其他工作者复用。经历若干次失败后，工作者进一步修订协议：约定授权同伴完成整个更新、测试、检查与合并的流程，同伴明确接受并执行了这一修订后的做法。
1024 个 Agent：组织规模上的角色分工。多名工作者承担相同的专门角色，或在同一技术领域形成专长。在 pandoc 中，多名工作者担任整合者。一名工作者可以联系多个候选整合者，选择第一个有效响应者，取消其他请求，并在选定之后才移交待整合的代码。同一技术领域的专长者，也能在他人尝试失败后接手工作，避免组织依赖任何单个工作者。
总结来看，随着组织变大，多 Agent 协作的范围从协调实现，逐步扩展到管理整合、标准化流程，乃至组织规模上的角色分工。这些结果表明，Agent 数量是多 Agent 组织的一个新的 scaling 维度。
本文来自微信公众号 “学术头条”（ID：SciTouTiao），作者：学术头条，36氪经授权发布。