日本 Sakana Fugu 把多模型协作封装成一个 API，Agent 竞争开始从单模型走向调度系统

东京的 Sakana AI 正在把一个很重要的方向推到产品层：未来的 Agent 竞争不一定只靠“一个最强模型”，也可能靠一个会组织多模型协作的调度系统。Sakana Fugu 的定位就是“Multi-Agent System as a Model”，也就是把多 Agent 协作能力封装成一个可调用的模型 API。

这种思路对个人开发者和企业团队都很有价值。现实工作里，一个模型擅长写代码，另一个模型擅长推理，还有模型更适合长文总结或安全分析。如果系统能自动判断谁适合做哪一段，再把结果组织回来，AI 工作流就不必被绑定在单一供应商身上。

一个 API 背后调度多个专家模型

Sakana Fugu 的官方页面强调，它通过动态协调和编排多个强模型来获得更好表现。用户表面上调用的是一个 API，但 Fugu 会在背后处理模型选择、切换和任务分派。

这张架构图说明了 Fugu 的核心角色：它不是把所有能力硬塞进一个模型，而是学习如何组合模型池里的能力。官方把这称为“one model to command them all”，意思是用一个调度层把多个模型组织起来。

对企业来说，这个能力会直接关系到成本、稳定性和合规。如果某个模型不适合处理敏感数据，或者某个供应商在特定地区不可用，系统需要能把它从池子里排除。Fugu 页面明确提到，用户可以控制哪些 Agent 进入模型池，以满足数据、隐私、合规或组织要求。

技术基础来自 TRINITY 和 Conductor

Sakana AI 把 Fugu 的技术基础指向两篇 ICLR 2026 论文：TRINITY 和 Conductor。TRINITY 使用轻量的进化型协调器，在多个回合中给不同 LLM 分配 Thinker、Worker、Verifier 等角色；Conductor 则用强化学习学习自然语言协调策略，让模型池在推理任务上超过单个 worker。

这说明 Fugu 的重点不是简单路由，而是把“如何让 Agent 沟通、分工、验证”当成一个可学习的问题。对 AI Agent 开发者来说，这是一个很好的信号：未来的 Agent 框架可能会从固定流程图，走向可学习、可优化的协作策略。

基准显示它在工程和推理任务上接近前沿模型

官方页面给出了 Fugu 和 Fugu Ultra 的多项定量结果，涵盖 SWE Bench Pro、TerminalBench、LiveCodeBench、Humanity's Last Exam、CharXiv Reasoning、GPQA-D 等任务。

页面说明，Fugu Ultra 会调度更深的专家模型池，面向高难度、高风险问题；普通 Fugu 则在性能和延迟之间做平衡，适合日常工作。这个划分很像真实工作里的两种需求：有些任务要快，有些任务要稳。

值得注意的是，官方也说明 Fugu 当前不在 EU/EEA 提供，因为还在处理 GDPR 和欧盟特定监管合规。这不是一个无关细节，而是提醒我们：当 Agent 可以调度多个模型和供应商时，数据流向和地区合规会成为产品能力的一部分。

对 AI Agent 工作流的启发

HelloAIFlow 关注 Fugu，不是因为它来自日本本身，而是因为它把 AI Agent 的一个关键问题讲清楚了：真正复杂的任务，不一定应该交给一个模型从头做到尾。

未来更现实的工作流可能是：一个模型负责规划，一个模型负责写代码，一个模型负责测试，一个模型负责安全审查，一个模型负责把过程整理成文档。真正的产品竞争点，会从“模型会不会回答”变成“系统会不会组织模型一起完成任务”。

对个人用户来说，这个方向也有实际启发。即使你现在没有 Fugu，也可以在 Codex、Claude、Qwen、GLM 或本地模型之间形成分工：让不同工具承担不同阶段，再用一个主 Agent 负责集成和验收。这比盲目追逐单一最强模型更稳。

参考来源

• Sakana Fugu — Multi-Agent System as a Model
• Sakana Fugu Technical Report