Sakana Fugu 上线：AI 竞争开始从单一模型走向模型编排

Sakana Fugu 不是又一个普通模型发布。

它更像一个信号：AI 基础设施正在换方向。

6 月 22 日，Sakana AI 发布 Sakana Fugu，把它描述为一个“像单一模型 API 一样使用的多 Agent 编排系统”。开发者只发送一个请求。背后，Fugu 可以决定是直接回答，还是把子任务委派给一组专家模型，验证中间结果，再综合成最终答案。

同时发布的 Fugu Ultra 面向更难的多步骤任务。两个模型都通过一个 OpenAI-compatible API 使用。

这件事重要，是因为企业 AI 的问题正在变化。

过去两年，大家一直问：哪个模型最强？

Fugu 问的是另一个问题：当一个模型不够用、太贵、不可用，或者不适合长期依赖时，谁来调度这些模型？

Sakana Fugu 是什么

Sakana 对 Fugu 的定义是：一个像单一模型一样工作的多 Agent 系统。外部看，你调用一个 endpoint。内部，系统处理模型选择、任务委派、结果验证和综合输出。

发布页给它的说法是 “one model to command them all”。重点不是 Fugu 替代所有 frontier models，而是 Fugu 试图学习什么时候该用哪个模型，什么时候该委派，怎么把多方结果合成一个答案。

Sakana 说，Fugu 本身也是一个语言模型，被训练来调用 agent pool 里的各种 LLM，甚至可以递归调用自己。它背后的研究线索来自 TRINITY 和 Conductor 这类 learned orchestration 工作。

这让 Fugu 和普通 model router 不太一样。

普通 router 通常是：一个请求，选一个模型。

Fugu 更像 conductor。它可能拆任务、调多个 Agent、验证结果，再返回一个答案。

为什么这个时间点重要

时间点很关键。

Sakana 在发布中明确提到了 single-vendor dependency，以及 Anthropic Fable / Mythos 访问变化带来的风险。VentureBeat 也把这次发布放在同一个背景下讨论：如果顶级模型的访问会因为监管、出口管制、价格、政策或供应商策略变化而突然改变，那关键 workflow 就不应该永远押在一个供应商身上。

这是云计算时代的那堂课，回到了 AI 里。

企业早就学会了，不能把连续性计划只押在一台服务器、一个 region、一个 vendor 上。

AI 现在也走到这一步。

如果一个 workflow 依赖单一模型，它就继承了这个模型的价格、限流、政策、区域限制、宕机、质量波动和路线图风险。

简单任务可以接受。

关键流程就会变成供应链风险。

模型路由不等于模型编排

模型路由已经不陌生。

router 可以把简单问题交给便宜模型，把代码任务交给代码模型，把长文档交给长上下文模型，把困难推理交给高价模型。

这很有用，但它主要还是一次选择。

编排更宽。它问的是：系统如何拆解任务，如何协调专家，如何验证，如何失败后重试，以及什么证据足够支撑最终答案。

一个真实的 Agent workflow 可能包括：

• planner 拆任务；
• coding model 写实现或草稿；
• verifier 检查逻辑；
• 工具或测试环境跑一遍；
• summarizer 包装结果；
• 敏感动作前的人类 review checkpoint。

Fugu 的商业动作，是把这些复杂度尽量藏到一个 API 后面。

这对开发者很有吸引力。

但它也带来治理问题。

坑也在产品故事里

Fugu 的优势和风险是绑在一起的。

第一，它降低了表面复杂度，但 routing 并不完全透明。Sakana 说具体 worker models 和协调方式是 proprietary。这作为产品 IP 可以理解，但受监管团队会问：哪些模型看过哪些数据？出错时怎么审计？

第二，编排可能提升结果，也可能隐藏成本。Fugu Ultra 有公开价格，VentureBeat 也提到 orchestration tokens 可能计入最终 usage。最终答案很短，不代表内部链路很短。

第三，benchmark 很漂亮，但不能直接当采购结论。Sakana 的跑分在 coding、reasoning、science、agentic tasks 上提供了早期信号，但团队仍然要在自己的代码库、文档、权限、失败场景、延迟目标和成本边界里测试。

团队应该从 Fugu 学到什么

最稳妥的结论不是“Fugu 赢了”。

更稳妥的结论是：单模型依赖越来越难防守。

团队应该开始从五层评估 AI 系统：

1. 模型质量 哪些模型足够胜任哪些工作？

2. 模型可替换性 如果一个模型涨价、限流、降质、改政策或不可用，workflow 能不能继续？

3. 编排可见性 团队能不能看到任务怎么被路由、用了哪些工具、失败发生在哪里？

4. 单次完成成本 系统是否真的减少 retry 和人工清理，还是只是把 token 消耗藏在更漂亮的界面背后？

5. 人类审核 哪些节点需要人批准、拒绝或重新定向？

这就是 AI 基础设施开始运营化的地方。

资产不再只是模型。

资产是模型周围的 workflow。

这和 Buda 有什么关系

Buda 正是为这个变化而设计的。

一个 AI Agent Workspace 不应该把团队锁死在某个模型身份上。它应该保存团队自己的上下文、流程、skills、审批、logs 和 review 习惯，即使底层模型发生变化。

这也是为什么 Buda 关注工作层：sessions、Drive、工具、browser 和 terminal 执行、channels、skills、人类 review。

模型可以换。

但被认真结构化、review、迭代过的 workflow，不应该因为底层模型变化而消失。

Fugu 从模型侧说明了同一个方向：编排很重要。

Buda 从工作空间侧补上另一半：编排必须可见、可管理，并由人类主导。

下一轮 AI 竞争，不只是谁训练出最强模型。

而是谁能把很多模型、工具、Agent 和人，组织成稳定产出。

Sakana Fugu 常见问题

Sakana Fugu 是什么？ Sakana Fugu 是一个通过 OpenAI-compatible API 提供的多 Agent 编排模型。开发者看起来是在调用一个模型，但背后可以协调多个模型和 Agent。

多模型编排和普通模型路由有什么区别？ 模型路由通常是“一个请求选一个模型”。多模型编排可以拆任务、委派子任务、验证中间结果、失败后重试，并把结果综合成最终答案。

企业为什么不能只依赖一个大模型？ 单模型依赖会继承一个供应商的价格、政策、地区访问、限流、宕机和质量波动。对关键流程来说，这就是 AI 供应链风险。

模型路由会不会成为 AI 应用的新基础设施？ 会，尤其是复杂工作流。当团队同时使用多个模型、工具、Agent 和审核节点时，编排层会变成管理可靠性、成本和治理的关键位置。

在 Buda dashboard 探索人类主导的 Agent 工作流，或阅读 Buda Agent Workspace 文档。