微软开源 Agensh：1024 个 Agent 没有"老板"，怎么自己把活干完？

当一个团队大到 1024 人，没有老板、没有主管、没有排期表，活儿还是能干完——这已经不是管理学想象，而是微软刚开源的一个多智能体框架。

1024 个发光节点彼此相连，像蜂群一样没有中心、却能协作。这是一张关于"组织"的图。

---

01 先说发生了什么：微软把"Agent 组织"开源了

北京时间 10 月 24 日，微软研究院开源了一个叫 Agensh 的多智能体编排框架，采用 MIT 许可证。它要解决的问题很直接：让 1024 个编码 Agent 在同一个代码仓库里协作，但没有"总指挥"。

几个关键信息：

• 没有 lead agent（主智能体），没有 中央调度器（central orchestrator）。
• 每个 Agent 自己认领子任务、共享发现，把成果合并进同一个 Git 仓库。
• 配套论文《Agensh: Scaling Organizational Intelligence to 1,024 Agents》9 月已在 arXiv 上线，这次把代码、启动脚本、复现指南一并开源。

为什么这事值得看？因为它不是又发了一个更强的模型，而是换了一种 组织方式：从"一个 Agent 干所有事"走向"一群 Agent 自己分工协作"。

这也把背后一个常被忽略的概念推到了台前——多智能体系统（Multi-Agent System）。

从一篇论文，到 MIT 许可的开源框架，再到 1024 个 Agent 自组织——速度比想象中快。

---

02 先搞清楚：多智能体到底是个什么概念

很多读者第一次接触"多智能体"，容易把它理解成"好几个 AI 一起干活"。这话对了一半。

一句人话：多智能体系统，就是让多个各自独立的 AI Agent 组成一个"团队"，通过分工、通信和协作，去完成单个 Agent 很难独立完成的任务。

一句排除：它不等于"一个 Agent 多开几个线程"，也不等于"把同一个任务复制给 N 个 Agent 跑 N 遍"。前者还是单兵作战，后者只是重复劳动。

一句关系：它真正改变的是——AI 从"单个工具"变成了"一套组织"。就像从"请一个全能员工"变成"组建一个各司其职的部门"。

用一个类比帮助你理解：单 Agent 像一个全能但只有一双手的手艺人，多智能体像一支有策划、有执行、有质检、有验收的团队。团队看起来更复杂，但接得了更大的单子。

---

03 多智能体为什么这么难做：五个绕不开的坎

理想很丰满，现实很骨感。多智能体喊了好几年，真正规模化跑起来的很少，卡在下面五个问题上：

① 协调与通信：谁来分配任务？ 团队一开会，第一个问题就是"谁干什么"。多智能体也一样：任务怎么拆？消息怎么传？如果两个 Agent 同时改同一个文件，谁听谁的？没有协调机制，N 个 Agent 就是 N 倍的混乱。

② 上下文墙：每个 Agent 都"记不全" 单个 Agent 的上下文窗口是有限的。当一个任务被拆给 1024 个 Agent，每个 Agent 都只看到自己那一小块信息，全局信息如何在碎片之间保持一致，就成了致命问题。信息在传递中还会"漂移"——A 改了一个变量，B 还在用旧值。

③ 故障与信任：一个 Agent 出错，怎么发现？ 团队里一个人摸鱼，其他人都可能被拖累。多智能体也一样：某个 Agent 产出错误代码，谁来审查？错了怎么回滚？如果靠人工一个个盯，规模化的意义就没了。

④ 成本与延迟：N 个 Agent = N 倍的账 每个 Agent 都在消耗 token 和算力。协调、通信、重试的额外开销，很可能吃掉并行带来的收益。团队越大，内耗越可能超过产能。

⑤ 规模瓶颈：调度器先撑不住 传统多智能体框架靠一个中心调度器分配任务。Agent 少时还行，一旦到几十个，调度器自己就成了瓶颈——这也是为什么很多框架在几十个 Agent 就上不去了。

核心结论：多智能体的难点，从来不在"数量"，而在"组织"。

协调、上下文、信任、成本、瓶颈——五个坎，道道都卡在"组织"上。

---

04 那为什么还要做多智能体：四个实打实的好处

既然这么难，为什么 OpenAI、Anthropic、谷歌、微软都在押注？因为好处同样实在：

① 规模化产能：把"快"变成"更快" 任务越能并行拆分，多智能体就越快。1024 个 Agent 不是 1024 倍速度，但相比串行，是数量级的差距。

② 专业化分工：让每个 Agent 成为专家 规划、编码、测试、审查——不同 Agent 各司其职，比一个"什么都会一点"的 Agent 更可靠。这就像大厂不养通才，要养专才。

③ 去中心化容错：没有单点，坏了也不停 没有中心调度器，意味着没有"一个节点挂了全队瘫痪"的单点故障。某个 Agent 出错，其他人可以接管它的活。

④ 组织化智能：涌现出单个 Agent 没有的能力 这是最诱人的一点：当一群 Agent 协作，可能产生"1+1>2"的涌现效果——就像蚁群单只很弱，整群却能建出复杂巢穴。多智能体要复刻的，就是这种"组织化智能"。

---

05 微软 Agensh 的解法：把"指挥"改成"自组织"

理解了难点和好处，再看 Agensh 就清楚了——它是在用"去中心化"同时解决上面几个问题。

它做了什么：

传统难题	Agensh 的解法
谁分配任务	没有调度器，Agent 通过共享工作区自己发现、认领子任务
怎么通信	共享工作区 + 消息接口 + 共享上下文
状态怎么同步	所有代码合并进同一个共享 Git 仓库，天然可回滚
怎么避免重复劳动	认领即占位，Agent 之间通过共享状态感知谁在做
出错怎么办	Git 版本管理天然提供回滚点

它新增了一个有意思的角色——"整合者"（integrator）： 在需要合并代码的任务（比如 pandoc 项目）里，多名 Agent 可以担任整合者。一个 Agent 会同时联系多个候选整合者，选第一个有效响应的，取消其他请求，然后在选定之后才移交待整合的代码。这像是团队里自发形成的"合并负责人"。

规模测试： Agensh 在 ProgramBench 上把编码 Agent 从 1 个扩展到 1024 个（16 个节点、每节点 64 个 Agent），并且没有硬性数量上限——相比之下，Kimi 的 Agent Swarm 大约限制在 100 个 Agent 左右。

用一个对比帮你定位它：

	传统中心化框架	Agensh
组织方式	中央调度器分配任务	自组织认领
数量上限	几十个就吃力	可扩展到 1024+
单点故障	有，调度器挂了全停	无，去中心化
控制粒度	强，任务可精确指派	弱，靠共享状态约束
适合场景	流程固定、需要强管控	任务可并行、规模大

一个是老板给员工派活，一个是员工自己认领——组织方式不同，能接的活也不同。

---

06 别把 Agensh 神话：几个需要冷静的地方

文章写到这里，很容易让人以为"多智能体要一统天下了"。但有几个边界必须说清楚：

① 去中心化也有代价。 没有中心调度器，意味着控制粒度变弱。如果任务流程强、需要精确指挥，自组织反而不如传统框架可控。Agensh 适合的是"能并行、能自发分工"的任务，不是所有任务。

② 1024 个 Agent ≠ 更强。 社区里有句很扎心的点评："一个用上新模型的 Agent，就能打败整个 1024 的 Agent 队伍。"（DEV Community 有开发者实测，单个更强模型 agent 的表现优于整个 fleet。）这提醒我们：模型本身的能力下限，往往决定了组织的表现上限。组织化不是万能的补丁。

③ 收益目前是"温和"的，不是"惊艳"。 有技术媒体把 Agensh 的增益评价为"modest gains"（温和增益）。它证明的是"去中心化可行"，而不是"去中心化一定更好"。实验价值和工程价值都很大，但离"人人都该用"还有距离。

④ 运行门槛不低。 Agensh 要求 Linux、Docker Engine、Compose v2、systemd、cgroup v2、Python 3.11+。这不是普通用户开箱即用的玩具，而是面向工程团队的基础设施。

一句话收束：Agensh 的价值，在于证明了"多智能体可以没有老板也能自组织地干活"，但它不是银弹。

---

07 给读者的判断框架：以后怎么看"多智能体"这股风

以后再看任何"多智能体"产品、框架或新闻，不必被"1024 个 Agent"，"Agent 群体智能"这些词唬住，先看四个变量：

1. 任务真的可并行吗？ 如果任务本质上必须串行依赖，多智能体的收益就很有限。
2. 协调成本小于并行收益吗？ 团队越大，内耗越大。要看通信、同步、重试的成本有没有吃掉并行带来的好处。
3. 出错能被隔离和验证吗？ 没有一个可靠的质量关（测试、审查、版本回滚），再大的 Agent 团队也只是"更大的噪音"。
4. 真的需要"组织"，而不是一个更强的单 Agent 吗？ 很多时候，一个更强模型的提升，比组织 100 个弱 Agent 更实在。

记住这四个问题，你就拥有了一个不被"多智能体"概念忽悠的判断框架。

---

结尾：从"指挥"走向"自组织"的历史拐点

单 Agent 时代，我们操心的是"怎么让一个模型更强"；多智能体时代，问题变成了"怎么让一群模型高效协作"。

微软 Agensh 的象征意义，大于它当前的实际能力：它第一次把"多智能体组织"从一个科研概念，变成了可复现、可扩展、MIT 开源的工程实践。下一步真正该观察的，不是又冒出多少个"Agent 框架"，而是去中心化到底能不能在真实复杂任务里，稳定地跑赢一个更强的单 Agent。

这个问题，比任何框架的名字都重要。