夜雨聆风SAKANA FUGU / MODEL ORCHESTRATION
日本 AI 公司 Sakana AI 发布了 Fugu。它不是神级基础模型，而是一个会调度 Claude Fable 5、Opus、Gemini 等模型的系统。
导读
日本也出了一个新的 AI，名字叫 Sakana Fugu。
它是日本 AI 公司 Sakana AI 在 2026 年 6 月 22 日发布的新系统。这个团队本身就很有话题性：CEO David Ha 来自 Google Brain，CTO Llion Jones 是 Transformer 论文《Attention Is All You Need》的共同作者之一，也就是今天大模型技术路线的重要源头人物之一。
但 Fugu 真正引发争议的地方，不是“日本突然训练出了一个比 Claude Fable 5 更强的模型本体”。
这里说的“模型本体”，不是说它只能处理文本。像 Fable 5 这种多模态前沿模型，当然也可以同时处理文本、图像、代码等任务。区别在于：Fugu 讨论的重点不是把所有能力压进一个模型里，而是让一个系统学会什么时候该调用哪个模型。
它更像一个会派活的 AI 调度系统：用户只看到一个 API，背后却可能把任务分给 Claude Fable 5、Claude Opus、Gemini 等不同模型来完成。也正因为这样，它一出来就被很多人嘲讽为“高级套壳”。
问题是，嘲讽归嘲讽，它确实把一个现实问题摆到了台面上：
当模型越来越多，谁来判断这件事该交给哪个模型做？
你看它的官方 benchmark，Fugu Ultra 在一些硬核任务上分数很高，甚至在 Terminal Bench 2.1、LiveCodeBench、CharXiv Reasoning 这类任务上，跑到了 GPT-5.5、Opus 4.8、Gemini 3.1 这些前沿模型旁边。
但如果因此就写成“日本模型超越顶级闭源模型”，那就看错了。
Sakana Fugu 的重点不是“我单体比你聪明”，而是“我知道这道题该派谁上”。
它不是神级模型。
它更像一个模型调度员。
PART 01
先别急着吹：它不是传统基础模型
如果你按传统大模型逻辑看 Fugu，会很别扭。
更准确地说，传统基础模型的能力主要来自预训练和后训练阶段：工程团队准备数据、设计训练流程、优化参数，让能力沉淀到模型自身权重里。上线之后，用户调用的是这个模型本体，让它在推理阶段完成回答。
但 Fugu 官方讲的不是这条路。
Sakana 把它定义成一个 learned LLM orchestrator，也就是学习型大模型编排器。外部用户只看到一个 API，内部其实是一个模型池：GPT-5.5、Claude Opus 4.8、Gemini 3.1 这类 worker models 都可能被调度进来。
这就是争议的来源。
有人会说：这不就是高级中转站吗？
这个吐槽不是完全没道理。因为 Fugu 的能力确实来自它背后能调用的强模型。如果把 GPT、Opus、Gemini 都拿掉，它就不可能凭空变强。
但如果只说它是“中转站”，又太粗糙。
普通中转站只是把请求转发出去。Fugu 要做的是：判断这个任务更像代码、数学、事实问答、调试、安全分析，还是长链路工程任务；再决定让哪个模型先做、哪个模型复查、哪个模型收尾。
这不是“我替你答题”。
这是“我替你派活”。
PART 02
它到底怎么让多个模型一起干活
官网那张架构图其实很直白。
上面是 Sakana Fugu，下面是一组 closed & open models。请求进来之后，Fugu 不一定自己完成答案，而是从模型池里选择合适的 worker model。
普通版 Fugu 更像“路由器”：它会学习不同模型在不同任务上的表现，然后把问题交给更可能做对的模型。
Fugu Ultra 更进一步。
它不是只选一个模型，而是能生成最多 5 步的 agentic workflow。每一步会指定三件事：
第一，这一步要做什么子任务。
第二，哪个 worker agent 来做。
第三，它能看到前面哪些 agent 的输出。
这就从“选一个模型答题”，变成了“组织一组模型协作”。
如果说 GPT-5.5、Opus、Gemini 是一群专家，Fugu 不是冒充专家，而是在做项目经理：谁先写方案，谁负责挑错，谁最后综合。
这也是它和普通 API 聚合平台最大的区别。
它不是只提供更多模型选项，而是试图训练一个模型学会“什么任务该交给谁”。
PART 03
最好的例子：GPT 搭东西，Opus 来挑刺
论文里有一个例子很适合解释 Fugu 的工作方式。
在 Terminal Bench 2.1 的一个任务里，Fugu Ultra 要搭一个 PyPI server 来托管 `vectorops` 包。
它没有让一个模型从头干到尾。
第一步，它先派 GPT-5.5 去搭建服务器，并确认服务可访问。
GPT 做完之后，Fugu 又把 Opus 拉进来做“复查”和“挑刺”。Opus 发现了几个具体问题：GPT 用的是普通静态 `http.server`，不是合适的 pypiserver；手搓 wheel 的方式比较脆；Debian-slim 环境没有处理好，后续命令会失败。
更关键的是，Opus 还发现 GPT 的可访问性检查本身也是错的。
这些问题再反馈回 GPT，最后任务被修好。
这个例子比跑分更有价值。
因为它说明 Fugu 的优势不是“单体智商更高”，而是让不同模型在不同阶段承担不同角色。
GPT 像施工队，先把东西搭起来。
Opus 像质检员，专门找漏洞和工程风险。
Fugu 像工头，不一定亲自搬砖，但知道什么时候该叫谁上。
这也是为什么“它不是模型”这个吐槽，只说对了一半。
它确实不是传统基础模型。
但它也不是简单转发请求。
PART 04
跑分可以炒，但不能瞎吹
Fugu 最容易被拿来传播的点，是它的 benchmark。
官方发布页里，Fugu Ultra 在多个任务上跑到了很靠前的位置。
这里可以写得有冲击力，但不能写歪。
BENCHMARK
比如 Terminal Bench 2.1，论文表格里 Fugu Ultra 是 82.1，GPT-5.5 是 78.2，Opus 4.8 是 74.6。论文也明确说，Fugu 在这个任务里可以超过 GPT-5.5，并且会在解题过程中在 GPT-5.5 和 Opus 4.8 之间切换。
BENCHMARK
LiveCodeBench 上，Fugu Ultra 93.2，也高于 GPT-5.5 的 85.3、Opus 4.8 的 87.8。
但这不等于“Fugu 本体比 GPT-5.5 更强”。
因为它不是拿一个单体模型去硬碰硬，而是拿一个调度系统去组织多个强模型。
更准确的说法是：
Fugu Ultra 在某些任务上，通过模型编排拿到了比单个前沿模型更高的结果。
这才是重点。
它不是把 Fable 5 或 GPT-5.5 干趴了。
它是把“怎么调用这些强模型”这件事做成了可计分的产品。
PART 05
为什么这个方向值得中国 AI 关注
这件事对中国 AI 的启发，不在于“日本模型有多强”。
而在于：未来企业可能不会只买一个模型。
中国现在并不缺模型。DeepSeek、通义、Kimi、豆包、GLM、混元、Qwen 开源生态，各有长板。不同公司还有自己的私有模型、行业模型、知识库模型。
一个更贴近国内用户的例子是：你可能会用一个偏代码和长任务的模型写工程代码，但当你想生成封面图、产品图、视觉素材时，通常又需要切到另一个专门的图像生成模型。
这不是代码模型“不行”，而是任务类型变了。
写代码、查资料、审逻辑、生图、读图、复查工程风险，本来就可能需要不同模型。今天很多产品把这些能力做成不同入口，用户要自己判断什么时候换模型、什么时候开新窗口、什么时候把上一步结果复制过去。
调度层真正想解决的，就是这件事。
真正麻烦的是：
哪个任务该用哪个模型？
什么时候用便宜模型，什么时候用强模型？
什么时候要代码模型，什么时候要长上下文模型？
什么时候让一个模型先写，另一个模型复查？
什么时候为了数据安全必须走私有模型？
如果企业未来维护的是一个“模型池”，那调度层就会变成入口。
这也是 Fugu 最值得看的地方。
它不是提醒我们“所有人都要去训练最大模型”，而是提醒我们：当模型越来越多、价格越来越复杂、能力越来越分化时，谁能更好地组织模型，谁就可能拿到新的控制点。
PART 06
也别神化：这条路还有硬问题
Fugu 的问题也很明显。
第一，底层模型依赖很强。它的表现很大程度取决于 worker model pool。如果底层模型换了、涨价了、限流了，调度层也会受影响。
第二，成本不一定便宜。Fugu Ultra 的卖点是质量优先，但多模型协作天然可能带来更高推理成本。
第三，透明度是问题。用户看到的是一个统一 API，但内部到底怎么选模型、怎么分工、怎么复查，不一定完全透明。
第四，benchmark 不能等于真实业务。论文里的任务很有参考价值，但企业真实工作流里还有权限、合规、稳定性、上下文污染、审计记录和数据边界。
所以这篇文章不应该把 Fugu 写成“日本 AI 逆袭”。
更准确的判断是：
Sakana Fugu 不一定证明日本造出了最强模型，但它证明“模型调度”已经可以被包装成一个正式产品。
这就够有意思了。
PART 07
结语：AI 竞争不只是谁更聪明
过去两年，大模型竞争主要围绕一个问题：
谁的单体模型更强？
但 Fugu 提出的另一个问题可能更现实：
如果世界上已经有很多强模型，谁能把它们组织得更好？
这就是 Fugu 的争议价值。
它被嘲“套壳”，不冤。
但它戳中的问题，也很真。
未来 AI 的竞争，可能不只发生在基础模型层，也会发生在调度层、路由层、Agent 编排层和企业模型池入口。
最值钱的未必永远是一个最聪明的大脑。
有时候，也可能是一个最会派活的系统。
资料参考
Sakana Fugu 产品页：https://sakana.ai/fugu/
Sakana Fugu 发布页：https://sakana.ai/fugu-release/
Sakana Fugu 技术报告：https://arxiv.org/html/2606.21228
Sakana AI Console Models：https://console.sakana.ai/models
Z.ai GLM-5.2 文档：https://docs.z.ai/guides/llm/glm-5.2
Z.ai GLM-Image 文档：https://docs.z.ai/guides/image/glm-image
