Agensh 论文精读：没有中央指挥，1024 个 Agent 如何协作写软件
原论文：Agensh: Scaling Organizational Intelligence to 1,024 Agents，Zhihao Zhan 等，Microsoft Research，arXiv:2609.26781v1，2026 年 9 月 22 日。PDF · 项目代码
如果让大量编码 Agent 同时完成一个大任务，瓶颈未必是它们各自写代码的速度，也可能是中央 Agent 分配工作、消解冲突和合并成果的能力。Agensh 的尝试是：去掉负责派工的中央指挥，让每个工作者自行寻找任务，并用共享基础设施维持协作。
论文最醒目的数字是：在六小时内重建 pandoc 的实验中，1 个
Agent 的最终测试通过率为 33.89%，1,024 个为
55.06%。但这不等于“任何任务上堆到 1,024 个 Agent
都有效”：论文的 1,024 Agent 实验只覆盖
pandoc；五任务对比最多扩展到 128
个。下面按“问题—机制—实验—限制”拆解。
一、论文要解决什么问题
常见的多 Agent 组织是 orchestrator–worker：一个主 Agent 做计划、拆任务、派给并行工作者，再收集和整合结果。这种模式容易理解，但随着工作者增多，主 Agent 必须持续处理分工、进度、依赖和合并，协调能力可能成为瓶颈。（论文第 1 节、图 2）
Agensh 改变的是组织层，不是底层语言模型。所有工作者共享同一个用户目标，运行相同的协作协议；每个人都可以发现任务、声明负责范围、实现、验证、合并，然后继续找下一件事。作者把“Agent 数量”视为模型能力、推理预算之外的另一个扩展维度。
这里的“无中央指挥”有明确含义：没有一个主 Agent 为全体工作者逐项派工和合并。它不意味着没有共同目标、规则、共享状态或事件分发系统。恰好相反，论文的核心贡献是用一套基础设施承接这些协作工作。
二、Agensh 的结构：每个 Agent 跑同一套五步循环
论文第 2.1 节、图 3 给每个工作者规定了一个异步重复的循环：
- Gather context，收集上下文：读取共同目标、仓库当前状态、同伴进度、消息和历史发现；观察环境，判断什么还没完成。
- Claim
sub-task，认领子任务：自行提出一个工作范围，把
CLAIM写入共享上下文。若与别人重叠，就通过私信协商。 - Take action，执行：在本地环境中实现任务，并及时分享对其他人有用的发现。
- Verify results，验证：按自己认领的子任务验收条件检查；不满足就继续修正。
- Merge progress，合并进展：把成果集成到共享仓库，公布改动思路和验证证据；出现合并冲突时先吸收最新进展、解决冲突，再合并。
合并后回到第一步。关键在于每个工作者独立推进，不需要全体 Agent 等同一个阶段完成。协作循环由工作者提示词引导，而不是写死在底层运行时；附录 A 展示的 1,024 人配置中，提示词除工作者 ID 外完全相同。（论文第 2.3 节、附录 A）
用一个简化例子理解：重建文档转换器时，有人探索表格行为并认领解析模块，有人探索命令行参数，有人修复构建脚本。各自验证后通过 PR 合入主分支；遇到相同文件或接口，再发消息协商。这是对论文机制的说明性例子，不是论文报告的一条具体执行轨迹。
三、让“自组织”运转的三层基础设施
| 组件 | 作用 | 论文中的实现 |
|---|---|---|
| 共享工作区 | 保存拟议、进行中和已集成的工作；提供版本历史与合并冲突 | Git 平台 Gitea；工作者使用独立检出和分支，通过 PR 集成到主分支 |
| 消息接口 | 广播进度，私下快速处理范围重叠与依赖 | Mattermost 的共享任务频道和私信 |
| 共享上下文 | 保存可复用的观察、确认事实、失败尝试、认领及改动摘要 | 追加式记录板；近期内容主动分发，完整历史可搜索 |
共享上下文的记录有明确类型：OBSERVED（观察到的行为）、FACT（确认的事实）、FAIL（被证伪的尝试）、CLAIM（正在负责的范围）、PATCH_SUMMARY（改动、思路和证据）。FAIL
尤其重要：一条可靠的失败记录能阻止其他工作者重复消耗时间。记录板保留近期内容，也提供全文搜索旧记录的工具。（论文第
2.2 节、附录 A）
消息有不同的到达时机。普通频道消息在下一轮循环开始时交给工作者；更紧急的私信，以及新的共享上下文记录，可以随工作者下一次基础设施工具调用的返回结果进入当前轮。这里不是任意时刻打断一个正在运行的进程，而是在工具返回边界插入新信息。（论文第 2.2 节、附录 B.2）
更底层还有事件路由和存活机制：Gitea 与 Mattermost 的事件进入持久队列，按事件 ID 去重；分发失败会重试，重启后恢复未完成事件；工作者空闲十分钟时会收到继续工作的提醒。这些细节表明，1,024 Agent 的实验不只依赖一段“大家自行协作”的提示词，也依赖可靠的分发、恢复和状态同步。（论文附录 B.1）
四、它和单 Agent Harness 的边界
Agensh 是叠加在单 Agent Harness 上方的组织层。单
Agent Harness
负责一个工作者的会话状态、模型调用、工具执行和下一步响应；Agensh
负责工作者身份、协作协议、共享仓库、消息、上下文、事件路由与恢复。在论文实验里，底层
Harness 使用 Copilot，模型固定为
GPT-5.6-sol、high
推理强度。作者说这层接口可以通过适配器连接其他底层
Harness，但论文的量化结果来自上述实验配置。（论文第 2.3 节、附录 C）
这个分层也解释了论文的“自组织”：它主要改变谁决定下一项任务，以及成果如何流入集体状态，并未展示训练一个全新的单体模型。论文没有通过实验把提示词、共享上下文、消息系统、Git 工作区逐一拆开，因而不能从结果中单独算出每个组件贡献了多少。
五、实验究竟怎么做
作者选择 ProgramBench
中按现有模型平均通过率衡量最难的五个任务：FFmpeg、gromacs、pandoc、PHP-src
和
ctags。任务要求在无互联网、六小时的条件下，仅通过运行一个不可读取源码的预编译参考程序，观察其行为，然后从零重建能通过隐藏测试的代码库。评测提交的是仓库中的程序和构建脚本，并报告
ProgramBench 的
canonical-kept pass rate。因此，这些数字表示重建程序通过的测试比例，不是完成整套产品的概率。（论文第
3 节、附录 A、C）
五个参考仓库大小差异明显，例如 pandoc 约 10.4
万行、PHP-src 约 281
万行；实验比较的是各任务的测试通过率，不是要求六小时复刻参考仓库每一行。所有报告的配置保持模型、底层
Harness、工作者协议、评测和总时限一致。为了降低启动时的抢占，前一小时每
30 秒启动一个 Agent，之后每 3 秒启动一个；1,024 Agent 分布在 16
台节点上，每台 64 个。单 Agent 基线另有持续工作提醒，多 Agent
的空闲工作者也会收到提醒。结束前 45 分钟和 5
分钟还有统一的合并与构建提醒。（论文附录 C）
六、结果：质量提升与达到相同质量的时间缩短
五个任务的平均分：最多测试到 128 Agent
| Agent 数 | 五任务平均最终通过率 | 相对 1 Agent 的百分点变化 |
|---|---|---|
| 1 | 19.31% | — |
| 8 | 20.68% | +1.37 |
| 32 | 26.52% | +7.21 |
| 128 | 28.78% | +9.47 |
从 1 个增至 128 个，平均分增加 9.47 个百分点，相对于 19.31% 的基线约提高 49%。论文图 5 显示五个任务整体呈随规模增大而上升的趋势；这些值是五任务平均值，不能当成每个单独任务的成绩。（论文第 3.1 节、图 5）
图 6 还比较前两小时达到相同成绩的速度。以 pandoc
为例，128 Agent 在第 30 分钟检查点超过 30% 通过率，32 Agent 在第 60
分钟、8 Agent 在第 90 分钟首次超过；单 Agent 在前两小时始终低于
30%。这说明扩大并发人数在这个设置下既提升六小时终点成绩，也让相同成绩更早出现。注意这里是离散检查点，不能解读为精确到分钟的首次达到时间。（论文第
3.1 节、图 6）
1,024 Agent：只在 pandoc
单项扩展
| Agent 数 | pandoc 六小时最终通过率 |
|---|---|
| 1 | 33.89% |
| 128 | 50.94% |
| 1,024 | 55.06% |
1,024 Agent 比 128 Agent 高 4.12 个百分点，比单 Agent 高 21.17 个百分点。从 128 到 1,024 增加八倍工作者，成绩继续增长，但边际收益明显小于从 1 到 128 的跨度。论文用这组数据证明其系统可以在该任务上扩展到千人规模并继续提高分数；它没有证明千人规模在所有任务、所有预算下都是最合算的选择。（论文摘要、图 1、第 3.1 节）
七、作者观察到的“涌现协作”
论文第 3.2 节通过工作轨迹归纳出四类现象：
- 8 人时，直接协调任务边界。
gromacs中，工作者约定模块接口后各自实现；FFmpeg中，有人在发现认领范围重叠后改做互补任务。 - 32 人时，多人共同管理集成。
PHP-src的一个贡献先得到同伴认可，随后另一人提出反例，作者修复后再次被审阅并合并。 - 128 人时，形成专业分工与重复使用的流程。
工作者按经验寻找审阅者；
pandoc中有工作者约定“作者提交已测试分支和 commit hash，由同伴验证并合并”的流程，失败后又调整协议。 - 1,024 人时，同类角色可由多人承担。
pandoc中多个工作者担任集成者；某人可以联系多名候选者，选出首个有效回应者，并取消其他请求。一个工作者失败后，同领域同伴也可能接手。
这些是从轨迹中观察到的定性案例，不是像通过率那样有统一统计检验的量化指标。它们支持“没有中央派工也能产生协调、复核和角色分工”的解释；但不能据此断言每个 1,024 Agent 运行都会出现同样组织形态。
八、如何评价这项工作
我认为最有价值的点是：论文把大规模并行 Agent 的难题从“怎样让一个主
Agent
管理更多下属”转向“怎样让工作者持续看到共同状态，并对认领、验证、合并负责”。CLAIM
降低重复劳动，FAIL 传播负面知识，PR
和验证证据让成果进入可追溯的共享状态。这种设计思路对需要长时间、多模块并行开发的任务有参考价值。
不过，读结果要保留以下边界：
- 任务范围有限。 五任务均是离线程序重建；1,024 Agent
只测了
pandoc。结果尚不能直接推广到产品开发、网页研究、写作或其他软件任务。 - 没有给出经济性结论。 论文报告通过率和到达某个通过率的时间，没有系统报告 token、算力、消息量、PR 数量或每提高一个百分点的成本。更高的六小时成绩不自动等于更省钱。
- 组件贡献未隔离。 论文固定了模型和 Harness 来比较人数，但没有充分的消融实验来分别量化共享上下文、消息、事件路由、Git 及提示词的作用。
- 统计不确定性未充分展示。 文中主要呈现这些配置的成绩和轨迹，没有提供足够的多随机种子重复、置信区间或显著性分析。尤其 128→1,024 的 4.12 个百分点差距，不能仅凭一组最终分数判断其稳定程度。
- “无中央指挥”是组织概念。 系统仍有共享服务、相同规则、统一时限和收尾提醒；这些本身就是关键工程投入。
九、一句话总结
Agensh 展示了一种让多个 Agent
自行认领任务、共享发现、互相处理冲突并完成验证合并的组织方式。在论文给定的六小时离线程序重建实验中，增加
Agent
数量带来了更高的最终测试通过率，也更早达到相近成绩；千人规模的证据目前集中在
pandoc
一项。下一步若要判断它是否适合实际工程，还需要成本、重复试验、组件消融和更多任务类型的证据。
资料：论文 PDF · arXiv 页面 · Agensh 代码仓库 · ProgramBench 论文