不用中心调度器，让 1024 个 AI 自己组队：微软的新框架把多 Agent 协作变成了 GitHub 仓库
AI飞行客 不用中心调度器，让 1024 个 AI 自己组队：微软的新框架把多 Agent 协作变成了 GitHub 仓库
上一轮我写了十个 Claude 自己组了个虚拟实验室，15 小时攻下汤姆逊问题。
那是一个非常引人注目的实验。但如果你仔细想，会发现一个问题：10 个 agent 的协作团队，可以靠大模型的能力”自然涌现”出分工。那 100 个呢？1000 个呢？ 自然涌现的组织在更大规模下还能运转吗？
微软的研究团队给出了一个答案。它叫 Agensh。
一句话概括
Agensh 是一个去中心化的多 Agent 协作框架——没有总管、没有中心调度器、没有谁给谁分配任务。
每个 agent 都并发、异步地跑同一个五步循环：收集上下文 → 认领子任务 → 执行 → 分享发现 → 验证并合并。
像极了一个开源项目的协作方式。
这恰好是 Agensh 最巧妙的设计选择：它没有发明新的协作范式，而是直接把”开源项目”这个人类已经用了 20 多年的协作模型，移植给了 AI agents。
内核：你不必等别人
Agensh 的核心机制是每个 worker 独立执行的五步循环：
1. 收集上下文：从共享工作区看看同伴们干了什么、有什么新进展 2. 认领子任务：自行决定”这个我能做” 3. 行动：写代码、跑测试、查文档 4. 分享发现：把它产生的结果、思路、中间结论写进共享上下文 5. 验证并合并：同伴审查它的贡献，通过后并入主分支
最关键的一行设计：所有 worker 异步推进，任何人都不必等待同伴完成一轮迭代。
这意味着不管你是指挥 10 个还是 1,024 个 agent，规模对延迟的影响不是线性的——所有人在并行干活，只有合并时才需要轻重协调。
支撑这一切的三件套
Agensh 的组织基础设施由三部分组成，每个都对应着开源项目里的一个经典组件。
共享工作区——用 Git。 没错，就是你们每天都在用的 Git。每个 worker 有私有分支，写完了提 PR，合并到主分支。Git 记录改动来源、检测文本合并冲突。如果两个 agent 同时改了一个文件，它们在”merge 冲突”这个环节就会暴露问题，需要回溯解决。这比”一个中心调度器告诉你谁该干什么”要灵活得多——冲突是暴露出来的，不是被压下去的。
消息接口——用 Mattermost。 共享频道发团队公告，直接消息用于紧急一对一的沟通。优先级低的频道消息在每轮循环开始时送达，优先级高的直接消息在每次工具调用结束时送达。消息的异步投递让 worker 可以及时消除归属重叠、协商依赖、寻求协助——而同伴继续干活不受打断。
共享上下文——保留可复用的发现和工作认领。 每个 worker 发布简洁的带类型条目，把”我发现这条路走不通””这个函数我已经优化完了””这个模块谁来接手”这样的信息标准化，让后续的 worker 能直接复用，不需要重新发现。
翻译一下：Git 管代码，Mattermost 管沟通，共享上下文管知识复用。
这是一套极其直白但有效的设计：把人类的协作基础设施直接给 AI 用，而不是为 AI 重新发明一套。
1024 怎么跑起来的
微软用 Agensh 跑了一个实验：让 1,024 个 agent 协同完成代码迁移任务（把 Python 2 代码迁移到 Python 3，在 300 多个开源仓库上跑）。
结果是通过率随 agent 数量增加而提高——尽管边际收益在递减，但曲线没有出现”超过某个阈值后崩溃”。这正是 Agensh 去中心化设计的关键价值：没有中心瓶颈，可以继续往上加人。
当然，这个结果也不是完美的。开发者社区里对它的讨论很明显分化成了三派：三分之一积极正面，认为这是多 Agent 系统的正确方向；一半混合态度，觉得”去中心化协作”这个概念很好，但 merge 冲突、重复劳动、隐形 token 成本仍然没有真正解决；剩下五分之一持怀疑态度——认为 orchestrator 的问题只是被”移走了”而不是被”解决了”，异步协调的开销不会消失，只是换了一种形式出现。
这跟之前系列的关系
把过去两周的几篇连在一起看，Agent 架构的演进路径开始变得非常清晰了：
– Post 237（OpenAI 叫停 GPT-6.1）：中心化的单体 Agent 越做越强，也越做越危险——安全墙撞上了 – Post 239（十 Claude 自组织）：去中心化的小团队实验——10 个 agent 能自己分工了 – Post 240（Gemini 4 Argon 发布）：模型竞争力的维度在变化——安全 + 价格正在追赶跑分 – Post 241（今天，Agensh）：把去中心化多 Agent 做成了框架，并且验证了 1,024 个 scale 可行
这个序列指向一个判断：单体 Agent 的天花板可能比我们想得近，但多 Agent 协作的天花板可能比我们想得远。
不是因为单 agent 不够聪明，而是因为安全约束、上下文窗口、越权风险这些瓶颈在单 agent 上都是内生矛盾——你越让它强，它越危险。而在多 Agent 协作中，同样的问题被拆解了：每个 agent 只负责一小块，权限半径天然缩小，犯错范围也被压缩。
单体 agent 是在一个容器里不断加火——迟早会烧破。多 agent 是把火分散到多个炉灶里，每个炉灶的火都小，但整桌菜一起上。
一个实用的判断
对正在设计 Agent 产品的团队来说，Agensh 给了一个明确的设计原则：
不要试图做一个”什么都能干的超级 Agent”——那条路上 OpenAI 刚刚帮你踩了刹车。而是做一个”很多小 Agent 各管一摊”的系统。它们沟通的成本是有的（merge 冲突、重复计算、异步协调），但这些成本是可预测、可管理的——而单 Agent 越权带来的风险是不可预测的。
用开源项目的逻辑来管理 AI 团队。Git 管代码、频道管沟通、上下文管复用。
人类开发者能协作的方式，AI 一样可以。甚至更好——因为 AI 不会因为收到 30 条消息就心态爆炸。