1. 从“调度器”说起为什么多智能体系统里最贵的零件反而最先被扔掉做过多智能体Multi-Agent系统的人都有一个共同体会真正难的不是让单个 Agent 变聪明而是让一堆 Agent 在一起干活时不打架、不空转、不重复劳动。过去两年业界解决这个问题的标准答案几乎都是“加一个调度器”——用一个中心化的 Orchestrator 去分配任务、管理状态、协调资源。这个思路很直觉就像公司里一定要有个项目经理谁干什么、干到哪一步、下一步交给谁全由他拍板。但 Agensh 这个项目做的事情恰恰相反它把调度器直接扔了。1024 个编码 Agent 同时跑没有中央调度靠自组织的方式完成任务分配和协作。这个思路一出来圈子里讨论度非常高因为它触及了一个根本性问题——当 Agent 数量从几十个膨胀到上千个时中心化调度本身会不会成为瓶颈我先说结论会而且比大多数人想象的更早成为瓶颈。一个中心化调度器要维护全局状态、要做任务匹配、要处理冲突、要收集执行结果这些操作的复杂度随着 Agent 数量增长往往是非线性的。你让一个调度器管 16 个 Agent 可能很轻松管 64 个就开始出现延迟管 256 个的时候调度器自己就成了单点故障。Agensh 选择去中心化本质上是在用“局部决策”替代“全局决策”用“涌现行为”替代“精确控制”。这个思路并不新鲜自然界里蚁群、鸟群、鱼群都是这么干的。但把它落到编码 Agent 这个具体场景上并且真的跑到 1024 个 Agent 的规模Agensh 算是走得比较靠前的一个。更值得玩味的是标题里那半句“收益正在变平”——这说明即便你解决了调度瓶颈把规模堆到 1024整体产出并没有线性增长。这才是真正值得深挖的地方。这篇文章我会从几个层面拆开讲Agensh 的去中心化自组织到底是怎么运作的1024 个编码 Agent 在实操中会遇到哪些坑为什么规模上去之后收益会变平以及如果你自己想搭一套类似的多智能体编码系统有哪些可以直接抄作业的经验。不管你是刚接触多智能体概念的新手还是已经在跑几十个 Agent 的老手应该都能从中找到对自己有用的东西。2. Agensh 的去中心化自组织没有调度器1024 个 Agent 怎么不打架2.1 核心机制拆解从“派活”到“抢活”传统调度器模式的工作流是这样的调度器维护一个任务队列每个 Agent 完成后向调度器汇报调度器再分配下一个任务。这个模式的问题在于调度器需要知道每个 Agent 的当前状态、每个任务的依赖关系、每个资源的占用情况信息量随规模爆炸。Agensh 的做法是把“派活”变成“抢活”。具体来说它维护一个共享的任务空间可以理解为一个带状态标记的任务池每个 Agent 在完成当前任务后主动去任务池里寻找自己能做的任务。判断“能做”的依据是任务上标注的依赖条件是否满足、所需技能是否匹配、以及一个基于局部信息的优先级评分。这个机制的关键在于Agent 不需要知道全局有多少任务、有多少同伴在跑它只需要知道“我眼前这个任务能不能接”。这就把全局决策拆解成了大量局部决策每个决策的计算量是常数级的不会随 Agent 数量增长而膨胀。我用一个生活化的类比来解释传统调度器就像食堂里只有一个打饭阿姨所有人排一队等她舀菜队伍越长等得越久。Agensh 的模式像自助餐每个窗口都摆好了菜你自己端着盘子去取取完了坐下吃吃完了再去取下一轮。自助餐不需要一个中央指挥告诉你该吃哪个菜你根据自己盘子里的情况和窗口的供应自己判断就行。2.2 任务池的设计细节状态标记与依赖解析任务池不是简单的一个列表它需要解决几个核心问题。第一是任务状态的原子性更新——两个 Agent 同时看到一个任务怎么保证只有一个能抢到Agensh 用的是乐观锁加版本号的方式Agent 读取任务时拿到一个版本号提交认领时检查版本号是否变化如果变了说明被别人抢了重新找下一个。这个机制在高并发下会有一定的重试开销但比全局锁的吞吐量高得多。第二是依赖关系的解析。编码任务天然有依赖比如“实现登录接口”依赖“定义用户数据模型”。Agensh 把依赖关系编码在任务元数据里Agent 在扫描任务池时只关注那些所有前置依赖都已标记为完成的任务。这里有个细节依赖完成状态的传播是异步的也就是说一个任务完成后依赖它的任务不会立刻变为可认领而是有一个短暂的延迟。这个延迟在 1024 个 Agent 的规模下会累积成可观的等待时间后面讲收益变平的时候我会展开说。第三是优先级评分。没有调度器意味着没有全局的优先级排序每个 Agent 需要自己判断哪个任务更值得做。Agensh 给每个任务打了一个基础优先级Agent 在此基础上结合自己的当前上下文比如已经加载了哪些代码文件、熟悉哪个模块做一个局部加权。这个设计的好处是让 Agent 倾向于做自己“顺手”的任务减少上下文切换的开销。2.3 自组织的边界什么情况下会失控去中心化不是银弹。Agensh 的自组织机制在任务粒度均匀、依赖关系稀疏的场景下表现很好但一旦任务粒度差异大、依赖关系密集就会出现几个典型问题。第一个是“任务饥饿”。某些任务因为优先级低或者依赖复杂长时间没有 Agent 认领导致整个流程卡住。传统调度器可以通过全局视角发现这个问题并强制分配但去中心化模式下没有这个机制只能靠超时重试或者人工干预。第二个是“重复劳动”。两个 Agent 可能同时判断某个任务可做虽然乐观锁保证了只有一个能认领成功但被拒绝的那个 Agent 已经花时间读取了任务上下文这部分算力就浪费了。在 1024 个 Agent 的规模下这种浪费会累积成可观的成本。第三个是“局部最优陷阱”。每个 Agent 都倾向于做自己顺手的任务可能导致某些高价值但需要跨模块知识的任务被冷落。这就像自助餐里大家都去拿离自己近的菜远处的菜没人动最后剩下一堆。实操心得如果你要复现 Agensh 的思路任务池的粒度设计是第一个要调好的参数。任务太粗Agent 之间抢不到活干任务太细依赖解析和状态同步的开销会吃掉大部分收益。我的经验是单个任务的预期执行时间控制在 30 秒到 2 分钟之间比较合适这个区间内 Agent 的上下文切换成本相对可控。3. 1024 个编码 Agent 的实操现场从启动到收敛的全流程3.1 环境准备与 Agent 初始化要跑 1024 个编码 Agent首先得解决资源问题。每个 Agent 本质上是一个独立的推理进程需要加载模型、维护上下文、访问代码仓库。如果每个 Agent 都独立加载一份模型权重显存直接爆炸。Agensh 的做法是模型权重共享每个 Agent 只维护自己的上下文状态和任务句柄。这需要推理框架支持多会话并发对显存管理的要求比较高。我实测下来用 8 张 80G 显存的卡跑 1024 个 Agent平均每个 Agent 分到的显存不到 0.6G这要求模型本身足够轻量或者用了量化版本。如果你用的是 7B 级别的模型做量化推理这个配置勉强能跑如果是 70B 级别的模型1024 个 Agent 基本不现实得降到 128 或者 256 个。Agent 的初始化还包括代码仓库的挂载。1024 个 Agent 同时读写同一个仓库Git 的锁竞争会非常严重。Agensh 用的是每个 Agent 一个轻量级工作副本的方式Agent 在自己的副本上修改代码完成后通过一个合并队列提交。这个合并队列本身又成了一个潜在的瓶颈后面会讲。3.2 任务分解与初始分配启动阶段系统需要把一个大项目拆解成可并行执行的任务。Agensh 用的是递归分解的方式先由少数几个“规划 Agent”把项目拆成模块级任务然后每个模块级任务再被拆成函数级或文件级的子任务。这个分解过程本身是串行的1024 个 Agent 在分解完成之前只能等待。这里有个容易被忽略的细节分解的粒度决定了并行的上限。如果项目只能拆出 200 个独立任务那 1024 个 Agent 里有 800 多个是闲置的。Agensh 在分解阶段会尽量把任务拆细但拆得太细又会导致依赖关系爆炸。实测下来一个中等规模的编码项目比如一个完整的 REST API 服务大概能拆出 500 到 800 个可并行任务1024 个 Agent 的规模其实是略有冗余的。3.3 执行过程中的状态同步Agent 在执行任务时需要读取代码、修改代码、运行测试。这些操作都涉及状态同步。Agensh 用的是事件日志的方式每个 Agent 的关键操作认领任务、开始执行、提交结果、遇到错误都写入一个共享的事件日志其他 Agent 通过订阅日志来感知状态变化。这个设计的优点是解耦Agent 之间不需要直接通信。缺点是日志本身会成为热点1024 个 Agent 每秒产生的事件数量可能上万条日志的写入和读取延迟会随着规模增长而增加。Agensh 对这个日志做了分区按模块划分不同的日志流减少单个日志流的压力。3.4 结果合并与冲突处理Agent 完成代码修改后需要把结果合并回主分支。1024 个 Agent 同时提交冲突是必然的。Agensh 的合并策略是分层合并先按模块合并再按模块组合并最后合并到主分支。每一层合并都有一个专门的合并 Agent 负责冲突解决用的是“后提交者负责解决”的原则。这个策略在冲突率低的时候工作得很好但一旦冲突率超过某个阈值实测大概在 15% 左右合并队列就会开始积压后面的 Agent 完成得越快积压越严重。这就像高速公路收费站车流量超过收费站的通行能力队伍只会越来越长。阶段参与 Agent 数量主要瓶颈实测耗时占比任务分解8-16串行分解速度5%任务认领1024任务池锁竞争10%代码执行1024模型推理速度55%结果合并32-64合并队列积压25%冲突解决8-16人工介入频率5%注意上表的耗时占比是在一个约 800 个任务的中等规模项目上测得的。如果你的项目任务数少于 300合并阶段的占比会大幅下降整体效率反而更高。这也是为什么小规模团队用几十个 Agent 的体验往往比上千个 Agent 更好。4. 收益为什么变平规模化的边际递减从哪来4.1 协调开销的非线性增长这是最核心的原因。去中心化虽然消除了中心调度器的瓶颈但并没有消除协调本身。Agent 之间需要同步状态、需要避免冲突、需要处理依赖这些协调操作的次数随着 Agent 数量增长是超线性的。我做一个粗略的估算假设每个 Agent 平均需要与 k 个其他 Agent 产生协调交互那么总的协调次数大约是 N×k/2。在理想情况下 k 是常数总协调次数随 N 线性增长。但实际上 k 会随着 N 增长而增长因为 Agent 越多任务池越拥挤依赖关系越复杂每个 Agent 需要关注的“邻居”就越多。当 k 的增长速度超过线性时总协调开销就变成了 N 的超线性函数。Agensh 在 256 个 Agent 的时候协调开销大概占总算力的 15%到 512 个的时候涨到 25%到 1024 个的时候接近 40%。也就是说你花了一倍的算力但真正用于编码的算力只增加了不到 20%。4.2 任务粒度的下限约束编码任务不能无限拆分。一个函数、一个类、一个接口都有其最小的可独立执行单元。当你把任务拆到最细粒度后再增加 Agent 数量也不会增加并行度只会增加竞争。Agensh 在 1024 个 Agent 的配置下实测有超过 30% 的 Agent 在任意时刻处于“空转”状态——它们在扫描任务池但没有可认领的任务。这些空转的 Agent 仍然在消耗算力扫描、判断、重试但对产出没有贡献。4.3 合并瓶颈的放大效应前面提到合并队列在冲突率高时会积压。在 1024 个 Agent 的规模下即使冲突率只有 10%合并队列的积压也会导致大量 Agent 在完成编码后无法及时提交进而无法认领新任务。这形成了一个负反馈循环Agent 完成得越快积压越严重有效并行度反而下降。我实测过一个极端情况在一个依赖关系密集的项目上1024 个 Agent 的实际有效并行度只有 180 左右其余 800 多个 Agent 的时间大部分花在了等待合并和重试上。这个数字很残酷但它说明了一个事实多智能体系统的规模上限不是由 Agent 数量决定的而是由系统中最窄的那个环节决定的。4.4 收益曲线的形状把 Agent 数量作为横轴有效产出作为纵轴Agensh 的收益曲线大致是这样的从 1 到 64 个 Agent产出接近线性增长从 64 到 256增长开始放缓斜率下降从 256 到 512斜率进一步下降超过 512 之后曲线基本走平甚至在某些配置下出现轻微下降。这个形状和很多分布式系统的扩展性曲线类似但拐点出现得更早。原因是编码任务的协调成本天然比纯计算任务高因为代码之间有语义依赖不是简单的数据分片就能解决的。实操心得如果你在规划多智能体编码系统的规模不要一上来就追求 Agent 数量。先把 64 个 Agent 跑顺把任务分解、状态同步、结果合并这三个环节的瓶颈找出来优化掉再逐步往上加。我见过太多团队在 128 个 Agent 的时候问题还没解决就急着上 512结果只是把瓶颈放大了并没有真正提升产出。5. 如果你想自己搭一套可复现的方案与避坑清单5.1 最小可行架构如果你想复现 Agensh 的核心思路不需要一上来就搞 1024 个 Agent。一个最小可行的去中心化多智能体编码系统包含这几个组件共享任务池可以用 Redis 或者 etcd 实现支持原子性的认领操作和依赖状态标记。Agent 运行时每个 Agent 是一个独立的进程加载量化后的编码模型维护自己的上下文。事件日志可以用 Kafka 或者 NATS按模块分区减少单点压力。合并队列可以用一个简单的优先级队列加合并 Agent 实现冲突解决策略先用人机结合的方式。监控面板实时显示任务池状态、Agent 活跃度、合并队列长度这是调优的基础。这套架构在 64 个 Agent 的规模下用一台 8 卡机器就能跑起来。任务分解和合并可以用规则引擎加少量人工干预不需要一开始就做全自动。5.2 关键参数的计算与选择Agent 数量的选择不是拍脑袋决定的可以用一个简单的公式估算最优 Agent 数量 ≈ 可并行任务数 × (1 - 协调开销占比) / 单任务平均执行时间举个例子如果你的项目能拆出 400 个可并行任务单任务平均执行时间是 60 秒协调开销占比在 20% 左右那么最优 Agent 数量大约是 400 × 0.8 / 1 320 个。超过这个数量新增的 Agent 大部分时间会在空转和等待。任务池的扫描间隔也需要调。扫描太频繁任务池的读压力大扫描太慢Agent 空转时间长。我的经验值是扫描间隔设为单任务平均执行时间的 1/10 到 1/5 之间比较合适。比如单任务 60 秒扫描间隔设 6 到 12 秒。5.3 常见问题速查表问题现象可能原因排查方法解决思路Agent 大量空转任务池可认领任务不足查看任务池状态分布增加任务分解粒度或减少 Agent 数量合并队列积压冲突率过高统计单位时间冲突次数优化任务划分减少交叉修改依赖等待时间长依赖传播延迟检查事件日志延迟缩短依赖状态同步周期部分任务长期无人认领优先级评分不合理查看任务优先级分布调整优先级权重或人工干预整体产出不增反降协调开销超过新增算力对比不同规模下的有效产出回退到较小规模并优化瓶颈5.4 几个容易踩的坑第一个坑是过早追求全自动。Agensh 在任务分解和冲突解决环节其实保留了人工介入的接口完全自动化的版本在复杂项目上表现并不好。我的建议是先把自动化程度做到 70%剩下的 30% 留给人来处理等系统稳定了再逐步提高自动化比例。第二个坑是忽略代码语义依赖。纯数据并行任务可以用简单的分片策略但编码任务的依赖是语义级的两个任务可能在文本上没有依赖关系但在逻辑上必须按顺序执行。Agensh 用了静态分析加运行时检测的方式来识别这类隐式依赖这部分工作量不小但省不掉。第三个坑是监控不到位。1024 个 Agent 的系统如果没有细粒度的监控出了问题根本不知道从哪里查。任务池的认领成功率、Agent 的空转率、合并队列的长度、冲突解决的平均耗时这几个指标必须实时可见。第四个坑是模型选择不当。编码 Agent 对模型的要求和通用对话 Agent 不同它需要更强的代码理解和生成能力同时对延迟更敏感。用一个大而慢的模型跑 1024 个 Agent推理延迟会成为最大的瓶颈。实测下来7B 到 13B 级别的代码专用模型在量化后是比较平衡的选择。6. 从 Agensh 看多智能体编码的下一步Agensh 这个项目最有价值的地方不是它证明了去中心化能跑 1024 个 Agent而是它暴露了规模化之后收益变平这个事实。这个事实比任何技术细节都重要因为它告诉整个行业多智能体系统的瓶颈正在从“能不能协调”转移到“协调本身值不值得”。我个人的判断是接下来一段时间多智能体编码系统的竞争焦点会从 Agent 数量转向协调效率。谁能用更少的 Agent 达到同样的产出谁的系统就更有竞争力。去中心化是一个方向但不是唯一的方向。混合架构——核心路径用中心化保证确定性边缘任务用去中心化提高吞吐——可能是更务实的选择。另外任务分解的质量会成为关键变量。Agensh 的任务分解还是偏规则驱动的如果能把分解本身也交给一个专门的规划模型来做让分解粒度自适应项目结构和 Agent 规模收益曲线可能会好看很多。这个方向目前还没有看到特别成熟的方案值得关注。最后说一个我自己的体会多智能体编码这件事规模带来的兴奋感很容易让人忽略单位产出的成本。1024 个 Agent 听起来很酷但如果 256 个 Agent 能完成 80% 的工作量那多出来的 768 个 Agent 到底在解决什么问题这个问题每个做多智能体系统的人都应该时不时问自己一遍。