多智能体编程系统通常依赖一个中心编排器：由它拆分任务、分发给多个工作 Agent，再回收并整合结果。微软研究院近期发布的一项实验试图改变这一结构。在论文 Agensh 中，研究团队取消了中央调度器，让最多 1024 个编码 Agent 并发运行，并通过共享状态自行协作。
该实验结果显示，在 pandoc 相关任务中，测试通过率从 33.89% 提升至 55.06%。但同样值得注意的是，当 Agent 数量继续增加时，收益曲线开始变平：增加 8 倍 Agent，只带来约 4 个百分点的额外提升。这也让一个问题浮出水面：多 Agent 编码的规模化红利，是否正在进入收益平台期。
从编排器瓶颈出发
目前主流多智能体编码系统大多采用 orchestrator-worker 架构。中央编排器负责理解任务、拆解子任务、调度执行并汇总结果。这种模式在几十个 Agent 的规模下通常仍然有效，但当 Agent 数量扩大到数百甚至上千时，中心节点本身可能成为瓶颈。
素材中提到，Agensh 的思路并不是继续给编排器扩容，而是直接移除这一中心角色。所有 Agent 异步并发运行，不再依赖统一指令，而是通过三类共享状态进行协调：
- 共享工作区：基于 Git，每个 Agent 使用独立分支，再合并到主分支，冲突时重新解决。
- 消息接口：包括任务频道和私信，支持异步通信和历史记录。
- 共享上下文：以追加式日志记录 OBSERVED、FACT、CLAIM、FAIL、PATCH_SUMMARY 等状态，供任意 Agent 检索。
每个工作者遵循同一个五步循环，并通过声明机制和对话处理任务重叠。换句话说，Agensh 将原本集中在调度器上的协调成本，转移到了共享代码仓库、消息系统和上下文日志之中。
规模带来的收益与边界
实验使用 ProgramBench 作为评测任务。该任务要求模型在断网和 6 小时预算内，根据一个已编译程序重建出行为一致且可编译的代码，评分标准为隐藏测试通过率。素材显示，在最难的五道题上，研究团队使用 GPT-5.6-sol 进行测试。
从 1 个 Agent 扩展到 128 个 Agent 时，平均通过率提升约 9.5 个百分点，相对提升约 49%。在 ProgramBench 五道难题上，均值从 19.31% 提升至 28.78%。
pandoc 文档转换任务是唯一扩展到 1024 个 Agent 的任务。其通过率从 33.89% 提升到 55.06%。但后续增长明显放缓：在达到较高规模后，增加 8 倍 Agent 仅带来约 4 个百分点提升。
这说明，去掉调度器确实打开了新的规模区间，但并不意味着 Agent 数量可以无限转化为等比例收益。对于工程团队而言，真正需要判断的不是“能不能堆更多 Agent”，而是任务是否适合这种扩展方式。
什么时候值得用
素材给出了较清晰的适用边界。Agensh 这类去中心化结构更适合可以拆分为独立子任务、且每个子任务都有明确验收标准的场景，例如代码重建、格式转换或仓库级改动。如果项目存在硬性时间预算，并行带来的速度优势也更有吸引力。
相反，如果任务需要单一连贯设计、强全局一致性，或依赖统一架构决策，去中心化共享状态可能反而造成相互干扰。另一个关键条件是测试能力：如果无法提供可靠验收测试，合并多个 Agent 的输出就容易变成灾难。
成本也是不可忽视的因素。素材指出，在次线性收益下，如果只追求通过率上限，账单可能快速上升。因此，相比单纯观察总通过率，团队更需要关注“每提升一个百分点的成本”。
下一阶段竞争点在共享状态
Agensh 的价值，并不只是证明可以运行 1024 个编码 Agent。更重要的是，它展示了一种替代路径：当中心调度器被移除后，多智能体系统的瓶颈可能从单个编排器的能力，转移到共享状态基础设施的质量。
这意味着，未来多 Agent 编程系统的工程重点，可能不再只是增加模型数量，而是如何设计 Git 合并策略、消息路由、上下文检索和冲突解决机制。Agent 数量仍然是一个新的扩展维度，但它和其他扩展一样，最终会遇到收益递减。
对于行业而言，这项实验提供了一个更现实的观察点：多 Agent 编程正在从“堆更多智能体”进入“如何让智能体更好共享状态”的阶段。去中心化是否能通过成本归一化检验，以及大规模协作中出现的角色分化能否被显式利用，仍是后续值得关注的方向。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/wei-ruan-chang-shi-qu-diao-zhong-xin-diao-du-qi-1024-ge
