去中心化智能体 swarm：微软 Agensh 如何拆解千级 Agent 协作难题
引言：当 Agent 数量突破三位数
多智能体系统的研究长期困在一个看似不起眼的瓶颈上：谁来指挥？现有的主流框架几乎无一例外地依赖一个中心调度器——它负责任务分解、工作分配、结果汇总。这种主从架构在小规模时运转良好，但随着 Agent 数量增长，调度器本身成为计算和通信的双重瓶颈，研究者称之为"编排天花板"（orchestrator ceiling）。
微软研究院最近开源的 Agensh 尝试了一条截然不同的路径。它彻底移除了中心调度器，让每个 Worker Agent 在完全平等的地位上自行决策、自主协作、自发生长。在 ProgramBench 的基准测试中，这套去中心化框架被推到了 1,024 个 Agent 的规模——这在当前的多 Agent 研究中几乎是一个前所未有的量级。
背景：编排天花板的困境
回顾近年涌现的多 Agent 系统，无论是基于大语言模型的代码生成团队，还是各类自主 Agent 集群，其底层结构高度同质化：一个顶层 Agent 充当"项目经理"，将复杂问题拆解为子任务，分发给下游 Worker，最后再由它验收并整合产出。这种设计直觉上符合人类组织的科层逻辑，但在机器协作场景中暴露出结构性缺陷。
调度器的串行处理能力限制了系统吞吐；它的理解偏差会级联放大到整个团队；更致命的是，一旦调度器失效，整个系统即刻瘫痪。研究者早已意识到这个问题，但工程层面的替代方案长期缺位。Agensh 的出现，正是对这一空白的一次系统性回应。
核心机制：没有老板的协作循环
Agensh 的核心设计哲学可以概括为一句话：把协调逻辑下沉到每个 Worker，而非上收到某个中心节点。具体而言，每个 Worker 运行同一个五步循环，且所有 Worker 并发异步执行：
- 收集上下文：读取任务目标、同伴进展、共享消息和已有发现
- 认领子任务：在公共板上发布 CLAIM（认领声明），若与其他 Worker 冲突则通过一对一消息协商解决
- 执行行动：在本地环境中使用工具完成工作，并尽早发布中间发现
- 验证结果：对照子任务的验收标准自查产出
- 合并进展：将代码提交到共享 Git 仓库，发布更新公告，然后进入下一轮
三个基础设施服务支撑起这套循环。Gitea 提供共享代码仓库，处理分支管理、Pull Request 和合并冲突——这几乎是开源社区协作流程的数字化复刻。Mattermost 承载团队频道和私聊通道，用于紧急碰撞和细节磋商。一个从 DeLM 适配而来的共享上下文板则存储结构化笔记，包含 OBSERVED（观察）、FACT（事实）、FAIL（失败）、CLAIM（认领）和 PATCH_SUMMARY（补丁摘要）等类型化字段。
耐人寻味的是，整个协作逻辑并非写在运行时代码里，而是内嵌在提示词（prompt）中。每个 Worker 收到的提示词几乎完全相同，唯一的区别是各自的 ID 编号。这意味着 Agent 的"社会行为"是由语言模型自身的推理能力驱动的，而非由外部脚本强制规定。Agensh 本身构建在单机 Agent 框架之上，实验中使用的是 GitHub Copilot CLI，研究团队指出通过轻量化适配器也可以接入其他框架。
规模实验：从 1 到 1,024
微软团队在 ProgramBench 最困难的五个任务上评估了 Agensh 的扩展性：FFmpeg、gromacs、pandoc、PHP-src 和 ctags。这些项目的规模从 pandoc 的 2,767 个文件到 PHP-src 的 26,266 个文件不等。Agent 的任务是根据程序的行为观测从零重建整个代码库，全程离线运行，时限 6 小时。
在使用 GPT-5.6-sol 并开启高推理强度的配置下，五个任务的平均最终测试通过率随 Agent 数量变化如下：单 Agent 为 19.31%，8 Agent 为 20.68%，32 Agent 为 26.52%，128 Agent 为 28.78%。从 1 到 128，绝对提升 9.47 个百分点，相对增幅约 49%。
分项目看，pandoc 的表现最为突出。使用 GPT-6.1-sol 时，32 个 Agent 达到了 79.59% 的通过率；即便使用 GPT-5.6-sol 并扩展到 1,024 个 Agent，pandoc 仍取得了 55.06% 的成绩。不过数据也揭示了边际效应：从 1 个 Agent 增加到 8 个，仅带来 1.37 个百分点的提升；五个任务在 128 Agent 时的均值停留在 28.78%，距离理想状态仍有显著差距。
实验环境的硬件约束同样值得关注。每个 Worker 被分配 272,000 token 的输入上下文和 128,000 token 的输出上限，内存封顶为 64 GiB。默认配置为单节点 8 个 Worker，1,024 Agent 的完整实验则动用了 16 个计算节点，每节点 64 个 Agent。
深度点评：开源社区原型的工程启示
Agensh 最引人注目的不是某个具体分数，而是它映射出的隐喻：一个去中心化的 Agent 集群，其行为模式与开源软件社区惊人地相似。没有项目经理，开发者自行选择感兴趣的 issue，在邮件列表或聊天频道中协调分工，通过 Pull Request 提交代码，由社区审查后合并。Agensh 把这套社会技术系统翻译成机器可执行的协议——Git 是协作介质，消息通道是议事厅，结构化提示词是行为规范。
这种类比暗示了一个深层洞察：大规模 Agent 协作的可行性，可能不取决于更强的调度算法，而取决于更合理的激励机制和冲突解决协议。在人类社区中，声誉、兴趣和专业分工驱动着自发协作；在 Agent 系统中，类似的机制需要被编码进提示词和通信协议。Agensh 的 CLAIM 机制本质上是一种轻量级的"先占声明"，配合事后协商，这正是避免重复劳动的最小可行方案。
然而，数据也暴露了去中心化架构的固有局限。从 1 到 8 个 Agent 的微小提升说明，简单的并行堆叠并不能自动产生智能涌现。当任务本身存在强依赖关系或需要全局一致性视角时，缺乏统一规划可能导致 Worker 在局部最优中徘徊。128 Agent 后增长放缓的趋势，提示着通信开销和冲突协调成本正在吞噬并行带来的收益。
另一个值得警惕的方向是"提示词即社会契约"的设计。把协作规则全部压在 prompt 上，固然简洁优雅，但也意味着系统的稳定性高度依赖语言模型对指令的理解一致性。当 Agent 数量达到千级，个体理解的微小偏差可能通过交互网络被放大为系统性混乱。这本质上是一个分布式一致性问题，只不过它发生在语义层面而非比特层面。
前瞻：走向自主软件生产的工程路径
Agensh 的开源标志着多 Agent 系统从"玩具级演示"向"工程级基础设施"的关键跨越。1,024 Agent 的规模验证，至少证明了去中心化架构在技术路线上是可行的。未来的演进可能沿着三条路径展开。
第一，混合式架构的探索。纯粹的去中心化与纯粹的集中式各有短板，更现实的方案可能是分层治理：局部集群保持自治，但在跨集群协调或长期规划层面引入轻量级协调者。这种"联邦式"设计可能兼顾灵活性与全局视野。
第二，通信协议的标准化。当前 Agensh 依赖三个独立服务，未来可能出现为 Agent 协作量身打造的统一通信层，整合版本控制、消息传递和状态同步，并内置冲突检测与仲裁原语。这将降低新框架的接入门槛，促进生态互操作。
第三，评估体系的升级。ProgramBench 的五个任务虽然困难，但本质上仍是"重建已知程序"。真正的挑战在于开放世界中的创意性问题求解——那里没有标准答案，也没有预先定义的验收标准。下一代基准需要衡量 Agent 集群在模糊目标下的创新能力、长期维护能力和知识沉淀效率。
无论如何，Agensh 已经推开了一扇门。它告诉我们，上千个 Agent 不必听命于同一个大脑，也可以像无数开发者一样，在共享的代码基上各自为战却又彼此呼应。这场关于机器协作的社会实验，才刚刚开始。