背景：瓶颈卡在编排器身上
并行执行降低复杂任务的端到端延迟，这是多智能体系统最直观的收益。过去两年，主流编码 Harness 陆续把子智能体能力做成标配，形态高度一致：一个编排者负责任务分解、分配与结果整合，若干工作者负责执行。论文点出的正是这个结构的上限——系统的可扩展性「往往受限于编排器管理、协调工作者并整合其贡献的能力」。
这个判断在具体工程里不难体会。编排器要维护全局任务表、跟踪每个工作者的状态、判断哪些产出可以合并、在冲突时裁决。工作者数量增长时，这些工作的复杂度并非线性增长：上下文要汇总、消息要路由、冲突要裁决，编排器自身的上下文窗口与决策频率都会先于工作者饱和。
Agensh 的做法是把这层拿掉。按论文摘要的表述，工作者「并发地执行一个多智能体协作循环，持续收集上下文、认领并自行分配子任务、采取行动并共享发现、验证结果、以异步方式合并进展」。注意其中的措辞：认领并自行分配。任务不是被派下来的，是工作者自己从共享状态里挑走的。
需要提前说明一处时间线：论文于 2026 年 9 月 22 日提交 arXiv（v1，署名 Zhihao Zhan、Ting Song、Li Dong、Shaohan Huang、Jianxun Lian、Yan Xia、Furu Wei 七位作者，来自微软研究院），代码于 10 月 24 日在 github.com/microsoft/Agensh 以 MIT 许可公开，版本号 1.0，除 Harness 本体外还包含实验启动脚本与复现指南。官方项目页另有单独入口。也就是说，论文与代码之间存在一个月的间隔，本文涉及仓库特有读数时会明确标注来自仓库而非论文。
五步协作循环：每个工作者跑同一份循环
Agensh 的核心抽象不是角色，也不是图，而是循环。每个工作者并发且异步地重复执行五个步骤，直到用户目标达成：
- 收集上下文（Gather context）：读取共享的用户目标、当前状态、同伴进展与消息、以及累积的发现，弄清哪些已完成、哪些待做，并与环境交互，规划有效的下一步
- 认领子任务（Claim sub-task）：提出一个打算做的子任务，并以 CLAIM 条目的形式把范围公布到共享上下文中
- 执行动作并共享发现（Take action and share findings）：实际动手，把过程中得到的可复用结论写回共享上下文
- 验证结果（Verify results）：对自己的产出做验证
- 合并进展（Merge progress）：把通过的进展异步合并回共享工作区
这五步里最容易被忽略的是第三步里的「共享发现」。它把工作者从「执行单元」提升为「信息生产者」：一个工作者在排查某个编译错误时得到的结论，会进入共享上下文供其他工作者读取，而不必各自重踩一遍。这是去中心化能成立的前提——没有编排器做汇总，信息就必须由工作者自己写进公共空间。
CLAIM 机制则是避免重复劳动的关键。工作者不是默默开工，而是先把打算做的范围公布出去。这里的公布是声明而非锁：从公开材料看，Agensh 并未描述一个中心化的互斥锁或仲裁者。这意味着在异步条件下，两个工作者仍可能认领到重叠范围，冲突最终由后端的版本合并来承担。这是一个设计取舍，后面会展开。
Agensh 把「谁来做」的决定权从编排器下放给工作者，用共享状态替代集中调度。代价是冲突从裁决阶段挪到了合并阶段，收益是系统的规模不再受单个编排者的上下文与决策频率限制。
组织基础设施三件套：工作区、消息、共享上下文
论文把支撑这套循环的部分称为智能体组织基础设施（agentic organization infrastructure），由三个组件构成。值得注意的是，三者都是成熟开源软件或既有研究成果，Agensh 本身没有重造轮子：
| 组件 | 实现 | 承载什么 | 解决的问题 |
|---|---|---|---|
| 共享工作区 | Gitea | 已提出（proposed）、进行中（ongoing）、已完成（completed）的工作 | 让每个人看得见全局进度，也让合并有统一落点 |
| 消息接口 | Mattermost | 工作者之间的沟通 | 提供异步、低耦合的通信通道 |
| 共享上下文 | 改编自 DeLM | 可复用发现与工作意图 | 把局部经验变成组织资产，避免重复探索 |
三者的分工值得单独说。Gitea 承载的是「物」——代码与其状态，它有天然的合并机制与冲突处理。Mattermost 承载的是「话」——即时、可丢失、不需要强一致。共享上下文承载的是「知」——沉淀下来、需要被反复读取的结论。把这三件事分开，是这套设计里最实在的一处工程判断：三类信息的时效性、一致性要求与读取频率完全不同，硬塞进一个结构里必然互相拖累。
还有一个容易漏掉的细节：实验中每个工作者跑在 GitHub Copilot 的 Harness 智能体循环之上。也就是说 Agensh 不是从零实现了智能体循环，而是把 Copilot 的智能体循环作为单工作者的执行引擎，自己只做上层的组织与协作。这个分层让它的工程量比想象中小，也意味着它的结论与底座 Harness 的能力强相关。
与「编排者—工作者」结构的差异
把两种结构放在同一张表里对照，差异比宣传语更能说明问题：
| 维度 | 编排者—工作者结构 | Agensh 自组织结构 |
|---|---|---|
| 任务分配 | 编排器分解并派发 | 工作者自行认领并以 CLAIM 公布范围 |
| 进度可见性 | 集中在编排器的任务表 | 分散在 Gitea 工作区与共享上下文 |
| 冲突处理 | 编排器裁决或串行化 | 版本合并，冲突在合并阶段暴露 |
| 规模瓶颈 | 编排器的上下文与决策频率 | 共享存储的写入压力与合并冲突率 |
| 失败影响 | 编排器故障影响全局 | 单个工作者故障不阻断他人 |
| 全局预算控制 | 天然有单点可施加 | 需要额外机制，公开材料未描述 |
| 任务去重保证 | 由编排器保证 | 依赖 CLAIM 声明的一致性，存在重叠窗口 |
最后两行是工程落地时最需要掂量的。中心编排器固然有上限，但它顺手提供了两个东西：一个可以施加预算的点，以及一个可以做去重裁决的点。去掉编排器之后，这两件事并不会自动消失，只会换一个地方出现。公开材料目前没有说明 Agensh 如何处理全局 token 预算与认领重叠，本文按未披露处理。
ProgramBench 读数：19.31% 到 28.78% 是怎么来的
先看评测设置，因为它决定了这些数字能推广多远：
- 基准：ProgramBench，共 200 个编码实例，实验取其中五项最难任务——FFmpeg、gromacs、pandoc、PHP-src、ctags
- 任务性质：根据行为与随附文档重建参考程序
- 模型：GPT-5.6-sol，高推理强度
- 预算：六小时
- 网络：无互联网访问
在这个设置下，智能体数从 1 增到 128，五项任务的平均最终测试通过率由 19.31% 升至 28.78%，相对提升约 49%。论文还提到一句容易被忽略的话：更大规模的组织能更早达到可比的通过率。也就是说收益不只体现在最终分数，也体现在达到同一分数所需的时间——在时间预算固定的场景里，这一条可能比最终分数更有意义。
要提醒的是口径。这是五项最难任务的平均值，不是 ProgramBench 全 200 个实例的平均值。选最难任务是对的，因为容易任务单智能体已接近饱和、看不出差异；但这也意味着这个 19.31% 的起点不代表常规任务的水平，不宜拿去与别的基准横比。
| 读数 | 数值 | 口径 |
|---|---|---|
| 单智能体基线 | 19.31% | 五项最难任务平均最终测试通过率，GPT-5.6-sol 高推理、6h、无网络 |
| 128 个智能体 | 28.78% | 同上，相对单智能体提升约 49% |
| pandoc 单智能体 | 33.89% | 单一任务，六小时预算 |
| pandoc 128 个智能体 | 50.94% | 单一任务 |
| pandoc 1024 个智能体 | 55.06% | 单一任务，标题中的 1024 来自此处 |
pandoc 那条曲线：1、128、1024
pandoc 是仅有的一项被推到 1024 个智能体的任务，也是论文标题里那个数字的来源。三点连成的曲线是 33.89% → 50.94% → 55.06%。
把这两段拆开看，形状很清楚：
- 1 到 128 个智能体：智能体数扩大 128 倍，通过率增加 17.05 个百分点
- 128 到 1024 个智能体：智能体数扩大 8 倍，通过率增加 4.12 个百分点
这是典型的对数型收益曲线。论文标题里的 1024 证明的是规模上限可以推到多远，而不是平均收益有多大。前者是能力证明，后者才是成本收益问题。这两件事在传播中经常被合并成一个叙事。
本文推算之一：边际收益在 128 之后明显变薄
论文没有给出「每翻倍智能体的收益」这一口径，以下是本文基于公开读数做的推算，仅供量级参考：把规模变化折成翻倍次数，1 到 128 是 7 次翻倍、换来 17.05 个百分点，约合每次翻倍 2.44 个百分点；128 到 1024 是 3 次翻倍、换来 4.12 个百分点，约合每次翻倍 1.37 个百分点。
| 区间 | 智能体数 | 翻倍次数 | 通过率增量 | 每翻倍增量（本文推算） |
|---|---|---|---|---|
| 起步段 | 1 → 128 | 7 | +17.05 pp | 约 2.44 pp |
| 规模验证段 | 128 → 1024 | 3 | +4.12 pp | 约 1.37 pp |
后一段的每翻倍收益约为前一段的 56%。这个推算有两个限定：一是只用了 pandoc 一个任务的三点数据，样本极薄；二是通过率本身有天花板，越接近上限增量自然越小，因此递减一部分来自测量尺度而非协作效率。即便如此，方向是清楚的——把 128 扩到 1024 需要多付约 8 倍的计算资源，换来的是 4.12 个百分点。对绝大多数团队来说，这个区间不划算。
本文推算之二：换模型比加智能体更划算
更有意思的一组对照来自仓库而非论文。公开转述显示，仓库中给出了一组论文未包含的数据：改用 GPT-6.1-sol 后，pandoc 六小时通过率从 1 个智能体的 56.19% 提升到 32 个智能体的 79.59%，相对提升 41.64%。
把两组数据放在同一个任务、同一个时间预算下横比，可以得到一个论文没有直接给出的结论：
| 路径 | 起点 | 终点 | 增量 | 付出的规模代价 |
|---|---|---|---|---|
| GPT-5.6-sol，扩到 128 个智能体 | 33.89% | 50.94% | +17.05 pp | 128 倍智能体 |
| GPT-5.6-sol，扩到 1024 个智能体 | 33.89% | 55.06% | +21.17 pp | 1024 倍智能体 |
| 换用 GPT-6.1-sol，仍用 1 个智能体 | 33.89%（参照基线） | 56.19% | +22.30 pp（跨模型口径，见下） | 1 倍智能体 |
| GPT-6.1-sol，扩到 32 个智能体 | 56.19% | 79.59% | +23.40 pp | 32 倍智能体 |
需要严谨说明口径：56.19% 是 GPT-6.1-sol 的单智能体读数，与 GPT-5.6-sol 的 33.89% 不是同一模型的基线，因此「+22.30 pp」这一格是跨模型横比，不是同模型内的提升，且该数据来自仓库转述而非论文正文，本文未取得论文原文的确认。即便把这一格打个折扣，方向依然成立：单个更新型号的智能体（56.19%）已经略微超过 1024 个旧型号智能体组织起来的结果（55.06%）。
这是本文认为这组材料里最值得记住的一条。它说明在目前的能力区间里，模型换代带来的收益至少与规模扩张同量级，而前者的成本结构远好于后者。组织规模可以补模型能力，但补得很贵。真正有效的组合是两者叠加：GPT-6.1-sol 配合 32 个智能体达到 79.59%，只用 32 倍规模就超过了 1024 倍规模的旧组合约 24.5 个百分点。
当然也要说明这条推算的边界：GPT-6.1-sol 的数据未见于论文，公开转述未提供评测设置的完整细节（是否与论文的六小时、无网络条件完全一致），因此本文只作量级参考，不作为选型依据。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
涌现的是什么：协作形式、集成流程与专门化角色
论文摘要的最后一句是：工作者轨迹进一步显示，不同形式的自组织协作随着组织变大而逐渐涌现并标准化。这句话没有展开成量化指标，但从机制上可以推三种形态：
- 协作形式：从各自闷头做，到出现请求复核、交叉验证、结果引用等交互模式
- 集成流程：从随意提交，到形成事实上的合并节奏与冲突处理惯例
- 专门化角色：部分工作者持续集中在某类子任务上，形成事实分工
「涌现」在这里是个中性词。它意味着不需要显式设计就长出了秩序，但也意味着这套秩序不受控——没人指定谁做集成，只是有人开始做了。对研究者这是有趣的现象，对工程团队这是需要监控的对象：如果一个组织里恰好没有人承担集成角色，合并就会堆积。
论文未提供上述三种形态的量化判定标准，本文按作者定性描述处理。
没有披露的部分：成本、冲突与失败模式
公开材料里有几处空白，恰恰是落地时最需要先问的：
| 未披露项 | 为什么重要 | 本文的处理 |
|---|---|---|
| 1024 个智能体跑六小时的成本 | 决定这条路是否具备经济性，也决定与单智能体的性价比对比 | 未披露，本文不做估算 |
| 认领冲突率与处理机制 | CLAIM 是声明不是锁，重叠窗口必然存在 | 未披露，按存在重叠风险处理 |
| 全局预算与熔断 | 去中心化后缺少天然的单点施力处 | 未披露，按需自建处理 |
| 失败模式分布 | 哪些任务会越并行越差，比平均提升更有决策价值 | 论文只报五项最难任务的均值，未给分布 |
| 非编码任务的迁移性 | ProgramBench 任务天然可分割、验收客观 | 未验证，按不适用推定需自测 |
最后一行尤其关键。ProgramBench 的五项任务有一个共同特征：可以从行为与文档重建、验收标准是测试通过率。这类任务的子任务之间耦合弱、验收客观、允许大量试错——恰恰是多智能体并行最理想的一类。真实工程里还有大量任务需要串行决策、共享可变状态、或验收标准主观，这些场景下的规模收益未必成立。论文没有声称可以迁移，本文也不做这个外推。
与同期相反结论的对照
把 Agensh 放进近期材料的坐标里看，会出现一个明显的张力。此前有基准工作在客户服务类任务上对多智能体与单智能体做了双控制对照，结论是多数配置下多智能体反而更差，且无预算上限时也至多打平，却要多花数倍 token。
| 维度 | Agensh（本文） | 同期对照研究（详见本栏目 R-BENCH-42） |
|---|---|---|
| 任务类型 | 程序重建，可并行、验收客观 | 客户服务对话，强状态耦合 |
| 结构 | 无中心编排器，自组织 | 带规划器的多智能体结构 |
| 规模方向 | 扩大规模带来正收益 | 扩大规模多数为负收益 |
| 验收指标 | 最终测试通过率 | 对话结果与约束满足 |
两份材料并不必然矛盾，最可能的解释在任务结构：可分割、弱耦合、客观验收的任务适合堆规模；强耦合、需维护一致状态的任务，多智能体的协调成本会吃掉并行的收益。这个判断对选型有直接价值：在决定要不要上多智能体之前，先给自己的任务做一次耦合度分类，比看任何一份榜单都有用。
还需要指出另一处结构差异：Agensh 去掉了中心编排器，而对照研究中的多智能体结构通常保留规划器。因此「去中心化」与「多智能体」这两个变量在上述对照里是混在一起的，现有公开材料尚不能把它们分开归因。
采用检查清单
如果要在自己的环境里评估 Agensh，以下六条建议先做：
- 先给任务做耦合度分类。子任务之间是否需要共享可变状态、是否有严格先后顺序。弱耦合任务才值得尝试堆规模；强耦合任务建议先做单智能体优化。
- 先测 8 到 32 个智能体这一段。按本文推算，边际收益在这一段最厚。直接上 128 或 1024 会先把预算花在收益最薄的地方。
- 把底座模型版本作为独立变量。不要只看智能体数量的收益曲线，同时跑一组换模型不换规模的对照。按现有读数，后者可能更划算。
- 自建预算与熔断。公开材料未描述全局 token 预算控制。在去中心化结构里，这件事必须在基础设施层做，不能指望工作者自觉。
- 监控合并与冲突。把合并冲突率、CLAIM 重叠比例、无人认领的子任务数做成日常指标。这些是去中心化结构特有的健康信号。
- 按研究原型对待。仓库提供复现指南与 Docker Compose 单机团队配置，成本很低，建议先在非关键任务上跑一遍，用自己任务的数据替代 ProgramBench 的读数。
冷静判断：它证明了什么，没证明什么
它证明了去中心化在规模上确实能走得更远。在此之前，行业默认多智能体规模的上限由编排器决定。Agensh 用 1024 这个数字证明，只要把协调从「集中调度」换成「共享状态 + 自主认领」，规模还能往上推。这是一条有价值的工程结论，而且代码、脚本、复现指南一并开放，验证成本很低。
它证明了收益曲线的形状。1 到 128 换来 17.05 个百分点，128 到 1024 只换来 4.12 个百分点。这条曲线比任何单点读数都更有指导意义：它告诉团队规模扩张的有效区间在哪里，也告诉团队什么时候该停下来换别的杠杆。
它没有证明规模是比模型更划算的杠杆。按本文对齐后的口径，单智能体配更新型号（56.19%）已略高于 1024 个旧型号智能体的组织（55.06%）。这两组数据的来源与设置不完全一致，结论只能作量级参考，但它足以提醒一件事：把预算一股脑投到规模上，未必是最优解。
它没有证明可以迁移到非编码或强耦合任务。五项最难任务都是可重建、可客观验收的编码任务。这个选择是合理的，但也把结论的适用范围限定住了。
它也没有回答成本问题。1024 个智能体跑六小时的花费未披露，而这恰恰是决定这条路能否走出实验室的关键数字。在补齐之前，任何基于规模扩张的 ROI 测算都缺一块。
综合来看，Agensh 最有价值的部分不是 1024 这个数字，而是它提供了一个可复现的实验装置，让「多堆智能体到底划不划算」这个问题首次有了可以自己动手测的工具。对大多数团队来说，真正该做的是跑一遍 8 到 32 个智能体这一段，然后用自己任务的数据说话。