月之暗面发布的Kimi K2.5带来了一个叫"智能体蜂群agent swarm"的黑科技，这玩意儿让AI从单打独斗变成了百人群殴。
以前的AI做事像排队买奶茶，一个一个来，等到天荒地老。
现在Kimi K2.5训练出了一个指挥官，能同时派出100个小弟并行干活，速度直接飙到原来的4.5倍。更狠的是，这种并行能力不是写 prompt 教出来的，而是通过强化学习硬训出来的。
与此同时，Anthropic家的Claude Teams搞了个多智能体协作，结果反而更慢更贵，
这说明协调才是多智能体系统的真正难点，光靠堆数量没用。
智能体干活慢，卡在“排队等工具”，想提速就得学会“分身术并发干活”，真正的关键在于训练一个会调度的总指挥，而不是靠提示词喊口号。并行是数学问题，是奖励函数问题，是调度问题，是关键路径问题。
智能体界的交通大拥堵
想象一下你正在用AI助手处理一个超复杂的任务，比如要搜集100个不同领域的资料。传统的AI就像一个超级勤奋但有点死脑筋的员工，它拿着清单一个一个查，查完第一个再查第二个，查完第二个再查第三个。每一步都要等上几十秒，100个步骤下来，你泡的咖啡都凉了，它还在那儿吭哧吭哧地干。这就是现在大多数AI智能体的现状：所有操作都是串行的，像一条单行道上的车队，前面一辆车抛锚了，后面全得等着。
这种串行执行的瓶颈有多严重呢？
时间成本随着任务步骤线性增长，10个步骤就是10倍时间，100个步骤就是100倍时间。你想要AI帮你做个深度调研，结果它在那儿磨叽半天，你的耐心早就被磨光了。
这就好比你在千问里点了个杯免费奶茶，结果千问需要一个个处理，忙不过来，只能告诉你免费延长到28日，它把责任推到骑手身上，骑手忙不过来啊，非要一家一家餐厅取餐，送完一家再送下一家，就是等你拿到手的时候，茶都馊了。其实是它自己面临串行执行的瓶颈！
顺序干活的智能体，像极了排队打饭，你现在用的很多智能体系统，干活流程长这样：
- 调用一个工具。
- 等结果。
- 再调用一个工具。
- 再等结果。
所谓“线性增长”，意思很简单：十步任务十倍时间，一百步任务一百倍时间。效率直接和步骤数量成正比。数学老师听了都会点头。
问题来了——任务本身其实可以拆开并行干活。查资料、写总结、做对比，这些活儿天生可以分给多个小助手同时干。结果现在却一条龙流水线排队。
你拥有一群天才实习生，却让他们一个一个轮流用一支铅笔写作业。效率感人。
并行真正的秘密在“学会调度”
有个新系统思路很狠，核心操作很简单：训练一个“总指挥”。
这个总指挥可以随时生成多个子智能体；子智能体同时干活；最后把结果汇总。
这类似大数据处理的Map/Reduce思想，类似Fork/Join算法。
关键不在生成子智能体，难点关键在于——调度。
调度这个词听着像物流公司。其实就是：谁先干？谁同时干？谁等结果？谁合并输出？
并行不是喊一句“大家一起上”就自动发生；并行是通过强化学习训练出来的能力。
强化学习就是通过奖励信号反复试错，让系统学会哪种策略更高分：Map/Reduce 或Fork/Join哪种在哪种场景下最合适。
这套思路的亮点在这里：并行拆解是学出来的能力，而不是提示词教出来的套路，也不是生搬硬套写死的算法调度。
Kimi K2.5的百人群殴战术
月之暗面这次搞了个大新闻，他们的Kimi K2.5模型里藏着一个叫"智能体蜂群"的杀招。这个系统最牛的地方在于，它不再是一个AI孤军奋战，而是能同时召唤出多达100个子智能体，像蜂群一样并行出击。
这些子智能体各自独立干活，最后把结果汇总给指挥官。这就好比原来是一个人在搬砖，现在是一百个人同时搬砖，效率直接起飞。
官方数据显示，在某些需要广泛搜索的任务上，这种并行架构能把执行时间压缩到原来的五分之一，也就是4.5倍的提速。
想象一下，原来需要等一个小时的任务，现在十几分钟就搞定了。这种感觉就像是从绿皮火车升级到了高铁，从 dial-up 拨号上网升级到了光纤宽带，爽得不要不要的。
强化学习炼出的指挥官
最离谱的是，Kimi K2.5的这个指挥官不是写 prompt 写出来的，而是通过一种叫"并行智能体强化学习"的方法硬训出来的。
月之暗面的工程师们发现，如果只是简单地告诉AI"你要并行执行任务"，AI往往会陷入两种坑爹状态：
一种是"串行崩溃"，就是明明有能力并行，但它偏要一件一件来；
另一种是"虚假并行"，就是生造出一堆子任务，但这些任务实际上并没有真正并行执行，反而增加了协调开销。
为了解决这个问题，他们设计了一个三段式的奖励塑造机制。
训练初期，系统会奖励指挥官创建子智能体和并行执行的行为，强迫它去探索并行化的可能性。这就好比训练一只狗，先给它零食让它学会握手，等它习惯了再教它更复杂的动作。
随着训练深入，奖励的重点逐渐转移到任务完成质量上，确保这些并行执行不是瞎折腾，而是真的能提高效率。
这种训练方法让AI真正学会了什么时候该并行、怎么并行、并行多少个子任务最合适，而不是死记硬背几个固定的流程模板。
关键路径上的数学博弈
Kimi 2.5还引入了一个叫"关键步骤"的约束指标，这个概念的灵感来自并行计算领域的关键路径分析。
关键步骤等于主智能体步骤数量加上每一组并行中最长子任务步骤，听着有点绕。翻译一下：并行提速只有在最长那条分支变短时才有效。
简单来说，就是不管派出去多少个子智能体，整个任务的完成时间取决于最慢的那个分支。如果你派了100个子智能体，其中99个都秒回结果，但有一个在那儿磨叽了半天，那整个任务还是得等那个最慢的。
这和著名的并行加速定律思想一致：瓶颈决定上限。如果你拆出一百个小任务，其中有一个任务特别慢，整体时间还是由它决定。生成大量微小任务不会提升速度。关键在于压缩最慢的那条路径。
这个约束条件逼着指挥官在分解任务的时候必须动脑子：不能为了并行而并行，得确保每个子任务的复杂度差不多，避免出现一个子任务重如泰山、其他子任务轻如鸿毛的情况。这就好比一个项目经理分配工作，不能把大部分活儿都堆给一个人，其他人闲着，得合理分配才能最大化团队效率。
这种设计有效防止了奖励作弊，避免AI通过创建大量简单但无用的子任务来刷奖励分。
并行不是拼数量；并行是砍掉最慢那根木头。
上下文分片的降维打击
智能体蜂群还有一个隐藏福利：上下文管理。
在传统的单智能体系统中，随着任务进行，上下文窗口会被各种工具调用结果、中间思考过程塞得满满当当，最后不得不 截断（丢失信息）或者 总结（压缩泄露），结果就是丢失重要信息。
Kimi 2.5的蜂群架构把这个问题也解决了。
每个子智能体都有自己的独立工作记忆和本地上下文，指挥官只接收任务相关的输出结果，而不是完整的执行轨迹。这就好比一个CEO不需要知道每个员工每天具体怎么工作的，只需要看他们的周报和最终成果就行。
这种主动的上下文分片比被动的截断策略高明多了，既保证了信息不丢失，又避免了上下文爆炸。
Anthropic的翻车现场
说到多智能体协作，不得不提Anthropic家的Claude Teams。
他们也搞了个多智能体功能，让多个Claude Code实例一起工作。理论上听起来很美好，大家分工协作，效率翻倍。但实际测试结果让人大跌眼镜：在WideSearch基准测试上，Claude Teams不仅比单智能体慢，还比单智能体贵，得分也更低。
具体数据是这样的：单智能体基线成本93美元，完成了46次任务；多智能体团队成本131美元，只完成了47次任务。
考虑到多智能体理论上应该更快，这个成绩简直是灾难。
得分方面，单智能体基线64.8%，多智能体团队只有53.8%，比单智能体还低了11个百分点。
这就好比你们公司招了更多人，结果活儿干得更慢、质量更差、花的钱还更多，老板不气炸才怪。
协调成本的隐形杀手
为什么Anthropic的多智能体会翻车？核心问题在于协调成本。
当多个智能体一起工作时，它们之间需要通信、同步、避免重复劳动、解决冲突，这些协调开销往往会吃掉并行化带来的所有收益。
如果没有一个训练有素的指挥官来统筹调度，多智能体就会变成一群无头苍蝇，各自为政，甚至互相干扰。
Kimi 2.5通过强化学习训练出的 orchestrator调度器 正好解决了这个问题。它学会了如何最优地分解任务、调度子智能体、聚合结果，把协调成本降到最低。
而Anthropic的Claude Teams似乎更多是靠 prompt 工程硬堆出来的，缺乏这种系统性的训练，结果就是协调开销爆炸，性能不升反降。
从提示工程到数学优化
多智能体本身不自动带来效率！如果没有好的调度机制，多个智能体就像多个实习生围着同一个问题互相重复查资料。
- 重复劳动。
- 上下文污染。
- 通信成本增加。
- 合并结果变复杂。
你多开几个窗口不等于电脑更快！真正的速度来自架构设计。
真正的结构：总指挥 + 冻结子智能体
系统结构其实很清晰：一个可训练的总指挥。一组固定能力的子智能体。
总指挥负责：规划任务拆分任务安排执行顺序汇总结果
子智能体负责：执行具体子任务各自独立运行
这里有个设计哲学很漂亮：子智能体是冻结的堵塞的，只有总指挥学习。
这种设计的好处是稳定。能力模块不乱变。策略层持续优化。
你可以理解成：工程师能力固定，总经理学会怎么安排项目。
奖励函数决定一切
真正的灵魂在奖励函数。
如果奖励函数设计不好，会出现两个经典问题：
一个智能体包办所有任务，形成串行坍塌。疯狂生成一堆子智能体刷存在感。
为了解决这个问题，奖励函数分成几个部分：
鼓励真正的并行鼓励合理完成奖励任务结果表现
更狠的是，还加入了“关键路径约束”。
奖励函数的魔鬼细节
Kimi 2.5的奖励函数设计堪称教科书级别。除了前面提到的防止串行崩溃和虚假并行的奖励项，还有一个叫"r_perf"的任务级结果奖励，确保最终输出质量。更牛的是，他们还引入了一种新的 token 级裁剪机制，用来缓解离策略发散问题。
这个问题在智能体工作负载中特别严重，因为智能体任务的序列通常很长，策略更新很容易偏离生成数据的原始策略太远。token 级裁剪就像给训练过程加了一个安全带，防止模型在学习过程中跑偏。这种细节上的打磨，体现了月之暗面团队在强化学习工程化方面的深厚功底。
实际应用的暴力美学
想象一下这种技术在实际场景中的应用。比如你要做一个市场调研，需要分析50个竞争对手的产品。传统方法是你一个人（或一个AI）逐个查，查完一个再查下一个，可能需要好几天。用Kimi 2.5的智能体蜂群，指挥官会瞬间创建50个研究专员智能体，每个负责一个竞争对手，并行搜集信息，最后汇总成一份完整的报告，整个过程可能只需要几十分钟。
再比如代码审查，你可以派出多个审查员智能体，分别检查代码的不同方面：一个查安全性，一个查性能，一个查代码风格，一个查业务逻辑，它们同时工作，最后把结果汇总。这种并行审查不仅更快，而且覆盖面更广，因为每个智能体可以专注于自己的专业领域。
计算瓶颈转移：从图形处理单元到调度系统
当智能体开始大规模并行，整个系统结构也变化！单次模型推理变成：分支并发合并
这时候瓶颈开始变化：调度开销尾延迟工具调用输入输出缓存沙箱执行；图形处理单元依然负责模型计算；CPU中央处理器负责调度、检索、工具执行。
智能体时代，中央处理器CPU的重要性提升。以前大家盯着模型算力,现在要盯架构效率。
智能体蜂群带来了一个更深层的变革：推理栈的范式转移。
传统的AI推理主要卡在GPU解码上，模型越大，解码越慢；但在智能体蜂群的架构下，瓶颈从"GPU解码"转移到了"调度器开销"、"尾延迟"和"I/O操作"上。整个推理栈开始看起来像一个数据中心规模的工作流引擎，而不是简单的模型推理服务。
在这个新世界里，CPU的重要性大幅上升。CPU负责编排调度、工具执行、检索管道、沙箱隔离、缓存管理，而GPU只管核心的模型计算。这种分工让系统能更好地扩展，也为未来的硬件设计指明了方向。以后买AI服务器，可能CPU的配置要比GPU更重要，这在以前是不可想象的。
重点不在“多”，在“优化关键路径”
真正的转变在于认知升级：多智能体是一种分布式运行时问题。是调度问题。是关键路径优化问题。是奖励函数设计问题。
只要奖励函数不约束生成滥用子智能体，系统就会走向混乱。只要关键路径没有被纳入优化目标，并行就失去意义。
数学支配智能体。奖励函数支配行为。架构支配速度。
什么时候群体更强？
群体优势出现于：任务可拆分分支之间依赖少；检索量大；信息源多！
单体优势出现于：逻辑高度耦合频繁共享上下文结果；需要持续迭代！
真正需要的是对比实验：群体何时赢单体何时稳？这才是工程理性。
并行提升来自训练；提示词只是表层。多智能体没有自动魔法。关键路径决定加速上限。奖励函数决定系统走向。协调成本是真实存在的。上下文分片提升稳定性。架构优化成为核心竞争力。
极客一语道破：openclaw vs. kim2.5
OpenClaw其实已经原生支持 spawning subagents，通过一个叫 sessions_spawn 的工具就能创建子会话，还能指定用哪个模型。理论上你可以并行跑很多个子智能体，就像一家餐厅可以同时开多个灶台一样。这个功能的存在说明大家早就意识到串行执行的问题了，都想往并行化方向走。
OpenClaw的并行能力给用户自己定制，而不是通过统一计划经济的方式去学习，再强大的集中式大象训练也不如众多蚂蚁的力量！
再强大的集中式大象训练也不如众多蚂蚁的力量 是指Kimi这种通过集中强大强化学习调度策略，不如放手让用户自己去定制，Kimi这种集中训练是上帝思维，以为自己可以像上帝指挥所有的场景，那么上下文为王就是一句空话，这是Kimi这些人根本没有上下文为王的信仰，是自己为上帝的信仰。
你可能反驳：强化学习调度器并不是“上帝”，它优化的是一类任务分布下的策略函数。也就是说：它学习的是在统计意义上哪种拆分方式平均收益更高！它是过去大量任务分布下的策略函数！
它优化的是一类任务分布下的策略函数。 这就是是一个平均主义吧，正如凭粮票供应，每人半斤，看似很优化，但是有人吃得多，有人吃不下！
这个大量任务是不是过去的事实，你能包括未来吗？过去大量任务表现好，未来就能表现好吗？
为何你喜欢在一个大模型里包办应该交由用户自己定制的场景呢？然后以强化学习为幌子，说明成绩多优秀，其实强化学习的坑就是在有限世界里做到好，但是世界是无限的，我们不能把自己培养成有限世界的思想奴隶，当我们把人生化为：高考、结婚和生孩子三个阶段时，我们已经掉入有限的困境。
OpenClaw是一种去中心化并行智能体实战；kim2.5是一种中心化思想的实验。
OpenClaw通过sessions_spawn工具开放子智能体并行生成能力，采用市场经济路线让用户自主定制任务编排策略，与Kimi K2.5集中式训练的计划经济模式形成对比。去中心化架构下众多用户的分布式探索可能涌现超越 集中式 训练的协调智慧，实现灵活性与效率的双重优势。
OpenClaw的开源特性让社区智慧成为进化的驱动力。当某个用户发现了一种高效的并行配置，他可以分享给社区，其他用户可以借鉴、改进、再分享。这种知识的快速传播和迭代优化，可能超过任何 centralized 训练的速度。
GitHub上的讨论和配置文件分享就是这种进化的缩影。用户们在探索不同的maxConcurrent设置、不同的模型组合、不同的任务拆分策略，每一次成功的实践都在丰富社区的集体知识库。这种自下而上的创新模式，可能比自上而下的训练更能发现多样化的最优解。
而且，社区中的用户面对的问题各不相同，有的需要处理大量文档，有的需要分析复杂数据，有的需要生成创意内容。这种问题的多样性驱动着解决方案的多样性，最终可能涌现出一整套针对不同场景的优化策略，这是单一模型难以覆盖的。
举例：OpenClaw多智能体调度一种简单策略：OpenClaw共享大脑：一行符号链接搞定多智能体编排框架
当然，OpenClaw这种基于提示词的编排方式也是有天花板：主智能体得靠人工配置来决定怎么拆任务、拆成几个、每个子任务给什么提示词，这些决策都是靠提示词工程硬写出来的，而不是真正学出来的。遇到复杂的、动态的、需要反复协调的任务，这种硬编码的编排逻辑就容易捉襟见肘。子智能体之间不能互相通信，不能动态调整，不能根据中间结果重新分配任务，这些限制让它的协调能力远不如Kimi 2.5那种训练出来的协调体指挥官。
但是，这个配置初始是人工配置，OpenClaw是可以自己优化的，自行改这个配置，这就是递归配置的力量：智能体递归觉醒：OpenClaw说明书学会改写自己！