当多智能体系统普遍依赖一个中心调度器分配任务时，微软研究院选择把调度器拿掉。
发生了什么
微软研究院开源了名为 Agensh 的多智能体 harness（运行框架），其核心设计是没有中心化编排器。参与的 worker 智能体通过三种共享设施协作：一个 Git 仓库、一个聊天通道，以及一块“发现板”（findings board）。据 MarkTechPost 报道，该框架在 ProgramBench 基准上可在 6 小时预算内从 1 个智能体扩展到 1,024 个智能体。
“harness”一词值得注意：它指的不是模型本身，而是包裹模型、管理任务分发、状态共享与结果汇聚的那层工程脚手架。换句话说，Agensh 解决的不是“智能体更聪明”，而是“大量智能体如何不互相踩踏”。
为什么重要
过去一年，多智能体系统的默认范式是层级式：一个 planner 拆解任务，若干 executor 执行，再由一个 reviewer 校验。这种结构可解释、易调试，但存在明显的规模瓶颈——中心节点既是性能上限，也是单点故障；智能体数量增加时，编排器本身会成为最忙、最容易出错的一环。
Agensh 的思路接近“黑板系统”与开源协作模式的结合：Git 仓库充当共享工作区，智能体的产出以提交的形式沉淀并可回溯；聊天通道用于协商；发现板则记录中间结论，避免重复劳动。这种设计让协调成本从“中心节点的算力”转移到“共享介质的读写协议”上，理论上更利于横向扩展。
选择 ProgramBench 作为验证场景也有讲究。编程任务天然具备可分解、可验证、可版本化的特性，Git 本身就是为多人异步协作发明的工具，用程序员熟悉的协作隐喻来组织智能体，是相对务实的选择。
影响与看点
对开发者而言，最直接的价值是提供了一个可运行的大规模多智能体参考实现，而不是又一篇只给架构图的论文。自组织意味着新增智能体不需要重新配置拓扑，这对需要弹性伸缩的任务队列有实际吸引力。
但需要冷静看待几点：其一，1,024 个智能体的规模数字来自特定基准和固定时间预算，不能直接外推为通用能力；其二，无中心编排在冲突消解上高度依赖共享协议的设计，Git 的合并冲突在智能体场景下可能被放大；其三，缺少编排器也意味着可观测性更难，出问题时定位责任主体会更麻烦。
我的判断是：Agensh 的真正贡献不在于“去中心化更先进”，而在于把多智能体的协调问题重新表述为一个共享状态与协议设计问题。这比继续堆叠编排器层级更接近本质，但距离生产可用还有一段工程距离。值得关注的是后续社区能否在其上长出成熟的冲突消解与观测工具。
