6 月 22 日，东京的 Sakana AI 发布了 Fugu。它没有训练任何一个前沿大模型，而是把一池现成的模型编排起来，对外表现得像单个模型，并且自报在一些硬基准上能和 Fable 5 比肩。这件事值得拆一拆，因为它顺手把「多模型编排」和「多 agent 编排」这两件常被混为一谈的事，照得很清楚。
一、背景：Sakana AI 是谁
Sakana AI 是东京的一家前沿 AI 公司，2023 年成立，联合创始人里有 Transformer 论文《Attention Is All You Need》的共同作者之一 Llion Jones。它的路线和「堆更大的模型」不太一样，信的是自然启发、进化式那一套，一句常被引用的话是「智能源于资源的匮乏，而非充裕」，所以更愿意让一堆小而专的模型协作，而不是训一个无所不能的巨型模型。
这条路线下，它做过几样有代表性的工作：用进化算法自动合并开源模型的「进化式模型合并」、尝试把科研流程自动化的 The AI Scientist、以及让多个前沿模型在推理时协作的 AB-MCTS。资本上，2025 年 11 月它完成了估值约 26.5 亿美元的 B 轮，投资方包括 Google、MUFG 等，业务方向放在金融、国防与制造。
二、Fugu 的原理（以官方与论文为准）
先用 Sakana 自己的话定位：Fugu 是「一个行为像单个模型的多 agent 系统」。你把请求发给一个 endpoint，Fugu 自己判断是直接回答，还是召集多个专家模型来啃一个复杂任务。
关键在于，Fugu 本身就是一个被训练过的语言模型，它学的是「什么时候该委派、参与的模型之间该怎么沟通」。官方把它内部干的事拆成四件：模型选择、任务委派、验证、合成。
这套「学出来的编排」建立在两篇 ICLR 2026 的论文上：
- Trinity（《An Evolved LLM Coordinator》, Xu et al., arXiv:2512.04695）：一个用进化方法得到的轻量协调器，给多模型池里的参与者分 Thinker、Worker、Verifier 三种角色，按 coding、数学、推理等任务类型，自适应地把活派下去。
- Conductor（《Learning to Orchestrate Agents in Natural Language》, Nielsen et al., arXiv:2512.04388）：用强化学习训练，自己摸索出「用自然语言怎么协调」的策略，也就是学会让一池风格各异的模型互相沟通，使整体表现超过其中任何一个单独的模型。
两篇合起来看，Fugu 的决策链是：读懂任务，决定直接回答还是拆成子任务；如果复杂，就给每个子任务挑最合适的专家模型，再做验证与合成。
这个「组合多个模型、超过任何单个」的核心思路，在 Sakana 更早的 AB-MCTS 里已经有过实证。AB-MCTS 在推理时用 Thompson 采样，在「生成新解（往宽里搜）」和「精修已有解（往深里搜）」之间动态选择，并把「这一步调用哪个模型」当成一个多臂老虎机问题来学。在 ARC-AGI-2 的公开任务上，单模型重复采样约 23% 的通过率，换成多模型组合后到了 30% 以上，并且出现了「任何单个模型都解不出、组合却解出」的题。
产品分两档：
- Fugu：偏性能与低延迟，面向交互式服务和日常使用。
- Fugu Ultra：偏最高答案质量，面向难的多步任务，比如研究、安全分析、代码审查。
基准数字要如实标清楚。Sakana 称 Fugu Ultra 在工程、科学、推理类基准上「与 Fable 5、Mythos Preview 等领先模型比肩」，对照的是 Gemini 3.1 Pro、Opus 4.8、GPT 5.5。但有两点必须说明：这些是厂商自报的数字；而 Fable 5 和 Mythos Preview 的分数来自各家自己公布，它们也并不在 Fugu 的模型池里。更细的口径在 Fugu 技术报告（arXiv:2606.21228）。
工程上还有一个直接的好处：模型池是可热插拔的，某一家不可用就换一家，不必把自己绑死在单一供应商上。社区也已经有人做了开源复刻 OpenFugu。
三、多 LLM 编排和多 Agent 编排，不是一回事
这里得插一个容易被混淆的区别，否则下一节会问错问题。
Fugu 内部分角色、走多步、还带 verifier，看着很像一个「多 agent 系统」，官方也这么叫它。但它和我们平时说的「多 agent 编排」（比如 Claude Code 的 Agent Teams、各种 agent 框架）其实是两层东西。
区别的根子在于：被编排的「单元」不同。多 LLM 编排，编排的是一次次模型推理调用；多 agent 编排，编排的是一个个 agent，而 agent = 模型 + 工具 + 记忆 + 一个角色 + 一个自己的循环。
把这两层并排看：
| 多 LLM 编排 | 多 Agent 编排 | |
|---|---|---|
| 编排单元 | 一次模型推理 | 一个带工具和记忆的 agent |
| 时间跨度 | 单次请求、短程 | 多步、长程 |
| 状态 | 基本无状态 | 有状态（记忆、工作区） |
| 核心动作 | 路由、集成、合成 | 分解、派单、调工具、聚合、纠错 |
| 对外副作用 | 无，只产出文本 | 有，会写文件、跑代码、发请求 |
| 优化目标 | 这一题答得更好、更便宜 | 把一个多步任务真正干完 |
一句更直白的分法：多 LLM 编排在编排「思考」，多 Agent 编排在编排「行动」。前者像一个关在房间里的专家委员会，吵出一个更好的答案再交出来；后者像一个会走出房间、真去做一件事、然后带着结果回来的人。Fugu 内部那套 Thinker / Worker / Verifier，是在房间里合议，它们不碰你的文件、不跑你的代码、不发你的请求。
而且这两者不是二选一，是一条光谱：从单模型，到模型路由，到多模型集成合成（Fugu 标准档就在这一段），到推理时的跨模型搜索（AB-MCTS），再到带工具和状态的多 agent（Fugu Ultra 开始往这边滑，Agent Teams 完全在这），最后到分层的 agent 团队。越往右，单元就从「一个会说话的模型」变成「一个会做事的 worker」。
判断一个系统落在哪一头，有个简单标准：被编排的单元，有没有「工具 + 状态 + 自己的循环 + 对真实世界的副作用」。只是被 prompt 出一个回答然后合并，就是多 LLM 编排，哪怕它自称 multi-agent；能调工具、写文件、看了结果再迭代，才是多 agent 编排。顺带说一句，「multi-agent」如今被当成营销词用得很滥，不少所谓的多 agent，拆开看其实只是多模型。
所以 Fugu 的准确画像是：一个带了 agentic 协调器的多 LLM 编排系统。它借用了 agent 的词汇，但被编排的 worker 本质上是从一池里选出来、无状态的模型调用。想清楚这一点，下一节才好谈它到底能替我简化什么。
四、放到一套真实系统里：Fugu 能简化什么
我自己跑着一套多 agent 的自动化系统，这里只讲框架。顶上一个总指挥，往下协调两条线：一条开发线，把任务派给各个项目里的编码 agent；一条运营线，做内容生产和社区互动。这些 agent 都会真的动手：写代码、跑命令、产出内容、对外发布，各自有不同的权限边界。总指挥负责拆需求、按路由派单、排优先级。
把 Fugu 接进来，第一件要想清楚的事是边界：Fugu 换的是每个成员的「脑」，不是「指挥」。 上一节说过，Fugu 内部虽然也分角色、也走多步，但那是一场封闭的合议，最后交回一段文本。真正动手、持有状态、对结果负责的，是上层那套编排。所以接 Fugu，编排层基本不动。
那它能简化什么？集中在「脑」这一层：
第一，把按角色配模型的策略下沉。以前要手工琢磨「这个轻量高频的 agent 用小模型、主力开发用中模型、最烧脑的分析用大模型」。这套按角色分档的活，大半可以交给 Fugu 动态路由，不必再逐个 agent 钉死模型。
第二，纯粹为了换模型而拆开的 agent 会被收编。如果某些 agent 当初分家，唯一的理由就是想用不同模型的强项，那么一个 Fugu 脑的 agent 每次调用都能动态拿到最合适的模型，这几个就能塌缩成一个，系统更简单。
第三，每个成员的单次脑力被抬高。一次思考从「问一个模型」变成「一个会路由、会合议的专家组在答」，地板高了一截。
但有同样多的东西，Fugu 收编不了，得老实保留。
我这套系统里的 agent 之所以分开，大多不是为了换模型，而是为了切活：不同项目、不同权限域、要并行、要上下文互不污染。这些跟「哪个模型更聪明」无关，Fugu 一个都收不走，团队结构原样保留。
还有两条使用纪律：
- 思考重、没有副作用的步骤，比如选题调研、内容起草、代码推理、数据分析，放心交给 Fugu。
- 动真格、不可逆、需要留痕的步骤，比如对外发布、改动线上，钉一个固定的已知模型，别让动态路由插手。这和 Fugu 自己主打金融、国防这类场景其实是同一个道理：这些地方要的是有界、可审计，而不是每次都换一个脑。
落地还有几处摩擦，点到为止：底层一旦换模型，工具调用的格式得保持统一，否则一个调用就可能出错；黑盒合议会牺牲一点可观测性，出问题时不容易看清是谁的决定；而多个 agent、各自多步、每步内部又是多模型合议，成本会叠起来，所以日常走标准档、难题才上 Ultra，是必要的省钱办法。
收口一句：Fugu 收编的是「为了答得更好而拼起来的多模型」，收编不了「为了分工、为了保留分歧、或者为了锁定某个模型而存在的多模型」。对一套已经按「切活」分好的系统来说，它简化的是每个人的脑，不是整套架构。
参考
- Sakana Fugu 发布：sakana.ai/fugu-releas...
- Trinity（论文）：arxiv.org/abs/2512.04...
- Conductor（论文）：arxiv.org/abs/2512.04...
- AB-MCTS：sakana.ai/ab-mcts/
- Fugu 技术报告：arxiv.org/abs/2606.21...
- 开源复刻 OpenFugu：github.com/trotsky1997...