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 文件。