Multi-agent的新趋势，从Agent Team到Agent Swarm

前言

当我们能同时调动上百个agent时，会诞生什么新的产品形态。

这是一篇没有明确中心思想的文章，想围绕多 Agent，聊几个最近不断冒出来的产品问题。

标题里 agent team 和 agent swarm 这两个词不用太较真，它们要解决的是同一件事：把一个任务拆开，同时跑十个甚至上百个 agent。

过去我一直觉得，多 Agent 不适合写作和写代码。道理很简单------十个人同时改一份文档，会出现文风不统一，内容互相打架的情况。让一个 Agent 从头写到尾，看起来才是最自然的做法。

但单 Agent 有个绕不开的毛病：慢 。三万字的稿子，模型一个字一个字往外吐，本身就很低效；写得越长，上下文包袱越重，也会出现前后不一致、信息漏掉、质量变差。多 Agent 最直接的好处就是快。一个小时的活压到半小时，用户愿意付的钱可能不止翻倍。

那问题也就来了：几个 Agent 同时写作、同时改代码，文风不一致、上下文割裂、改动冲突，到底怎么解决？

还有一件想搞清楚的事。多 Agent 不该只用来并行搬砖，同时调研一百个博主、分析一百份资料，这类活它当然能干。但它能不能参与真正的 Creative Discovery？我们要的不是一百个 Agent 各做一遍、然后挑出现次数最多的那个答案，那样只会得到一个安全平庸的众数；我要的是那百分之一看着离谱、但可能打开新方向的想法，有机会冒出来。

至于现在这些在 Harness 层用代码堆出来的东西，我个人倾向于最后都会被训进基座模型里。

这篇就天马行空地聊聊这些。

正文

今年 2 月我写 《Scaling起来 #01｜让 AI 并行调研 50 个 benchmark》 的时候，Kimi K2.5 的 Agent 集群刚上线没多久。我给它派了同一个活------同时去查 50 个 benchmark、每个填一张表。实测下来我给了 0 分：它一个字段都没真去查，把论文里现成的跑分抄了一遍就交差了。

那时候 "agent team" 给人的感受是：概念很性感，产品很难用。

半年过去，agent team 的热度突然最近几个月又起来了。看些时间线

• 1 月 27 日，Kimi K2.5 发布，首次引入 Agent Swarm，官方博客的说法是能自主指挥最多 100 个子智能体。
• 2 月初，Claude Code 放出 Agent Teams 研究预览。官方建议的规模是 3 到 5 个 teammate，文档原话是"三个专注的 teammate，常常胜过五个散的"。
• 2 月 5 日，Cursor 讲他们编排"数千个 agent"协作开发一个真实项目，峰值一小时 1,000 次 commit，连跑一周，累计一千万次工具调用。
• 3 月中，Codex 的 subagents 结束预览正式放开，主 agent 带着 explorer / worker 一起跑。
• 4 月 20 日，K2.6 发布并开源，帮助中心把子智能体上限提到 300 个、单次任务超 4,000 次工具调用。
• 5 月下旬，Anthropic 又在 Claude Code 里上了 Dynamic Workflows，单次运行的 agent 总量上限写的是 1,000 个。
• 5 月 27 日，MiniMax 把自家 Agent 整体升级、起名 Mavis，同时上了 Agent Team，并写了一篇很实在的设计复盘。
• 7 月 20 日，Cursor 第二篇把同一个数推到了一秒 1,000 次 commit。

名字各叫各的。MiniMax 叫 Agent Team，一个 Leader 带几个固定角色的 Worker；Kimi 叫 Agent Swarm，官网写的是"无需预定义角色或手工设计工作流程"，最多 300 个；Anthropic 干脆都做，claude code即有传统的subagent（主agent把活分给多个subagent，每个subagent各做各的），也有agent team（预览功能，一个agent小组，互相干活互相通讯），也有dynamic workflows（可以调用上千个agent）。

目前市面上的 agent，大多还是 orchestrator-worker 那一套。Anthropic 的 deep research 是最标准的样本：一个主 agent 协调全局，把活派给一批并行跑的专用子 agent。但这半年，明显开始往外走了。

那单次任务能跑的 agent 数量上来之后，会发生什么？这篇分四章，最后再聊点个人感受。

第一章，多 agent 到底有哪些形态。 Kimi 按"协作风格"分了五类，LangGraph 按"拓扑"分了五种。

第二章，agent 之间怎么协同。 Evomap 那个实验最直接：同一个模型、同一批题，只换组织方式，差了 44 个点。然后看 MiniMax、Codex、Claude Code 各自的解法，最后是 Cursor------几千个 agent 改同一个仓库，冲突怎么办。

第三章，怎么把它原生训进模型里。 前面几家都在 harness 层写代码，Kimi 把编排能力直接 RL 进了权重。模型不会自己学会并行，它会偷懒退回单 agent，得专门设计一个奖励项把它逼出来。

第四章，怎么用agent激发真正的智能。（openai AIG路线的L4 创新者 Innovator） 前三章都是拿 agent 数量换速度换质量，这章想讨论的是，假如我们能同时派出上百个agent做科研探索任务，能不能做出真正 creative 的科研工作。

第一章 · 多 agent 到底有哪些形态

在看各家怎么做之前，先把"形态"这件事说清楚：多个 agent 凑在一起工作，到底有几种协作方式？有两套分类个人觉得比较直观。

LangGraph 的文档按拓扑分------消息在谁和谁之间流动；Kimi 的科普页按协作风格分------大家各自扮演什么角色。

LangGraph-按拓扑分的五种连法

LangGraph 文档里的多 agent 架构图。注意左上角的单 agent 不是一种多 agent 架构，是放在那儿做对照的基线；真正的五种是网状、主管式、主管式（把 agent 当工具调）、分层式、自定义

形态	消息怎么流	谁有权决定下一步
单 agent	一个 LLM 拿着一组工具，自己从头做到尾	它自己
网状（Network）	每个 agent 都能跟其他任意一个通信	任何一个 agent 都可以决定下一个叫谁
主管式（Supervisor）	每个 agent 只跟一个主管通信	只有主管
主管式（Subagent as tool）	上一种的特例：每个 agent 被包装成一个工具	只有主管，而且它用"调工具"的方式来决定调谁、传什么参数
分层式（Hierarchical）	主管之上还有主管	各层的主管，逐层往下
自定义（Custom）	每个 agent 只跟一部分 agent 通信	流程里有一部分是写死的，只有某些 agent 有权决定下一步

主管式（Supervisor）和主管式（Subagent as tool）可能有点绕。

Subagent as tool，是指主管不再用自然语言喊"接下来轮到检索 agent 了"，而是像调一个普通函数那样直接发出 检索agent(关键词="2026年Q1财报") 这种调用------agent 在主管眼里就是一个有名字、有参数、有返回值的函数。 好处是传了什么参数都是结构化的、程序能校验，不会像自然语言那样传着传着就走样。它跟上一行"主管式"的权力结构完全一样，差别只在主管派活时用的是"说话"还是"调函数"。

这张图把 "谁有权决定下一步"画出来了：网状是人人都有权，主管式是只有主管有权，自定义是一部分写死。而这条线，恰好就是后面几章各家分歧的根源。

Kimi-常见的五种多智能体架构

Kimi 是另一个切法，把生产系统里常见的组织方式归成五类。

架构	它回答的问题	怎么组织	原文给的例子
分层式	谁决定下一步	顶层主管拆解目标、把子任务派给下层专家，专家回传结果、主管综合	内容生产流水线：主管拿到一份选题简报，把"查资料"派给一个 agent、"起草"派给第二个、"编辑"派给第三个，最后自己在发布前审一遍整合稿。每个专家只管自己那一段，主管负责让整篇读起来像一个人写的
协作式	谁决定下一步	平级同伴，靠一块共享工作区（大家读写同一份东西），或者一条公共消息通道（谁有发现就往里播一条，其他人都收得到），实时共享工具、数据和中间结果	客服系统：一条投诉进来，一个 agent 做情绪分析、一个查订单历史、第三个起草回复，三者在同一个线程里边干边同步。因为发现都汇总在共享工作区，没有任何一个 agent 需要在脑子里装下完整的客户档案
对抗式	成员之间什么关系	内置相反的目标，让它们互相挑战	安全测试：红队 agent 往系统里注入畸形输入、把漏洞串起来打，蓝队 agent 在每个入口冒出来时检测和修补。单个"审核 agent"只朝一个目标努力时容易漏掉的边缘情况，会在这种交锋里被逼出来
异构式	成员长得一样吗	不同能力、不同模型、不同工具的 agent 混编	金融分析流水线：一个轻量的快速分类器高频扫实时行情里的异常，一个大模型写宏观评论和风险判断，第三个专门去调外部 API 取数据。每个 agent 都为自己那摊活用"恰到好处"的模型和工具
基于图	流程写不写出来	agent 和步骤都是图上的节点，每条边定义下一步跑什么	深度研究：先做一轮广撒网的搜索，再分叉出若干子主题并行深挖；初步发现不够充分就绕回去再收集一轮；只有质量过线才进入最终综合

看懂这张表的关键，是认清哪几行在同一个维度上：

• 分层式和协作式是一对，区别就一条：分层式里"下一步谁干"是主管说了算，协作式里是成员自己看着办。对着上面 LangGraph 那张图，前者是主管式，后者是网状。
• 对抗式根本不在这个维度上。 它问的是另一码事：这两个 agent 的目标是不是打架的------一个分层式系统里完全可以塞进一对红蓝队。
• 异构式关心的也不是拓扑，是成员配置。 这一条既是效果问题，更是成本问题------第二章 Cursor 那笔 8 倍的账，讲的就是它。
• 基于图跟前四类的关系最微妙。 前四类讲的是"这群 agent 长什么样"，它讲的是"这套流程有没有被提前画出来"。回头看上面那个深度研究的例子：先搜一轮、再分头深挖几个子主题（这是分支），发现材料不够就绕回去重搜（这是循环），质量够了才往下走综合（这是条件判断）。如果你只能写成"第一步、第二步、第三步"这样一条直线，这三件事一件都表达不了；画成图------节点是步骤，边上标着"什么情况下走这条"------才装得下。

所以它们是可以叠着用的，后面几章出场的每一家都是混搭：

• MiniMax 那套 Leader / Worker / Verifier，同时是分层式（Leader 派活）和对抗式（Verifier 专挑 Worker 的错）。
• Cursor 是分层式，而且层数是跑起来才决定的------上面的 planner 觉得活还能再拆，就现场生一个下级 planner 出来。
• Kimi 的 Agent Swarm 也是分层式，但它连角色表都不预先写，orchestrator 一边跑一边把子 agent 造出来。所以它恰恰不是"基于图"------图压根没被画出来。
• Claude Code 的 Dynamic Workflows 是这里面唯一真正"基于图"的一个：它干脆让 Claude 把整张图写成一段 JavaScript 脚本。
• 第四章还会出现一家叫 Apodex 的case（陈天桥投的那家，原名 MiroMind），它三样都占------分层、对抗，再加一堆不同职能的异构子 agent。

形态就讲到这儿。但光有形态还不够------真正难的是这些 agent 凑到一起之后，context怎么传递。

第二章 · agent 之间怎么协同（context engineering）

Evomap-同一个模型下，三种组织方式的对照实验

Evomap 这家公司（EVOMAP PTE. LTD.，新加坡注册）。它既不做模型也不做 coding harness，做的是 agent 的"经验基础设施"------核心是一套叫 GEP（Genome Evolution Protocol） 的协议，把某个 agent 验证过的有效做法打包成可继承的"基因胶囊"，别的 agent 直接拿去用，官网口号是"一个 agent 学会，一百万个继承"。在这之上它也做 agent swarm 平台，下面实验里的 EvoX 就是它自家的蜂群实现。

实验一：只换组织方式，能差多少

《From 26% to 71% with the Same Model: How an AI Swarm Wins》（同一个模型，从 26% 到 71%：AI 蜂群是怎么赢的）。设置也很朴素：同一个模型（Claude Haiku 4.5）、同一批 563 道题、同一套判分规则，只换组织方式。

三种模式的差别是这样的：

• single-context（单上下文）：一个 agent 从头做到尾，563 道题全塞在同一个对话里。做到后面，前面的题早被挤出记忆了。
• Sub-Agent 模式：一个主协调 LLM 先把题分成几摞派给子 agent；子 agent 做完，用自然语言写一份报告交回来；主协调 LLM 读完所有报告，自己整理出最终答案表。
• EvoX swarm：拆到不能再拆------一题一个 agent，各自把答案写到指定位置，最后由一段程序按题号把答案捡起来拼成表，没有任何模型再读一遍、总结一遍。

记住第二种和第三种的唯一分野：最后那步汇总，是模型干的，还是程序干的。 后面 32 个点的差距，全在这里。

原文的三种模式叫 EvoX swarm、Sub-Agent mode、single-context mode。左边 EvoX swarm 是把任务尽可能拆成原子单元、每题一个独立 agent；中间 Sub-Agent 模式是一个主协调 LLM 拆活、子 agent 各自汇报、主协调 LLM 再汇总；右边 single-context 就是一个 agent 在同一上下文里做完全部

Figure 2：563 道题的构成------250 道 MATH、150 道 UGPhysics、100 道 ZebraLogic、63 道 AIME / HMMT 竞赛题

同模型同题集，single-context 26.29%、Sub-Agent 模式 38.54%、EvoX swarm 70.69%--70.87%

单上下文到 Sub-Agent 涨 12 个点，符合直觉------上下文不打架了。但 Sub-Agent 到 swarm 又涨 32 个点，同一个模型、同一批 563 道题，在 EvoX swarm 里最终答对 398 道，在 Sub-Agent 模式里只答对 217 道。

原文里细拆，这 180 道的差距不是子 agent 算不出来。原文往回追了一层：Sub-Agent 模式的子 agent 在中间环节做对过 373 道------离 398 已经不远了。但这 373 道里，只有 207 道原样活到了最终交付，166 道在传递过程中变成了错的、或者干脆没了，保留率 55.50%。（最终那 217 = 活下来的 207 + 另外 10 道中间答错、在汇总环节反而被扳回来的。）

一句话：不是子 agent 算错了，是子 agent 算对了、然后用自然语言汇报给协调者、协调者再理解一遍、再总结一遍------在这个传递链路上丢掉了。

Sub-Agent 流水线里丢掉的正确答案------中间阶段判对 373 道，其中 166 道在传递过程中变成"错误或缺失"，只有 207 道活到最后

EvoX 的解法是：任务拆成边界尽可能清晰的原子单元，每个单元一个隔离的 agent，结果写到指定位置，再由主 agent 自己写的一段程序按题号把答案收上来------注意是"写一段程序去收"，不是"自己读一遍再总结"。没有第二个模型重写结果，也没有一个中心角色决定哪些答案该留。用原文的话说：汇总这一步，不再依赖"重新理解一遍"。

让模型做汇总，等于在系统最后一环塞了一个有损压缩器。

实验二：让 agent 自己挑伙伴

它的第二个实验换了个角度。

实验一 Agent Swarm 完整的拆解是脚本保证的------原文自己也承认，现实任务很少像 563 道独立题这么整齐："有些部分互相依赖，有些需要不同专长，有些是执行过程中才产生的，还有些会失败、冲突、重复。"所以剩下一个更难的问题：能不能从"脚本提供完整分工"，走到"agent 自己发现专长、认领任务、挑选伙伴、调整组织"？

实验设置分两段。第一段是让身份先长出来：24 个配置完全相同的 agent 去做题，每做完一道就把"这类题我学到了什么"写进持久记忆；在某一类上积累得越多，下一轮就越可能继续挑那一类。跑满 8 轮之后，系统用它们的实际选择和成绩生成两条身份信息：专长画像和准确率。

以 agent-8 为例，它的起点跟其他 23 个一模一样，但 8 轮里它挑了 5 次物理、2 次普通数学、1 次竞赛数学，最后长成"物理 0.625 / 数学 0.25 / 竞赛数学 0.125"、准确率 0.25 的样子。这个"物理型"身份不是提前写进角色表的，是它自己选出来的一段个人史。

第二段才是组队：24 个 agent 从同一张"圆桌"关系网出发（每个连着左右各两个，共 4 条关系），实验随机断掉一些边，让受影响的 agent 从没连过的候选里挑一个新伙伴。三个组的初始 agent、被断的边、候选集完全相同，唯一的变量是挑伙伴时它能看到什么------只看连接关系；连接关系加上专长画像和准确率；以及不做偏好判断、由系统随机重连的对照组。

不同可见信息下的伙伴选择。只看社交关系时，agent-8 挑了有四个共同连接的"熟人"agent-7（准确率 0.25，但它当时看不到这个数）；能看到专长画像和准确率之后，同一个 agent-8 转而去找了没有共同邻居、但准确率 0.75、专长互补的 agent-2

原文用统计模型给每一种择友倾向拟了个系数，数越大表示"越倾向于这么挑"，接近 0 就是"基本不看这个因素"：

• 只给社交信息时，"找朋友的朋友"是压倒性的最强偏好，系数 +2.28------它能看到的只有关系网，那就只能按关系网挑。
• 一旦把专长画像和准确率摆上台面，同一个偏好掉到 +0.19，等于消失；接替它的是"找准确率高的"（+1.88）和"找专长互补的"（+1.47）。

网络的形状也跟着变了。衡量"抱团程度"有个指标叫聚类系数------你的朋友之间彼此也是朋友的比例越高，这个数越大，直观上就是"小圈子有多密"。只看社交信息时它是 0.53（明显在抱团）；能看到任务信息之后掉到 0.28，而完全随机乱连的对照组是 0.27。

注意原文的结论不是"组织是涌现的"，恰恰相反------组织不会凭空出现；你让 agent 看到什么信息，就决定了这个系统奖励什么样的连接。 原文还有一句更硬的：自由分工不等于没有规则，你越希望 agent 自主，底层协议就越得可靠。

MiniMax-单 agent 的毛病，与一个不是模型的 Team Engine

《MiniMax Agent Team: Built for Long-Running Tasks and Continuous Evolution》（2026.5.27）重点不在"我们做了 Agent Team"，而在"为此付了什么代价"。它先列单 agent 的几个毛病：

一是在你没预期的时刻停下。派一堆事，做完三件就开始汇报："我已经完成了 1、2、3，要不要继续？"原文把这归因于模型普遍存在的"上下文焦虑"------怕自己撑不到最后，索性早点交差。

二是越跑越傻。原文的说法是，用户会感觉它从"一个聪明助手"慢慢变成"我在带一个很忙但容易分心的人"。原因也简单：只要有一步跑偏了，后面所有步骤都会顺着这个偏差继续往下生成。

三是长任务跑起来之后一直没有回音。注意原文抱怨的不是"任务跑得久"------它整篇的立场恰恰是长任务本来就该跑很久------而是连一句"收到"都等不到：用户在 IM 里发完消息，是按"几秒内该有反应"来期待的，哪怕任务复杂，也想先听到一句"收到，我打算这么干，干完回来找你"，而不是盯着对话框十分钟、半小时，连任务有没有开始都不确定。"我的 Agent 怎么不回我"，是他们收到最多的一类用户反馈。

单 agent 的自检是个闭环------它产出内容，然后回头检查自己刚造出来的现场，没有相互制衡，偏差就沿着同一条线一路累积下去

单 agent 在产出最终结果的时候，不可避免地既是运动员又是裁判。它可能很诚实地做了一遍自检，但它检查的那个对象，就是它自己刚刚造出来的现场。原文的措辞是单 agent 很难形成天然的相互制衡。

三个角色，外加一个不是模型的 Engine

三个角色本身不新鲜：Leader 把用户目标翻译成任务结构，Worker 干活，Verifier 验收。Worker 和 Verifier 是明确的对抗关系，原文的比喻是公司里的研发和 QA------两边都想把活干完，但一边干完，恰恰是另一边开工的信号。

真正的设计重心，在中间那个 Team Engine。先说它不是什么：它不是又一个 agent，不是"再叫一个模型来当调度员"。它是一段普通的、写死的代码------同样的输入永远给出同样的结果，不会像模型那样这轮这么判、下轮那么判。

Leader 拆出 Plan 交给 Team Engine，Engine 按 batch 调度、同批 task 并发跑，每个 Worker 配一个 Verifier 对抗，retry 到 PASS 才推进下一批，最后打包成 CycleReport 回给 Leader 决策

这张图里有几个正文没展开、但很能说明设计取向的细节：Plan 内部按 depends_on 切成多个 batch，同批并发、跨批串行；Engine 控制 max_concurrency（同批最大并发）和 max_cycles（最多重试几轮）；Leader 平时不介入每个 task，只在每轮 CycleReport 上做 accept / reject / override_accept / manual_retry，高风险的才 escalate 给人。

任务在 Engine 里走 producing → verifying → done 三个状态（图上那条更完整的链路还带了前置的 blocked / ready），verify 失败时 Engine 把 producing 节点重新唤醒继续改。

正文里另外补了一句，跟图上"Leader 不事无巨细介入"可以合起来读：Leader 全程能拿到 Engine 的最新状态，可以主动确认任务细节，甚至给正在跑的 Worker 或 Verifier 补一段 prompt；而在合并代码、覆盖生产数据这类高风险动作前面，最终判断必须由人签字。

它还专门画了一张图，对比"传统 Task 工具"和这套 Agent Team 的区别：

左边是传统的 task / dispatch / spawn 工具：传一段 prompt 进去，等一段文本出来，调用即终结------子 agent 不能反问主 agent，中途遇到阻塞或矛盾也没法实时上报，只能在最终 return 里体现。右边是状态机 + 消息通道：blocked → ready → producing → verifying → done，而且 finished 之后仍然能接收

左边那一栏的四条"能力边界"，其实就是前面那个"有损压缩器"的机制层解释：问题不只是返回值被压缩了，而是发现不对的那一刻，信息根本没有通道传回去------等它写进 return 的时候，已经是事后总结了。

原文有一句总结这套东西的话很到位：多 Agent 系统是一个运行时（runtime），而不是把提示词编排一下。

多 agent 的三种成本

原文把多 agent 的额外开销拆成三块：

• 交接成本：同一份信息要在 agent 之间重新组织一遍。它的做法是落成文件------可读的交接文件，加一块跨 agent 的共享记事板，Worker 之间通过"文件路径 + 摘要"慢速通信，而不是把东西一次性塞进上下文。补一句：慢速的文件通道之外，原文还留了一条 agent 间通信的 CLI，agent 可以直接跟其他正在跑的节点说话------所以 MiniMax 这套并不是纯星型，Worker 之间是有直连能力的，只是默认走那条慢的。
• 共享成本：让每个 agent 都看到全部信息是要付钱的------每多共享一段内容，每个 Worker 的每一轮都要为它多烧一遍 token。
• 汇总成本：这条是原文说得最狠的一句------并行收集 10 份材料很容易，把它们合成一篇事实一致、引用对得上、风格统一的文章很难。承认这件事很贵，是设计一个 Team 的第一步。

第三条正是 Evomap 里提到的sub-agent形态的弊端。原文还强调这一步 Leader 的活是"把 10 份并成 1 份"，而不是"再叫几个人多产一点材料"。

它还引了一篇叫 Cost of Consensus 的研究，结论是：多 agent 的 token 消耗能到基线的 2.1--3.4 倍，准确率却没涨，有时还更差。

但这个数有前提：

• "同质化辩论"指的是最朴素的那种多 agent 玩法------开几个一模一样的模型，给同一个问题，让它们互相看对方答案、来回辩论直到达成一致。大家能力相同、视角相同，辩到最后往往只是彼此附和，多烧的 token 换不来新信息。
• "独立自我纠错"是拿来对比的基线------一个 agent 自己答完、自己回头检查一遍、自己改。

所以这个 2.1--3.4 倍量的是"多开几个一样的 agent 互相吵架"有多不划算，它并没有证明"角色分工明确、有验收、有停止条件的多 agent"不划算------而后者恰恰是 MiniMax 这套要做的事。原文的评语是：没有结构、没有停止条件的"更多"，只是把不确定性并行地摊开而已。

角色专业化不是换个 prompt

Code / Research / Doc / Data / Project 各是一个 agent，每个的 Tools、Context、Memory、Skill 都各自独立；底下那条飞轮是"高频接触 → 踩坑写进 Memory → 抽象成 Skill → 越变越好

靠 Skill 让单 agent 临时扮演不同角色，跟真正的角色专业化不是一回事。后者至少有四个维度------不同的工具、不同的上下文、不同的记忆、不同的 skill，而且从结果侧看，输出协议和验收标准也不一样。

文末给了一条判断标准，可以拿来回看前面几家、也用来看后面几家：

判断一个多 Agent 产品有没有价值，别看它能同时起多少个 Agent。看它能不能回答这几个问题：为什么拆、怎么验、什么时候停、失败怎么恢复、记忆怎么管。

原文还补了一句：这几个问题答得越清楚，它就越像一个生产系统；答得越含糊，就越像一个"演示用的群聊"。

OpenAI Codex-只做了最轻的一层 subagent

个人觉得在agent这块openai做得相当保守。当claude code都在实验多种类型的agent协作时，openai 3月份才推出subagent，而且默认是不开启，只有当用户在指令里明确说请用subagent时，codex才会明确调用。

Codex 的 subagents 内置三种：explorer（read-heavy 的代码库探索）、worker（execution-focused，负责实现和修复）、default（兜底）。

内置三种，区别就在"准不准改你的代码"：explorer 只读不写，专门翻代码库、搞清楚现状；worker 是真动手的那个，负责写实现、改 bug；default 是兜底的万金油。

自定义 agent 就是一个个配置文件，放在 ~/.codex/agents/（只对你自己生效）或项目里的 .codex/agents/（跟着仓库走）。每个必填三样：name（叫什么）、description（什么时候该用它）、developer_instructions（它的行为准则）；还能选填用哪个模型、思考多深、沙箱权限、挂哪些 MCP server、开哪些 skill。

拓扑是标准的星型------画出来就是一个中心点连着一圈外围点，所有子 agent 只跟中间那个主 agent 说话，彼此之间没有连线。而且是同步的：主 agent 把活派出去之后就在那儿等，等到最后一个子 agent 也交了活，才把所有结果并成一份回答返回。

有一点要说清楚：文档从头到尾只描述"主 agent 派活、主 agent 收活"，没给子 agent 之间提供任何互相说话的手段------但它也没有明文禁止，是只字未提。派活的触发也保守：在 ChatGPT Work 里，只有最高的 Ultra 智能等级会主动委派，其他等级都得你开口要；本地的 CLI 和 IDE 插件则是你直接要求、或者项目的 AGENTS.md / skill 指令写了要求，它才会派。

Anthropic Claude Code-三种并存的多 agent 形态

Claude Code 是这几家里唯一把"多 agent"拆成三种并存产品形态的。

Subagents：派出去，汇报回来

大家最熟悉的形态：主 session 把活派出去，子 agent 干完把结果汇报回来，子 agent 之间不说话。跟上一节 Codex 那套基本是同一个东西。

每个 subagent 有自己独立的上下文窗口，翻代码翻出来的几万行、试错试出来的一地报错，全都留在它自己那边，主 session 只收一句结论。

但也正因为如此，它有个绕不开的天花板------那句结论最后还是要落进 Claude 的上下文窗口里。派 3 个还好，派 200 个，主 session 一样会被撑爆。这就是后面 Dynamic Workflows 要解决的问题。

Agent Teams：teammate 之间能直接说话

一个预览的试验性功能。

官方文档专门画了张图讲区别：左边 subagent 是主 agent 派出去、干完把 Result 汇报回来，彼此不说话；右边 agent team 是一张共享任务清单，teammate 自己认领、互相直接通信

机制上：

• 每个 teammate 都是一个完整独立的 Claude Code 会话------你可以理解成又开了一个跟你自己那个一模一样的 Claude Code，有自己独立的记忆空间，而不是主 agent 顺手派出去的一个小工具。它开机时会像正常启动一样把项目那套家当读一遍：项目说明文件（CLAUDE.md）、你挂的外部工具、你装的技能包。但有一件事它拿不到：你和 lead 之前聊的所有对话，它一个字都看不见。 所以派活的时候，背景得在派活那句话里重新交代一遍，别指望它"你懂的"。用户可以绕过 lead 直接跟某个 teammate 对话------方向键选中、Enter 进去发消息、Esc 打断。
• 通信走 mailbox，实现是 ~/.claude/teams/{team-name}/inboxes/{agent-name}.json 这样一个 JSON 文件，消息自动投递，lead 不用轮询。这里有个细节：{team-name} 不是你起的名字，是会话派生的------session- 加上 session ID 的前八位。
• 共享任务清单带依赖关系和文件锁：多个 teammate 同时抢一个任务时靠文件锁防竞态，前置任务完成后被阻塞的任务自动解锁。不过文档自己在限制那一节里补了一刀：任务状态会滞后------teammate 有时候干完了忘记把任务标成完成，结果就把依赖它的任务一直卡在那儿。
• 可以要求 teammate 先出计划再动手，lead 审批不通过就打回重写。而且这个审批是 lead 自主做的，不会来问你------文档说这是权限模型里唯一一个设计好的例外。
• 你还可以往三个关键时刻插一段自己写的小程序（官方叫 hook，钩子）当质量门。规矩很简单：这段程序跑完，如果以状态码 2 退出，就等于投了反对票，Claude Code 会拦下这个动作，并把你程序打印的话转达给对应的 agent。三个时刻的"反对"含义各不相同------插在 TeammateIdle（某个队友准备收工闲着了）上是"别下班，接着干，理由如下"；插在 TaskCreated（正要新建任务）上是"这个任务不许建"；插在 TaskCompleted（正要标记完成）上是"不算完，回去重做"。比如你可以写一句"测试没跑过就不许标完成"，然后它对每个队友都生效。

限制也不少：

• 默认是关着的。 这还是个实验功能，得先设一个环境变量CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 才打得开。
• 团队不能套娃。 teammate 不能再拉起一支自己的队伍，建队、招人永远只有 lead 说了算。（它倒是可以派自己的一次性 subagent，只是不能让那个 subagent 挂在后台跑。）
• 队长身份定死。 lead 永远是你最开始开的那个会话，中途不能把队长让给别人。
• 会话恢复救不回队友。 默认模式下（所有队友挤在同一个终端里跑），/resume（恢复会话）和 /rewind（回退）都不会把队友一起恢复；更尴尬的是恢复之后，lead 可能还在继续给一群已经不存在的人发消息------这时候直接让它重新招一批就行。
• 一个会话只能带一支队。

官方建议是 3-5 个 teammate、每人 5-6 个任务，文档原话是：三个专注的 teammate，常常胜过五个散的。

Dynamic Workflows：把计划挪进代码

《Orchestrate subagents at scale with dynamic workflows》做法是：Claude 现写一段 JavaScript 脚本，由一个独立的 runtime 在后台执行，用户会话保持可用。脚本里 agent() 派一个子 agent，pipeline() 对一个列表逐项派。官方原话是：workflow 把计划挪进了代码里。

而它后面紧跟的那句才是关键：

用 subagent、skill 和 agent team 的时候，Claude 本人就是那个编排者：它一轮一轮地决定下一步派谁、分什么活，而每一份结果最后都要落进某个上下文窗口。而 workflow 脚本自己攥着循环、分支和全部中间结果，所以 Claude 的上下文里只剩下最终答案。

中间结果落在脚本变量里，不落在 Claude 的上下文里。

举个具体的例子。假设你要扫 200 个文件，找出同一类 bug：

• 用 subagent：每个子 agent 查完一个文件，把结果汇报回主 session。200 份汇报全都要挤进 Claude 的上下文窗口，扫到一半就撑爆了，于是它只能边扫边压缩、边丢细节------Evomap 那 166 个丢掉的答案就是这么没的。
• 用 workflow：脚本里写一行 const results = await pipeline(files, f => agent(...))，那 200 份结果全都待在 results 这个 JS 变量里，Claude 从头到尾没看过它们。最后进 Claude 上下文的只有一句"发现 7 处，在这几个文件"。

差别不在于派了几个 agent，而在于中间那 200 份东西有没有从模型脑子里过一遍 。这一下就把前面那个有损压缩器从主链路上摘掉了。

规模上：最多 16 个并发 agent（CPU 核少的机器会更少），单次运行总量上限 1,000 个。默认规模建议是 medium（15 个以内），可在 /config 改成 small（5 个以内）或 large（50 个以内）------注意这是"建议"不是硬上限，prompt 要求的规模不一样时会覆盖它。单次排到 25 个以上 agent、或预估 token 超 150 万，任务面板会挂一个 Large workflow 警告，但它纯属提示，不暂停也不限流。25 这个门槛还跟着设置走：你要是自己在 /config 里挑过档位，门槛就换成那个档位的数（挑了 small 就是 5），只有沿用内置默认才是 25。

内置的 /deep-research 是个现成的样本：扇出搜索、抓取、交叉核查、对每条 claim 投票，没通过交叉核查的 claim 直接从报告里滤掉。还有一条细节很讲究------verifier agent 因为限流或 API 报错检查不了某条 claim 时，报告会把它标成"未验证"，而不是当成"被推翻"。

跑完还能把这套流程存下来，下次一条命令复用。注意存下来的是什么------能复用的不是 worker 的定义，是那套编排本身，这是它跟前两套最大的区别。

官方对比表：谁持有计划

文档里这张表用的划分标准只有一个：计划握在谁手里。

	Subagents	Skills	Agent Teams	Workflows
它是什么	Claude 派出的一个 worker	Claude 遵循的一段指令	lead 监督一组平级 session	runtime 执行的一段脚本
谁决定下一步跑什么	Claude，逐轮决定	Claude，照着 prompt	lead agent，逐轮决定	脚本
中间结果存在哪	Claude 的上下文窗口	Claude 的上下文窗口	共享任务清单	脚本变量
可复用的是什么	worker 的定义	那段指令	team 的定义	编排本身
规模	每轮几个	同上	少量长跑的 peer	每次几十到几百个 agent
被打断之后	整轮重来	整轮重来	teammate 继续跑	同一会话内可续跑

表看着抽象，落到具体场景挺好分的：

• Subagents------一次性的脏活。 比如"把这个仓库里所有用到 moment.js 的地方找出来"。派三个出去分头翻，各自回一句话，主 session 汇总完就散了。它们之间不需要商量，你也不用中途插手。
• Skills------同一套动作反复做。 比如"每次写周报都按这个格式、先查这几个数据源、最后附一张表"。这压根不用多开 agent，它就是一份写死的操作规程，Claude 照着走。所以它的规模跟 subagent 一样，但复用的是那段指令本身。
• Agent Teams------需要互相抬杠的活。 官方举的例子是"应用收到一条消息就退出了，派 5 个 teammate 各查一个假设，让它们互相证伪"。关键在于它们得能互相说话------一个人挖到的线索要能当场推翻另一个人的结论。跨层改动也算：前端、后端、测试各归一个人，谁改完通知谁。
• Workflows------又多又重复，而且你不想让中间过程弄脏上下文。 官方给的例子是全仓库扫一遍 bug、500 个文件的迁移、一个需要交叉核查来源的研究问题。共同点是同一个动作要在几百个条目上各跑一遍，而你只想要最后那份结论。

一句话版的选法：成员之间要不要互相说话？要 → Agent Teams；不要但量很大 → Workflows；量不大、一次性 → Subagents；压根不用多开 agent、只是同一套流程反复走 → Skills。

真要上规模时，它放弃了团队形态

在 Anthropic 自己的文档里，Agent Teams 并不是它推荐用来上规模的那一套。 那张四方表里，agent teams 的规模一栏写的是"少量长跑的 peer"，真正做几十到几百个 agent 的是 Workflows。

而 Workflows 的拓扑恰恰又回到了星型：agent 之间不直接说话，中间结果由脚本收拢。当 Anthropic 要把规模推上去的时候，它主动放弃了"团队"这个形态，换成了跟 Codex 更接近的结构------只不过把中间那个协调者从"模型逐轮判断"换成了"一段确定性的脚本"。

所以更准确的说法可能是：

• Codex 只做了一种形态，对应 Anthropic 表格里 subagents 那一列；验证、角色分工这些都留给用户自己用 TOML 配。
• Claude Code 做了三种，并且划了适用边界：文档给的二选一标准就一句话------你的 worker 之间需不需要互相说话。需要一批干活快、目标明确、干完汇报就走的，用 subagent；需要成员之间共享发现、互相质疑、自己协调的，用 agent team。
• "更像团队"和"更能扛规模"在当前的工程现实里是两件事，而且方向相反。 团队形态的成本在于每个成员都是一个完整 session、通信是 N×N；规模形态的前提则是你得先把任务拆成互不相干的原子单元。

两家同时画出的一条红线

这一节最值得注意的，是两家在同一件事上给出了相同的警告。

Claude Code 的 Agent Teams 文档在讲适用场景时写道：

agent team 会带来协调开销，token 消耗也远高于单个会话。它最适合的场景，是 teammate 之间能各干各的。至于那些必须按顺序做的任务、要改同一个文件的任务、以及依赖关系很多的工作，用单个会话或者 subagent 反而更有效。

Codex 的文档在讲"什么活适合派子 agent"时写道：

一开始，先把并行 agent 用在读密集的活上------探索代码、跑测试、做分流、写摘要。写密集的并行流程要更小心，因为多个 agent 同时改代码会造成冲突，也会推高协调开销。

Anthropic 那篇 deep research 的工程博客也承认：

有些领域要求所有 agent 共享同一份上下文，或者 agent 之间存在大量依赖，这类场景在今天并不适合多 agent 系统。

同一份文件的编辑、依赖很多的工作------Claude Code 和 Codex 这两个包在模型外面的 agent 工具，都在自己的文档里劝退了。 不过三家的力度不一样：Anthropic 那篇博客说得最重，直接讲这类场景"今天并不适合多 agent"；Codex 说的是"要更小心"；Claude Code 则是建议你退回单会话或 subagent。

那有没有人硬闯这条线？有。

Cursor-上千个 agent 改同一个代码仓库

在我过往的认知里，多 agent 适合的是并行调研这类任务：同时查 50 个 benchmark、同时分析 500 个作者的文风。结构相同、互相独立、单个不难，天然适合 map-reduce。

但写作和代码生成这类活，我一直觉得不合适。理由很直接：你让几个 agent 去改同一个代码仓库，冲突是必然的。

人类团队靠"一个人负责一个模块"、"改之前先说一声"和"资深的工程师负责解决冲突"。但几百个 agent 同时动手、还谁都不跟谁说话，就很难办了，所以那会儿的结论是"这类任务还是单 agent 老老实实做"。

可基模越来越强，而想上多 agent 的理由又很朴素：我们就是要快啊。 10 分钟并行写完一个代码仓库，和 60 分钟串行写完，这中间的差别不是效率的百分比，是能不能改变工作方式。

所以问题就变成了：那冲突到底怎么解决？

Cursor 今年发的两篇博客有做这方面的尝试。

架构是迭代出来的，不是设计出来的

《Towards self-driving codebases》（2026.2.5）讲他们怎么让大量 agent 协作开发一个真实项目：

• 累计编排了好几千个 agent。不过要注意另一个数：单次运行同时在线的峰值是几百个，原文说大多数 run 都在几百个 agent 这个量级上封顶。
• 峰值约 1,000 commits/小时，连跑一周，累计约 1,000 万次工具调用，而且"一旦启动就不需要我们任何干预"。

架构是迭代出来的，不是设计出来的，这个演进过程比最终形态更有信息量。

往下看之前，先跟大家把几个角色名说清楚------后面四版翻来覆去，就是在调整它们的关系：

• planner（规划者）：拿着目标，决定"这事该拆成哪几件"，自己不写代码。
• worker（干活的）：领一件具体的活，把它做完，不关心别人在干什么。
• executor（执行主管）：介于两者之间，负责盯着计划落地、派活、验收。
• judge（验收员）：干完之后单独跑一遍，判断"这算做完了吗"。

套项目组来理解就行：planner 是只出方案不动手的人，worker 是照着工单干活的人，executor 是项目经理，judge 是 QA。 Cursor 迭代了四版，就是这几个岗位怎么被增、被删、被合并。

第一版：一堆平级 agent + 一个共享状态文件加锁。

四个地位相同的 agent，全都去读写中间那一个 Coordination File

思路很直觉：既然大家要协调，那就搞一个共享文件写清楚"谁在干什么"，加锁防止互相踩。

问题一，模型不懂锁。 原文说 agent 会把锁攥太久、会忘了释放、会在不该加锁解锁的时候乱来------它们压根不理解"持有一把锁"这件事意味着什么。 结果是 20 个 agent 的吞吐量掉到 1--3 个的水平，绝大部分时间都耗在等锁上。

问题二：没有结构的时候，没有一个 agent 愿意接大活。它们全都在规避冲突，专挑小的、安全的改动做，谁也不为整个项目负责。这个副作用不是性能问题，是责任问题------你以为你有 20 个开发，实际上你有 20 个只肯改错别字的人。

第二版：引入 planner / executor / worker / judge 四个角色。

Planner → Executor → Judge 串成一个闭环，judge 判完再转回 planner；右边那一排 worker 跟 executor 之间收发事件

既然平级不行，那就上角色。planner 先把做法和交付物定下来，交给 executor 当唯一的主事人，executor 再派 worker 去干，最后由一个独立的 judge 在 executor 收工后跑一遍验收。

这一版好了不少，但撞上两个问题。

一是整个系统被最慢的那个 worker 卡住。 原文的评价很直接：太僵硬了。

二是所有规划都在最前面一次性做完，等真跑起来发现新情况的时候，系统很难再动态调整------而在一个真实项目里，"跑着跑着发现事情不是那样"几乎是常态。

顺带说两个被砍掉的角色，理由都很实在：

• judge 被砍，是因为他们发现 agent 照着指令干到底这件事做得还不错，那就为了让系统简单点，去掉。
• 一个集中的 integrator 也被砍了，原因是它立刻成了明显的瓶颈------它当初被加进来，恰恰是为了做全局质量把关、顺便消化"太多 worker 同时推代码、解冲突、合并"的争抢。结果它立刻成了明显的瓶颈：几百个 worker，却只有一道所有产出都必须经过的关口，原文的评价是这就成了"繁文缛节"（red tape）。

第三版：砍掉独立的 planner，让 executor 兼做规划。

只剩一个带循环箭头的 Executor，直接跟每个 worker 收发事件------planner 和 judge 都没了

既然一次性规划太僵硬，那就让 executor 边干边规划。

结果 executor 开始出现各种病理行为：随机睡觉、把正在跑的 agent 停掉、自己动手干活、死活不肯多派任务（只肯派那么几个窄得不能再窄的）、不好好合并 worker 的改动、还没做完就宣布完成。

原因是它一个人被塞了太多角色和目标。

最终版：递归的 planner。

最终形态：一个 root planner 拥有全部 scope、自己不写代码，觉得可以再拆就派生 subplanner，递归下去；worker 不知道更大的系统存在、不跟任何人通信、在自己那份仓库副本上干活，做完写一份 handoff。所有产出统一落到 Git

最终形态是把"分层"这件事做成了递归：一个 root planner 拿着全部 scope，自己不写一行代码，觉得某块还能再拆就派生一个 subplanner，subplanner 再往下拆------planner 这一层可以长成任意深的树。树的最末端才是 worker：worker 不知道更大的系统存在，不跟任何人通信，干完写一份 handoff（交接说明）就走人。所有产出统一落到 Git。

这里有个机制值得单独说，因为它是后面所有冲突故事的前提：每个 worker 先给自己拷一份完整的代码副本，在副本里改，不直接动主仓库。 好处显而易见------你改你的、我改我的，改的过程中谁也碰不到谁，几百个人可以真正同时动手。但代价是，冲突并没有消失，只是被推迟到了"合回主干"的那一刻。

还有一条反直觉的原则值得单独拎出来：要显式地为吞吐量做设计，而不是为 100% 的正确性做设计。

他们试过"每一次提交前都必须完全正确"，结果是整个系统被串行化：只要有人手滑改了个接口、打错一个字，几百个 agent 就一起停在那儿等修好。改成允许一点松弛之后反而更快------因为每个 agent 都可以信任"这个毛病会有同事很快修掉"。代价是要专门留一条常绿分支，让一个 agent 定期打快照、在发布前统一收一遍尾。

冲突后来是怎么压下去的

但冲突（两个agent同时在改同一份代码）还是会存在，《Agent swarms and the new model economics》（2026.7.20）第二篇提到：

失效模式一：脑裂（split-brain）。 两个互不知情的 planner，在代码库的不同位置，用两套不一样的做法把同一个概念各实现了一遍。这不是"白干一遍活"那么简单------是这个仓库里从此并存两种互相打架的设计，而且谁都不知道对方存在。

解法是提示词层面的，两条：

1. 决策不许下放。 planner 自己把设计决定拍下来，而不是把"这块你自己看着办"派下去。道理很直白------一旦把"决定"派下去，下面两个人各拍各的，就一定不一样。
2. 拆活的时候保证不重叠。 要求 planner 在往下分子树的时候，确保任意两棵子树不会去决定同一个问题。

归拢起来就一条：把"做决定"和"干活"分开------决定必须在能看到全局的那一层做完，往下派的只能是实现，不能是决策。

失效模式二：planner 之间抢文件。 这个更难，因为两个 planner 知道彼此存在，却还是在同一批文件上来回改。原文：问题在于这里有两份互相矛盾的"现实图景"，而合并工具是修不了分歧的。 合并工具能解决"两个人改了同一行"，解决不了"两个人对这件事的看法不一样"。

举个例子（我编的，原文没给）：planner A 定了内部字符串统一用 UTF-8，planner B 定了用 UTF-16，各自往下派活。两摊代码各自都能编译、测试都过，合并时 git 一声不吭------因为他们改的压根是不同的文件，git 只比对行，不看意思。等到 A 的函数把结果传给 B 的函数，才炸。

解法是三步：

1. agent 把设计决策写进一份共享设计文档------不是塞在代码注释里，是单独一份 doc。
2. 依赖这个决策的代码，带一个能被编译器校验、并且能追溯回那份文档的引用。
3. 两个 planner 无意中互相矛盾时，一个 reconciler 去把文档合并掉，然后这些引用把结论传播到下游。

还是上面那个例子：A 把"用 UTF-8"写进一份决策文档，所有相关代码挂一个指回它的引用；B 写了矛盾的决策之后，reconciler 裁定 UTF-8 胜出、改掉文档------于是 B 那摊代码当场全部编译失败，它手下的 worker 撞上报错，顺着引用找到文档，跟着改。

第 2 步是整套机制的关键，但原文没说这个引用具体长什么样（是个常量？类型？注解？），只说了它"可被编译校验"。不过同一篇文章里另一处讲"僵化"问题时，用的是同一个思路，那段写得就具体多了------

他们发现 agent 有个毛病：在有人类参与的代码库里待久了，学会了"核心代码碰不得"，哪怕它确实该改。于是他们允许 agent 故意把编译搞坏：某个 agent 如果判断这处核心改动值得做，就可以越出自己的范围打一个补丁，并留一段注释说明为什么。然后编译器会把这个改动带到整个系统，所有依赖旧设计的地方全部构建失败；每一个撞上这些报错的 agent，都会顺着找到那段注释、读到理由，再把自己那块改成匹配的。

这就是"用编译器当广播机制"。 核心代码一改，所有依赖旧设计的地方立刻编译失败，谁都躲不过去------光留一段注释是做不到这件事的，因为没人会主动去读一段跟自己无关的注释。这里的分工是：编译错误负责把人拦下来，注释负责告诉他为什么。

失效模式三：合并冲突爆炸。 旧系统在被暂停之前（不到两小时）就累计了 7 万多次冲突，而且还在加速；最热的那一个文件吃掉 7,771 次冲突，被 1,173 个不同的 agent 碰过。

解法方法是：

• 一个中立的第三方仲裁 agent：冲突发生时它介入，代表所有相关方把冲突解掉。原文说它唯一的目标就是公正和高效，类似工程团队里的合并队列。关键在"中立"------它不是任何一方的 planner，所以不会偏袒。
• 自动拆分过大的文件：给 worker 一个"举报臃肿文件"的口子。一旦某个文件被举报，先冻结它的新提交，然后派一个外部 agent 把它拆成小模块。原文管这些膨胀失控的文件叫"巨型文件"，评价是：这些巨型文件会把一切都噎住。

这两件事之后，完整 4 小时的冲突降到 1,000 次以下，全库最热的文件只有 47 次。

同一个 Grok 4.5，v1（灰）在两小时内累计冲突冲到 7 万还在加速，v2（橙）跑满 200 多分钟几乎贴着 0

还有个数字特别能说明"忙"和"有产出"是两回事：旧 run 头两个小时产出了 68,000 次 commit，是新 run 节奏的 70 倍。 一种读法是它更高产，另一种读法是------那些 commit 大部分是 thrash、争抢和空转。包结构上也有物证：旧 run 摊到了 54 个 crate，其中有三个各自独立的 SQL 包；新 run 早早收敛在 9 个，之后再没加过。

还有一个我很喜欢的设计叫 Field Guide：一个完全由 agent 自己拥有的文件夹，index.md 会自动注入每个 agent 的开头，唯一的约束是行数预算。理由是：模型权重是冻结的，所以真正值得记下来的，恰恰是那些"没想到"的遭遇------这样下一个 agent 的路径就能短一点。

SQLite 实验：只给一份 835 页手册

实验设置排得很干净：只给一份 835 页的 SQLite 手册，不给源码、不给测试套件、不给二进制、不给联网，让 swarm 用 Rust 把手册的全部内容实现出来。评分用 sqllogictest（百万级已知答案的 query），而且swarm 从头到尾不知道这个测试套件存在；每次跑完他们还人工复查代码和运行过程，专门查有没有作弊和走捷径。

结果：4 小时截点上，新框架 73--85% 通过率，旧框架 11--77%（其中 Grok 4.5 的旧框架 run 在两小时之前就被暂停了）。

但这里有句比截点更重要的话：新框架的每一种配置，最后都跑到了 100% 通过。

代码量的对比更能说明问题：

同样的模型、同样的任务，Fable 5 组合从 64,305 行降到 9,908 行；Opus 4.8 组合从 19,013 行（97% 通过）降到 4,645 行（100% 通过）

少写四分之三到六分之五的代码，把同一件事做得更对------这比通过率涨几个点更能说明组织方式的价值。

钱到底花在哪

重建 SQLite 的成本按模型组合拆分，灰色是 planner、橙色是 worker

区间是 （混合配置）到10,565（GPT-5.5 全包），质量接近，成本差 8 倍。拆开看更夸张：GPT-5.5 全包那次，光 worker 就花了 ；而做、做那次，整个集群总共只花了411。

worker（橙）吃掉绝大部分 token，planner（灰）只是底下窄窄一条。但对照上面那张成本图看，这条窄的才是花钱的大头

worker 至少吃掉 69% 的 token，多数配置里超过 90%；但在 Opus + Composer 的组合里，作为 planner 的 Opus 只产生了很少一部分 token，却占了大约三分之二的成本。

Cursor 的结论是：一个大任务里，真正需要前沿智能的时刻其实很少------最初的拆解、设计决策、某些取舍，就这么几处。而一旦前沿模型把不确定性坍缩成了一条详细、明确的指令，后面的模型只要照着做就行了，用便宜的完全够。

它真正解决的其实是上下文效率

它自己给的解释我觉得比"并行"更准确：

左边是单 agent 走完整棵树，目标、子系统 A、B、C 一路往上堆，很快撞上下文上限；右边是 planner 只拿目标和一层 children，subplanner 拿一个 slice，worker 只拿一个 slice------每个人的上下文都很小

在蜂群里，planner 从来不写实现，所以它的上下文永远不会被底层细节填满；worker 从来不做规划，所以它能把全部上下文花在一小块活上。我们怀疑，蜂群之所以能上规模，靠的是这种上下文效率，而不是并行本身。

这句我觉得比"并行"这个词准确得多。

它还引了科斯的企业理论作类比：协调成本比工作本身增长得更快，所以组织会长成一层层有边界的单元，而不是让所有人跟所有人说话。

回到我最初的疑虑：冲突是真的会爆炸------两小时全库 7 万次，最热的那一个文件被 1,173 个 agent 轮番碰过。但它确实是可解的，靠的是仲裁 agent、自动拆文件、编译器可校验的决策引用，而不是靠模型变聪明。

第三章 · 怎么把它原生训进模型

Kimi-把并行编排训进模型权重（PARL）

PARL：只训 orchestrator，子 agent 冻住不动

K2.5 技术报告里这套训练框架叫 PARL（Parallel-Agent Reinforcement Learning），架构是解耦的：

PARL 框架采用了一个解耦的架构：一个可训练的 orchestrator，加上一批从固定的 中间策略 checkpoint 实例化出来、权重冻结的子 agent。 这个设计刻意避开了端到端 联合优化，为的是绕开两个根本难题：功劳归属说不清，以及训练不稳定。

先说角色。orchestrator（编排器）是总指挥------它拿到你的任务，决定要不要拆、拆成几块、每块交给谁；子 agent 是干活的------各管自己那一小块，互相不说话，干完把结果交回来。

再说"从固定的中间策略 checkpoint 实例化"。模型训练时会像打游戏存档一样，每隔一段就把当前参数存一份，这份存档就叫 checkpoint。Kimi 的做法是：从训练途中挑一个存档，把它当成子 agent 的固定人格，之后再也不动它。所有子 agent 都是这个存档的副本，只是被塞了不同的岗位说明书。

最后是"权重冻结"。模型的本事都记在一堆参数（权重）里，训练就是不停改这些参数；冻结就是把子 agent 的参数锁死不许改，整场训练只有总指挥在变聪明。

用一个比方最好懂：这是一支足球队，只练教练，不练球员。 球员的水平从第一天到最后一天完全没变，变的只是教练怎么排兵布阵。

为什么这么做，论文讲得很清楚：多 agent 场景里，基于结果的奖励天生稀疏又嘈杂------最终答案对，不代表每个子 agent 都没出错；答案错，也不代表所有子 agent 都错了。所以他们干脆把子 agent 的产出当作"环境观测"，而不是可以求导的决策点------把"高层的协调逻辑"和"底层的执行能力"拆开各归各的，论文说这样训练收敛得更稳。

serial collapse：模型会偷懒，退回单 agent

训一个可靠的并行 orchestrator 很难，因为子 agent 独立执行带来的反馈是延迟的、稀疏的、非平稳的。论文在这里同时防两种毛病：一种是不敢并行，一种是滥用并行。前一种有个专门的名字叫 serial collapse：

串行坍缩（serial collapse）------一种局部最优：orchestrator 默认退回到单 agent 执行。

"局部最优"这个词值得解释一下，因为它是理解后面那笔奖励的关键。

想象你在爬山，目标是最高峰。你现在站在一个小土包顶上：往哪个方向迈一步都是往下走，所以你不动了------但你离真正的山顶还差得远。这个小土包就是局部最优：周围都不如它，可它并不是最好的。

串行就是总指挥的那个小土包。一个人埋头干，虽然慢，但每一步都可控、结果也过得去；而"派 5 个人出去"这个动作在刚开始学的时候几乎必然翻车------派错人、拆错块、结果收不拢，分数当场变低。于是模型试了两次就学乖了：还是自己干吧。 从此再也不碰并行，也就永远学不会并行。

模型不会自己一头扎进并行，它的默认选择是退回一个人干。 所以得先用一笔额外的奖励，把它从这个舒适区里推出去------注意是"推出去探索"，不是"逼它永远并行"。论文说得很明确：并行本身不被预设为更优，到底要不要并行、什么时候并行、怎么拆，全都是靠环境反馈学出来的。

所以 PARL 给总指挥打的分是三个数加起来的：

• r_perf：任务层面的结果，评估解答的成功度和质量。
• r_parallel：实例化奖励，专门对抗 serial collapse------通过奖励"开子 agent"这个动作本身，逼它去探索并发调度的空间。
• r_finish：子 agent 完成率，防的是另一种作弊叫 spurious parallelism（虚假并行）------orchestrator 为了刷并行指标，疯狂开一堆没意义的子 agent。奖励"完成的子任务"就把这条路堵上了。

不用管符号，它读起来就是：总分 = 任务干得好不好 + λ₁ × 有没有真的并行 + λ₂ × 派出去的活有没有干完。 前面那两个 λ 是权重，就是"这一项在总分里占多少斤两"的旋钮。

而最关键的一笔在这儿：λ₁ 和 λ₂ 这两个旋钮，在训练过程中被一路拧到 0。

"退火"是从炼钢那儿借来的词------金属加热之后要慢慢降温，不能一下冷透；放到训练里就是"这个数值随着训练一点点往下调，不是说切就切"。

翻译成带队的话：新手期，教练每换一次人、每成功派出去一个活，都单独给他记一功，逼他习惯用团队；等他用顺了，这些奖励一点点撤掉，最后只剩一条------赢没赢。

这一笔退火是整套设计的关键。如果并行奖励一直留着，模型最后一定会学成"为了拿分而拆任务"；撤掉之后，训练末期它没有任何理由再去并行了，可它还在并行------说明这时候它是真的算明白了并行更划算，而不是在领奖金。

CriticalSteps：它优化的是关键路径

论文还定义了一个专门的计时单位，叫 critical steps（关键步数）。名字听着玄，讲的是一件生活常识：一件事由几拨人同时干，总耗时不等于所有人干活时间的总和，而是等于"每一轮里最慢那个人"的时间加起来。

就像装修房子：瓦工、木工、水电工同时开工，这一轮什么时候能结束，取决于最慢的那个工种，跟另外两个几点收工没关系。

公式就是这个意思：把一次运行切成若干轮，每一轮 = 总指挥自己花的步数（论文说通常就是 1 步，也就是"派活"这个动作本身）+ 这一轮里跑得最久的那个子 agent 的步数；所有轮加起来，就是关键步数。

举个数：一轮里派了 10 个子 agent，9 个各跑 5 步就回来了，第 10 个跑了 40 步。这一轮记 41 步，不记 86 步------因为前 9 个等第 10 个的时候，时间并没有白流走。

反过来说，如果这 10 个人的活拆得均匀、每人 8 步，这一轮就只有 9 步。 同样的总工作量，耗时差了四倍多，差别全在"最长那条腿有多长"。

这个指标很讲究：

如果只是拼命多开子任务，却没能缩短并行组里最长那条的执行时间，在这个指标下几乎没有收益；反过来，均衡的任务拆解只要缩短了最长的那条并行分支，就能直接降低 critical steps。

开一堆子 agent 但没缩短最长那条分支，在这个指标下几乎没有收益。所以 orchestrator 被引导去最小化端到端延迟，而不是最大化并发数或总工作量。

训练数据也是围着这个设计的：合成的 prompt 分两类，wide search（需要同时探索很多独立信息源）和 deep search（需要多条推理分支、延迟聚合），另外掺了长文档分析和大规模文件下载这类真实负载。但论文特意强调了一句：

要强调的是，这些 prompt 并没有明确指示模型去并行。 它们做的是塑造任务分布，让"并行拆解和调度"这种策略自然而然地占优。

不告诉模型要并行，而是把任务分布做成"并行才划算"的样子，让它自己学。

工程上还有一笔：为了提高效率，先用小尺寸的 subagent 训 orchestrator，之后再换成更大的模型。

它到底换来了什么

论文用三个 benchmark 验收，对照组是同一个 K2.5，只比"单 agent"和"开 swarm"：

• BrowseComp（深度检索）：60.6 → 78.4，涨 17.8 个点，超过了 GPT-5.2 Pro 的 77.9。
• WideSearch（广度检索，Item-F1）：72.7 → 79.0，涨 6.3 个点，越过 Claude Opus 4.5 的 76.2。
• 自建的 Swarm Bench：41.6 → 58.3，涨 16.7 个点。这套题包含开放网页检索、批量下载、100+ 份文档的广域阅读、10 万字以上的长文写作，是专门照着"值得并行"设计的，所以涨幅最大。

速度那一栏的口径要小心：论文说的 3--4.5 倍不是"总耗时快 3--4.5 倍"，而是"达到同一个质量目标所需的耗时之比"。在 WideSearch 上，目标 Item-F1 从 30% 抬到 70% 的过程中，单 agent 的耗时从约 1.8 倍一路涨到 7 倍以上，而 Agent Swarm 基本贴在 0.6--1.6 倍不动。换句话说：题越难，这个倍数越大；题很简单的时候，并行并不省时间。

附录里还有一个数很能说明问题：在 BrowseComp 上，orchestrator 自己的预算只有 15 步，而它派出去的每个子 agent 可以用 100 步。主脑几乎不干活，它的全部本事就在这十几步里------派谁、派几个、派去干什么。

专业化是涌现出来的

论文里有一张词云（Figure 6），图注写的是：这张词云展示的，是 orchestrator 在各项测试中动态实例化出来的、各不相同的 K2.5 子 agent。

orchestrator 自己造出来的子 agent 角色名

里面字号最大的两个是 Biography Researcher（传记研究员）和 Verification Specialist（核实专员），紧跟着是 Award Researcher、Historical Researcher、Timeline Researcher、Cross Reference Analyst、University Researcher、Article Researcher 这一批；再往下越缩越小，一直到 fact checker、genealogy researcher、award investigator，最后是编号化的 verifier 2 / verifier 3、writer sec01 / sec03。

顺带说一句：这张图上的角色高度集中在"查人物、查奖项、查时间线、交叉核实"这一族，因为它主要来自 BrowseComp 这类深度检索题。所以它证明的是"角色由模型现场造"，而不是"模型什么职业都会造"。

这些角色没有一个是人写进角色表里的。 这就是"无需预定义角色"最直观的证据。

如果编排本身可以被 RL 训进 orchestrator 的权重，那第二章里所有人在 harness 层写的调度代码、状态机、仲裁 agent，是不是过渡形态？

我倾向于短期内不是。PARL 训的是"要不要并行、怎么拆"这一层判断，而 Cursor 那 7 万次合并冲突、MiniMax 那三种成本，是执行环境本身的属性，不会因为 orchestrator 变聪明就消失。但最终agent的编排可能都会被训到基模里面。

第四章 · 怎么用它激发智能、找到真正的创新

到这儿为止，所有的努力都是在用 agent 的数量换速度。那能不能换智能？

第一类是"显然能做"的并行任务，也就是 Scaling 01 里那种：同时调研 50 个 benchmark、同时分析 500 个作者的文风、同时梳理 200 个 API 的入参出参。这类任务结构相同、互相独立、单个不难，天然适合 map-reduce。现在的 harness 基本都能做，剩下的差距在质量而不在能不能。

第二类是本质上不是并行、而是博弈的任务：一百个 agent 互相 judge、互相证伪、互相在对方的证明里找洞，最后收敛出一个单个 agent 到不了的结论。

我们来看看第二类是怎么做的

Apodex（MiroMind）-同一个团队三代模型，一路把验证往外挪

这一节把三个模型放一起讲，因为它们是同一家的。

这家公司值得单独说两句。Apodex 的创始人是陈天桥。公司 2024 年成立，由他和清华大学电子工程系副教授代季峰一起筹办（代季峰已于 2026 年 1 月卸任），2025 年 8 月靠开源的 Miro Open Deep Research 第一次进入公众视野，总部在美国 Redwood City，2026 年 4 月 23 日改名 Apodex。 开源的 MiroThinker 系列和 MiroFlow 都出自这个团队。

它的愿景那句话，跟这篇文章的主线撞得很准：它还叫 MiroMind 的时候，官方对自己的定义是一个"可被证明是对的"（engineered to be provably right） 的推理系统；改名之后换了个讲法，但意思没变------在前沿做研究、解题、发现，光有模型能力不够，得靠严谨的推理，而且每一步都被验过。 产品上叫 "Heavy Duty Solver"，瞄的是那些难、赌注大、答错代价实打实的问题：官网列的是科研、金融、法律合规、临床推理。

所以它三代模型连起来看，主线特别清楚------从"把交互做深"，一路走到"把验证从生成里拆出去"。

第一代：交互深度是第三个 scaling 维度

MiroThinker v1.0（arXiv:2511.11793）提出 interaction scaling------在模型规模、上下文长度之外的第三个 scaling 维度。单任务最多 600 次工具调用、256K 上下文。72B 版本的最好成绩：GAIA 81.9%、HLE 37.7%、BrowseComp 47.1%、BrowseComp-ZH 55.6%------超过此前所有开源 agent，逼近 GPT-5-high 这类闭源产品。核心主张是交互深度本身就是一个可预测涨点的维度。

MiroThinker v1.0 的总览图。右下角那三行是它主张的三个 scaling 维度：模型大小（8B / 30B / 72B）、上下文长度（最高 256K）、以及交互次数（每个任务最多 600 次工具调用）------第三行才是这篇的新东西

第二代：把验证塞进推理过程本身

MiroThinker-1.7 & H1（arXiv:2603.15726）在这基础上加了两层验证：

Local Verifier 管的是"每一步走得对不对"。

它对付的毛病是：agent 每一步都会挑那条"看起来最顺"的路走。比如你让它查"某人 1998 年在哪家公司"，它第一反应是搜维基百科，搜到一条就收工了。局部验证就是在每一步之后追问一句：这一步真的推进了吗？还有没有别的方向没试？------别让"探索"退化成反复确认自己的第一直觉。

这一条的消融数据很硬：在 BrowseComp 的 hard 子集（295 题）上，加了 Local Verifier 之后准确率从 32.1 涨到 58.5，而交互步数从 1185.2 掉到 210.8。原文特意说了一句：步数减少不是设计目标，是局部验证的自然副产品。

Global Verifier 管的是"整条链撑不撑得住"。

它吃的是一个不对称性：让你从头写一个证明很难，但让你检查一个证明对不对，容易得多。 所以它把收集到的证据整条摊开看一遍------如果 agent 说"答案是 A"，但支持 A 的只有一条二手转述，那就不收，打回去让它重新采样、或者把证据链补全，而不是硬着头皮交一个答案。 如果手上同时有好几条候选路径，它还会横着比一遍，在给定的算力预算内挑出证据链最完整、最经得起查的那一条------不是挑说的人最多的那一条。这一步就是下一代那套"看整体证据而不是看票数"的雏形。

第三代：heavy-duty 模式，和一个可以说不的 global verifier

先解释一下 "heavy-duty"（大致可以译成"重载"）。它不是另一个模型，是同一个模型的另一档运行模式------就像同一辆车挂低速四驱：慢、费油，但能爬平时上不去的坡。普通模式是你问一句它答一句；heavy-duty 是你把一个真研究问题丢进去，它可能花上几个小时、开出上百个 agent、走上万步，最后交一份带引用的报告回来。你会为一条微博开这个模式吗？不会。你会为一份要拿去做投资决策的尽调开吗？会。

到了 Apodex-1.0，验证不再只是推理过程里的一环，而是被抬成了整个架构的中心。

Apodex-1.0（官方技术博客，原文把这套东西描述成"一支异步的 agent 团队：各自专精、互相交叉核对、在回答之前先审一遍自己的证据"）的 heavy-duty 模式结构最完整。原文把整条链路写成了一段话，我拆开讲：

1. 拆：一个总调度（orchestrator）接到问题，拆成一堆子任务。
2. 派：每个子任务派一个专门的 agent，各自带自己的上下文、指令和工具------查文献的和跑数据的，工具箱是不一样的。
3. 收：所有 agent 干完把报告丢进一个共享的报告池。这里有个细节值得停一下：总调度不等，它只是隔一会儿去瞄一眼池子边上那张"谁交了、谁还没交"的状态表。这就意味着一个卡住的 agent 拖不垮整场------这正是第二章 MiniMax 那个"被最慢的 worker 卡死"的正面答案。
4. 验：全部收齐之后，才轮到最后那个 global verifier 出场，它对着拼起来的全部证据从头推一遍，然后才允许输出答案。

单个任务里，这套东西最多能协调 150 个子 agent、跑超过 15,000 步，官方说法是"比单 agent loop 的饱和点高两个数量级"------翻译一下：一个单 agent 跑到一两百步就开始原地打转、再跑也不涨了，而这套东西能一路跑到 15,000 步还在往前推。 作为对照，同一家第一代 MiroThinker 的上限是 600 步。

关键差别在于：最后拍板的那个 agent，不在干活的那批里面。

原文的说法是，verifier 拿到的指令是"评估"，不是"接着往下推"，而且它有权说不同意。这跟"让干活的人自己复查一遍"是两回事。

而且它不是投票。原文把这个区别讲得很清楚：问题从"哪个答案得票最多"换成了"整体证据支持什么"------三个 agent 都说 A，但三个人的依据都来自同一篇不靠谱的文章，那 A 照样不成立。

中间还有一支专门的验证小队随时待命：两份报告打架，派 conflict reviewer；某条结论需要落实，派 fact checker；草稿要过最后一遍，派 draft-report reviewer。

同一个 Apodex-1.0，开不开 heavy-duty 差多少？BrowseComp 上从 75.5 涨到 90.3（+14.8），FrontierScience-Research 上从 28.3 涨到 46.7（+18.4）------越是没有现成答案、越要自己拼证据的题，这套外置验证的收益越大。

还有个反直觉的点：同一个 Apodex-1.0，开了 heavy-duty 之后总步数经常比不开的时候还少------因为 verifier 会把那些不产生信息增益的步骤滤掉，把算力集中到真正推进问题的地方。

这跟 Cursor 那边"少写四分之三代码把同一件事做对"是同一个现象：组织方式对了，效率和质量是一起涨的，不是拿一个换另一个。

Evomap 那 166 个丢掉的答案、Cursor 的中立仲裁 agent、MiniMax 的 Verifier、Claude Code /deep-research 里的投票过滤、Apodex 的 global verifier------都是同一件事：不能让生成者自己当裁判。

DeepMind AlphaProof Nexus-集群买的是能力，还是成本

5 月 DeepMind 的 AlphaProof Nexus（the-decoder 报道、arXiv:2605.22763）把这条路走通了一段：

• 在 353 个尝试的 Erdős 问题里解出 9 个，其中两个悬了 56 年。
• 证明了 OEIS 上 492 个开放猜想里的 44 个（这 44 个是经人工复核确认"形式化正确且此前未被证明"的净值）。
• 解决了代数几何里一个悬了 15 年的开放问题------证明了 codimension 3、type 2 这一档 pure O-sequences 的 log-concavity（注意是这个大猜想里的一个特例，不是整个猜想）；还在凸优化里一边找证明一边发现了一个新的参数调度，把一个此前开放的收敛率问题做到了精确的 O(1/t)。
• 每个问题的推理成本"几百美元"。

它一共试了四档配置，可以理解成给同一个 agent 逐级加装备：

• A 档（最朴素）：一池子 Gemini 3.1 Pro 各写各的证明，互相不通信、不共享任何中间结果；每个都是写完丢给 Lean 编译器检查，编译不过就把报错喂回去重写，如此死循环。注意它本来就已经是并行的了------它缺的不是"多"，是"这些 agent 之间有没有关系"。
• B 档：在 A 上面加外援------卡壳的时候可以调 AlphaProof，那是 DeepMind 用强化学习专门训出来的定理证明器，擅长把证明里缺的那几步补上。
• C 档：换个方向加------让一群子 agent 同时写证明草图，草图全都丢进一个共享池子；另有一批评分 agent 两两比较这些草图谁更有戏，汇总成 Elo 分（就是国际象棋排名用的那套分）。分高的草图被优先拿来继续往下演化。说白了，就是给证明思路搞了个赛马。
• D 档：B 和 C 全都要。

那 9 道题是 D 档跑出来的。

!\[scaling07-alphaproof-架构.png\|600] AlphaProof Nexus 的架构。左边红框是写证明的 Prover Subagent（LLM，可选调 AlphaProof），产出先过黄框的 Proof Validator，再存进绿框那个共享的 Population Database（草图、目标证明、ELO 分）；右边蓝框是打分用的 Rater Subagent，靠"锦标赛"式的两两比较给草图排名，排名再反过来指导下一轮怎么写。最上面那位数学家负责把问题形式化成 Lean

总结

这半年最直观的变化是数量------从"3 到 5 个 teammate"到"一次派 1000 个"，只用了三个月。但把六家的做法摆在一起看，难的从来不是拆，是合：Evomap 那 166 个算对了却没送到的答案、Cursor 那 7 万次合并冲突、MiniMax 把"汇总"单列成一种成本，讲的都是同一件事。

各家的解法也殊途同归------能用确定性程序做的调度和汇总，就别交给 LLM。MiniMax 把它写成状态机，Anthropic 把它写成脚本，Cursor 派了个中立的仲裁 agent；Kimi 把编排能力直接 RL 进了模型权重，而且发现模型并不会自发学会并行，得专门设一笔奖励，把它从"还是自己干吧"的舒适区里推出去。

至于用 agent 数量换智能、而不只是换速度，目前唯一靠得住的东西是一个不会被说服的裁判：Lean 编译器、sqllogictest、外置的 global verifier。有这么个东西在链条末端，前面开多少个 agent 都不太会失控；没有的话，开得越多，错得越齐。

麻烦的是"哪个点子更好"这类问题恰恰最难找到裁判。你没法编译一个创意，也没有哪个测试套件能告诉你哪个角度更有价值。但真正的AI4SI往往藏在那1000次rollout的某次中。