你往一个 API endpoint 发请求，以为自己在调某个模型。对面的模型几乎不自己答题。它把 GPT、Claude、Gemini 叫到一起，分好角色：你出主意，你动手，你验收。几轮讨论验证之后，把答案递回来。从你这端看，始终只有一个 API。你调的，是一个训练出来专门组织会议的协调器。
Sakana AI 发布的 Fugu 就是这么一套系统。底层是两篇 ICLR 2026 论文：TRINITY 用进化策略训练了一个极小的协调器，Conductor 用强化学习训练了一个七十亿参数的编排器 (Conductor arXiv) (TRINITY arXiv)。它跟现有方案真正不同的地方在于：叫谁、怎么分工、谁来核验，全都是模型从海量题目里练出来的，没有一行 if-else 是人硬编码进去的。Fugu 把多智能体编排从开发者手写的 workflow，变成了训练进模型权重的能力。放在 multi-agent 这条演化线上看，是一次真实的转折。
它像一个学会了管理的 AI 经理：调度谁、怎么分工、谁来验收，这些原来靠人拍板的事，都训进了模型权重里。学习型协调天生是个黑盒，但在这一层上，信任它跟信任一个人类经理没有本质区别。真正该追问的是另一件事：Sakana 在经理的推理黑盒之外，把经理调了谁、派了什么活也一并藏了起来，藏得比一家真实组织里的经理还彻底，而这层是可解的。Fugu 是第一个让 AI 学会怎么管其他 AI 的产品。
Fugu 本质上就是一个训练出来的协调器。请求进来，它自己判断这件事一个人能扛还是需要组队。调哪个模型、分什么角色、谁出主意谁动手谁验收、怎么汇总，全部由它自己拍板。
角色分工走的是三权分立路线。Thinker 出主意，Worker 动手，Verifier 验收。Verifier 说不行就打回重做。这套行为的来源是强化学习中的奖惩信号把协调策略压进权重：海量题目反复做，做对有奖励，模型自己学会遇到什么题就组什么队。
递归自调用是这套机制里最像人的设计。Fugu 拿不准的时候可以叫自己的分身，分身拿不准再叫分身。类似主管接到一个复杂需求，第一反应是拉组开会；会上有人觉得某一块拿不准，主管说这块你再去开个小会。官方说明明确写道，Fugu 调用的模型池子里包含它自己，支持递归调用 (Sakana AI)。
用户只看到一个 API；内部由协调器调度一组 AI 分工协作，验收通过才合成答案，全过程对用户不可见。
市面上多模型工具大致可以分成几类。OpenRouter 帮你挑模型，一次只调一个。LangGraph 给你搭积木，让你自己画流程图编排 agent。OpenRouter 的 Fusion 走固定流水线：并行派发，评判打分，汇总合成 (OpenRouter)。Fugu 跟这些都不一样，协调这件事本身是它学来的，不靠规则，也不靠固定流水线。你没法像改 LangGraph 流程图那样去编辑它的协调策略，只能换训练数据重新炼。
技术读者看到这里，自然会反问：GPT 自己就会推理、会分析、会拆解任务，把任务描述写详细一点，让它去规划、调度别的模型，这条路难道走不通吗？
这个反问指向的是协调能力的存放位置。历史上，这个位置一直在迁移。最早，AI 在内部做分工，比如混合专家模型里不同参数区负责不同计算，但模型只跟自身交互。后来人们在已训练好的不同模型之间做选择：简单题用便宜的，难题用贵的。这属于挑工具，不算协调工具。再到后来，开发者手写多 agent 协作流程图，流程质量取决于写流程那个人的判断力，换一个任务就得重画一张。Fugu 把这个箭头推到了下一个位置：协调能力不再写在代码里，而是训进了模型本身。推理模型（o1 那类）把推理能力从人类的 prompt 工程搬进了训练，Fugu 做的事跟它同构。用 GPT 当编排器，协调智能来自你写的 prompt；Fugu 的协调器是专门训练出来的，协调策略训进了权重里。协调的控制权从代码搬进了权重。这一轮演化里真正发生的，就是这个转换。
理论上看，这个方向站得住。两篇论文也直接设了对照组，而且给了 LLM 编排器优待条件。
Conductor 论文的附录 Table 11 比较了三种编排器：GPT-5 当编排器、Gemini 当编排器、训练好的七十亿参数 Conductor，用的都是同一套 prompting 框架 (Conductor arXiv)。为了让 LLM 编排器有最好的表现机会，还额外加上了格式失败自动重采样和输出 token 翻倍的处理。结果：训练版平均 75.65 分，Gemini 当编排器 71.59 分，GPT-5 当编排器（管理三个模型）70.05 分。训练版整体领先，但这个领先并不均匀分布。优势高度集中在代码题上：LiveCodeBench 领先 13 到 33 分，BigCodeBench 也有小幅领先。数学和科学题上几乎打平：AIME 训练版 93.30 对 GPT-5 编排器 93.30，GPQA-D 上 87.50 对 86 到 87 分。论文的解释是：提示编排器无法理解 Claude 在代码题上较弱而 GPT-5 在另一类题上较弱，它依赖的是先验偏见，对不上实际下游表现。
TRINITY 论文的附录 Table 8 做了同样的对照：直接用 Gemini 2.5 Pro 提示当 coordinator，每轮选择模型和角色 (TRINITY arXiv)。训练版平均 70.44 分，提示版只有 53.76 分，落后 16.7 分。论文明确写道，提示式的 LLM 难以理解和管理七个 agent 各自的属性。
这里需要加一句诚实的限定。论文同时也承认，前沿模型本身就具备不错的 meta-orchestrator 能力：GPT-5 当编排器，表现超过它自己单模型的结果，也超过未训练的七十亿参数基座。训练是在这个底子上再拉开一截，增量集中在指令复杂的代码和工程任务以及成本效率上。准确的表述是：训练能在特定维度上稳定拉开差距，在另一些维度上两者打平。训练编排器并非全面碾压提示编排器。如果你关心的恰好是代码这类指令复杂、对模型个体差异敏感的任务，训练的收益就成立；如果只是做简单的数学和科学路由，提示编排器已经够用了。
Fugu 目前有两个版本，训练方法不同，各对应一篇论文。
标准版 Fugu 走 TRINITY 路线 (TRINITY arXiv)。协调器非常小：主干是 Qwen3-0.6B，上加一个约一万参数的小 head，总可训练参数不到两万。head 只输出 logit 做决策，不生成文本，推理成本极低。训练用的是进化策略，具体算法叫 sep-CMA-ES。思路是随机生成大量候选参数，让它们去解题，留下表现好的，迭代几十代，类似优胜劣汰。奖励信号简单到只剩一条：题解出来得一，没解出来得零。每个候选参数重复评估十六次取平均 fitness，最多协调五轮。论文解释了为什么不选 RL 或 SFT：一万个参数每个对最终 reward 的影响极其微小，REINFORCE 那种逐参数梯度方法信噪比太低、不够稳定；SFT 则需要先生成多轮协调的示范标签，按论文的估算，五轮场景下需要八百七十亿次查询，成本上不可行。论文还做了直接对比：sep-CMA-ES 在 LiveCodeBench、MATH500、MMLU、RLPR 四个 benchmark 上全面赢过 REINFORCE、SFT 和随机搜索。
Fugu Ultra 走 Conductor 路线 (Conductor arXiv)。协调器是 Qwen2.5-7B，用 GRPO（Group Relative Policy Optimization）训练。每个问题采样六十四个协调方案，跑一遍看答案对不对：对了满分，格式不对零分，格式对但答案错给中间分。训练两百轮，关掉了 KL 惩罚，在两块 H100 上跑。协调的工作流上限设为五步，实际平均只用三步。token 消耗大约只有手写多 agent 拓扑的六分之一。
两篇研究论文用的是同一个七模型池：GPT-5、Gemini-2.5-Pro、Claude-Sonnet-4，加上四个开源模型：DeepSeek-R1-Distill-Qwen-32B、Gemma-3-27B、Qwen3-32B 的 direct 和 reasoning 两种模式（计为两个独立 agent）。产品级的 Fugu Ultra 把这个池子升级成了更新一代的 Gemini-3.1-Pro、Claude-Opus-4.8 和 GPT-5.5 (Fugu 技术报告)。
数据来源方面，两篇论文都没有使用标注好的协调示范数据集。它们走的是 RLVR 思路：拿一批有可验证答案的 benchmark 题目，把答案对不对作为奖励信号，协调策略在奖励最大化的过程中自己涌现出来。训练用 LiveCodeBench 的 V1 版本，测试用 V6 版本，刻意隔开以防止泄漏。论文里那些涌现行为，包括简单题直接一枪、难题自动搭出从规划到执行再到验证的流水线、独立尝试加最终辩论，全部是从奖励里冒出来的，没有一条是人写进 prompt 的。
前面说过，学习型协调天生是个黑盒。这句话需要拆开来看：到底黑在哪里，跟一个人类经理比，黑的程度真的一样吗。
第一层，Fugu 的协调器自身就是一个语言模型。它为什么在某道题上决定拉团队而不是交给单个人、为什么用模型 A 不用模型 B，这些决策训在权重里，没法逐条回溯。不过这一层跟信任一个人类经理没有本质区别。你同样没办法形式化一个经理为什么拉三个人开会而不是自己拍板。你判断经理靠的是结果，不靠逆向工程他的决策算法。这一层是可接受的。
第二层开始，差别出来了。人类经理黑的是推理，动作层面不黑。活派给了谁、批了什么预算，组织里看得见、有记录、能审计。Fugu 不一样：它的协调器在内部每一步都产出了协调序列，调了哪个 agent、给了什么子任务、上下文怎么共享，全都包含在内。这份产出是机器可读的，本来就能记录、能透传 (VentureBeat)。GIGAZINE 的报道也确认了用户无法确认每次调用实际用了哪些模型 (GIGAZINE)。但 Sakana 选择不给。VentureBeat 引述了公司的态度：路由信息属专有资产，设计上刻意对用户不可见。
第三层，底层每个 agent 产出了什么原始内容、数据流向了哪个 provider、整套答案里哪个部分由哪个模型贡献，技术上都能透出来。Sakana 同样选择藏起来。
真正卡住调试、合规审计和成本归因的，并不是推理层的天生黑盒，那一层人类经理也一样。问题出在第二层和第三层：Fugu 把协调的动作也藏了，藏得比一个真实组织里的经理还彻底。在正常公司里，你至少知道领导把活派给了谁、花了多少钱。用 Fugu 的时候你连这些都不知道。
这两层的隐藏是商业选择，不是技术宿命。保护学来的协调策略和 blended pricing 不被穿透，动机可以理解，但这个选择本身是可逆的。经理类比的价值在于精准定位它比人类经理多藏的那一层，而那一层可以打开。如果 Sakana 给企业客户开放协调序列日志和底层模型身份，合规那道坎基本能过。
方向站得住，不代表产品已经到了生产可用的状态。实际表现是一组混合信号。
Sakana 的研究显示，RL 练出来的协调策略打赢了手写基线，包括 Mixture-of-Agents 等方法。平均三步工作流，token 成本比手写拓扑降低约 20 倍 (VentureBeat)。Fugu Ultra 在 LiveCodeBench 拿到 93.2 分，超过 Fable 5 的 89.8；GPQA-D 上 95.5 对 94.6，同样是 Fugu 领先 (Sakana AI)。
在业界更看重的 agentic coding 上，SWE-Bench Pro 只有 73.7，Fable 5 是 80。在最难推理测试 HLE 上，Fugu 50 对 Fable 53.3，同样落后 (Sakana AI)。这两个分数尤其需要小心解读：Fable 5 不在 Fugu 的 agent pool 里。官方页面白纸黑字写着 Fable 5 和 Mythos 不在 agent pool 中，因为它们不对外公开访问 (Sakana AI)。也就是说，Fugu 是用协调器加上池子里其他模型去对阵 Fable 5 这个单体模型，本质上是一边倒的不对称比较。但 Sakana 的页面同时用了 shoulder-to-shoulder 来描述 Fugu 跟 Fable 5 的竞争关系。
缺两块关键拼图。第一，没有跟 OpenRouter Fusion 的正面对比。Fusion 用便宜模型 panel 也声称超过 frontier，甚至同一模型自 fuse 都能涨分 (OpenRouter)。第二，没有独立第三方复现，目前所有数据都是 Sakana 自报。延迟特性也没有公开。
Sakana 把模型可替换包装成了主权卖点。David Ha 说 Fugu 靠完全可替换的 agent pool 绕过供应商限制 (VentureBeat)，官方页面也提到了不受出口管制风险影响 (Sakana AI)。背景是 Anthropic 的 Fable 5 和 Mythos 因美国商务部出口管制指令在全球范围内停用 (CNBC)。可替换对应的是供应韧性：某个模型断供了，系统能绕开继续工作。但它不回答主权问题：谁能决定模型和数据是否继续存在。这个卖点最想吸引的受监管欧洲企业，恰好是当前 opacity 选择最难服务的对象。不过这个张力是商业取舍，可以分层解决，算不上死结。
Fugu 踩稳了一件事：learned orchestration 在学术层面确实比手写协调有优势。但值不值得把自己的工作流塞进这个黑盒，目前还看不准，Fusion 对照和独立验证这两块都缺着。Fugu 未必是 AI 多模型协调的最终答案，但模型学会管理其他模型这个方向不会消失。它只需要先补上透明度这一课。