没有调度器也能跑？1024个自组织Agent协作如何突破收益变平困局

最近一直在折腾多编码 Agent 的协作架构，从中心化调度器到自组织模式都试了个遍，看到微软团队这套 Agensh 实验——把调度器整个拆掉，让 1024 个编码 Agent 在没有全局指挥官的情况下自组织干活——一下子戳中了我的关注点。更让我在意的是它的实验结果：当 Agent 数量冲到一定规模之后，收益曲线开始明显变平。这个现象，比“调度器到底该不该留”这个争论有信息量得多。

这篇文章我想顺着这条线索，把三件事讲透：为什么有人会想扔掉调度器、1024 个 Agent 在没有调度器时是怎么协作的、以及“收益变平”背后到底是哪些结构性问题在拖后腿。最后再聊聊，我们普通做系统的人，能从中学到什么设计和取舍。适合正在做多 Agent 系统、被编排逻辑折磨到头疼的工程师，也适合那些准备把集群规模往上堆但其实还没想清楚成本曲线的技术决策者。

1. 调度器不是在偷懒，是真的顶不住了

1.1 调度器一天到晚在干什么

先给没亲手做过编排的朋友补个背景。所谓调度器，在多 Agent 系统里承担的活儿远不止“把任务发给空闲 Agent”。一个典型的中心化调度器，至少要做四件事：任务分解和排队、资源分配和负载均衡、进度跟踪与失败重试，最后还要负责冲突消解和结果合并。

拿编码 Agent 场景来说，调度器首先要理解你提交的需求，把它拆成若干个可以并行处理的子任务，然后逐个分配给不同的编码 Agent。每个 Agent 干完活之后，结果要汇总回调度器，由它来做最终合并、修复接口不匹配、处理同一个文件被两个人改过的冲突。你发现没有，调度器其实是个“超级集中节点”，所有信息都流向这里，所有决策都从这里发出，它天然就是系统的瓶颈。

我自己的项目到 30 多个 Agent 的时候，调度器就明显开始变成“人有失手”的环节了。任务队列堆积、心跳超时判断出错、两个 Agent 改了同一个接口没人察觉——这些问题都集中爆发在调度器身上。你加大调度器的处理能力，它就变成新的单点；你给调度器做高可用，复杂度直接翻倍。这时候你再看 Agensh 的实验思路，就很容易理解那种“干脆把这个瓶颈整个拿掉”的冲动。

1.2 Agent 数量翻倍，调度器先崩

中心化调度器有一个很尴尬的扩展规律：Agent 数量每翻一倍，调度器的负载上升得比 Agent 数量本身还要快。因为每个 Agent 的状态上报、任务领取、结果回传，全都要经过调度器处理，这部分负载是跟 Agent 数量线性增长的。但调度器还得处理 Agent 之间的间接依赖，比如 A 的任务结果会影响 B 的输入，这种依赖判断在中心化模式下都压在调度器身上，增长的复杂度远超线性。

所以你会看到一种很典型的状态：集群规模在 64 到 128 这个区间时，调度器已经天天报警；你把调度器拆成多线程、加缓存、上消息队列，也只是把爆炸时间往后推了几个版本。真正让人绝望的是，当你为了支撑更多 Agent 而上调调度器的资源时，整个系统的响应延迟也在涨，因为每次通信都要多走一跳。

Agensh 实验选 1024 这个数字，真的很有挑衅意味。它就是要告诉你：我们不是用更强的调度器去扛 1024 个 Agent，而是直接把调度器拿走，让 Agent 自己解决协作问题。这等于默认一个前提——中心化调度的成本在某个规模下是“不可持续”的，而不是“不够优化”。

1.3 “把调度器扔了”的真实动机：不是叛逆，是成本

我不是说调度器的设计者不行。实际上，中心化调度器到今天依然是多 Agent 系统里最可靠、最可控的方案。但它的可靠和可控是有代价的，而且这个代价会随着规模上升变成天文数字。

你想一下，调度器要保证全局状态一致，就需要频繁做同步；要做出全局最优分配，就需要收集所有 Agent 的状态；要做安全控制，就需要拦截所有通信。每一条都是在用中心节点的算力和带宽换取控制力。当 Agent 数量足够多、任务足够碎片化的时候，调度器本身的运转成本会开始吞噬掉并行带来的收益。你加一个 Agent，理论产能加一份，但为了让这个 Agent 接入调度体系，你还要付出额外的通信和同步成本。总有一个拐点，新增 Agent 的成本会超过它的产出。

这个逻辑跟分布式系统里“一致性协议的成本随着节点增加而快速上升”是完全一样的。Agensh 的做法相当于选择了一条相反的路：放弃全局最优的执念，允许局部决策、允许不完美的协调，换取系统整体不被调度器卡死的可能性。这个交换划不划算，就要看它的收益曲线了。

2. Agensh 的自组织协作：1024 个 Agent 在没有总指挥的情况下怎么干活

2.1 三条基础规则：局部通信、任务认领、冲突协商

调度器被拿掉之后，最核心的问题就来了：Agent 之间怎么知道该干什么、怎么避免两个人干同一件事、怎么解决冲突？

Agensh 这套自组织框架，底层用的逻辑其实很朴素，就是三条规则：第一，Agent 只跟相邻的 Agent 通信，不搞全局广播；第二，任务在协作网络中“暴露”出来，空闲 Agent 自己认领，而不是被指派；第三，当两个 Agent 的工作范围出现重叠时，通过局部协商决定谁继续谁让路。

这三条规则分别对应中心化调度器里最难做的三个功能：全局通信、任务分配、冲突消解。Agensh 做的是把这三个功能“下沉”到 Agent 的局部交互里。Trade-off 很明显——它不追求全局最优解，只要你不出大乱子就行。比如任务认领阶段，两个 Agent 同时认领同一个模块不同部分的概率是允许出现的，系统靠后续的协商机制去纠正，而不是靠“先分配好”来预防。

把编码任务抽象出来看，这就好比一个开源项目里没有项目经理，贡献者看 issue 列表自行认领任务，互相之间通过 PR 讨论解决重叠和冲突。开源社区能跑起来，说明这套逻辑在人类世界是可行的，Agensh 只是想把它搬到 Agent 的世界里。

2.2 一个编码任务的完整生命周期

我把这套机制套到一个具体编码任务上看一下全流程，感觉会更直观。

假设系统接收到的需求是“给一个电商后端增加积分兑换功能”。在自组织模式下，一个 Agent（姑且叫它入口 Agent）负责把这个需求拆成若干子任务并发布到协作网络里。子任务可能包括设计数据库 schema、实现积分流水接口、调整下单流程、写单元测试、更新 API 文档。每个子任务自带一个粗略的依赖关系字段，比如“下单流程调整”依赖“积分流水接口”的返回格式。

接下来，空闲的编码 Agent 会扫描自己能看到的任务列表，根据自己擅长的方向认领任务。数据库 Agent 认领 schema 设计，接口 Agent 认领流水接口，测试 Agent 看到有测试任务空缺就补位。这里没有任何中央协调者告诉谁去做哪个任务，每个 Agent 都是根据自己的能力、当前负载、以及任务在拓扑上的位置自主决定的。

任务完成后，产出会写回协作网络，并通知依赖它的下游 Agent。下游 Agent 拉取自己的依赖并继续推进。如果 Agent A 发现 Agent B 提交的接口定义跟自己正在写的调用方期望不一致，两者会进入一个局部协商流程，各自带着自己的约束条件去交涉，最后谁修改谁妥协，由他们自己定。

从外部的视角看，这个系统像一个不断自我修正的工作流网络。从内部的视角看，每个 Agent 其实都只看到一小片局部信息，像盲人摸象一样通过局部共识推进全局任务。Agensh 能跑通 1024 个 Agent，靠的正是这种“局部处理”的取舍——没有人能看到全局，但每个局部都在做正确的事。

2.3 “收益变平”是怎么测出来的：评测口径要看清

读这类实验报告，最怕的就是不看评测口径只看结论。收益变平这个结论，到底是用什么指标测出来的，直接决定了它对你有没有参考价值。

按照 Agensh 实验的惯用做法，收益衡量的通常是“单位时间内完成的有效任务量”，而且这个完成度是打过折扣的——产出代码能通过编译、通过测试、通过接口一致性检查，才算有效产出。半成品代码和返工代码会对应扣减成功任务数。换句话说，它测的不是 Agent 产生了多少 token，也不是写了多少行代码，而是整个自组织系统在给定时间内把需求推向“可交付状态”的能力。

这个设计我非常赞成。因为在实际编码场景里，很多并行方案的虚胖都藏在“产出看起来很多但互相不兼容”上。两个 Agent 各写了 300 行代码，结果 200 行要返工，净收益可能还不如一个 Agent 老老实实写 250 行。Agensh 的评测口径把这种返工成本显式地计入了收益，所以它测出来的收益曲线会比只看代码量的曲线更早变平。这其实是一个诚实的指标，值得所有做多 Agent 系统的人学习。

3. 收益为什么会变平：并行不是免费的，越往后越贵

3.1 收益曲线的三个阶段：准线性、亚线性、平台期

现在聊重头戏，为什么收益会变平。我结合自己的经验和 Agensh 实验里能看出来的规律，把收益曲线粗略分成三个阶段。

第一阶段是 Agent 数量还比较少的准线性区。这个区间内，每个新增 Agent 几乎都能带来接近满额的产能提升。因为 agent 之间还够不着彼此，任务分发出去各自埋头干活，通信成本接近于零。假设你有 1600 个完全独立的子任务，从 10 个 Agent 加到 20 个，完成时间基本就减半，体感接近线性。

第二阶段是亚线性区。大概从 256 到 512 这个区间开始，新增 Agent 带来的收益明显小于理论值。最直观的感觉是，你加了 100 个 Agent，完成时间只缩短了原来的一半不到。这时候系统里已经开始频繁出现“等待依赖”——Agent 干完自己的活之后，发现下游还没就绪，于是进入空闲，而那部分空闲时间算是白付出的成本。

第三阶段就是平台期，也就是标题里说的“收益正在变平”。Agent 数量从 512 加到 1024，完成时间几乎不再明显缩短。个别任务甚至可能变慢，因为通信日志的量级上来了，Agent 花了大量时间在收发消息而不是写代码。在 Agensh 的实验条件下，1024 这个规模基本就处在平台期的位置附近。

3.2 变平背后的三个结构性瓶颈

为什么会有这样的曲线？我的分析是三个瓶颈叠加的结果。

第一个瓶颈是通信成本。自组织模式下虽然没有中心调度器，但 Agent 之间依然需要协商和同步。从 512 到 1024，Agent 数量翻倍，局部交互的消息数量却会以更快的速度膨胀。这就好比你把一个团队的沟通模式从“全组开会”改成“小范围拉通”，人数涨到一定程度之后，仍然会有大量时间浪费在对齐信息上。编码 Agent 本质上是 IO 密集型工作者，它们消费和产生 token 的速度有限，大量时间被占用在来回确认接口、协商工单、同步进度上，实际写代码的时间就缩水了。

第二个瓶颈是任务碎片化。一个大需求拆到 1024 份之后，每份任务的体量会变得非常小。看起来并行度上去了，但每个任务之间的依赖关系并不会消失。依赖链上有一个环节没完成，整条链路都要等着。任务拆得越碎，这种串行依赖的相对占比就越大，并行带来的收益就被稀释得越厉害。你可以理解为，100 万行代码的任务拆给 1024 个 Agent，每个 Agent 拿到的可能只是几百行的小模块，但模块之间的接口设计、合并验证、全局测试，依然需要大量串行操作，这部分就是无法并行化的硬成本。

第三个瓶颈是冲突消解成本。编码场景跟很多可完全并行的计算任务最大的区别在于，代码是高度耦合的。两个 Agent 同时写一个包、一个类、甚至一个方法，在自组织模式下是没办法完全避免的。出现冲突之后，需要额外的协商和返工来修复，这部分成本在 Agent 少的时候几乎可以忽略，一旦数量上来，冲突概率会显著上升。更麻烦的是，自组织系统没有中央仲裁者，冲突消解要靠 Agent 之间一对一的谈判，这种局部谈判在大规模下到达不了全局最优，甚至可能让冲突反复出现。

3.3 1024 这个数字的真正含义：边际收益趋近于零

很多人看到“1024 个 Agent”会觉得这是规模的炫耀，但我从这个实验里读到的反而是另一种含义——这是一个告诉你“规模不是越多越好”的警示数字。

我根据实验思路做了一张简化对比表，把不同规模段的特征整理出来，方便读者对应自己的场景：

这个趋势不是我拍脑袋想出来的，它是多 Agent 系统里“并行都贵”这个基本逻辑的必然结果。把 1024 个 Agent 堆上去了，真正的瓶颈不再是算力、不是模型能力，而是协作成本本身。这就像你招了 1000 个程序员去改同一个代码库，刚开始效率翻倍地涨，到后面光开会和 code review 就耗掉所有省下来的时间。

所以，看到“收益变平”不要觉得实验失败，恰恰相反，这说明实验设计者想得很明白。他们不是要让大众相信“自组织很牛”，而是要让大众看到自组织的上限在哪里。系统的总产出最终会收敛到由通信机制、任务依赖和冲突处理机制决定的某一个水平，这个水平就是你的"架构天花板"。

4. 拿掉调度器之后的架构取舍：不是非黑即白

4.1 该留着调度器的场景：Agent 的“硬约束”部分

聊完收益变平，我估计不少人的反应是：“那调度器到底该不该扔？”我的回答是：扔不扔，取决于你系统里有多少“必须全局一致”的硬约束。

如果任务之间存在着强制的前后依赖，比如编码任务里的编译、打包、发布环节，这些步骤是天然串行的。你在这些环节上无论怎么自组织，都不可能让一个还没写完的模块提前参与编译。这种硬依赖如果交给自组织协商去处理，只会让系统陷入无穷无尽的等待与重试，倒不如由一个轻量调度器显式地控制任务门禁——第 N 步完成之后才放开第 N+1 步的 Agent。

另外，如果系统对外承诺了某种安全边界或合规要求，比如不允许某个 Agent 访问敏感信息、不允许特定操作在未授权时执行，这类强制约束也不适合下放到自组织层。自组织是效率导向的，它倾向于“快速达成局部共识”，而不是“死守全局红线”。你需要一个调度器把这些不能协商的事情当成硬性门槛守住。

我自己的经验是，调度器负责“必须做的事情”和“必须不做的事情”，自组织负责“怎么做都行的事情”。把两者分清楚，架构就稳了一大半。

4.2 适合放养自组织的场景：探索与局部生产

哪些场景适合放养呢？核心特征是任务可并行度高、Agent 之间相对独立、不需要严格全局一致性。

典型的就是“探索式编码”——你不知道哪个方案更适合当前的业务场景，让几十个 Agent 各自实现一个候选方案，然后横向比较效果。这种场景下中心化调度器反而容易被做好全局规划，因为连你自己都不知道下一步要探索什么方向。自组织让 Agent 各自基于局部信息发挥，反而能带来更丰富的多样性。

另一个适合自组织的场景是模块边界足够清晰的项目。如果你的代码库里不同服务、不同组件之间接口已经定义得足够稳定，各个模块的开发就可以完全并行进行。每个 Agent 守着自己的模块干活，偶尔在接口层对齐一下，基本不需要一个总调度器来管谁先做谁后做。

我用过一个比喻：调度器模式像指挥中心，适合“确定性高的流程推进”；自组织模式像自由市场，适合“不确定性高的探索和并行生产”。你手里的项目偏向哪一端，选择的天平就往哪一端倾斜。

4.3 最稳的组合：分层调度 + 自治单元

我在自己的项目里最终没有选择“全有调度器”或“全无调度器”的极端方案，而是做成了一个分层结构。最上层保留一个轻量编排层，负责理解需求、拆分大任务、设置硬性的依赖门禁。中间层按照模块或领域划分成若干个自治单元，每个单元内部有若干编码 Agent 自组织协作，单元之间的交互通过定义的接口进行。最底层是每个 Agent 内部的工作流，完全独立。

这个结构的核心思路是：把决策权的粒度放大，不让每个细小操作都上报给中央调度器，但保留必要的全局视野。比如在编码任务里，上层调度器只关注“哪几个模块可以并行开工”“哪些模块必须等接口定稿”，至于模块内部某个任务先做还是先做那个，完全交给单元内自组织去处理。

从实测体感来说，这个组合比纯调度器轻松，比纯自组织可控。它继承了自组织系统的扩展能力，同时用轻量调度消除了最危险的那部分全局一致性风险。Agensh 实验也隐隐指向这条路——它证明了纯自组织的可行性，也证明了纯自组织的天花板，那么聪明的做法就是在天花板之下做文章。

4.4 评估自己系统的方法：通信/协调/并行三因子模型

具体怎么判断自己的系统在什么规模下收益开始变平？我给一个非常粗但很实用的评估模型，把影响收益的变量压缩成三个因子：通信因子、协调因子和并行因子。

并行因子衡量任务可拆解的程度，即有多少比例的工作可以同时进行。通信因子衡量每个 Agent 每天花在收发消息上的时间占比。协调因子衡量为了保持全局一致性而排除并行的时间占比。有效产出大致可以用一个直觉公式估算：

有效产出 = 总工作量 × 并行因子 / (1 + 通信成本系数 + 协调成本系数)

当 Agent 数量增加时，并行因子增长会越来越慢，通信成本系数和协调成本系数却会加速增长。你不需要跑 1024 个 Agent 的完整实验，只要在 100 到 300 个 Agent 之间测到两组数据，就能估算出这个系统收益变平的拐点大概在什么位置。这个拐点就是你的“最优 Agent 规模”，再往上加，只是给日志系统添负担。

实操上，我用来判断的一个简单标尺是：如果 Agent 平均每小时花在等待消息/处理消息上的时间超过了实际写代码的时间，那么这个规模就已经越过了甜点区，加人不如优化通信协议。

5. 我从中拿到的实际启发：先长大的团队会告诉你的事

5.1 通信协议设计比 Agent 数量重要

Agensh 实验最让我意外的不是“1024”这个数字，而是他们为了支撑自组织协作，通信协议的设计必须足够轻量、语义化、无歧义。Agent 之间的每次协商都是在消耗真实的时间和 token，协议设计得差，Agent 就要来回多打几轮补丁式的对话。

举个具体例子。两个 Agent 因为接口参数类型不一致发生冲突，如果协议里允许“直接传递废弃消息历史”，Agent 就会翻出早期不相关的对话夹杂在协商里，把协商效率拖到极低。更好的做法是定义一条简洁的任务状态变更消息，只携带任务编号、变更类型、变更内容和期望影响范围四个字段。消息越短，Agent 消费越快，整个系统的吞吐就越高。

这也是为什么我现在设计多 Agent 系统时，会把通信协议当成第一等公民来看待——它决定你的团队在 500 个 Agent 时的效率，而 Agent 本身的模型能力反而还在其次。

5.2 任务粒度是一道数学题

这个启发来自对“任务碎片化”的分析。任务的拆分粒度既不是越粗越好也不是越细越好，而是一道有最优解的数学题。

粒度太粗，Agent 之间会出现大量空闲等依赖的现象。粒度太细，碎片化带来通信和合并成本，前面已经说过会吞噬收益。最优粒度应该满足一个条件：单个任务的处理时间，显著大于该任务依赖同步和通信所消耗的时间，通常可以设一个 5 到 10 倍的比例。任务处理要足够大，让 Agent 大部分时间在干活；又要足够小，不至于让上游 Agent 等得太久。

实操中我会在任务拆分之后跑一遍竞态检测，看看有多少 Agent 在等待同一个人工设置的“里程碑任务”。如果等待比例超过 30%，说明任务拆得不够合适，我会合并部分小任务或者把依赖关系调整得更加并行友好，而不是盲目增加 Agent 去填坑。

5.3 收益变平是常态，找到自己的甜点区就够了

最后想聊一个心态层面的东西。很多工程师会陷入“更大规模更厉害”的执念，看到 1024 就兴奋，看到自己团队试到 300 个 Agent 就不行了，觉得是自己的问题。

但 Agensh 这个实验的意义恰恰在于：连微软做了这么精心的自组织设计，收益在 1024 也变平了，何况我们普通团队？收益变平不是 bug，更不是失败指标，它是并行系统在这个世界上的正常归宿。你的目标不应该是无限扩展 Agent 数量，而应该是找到自己特定场景下的“甜点区”——在这个区间内，边际收益接近线性，成本可控，系统稳定。

我自己现在做多 Agent 系统，评估方案时先问的不是“这个设计能撑多少 Agent”，而是“我预期的最优规模是多少，这个方案在最优规模下是否足够简单可靠”。如果答案是可以，那调度器留着也好，扔了也行，都不是什么生死攸关的问题。

这个思路，才是这次在 1024 个 Agent 面前变平的收益曲线，教给我最值钱的东西。