20260625-02 | EP348 - 日本模型空降AI前段班?Sakana Fugu 評測超越 Mythos!?單一模型時代結束了?如何用多代理協調系統,讓 AI 效能翻倍成長?
來源:Youtube | 建立:2026-06-25T10:08:54 | HTML:2026-06-25T10:11:42
開啟原始影片 note.md transcript.txt transcript.vtt

影片筆記:EP348 - 日本模型空降AI前段班?Sakana Fugu 評測超越 Mythos!?單一模型時代結束了?如何用多代理協調系統,讓 AI 效能翻倍成長?

YouTube 影片框會固定在左上方;點擊右側逐字稿時間戳可跳到對應時間。

一句話總結

影片探討了 AI 競爭焦點從「單一模型能力」轉向「系統架構與多代理協調」的趨勢,重點分析了 Sakana AI 的 Fugu Ultra 系統如何透過協調多個模型在基準測試中超越單一頂尖模型,但指出其在實際軟體工程任務中面臨高昂成本與延遲的問題,同時披露了 Anthropic 與 OpenAI 最新模型的洩漏資訊與能力升級。

核心重點

Sakana AI 的 Fugu Ultra 系統

Anthropic 的模型動態

OpenAI 的新功能與模型

未來趨勢

詳細大綱

一、 Sakana AI 與 Fugu Ultra 系統解析

二、 Anthropic 的模型發展與審查現狀

三、 OpenAI 的新模型與語音升級

四、 總結與未來趨勢

工具 / 模型 / 名詞整理

操作流程整理

Sakana Fugu 系統運作流程

Claude Sonnet 5 新分詞器應用流程

OpenAI 新模型 3D 生成流程

GPT-BDI 1 語音互動流程

值得注意的限制或風險

Sakana Fugu 的成本與效率問題

Claude Sonnet 5 的 Token 消耗

Mythos 6 的可用性

OpenAI 新模型的技術挑戰

自主代理的成本失控風險

逐字稿辨識疑點

逐字稿時間軸

右側可一路往下捲;左側影片框會固定。點擊時間戳會讓左側影片跳到對應秒數。

00:00:00.000 → 00:00:04.109
每天都有一堆新的AI工具冒出來 是不是常常不知道該從哪裡開始
00:00:04.540 → 00:00:06.616
別擔心這裡是AI懶人報
00:00:06.616 → 00:00:13.222
每天幫你精選五個最多人討論的AI工具影片 每天十分鐘讓AI走進你的生活中
00:00:13.222 → 00:00:17.017
讓你不知不覺成為效率大師 今天最有趣的是
00:00:17.017 → 00:00:23.342
Sakana AI 不是靠單一超強模型翻盤 而是做了一個很會分工的AI經理人
00:00:23.560 → 00:00:28.745
這件事如果跑順未來我們用AI寫程式 可能就不是自己下指令
00:00:28.745 → 00:00:33.828
而是在管理一整隊模型 好那我們就從今天的重頭戲說起吧
00:00:34.040 → 00:00:36.231
如果你這禮拜有在關注開發者社群
00:00:36.231 → 00:00:43.095
你一定會看到一個叫做 Sakana AI 的日本新創公司 還有他們的新產品 Fugu Ultra
00:00:43.095 → 00:00:47.889
在網路上引起了超級大的討論 Fugu Ultra 官方宣稱的資料非常驚人
00:00:47.889 → 00:00:53.079
他們說 Fugu Ultra 在一系列的基準測試中 表現超越了 Fable 5 和 Mythos
00:00:53.183 → 00:00:57.740
這些測試可不是普通的測試喔 像是 SWE Bench Pro
00:00:57.740 → 00:01:04.025
它是目前軟體工程任務的黃金標準 Fugu Ultra 在上面拿到了 737 的分數
00:01:04.300 → 00:01:10.914
你知道 Claude Opus 48 才 692 嗎 在另一個叫 LiveCodeBench 的測試裡
00:01:10.914 → 00:01:15.900
Fugu Ultra 更猛直接衝到 932 把 Opus 48 遠遠甩在後面
00:01:16.100 → 00:01:22.357
它不只在這些專業的程式碼測試上表現亮眼 連在研究生等級的科學推理終端機操作
00:01:22.357 → 00:01:27.501
還有多代理任務上都表現得非常出色 但是這裡就有一個很關鍵的點
00:01:27.501 → 00:01:33.139
你必須深入瞭解一下 因為 Fugu Ultra 跟你想像的完全不一樣
00:01:33.260 → 00:01:37.454
它不是那種 Sakana AI 在東京的地下室 從零開始訓練出來
00:01:37.454 → 00:01:42.100
然後就神奇地把 Anthropic 和 OpenAI 嚇跑的超大型基礎模型 完全不是
00:01:43.460 → 00:01:47.850
Fugu Ultra 其實是一個多代理協調系統 但它特別的地方在於
00:01:47.850 → 00:01:53.028
你只需要透過一個單一模型的 API 就可以呼叫它 這個區別非常重要
00:01:53.780 → 00:01:59.454
當你呼叫 Fugu Ultra 的 API 時 你不是在跟一個單一的類神經網路對話
00:01:59.454 → 00:02:04.437
你其實是在跟一個高度最佳化的指揮家互動 這個指揮家會接收你的指令
00:02:04.437 → 00:02:06.643
把任務拆解成很多小的子任務
00:02:06.643 → 00:02:14.280
然後把這些子任務分派給它背後預先串接好的 各種現有的頂尖模型像是 GPT-55Opus 48
00:02:14.280 → 00:02:21.170
Gemini 31 Pro 等等 最後它會綜合評估驗證這些模型的結果
00:02:21.170 → 00:02:25.979
然後才把最終的成果交給你 你可以把它想像成一個管絃樂團
00:02:26.300 → 00:02:33.222
樂團指揮不需要比首席小提琴手更會拉小提琴 他只需要知道小提琴什麼時候該進場
00:02:33.222 → 00:02:39.306
銅管什麼時候該加強音量還有誰走音了 順帶一提Sakana AI 的共同創辦人之一
00:02:40.559 → 00:02:47.173
他可是當年那篇傳奇論文Attention Is All You Need的作者之一喔 Fugu 這個系統
00:02:47.173 → 00:02:52.038
是他們基於兩篇非常有趣的論文打造出來的 第一篇論文提出了一個框架
00:02:52.038 → 00:02:55.993
就是用一個比較小 效率高的 AI 來扮演經理人的角色
00:02:55.993 → 00:03:03.586
然後它會給大型模型分配三個特定的角色思想家Thinker 製造者Maker和驗證者Verifier
00:03:03.960 → 00:03:10.086
思想家負責分析問題和制定計畫 製造者負責寫程式或執行計算
00:03:10.086 → 00:03:15.991
而驗證者則負責檢查工作成果 但第二篇論文才是真正厲害的地方
00:03:16.160 → 00:03:21.697
這個系統會利用演化演算法和強化學習 自動去最佳化那個 AI 經理人
00:03:21.697 → 00:03:25.576
給子代理們下達的提示詞prompt 也就是說
00:03:25.576 → 00:03:31.493
不是人類工程師去寫這些協調系統的提示詞 而是這個 AI 透過不斷的試錯
00:03:31.493 → 00:03:37.379
學習到如何最有效地跟其他 AI 溝通 它會保留那些有效的方法
00:03:37.379 → 00:03:42.185
然後淘汰掉那些沒用的這整個過程 就跟自然選擇一樣
00:03:42.440 → 00:03:48.873
說真的我想我們很多人都有過這種經驗對不對 你可能對自動化非常著迷花了三個小時
00:03:48.873 → 00:03:53.436
在自己的環境裡搭了一個超複雜 超精密的多代理迴圈
00:03:53.880 → 00:03:59.638
你給它設定了專門的子代理批評迴圈 還有記憶向量資料庫
00:04:00.060 → 00:04:04.482
然後你按下確認鍵坐下來 看著終端機亮起來各種平行處理在跑
00:04:04.960 → 00:04:06.093
結果四十五分鐘後
00:04:06.093 → 00:04:13.843
它吐出來的只是一個你十分鐘就可以自己寫出來的基本 React 元件 你花在設計自動化流程的時間和金錢
00:04:13.843 → 00:04:19.471
比手動完成這個任務還要多上好幾倍 而這也正是 Fugu Ultra 的兩面刃
00:04:19.620 → 00:04:24.827
當你在真實世界情境中測試它時 那些基準測試的漂亮資料
00:04:24.827 → 00:04:29.456
就開始出現裂痕了 沒錯它確實可以產生非常驚人的結果
00:04:29.640 → 00:04:33.269
在一個盲棋測試中 模型必須在沒有看到棋盤的情況下
00:04:33.269 → 00:04:35.320
只靠記憶來維護整個棋局狀態
00:04:35.320 → 00:04:45.235
Fugu 連續跟其他頂尖模型還有一個 2100 ELO 等級的 Stockfish 引擎下了四盤棋 它始終保持完美的精準度
00:04:45.235 → 00:04:50.785
而其他模型則開始混亂或出現幻覺 Fugu 最終每一盤都將死對方
00:04:51.260 → 00:04:56.384
它還解決了 Rubiks cube 的 300 個謎題 其他模型都是零分
00:04:56.384 → 00:05:01.624
但 Fugu 也是 300 題全對 但是在日常的軟體工程流程中
00:05:01.624 → 00:05:06.991
這種協調的額外負擔代價非常大 不只是金錢上的還有時間上的
00:05:07.200 → 00:05:12.826
在一個針對 38 個不同複雜程式碼任務 謎題和演算法設計的大規模對比測試中
00:05:12.826 → 00:05:18.938
Fugu Ultra 在幾乎所有專案上都跟 Opus 48 打成平手 但是
00:05:18.938 → 00:05:23.655
Fugu 完成任務所需的時間比 Opus 多了四倍半 成本更是高出五倍
00:05:24.260 → 00:05:29.220
我們在講的是Fugu 總共花了 357 分鐘 而 Opus 只花了 80 分鐘
00:05:29.760 → 00:05:34.881
一個 Opus 六秒就能搞定的任務 Fugu 可能要花好幾分鐘
00:05:34.881 → 00:05:39.319
因為它必須把任務丟給它的思想家 製造者和驗證者迴圈一輪
00:05:39.520 → 00:05:46.970
我們來看一個實際的例子打造一個完整的即時交易臺 包含前端和後端元件即時市場資料
00:05:46.970 → 00:05:53.123
還有一個客製化的深色主題介面 Fugu Ultra 確實交付了一個最精美
00:05:53.123 → 00:05:57.064
功能最豐富的介面 但它燒掉了 22000 個 token
00:05:57.064 → 00:06:03.119
成本是 51 美分 Opus 48 也做得很好 用了 16000 個 token成本 31 美分
00:06:03.940 → 00:06:07.349
但最關鍵的是 如果你只是想要一個超棒的前端設計
00:06:07.349 → 00:06:13.083
GLM 52 或是 Chinchilla 52 只要大約 3 美分就能搞定
00:06:13.600 → 00:06:16.485
在另一個複製遊戲 Crossy Road 的測試中
00:06:16.485 → 00:06:23.151
Fugu Ultra 在效率上竟然打敗了 Opus 48 Opus 燒掉了將近一百萬個 token
00:06:23.151 → 00:06:27.065
花了 79 分鐘 成本高達 37 美元才把遊戲做出來
00:06:27.065 → 00:06:31.903
雖然成品非常精美 而 Fugu 只花了 22 分鐘成本 732 美元
00:06:33.040 → 00:06:38.092
但是Fugu 做出來的版本操作是反向的 攝影機怪怪的而且還缺少音效
00:06:38.880 → 00:06:44.939
所以Sakana Fugu 到底有什麼實際用途呢 如果它只是一個加強版的 API 包裝
00:06:44.939 → 00:06:46.990
我們為什麼要關注它呢 首先
00:06:46.990 → 00:06:55.136
它完美展示了我們未來的 IDE整合開發環境和本地環境會長什麼樣子 我們正在從寫程式的工程師
00:06:55.136 → 00:07:01.442
轉變為管理系統的協調者 Fugu 證明瞭 如果你有一個很棒的路由和驗證系統
00:07:01.442 → 00:07:05.583
你可以把現有模型的能力 推向遠超它們原生極限的境界
00:07:05.800 → 00:07:08.104
第二點這對企業來說可能更重要
00:07:08.104 → 00:07:11.561
Fugu 代表了一個巨大的地緣政治避險策略
00:07:11.860 → 00:07:17.931
Sakana 明確地將 Fugu 定位為提供頂尖能力 同時沒有出口管制風險的產品
00:07:18.160 → 00:07:24.043
假設你公司的客服系統全部綁死某個美國模型 一旦 API 因法規停掉
00:07:24.043 → 00:07:29.008
整條客服流程就卡住 多代理系統至少能把任務改丟給其他模型
00:07:29.008 → 00:07:33.448
這樣你就分散了風險 如果某個模型掛了或被限制
00:07:33.448 → 00:07:38.315
協調器會自動繞過它 把任務分配給其他模型 當然諷刺的是
00:07:38.315 → 00:07:47.766
Fugu 本身目前在某些歐洲地區也因為 GDPR 和法規限制而無法使用 所以這個避險策略還不夠完美
00:07:47.980 → 00:07:50.780
那到底 Sakana Fugu 的結論是什麼呢
00:07:50.960 → 00:07:56.339
它在系統設計方面是一個令人驚嘆的工程成就 但對於你日常使用來說
00:07:56.339 → 00:08:02.416
如果你是一個單打獨鬥的創業者 或者是一個想快速推進專案的資深開發者
00:08:02.416 → 00:08:09.346
你可能還是手動協調自己的流程會比較好 例如用 GPT-55 來處理複雜的邏輯
00:08:09.346 → 00:08:15.824
用 GLM 52 來生成便宜的前端介面 然後用 Opus 48 來做架構規劃
00:08:16.140 → 00:08:21.228
你自己管理這些成本效益 但還是要持續關注 Sakana
00:08:21.228 → 00:08:26.683
因為一旦他們優化了這種協調的延遲問題 那真的會改變整個遊戲規則
00:08:27.220 → 00:08:33.075
好剛剛我們聊到 Sakana Fugu 證明瞭 你可以透過巧妙的系統設計
00:08:33.075 → 00:08:36.361
把現有模型的能力發揮到極致 這個概念
00:08:36.361 → 00:08:40.281
也完美地銜接到 Anthropic 那邊正在發生的事情
00:08:40.520 → 00:08:47.050
雖然 Sakana 證明瞭你可以透過精巧的協調來硬幹出智慧 但那些正在開發基礎模型的實驗室
00:08:47.050 → 00:08:53.767
可沒有閒著 但最近
00:08:53.767 → 00:09:00.304
一個新的模型名稱Claude Sonnet 5出現在 Anthropic 合作夥伴的系統中 我們大概有一段時間沒有聊到 Sonnet 了
00:09:00.304 → 00:09:04.608
這裡快速幫大家複習一下 在 Claude 的生態系統中
00:09:04.608 → 00:09:10.265
Sonnet 是一個中階的主力模型 在複雜的代理流程中例如 Claude Code
00:09:10.265 → 00:09:14.222
你通常會用 Opus 來做高階的架構規劃 然後再啟動 Sonnet 來作為執行工作者
00:09:14.222 → 00:09:23.997
處理那些成本較低速度較快的任務 通常 當一個模型名稱洩漏到合作夥伴的系統中
00:09:23.997 → 00:09:28.285
這代表它很快就要推出了 早期的測試顯示
00:09:28.285 → 00:09:29.683
Sonnet 5 將會是一個巨大的升級
00:09:30.220 → 00:09:36.803
我們預期它會有 1 到 2 百萬 token 的脈絡長度context window 顯著提升的視覺能力
00:09:36.803 → 00:09:41.443
以及對介面設計稿和架構圖更強的理解能力 但是這裡有一個關鍵的點
00:09:41.443 → 00:09:46.820
又回到我們對代幣經濟的執著了 有報導指出
00:09:46.820 → 00:09:52.414
Anthropic 在 Sonnet 5 上使用了一種新的分詞器tokenizer 這種新的分詞器對於完全相同的提示詞
00:09:52.414 → 00:09:57.582
可能會比舊模型多消耗高達 30 的 token 乍聽之下
00:09:57.582 → 00:10:01.922
這對你的 API 預算來說好像很糟糕 但這個取捨是
00:10:01.922 → 00:10:07.695
這種分詞器讓模型能夠以更強大的推理能力和多模態理解能力來處理資訊
00:10:08.420 → 00:10:13.017
這是一個經典的工程學權衡你在輸入端燒掉更多的 token
00:10:13.017 → 00:10:22.211
但你在輸出端獲得一次成功率zero-shot success的機率會大大提高 這就減少了需要無止盡高成本的修改迴圈
00:10:24.864 → 00:10:27.524
我們看到一個洩漏的演示 Sonnet 5 僅僅從一個提示詞
00:10:27.524 → 00:10:28.854
沒有參考圖片就生成了一個完美
00:10:28.854 → 00:10:35.498
高度詳細的 Nintendo Switch 2 的 SVG 圖檔 它的設計品味和空間推理能力都非常驚人
00:10:36.040 → 00:10:38.472
但 Anthropic 那邊正在醞釀的可不止 Sonnet 5
00:10:38.728 → 00:10:47.773
這就牽扯到 AI 開發的審查現實有多麼嚴峻了 我們知道Anthropic 的 Fable 5 架構
00:10:47.773 → 00:10:50.737
那個能夠執行超狂 長週期自主代理流程的模型
00:10:50.737 → 00:10:55.314
目前因為審查問題而停用了 但一個模型被限制公開 API 存取
00:10:55.314 → 00:11:00.359
不代表實驗室就會停止工作 事實上這反而釋放了大量的運算資源
00:11:00.359 → 00:11:02.624
這些資源原本是用於推理的
00:11:02.624 → 00:11:07.355
現在他們可以把這些資源全部轉移到訓練上 根據可靠的洩漏
00:11:07.355 → 00:11:12.367
一個新版本的 Mythos 架構 很可能是 Mythos 6已經訓練完成了
00:11:12.520 → 00:11:17.670
據說它的能力比已經被限制的 Fable 5 還要強大得多 我們在說的是
00:11:17.670 → 00:11:23.505
它具備了更高層次的長週期推理能力 改進的多步驟規劃能力以及在處理大規模
00:11:23.505 → 00:11:27.280
整個程式碼庫遷移任務時 擁有高度可靠的執行能力
00:11:27.620 → 00:11:32.180
但關鍵是它已經被限制了 現在大模型公司的競爭
00:11:32.180 → 00:11:36.319
已經不只是誰模型更強 那些在幕後開發的模型
00:11:36.319 → 00:11:42.233
現在在自主執行方面已經強大到 它們在公開之前就觸發了法規門檻
00:11:42.440 → 00:11:48.472
Anthropic 正在利用這些內部模型 來找出需要在系統中建立哪些防護措施
00:11:48.472 → 00:11:54.854
以防止未來再次被限制 現在的問題是 他們是否會將 Mythos 6 公開釋出
00:11:54.854 → 00:11:59.328
或者它將僅用於內部 生成合成資料並加速訓練接下來的模型
00:12:00.000 → 00:12:04.470
當 Anthropic 正在努力應對這個複雜的審查迷宮時
00:12:04.470 → 00:12:11.088
OpenAI 卻只是輕輕鬆鬆地準備推出他們自己的能力明顯往上跳一階的產品 有洩漏指出
00:12:11.088 → 00:12:14.882
OpenAI 準備在本週推出一個新模型 有趣的是
00:12:14.882 → 00:12:20.477
這些洩漏對於模型的命名方式意見分歧 有些來源稱它為 GPT-46
00:12:20.477 → 00:12:26.974
而其他深入測試則稱它為一個功能非常強大的檢查點 叫做 GPT-56 Pro
00:12:27.180 → 00:12:28.354
無論最終產品上的版本號是什麼
00:12:28.354 → 00:12:31.373
我們從內部代號為Kindle Alpha的檢查點中看到的這些能力 都非常狂
00:12:33.973 → 00:12:39.629
我們一直都在討論 AI 程式碼編寫的摩擦問題 像是模型會偷懶
00:12:39.629 → 00:12:45.284
會給你請在此處插入其餘程式碼這樣的佔位符 以及它們在處理複雜
00:12:45.284 → 00:12:52.010
有狀態的介面時會遇到困難 然而 一個關於 GPT-56 Pro 的洩漏測試顯示
00:12:52.010 → 00:12:57.013
這個模型竟然能生成一個完整可遊玩的 第一人稱的 3D 室內房屋
00:12:57.460 → 00:13:03.991
它建立了一個連貫的平面圖詳細的房間 以及一個流暢的第一人稱移動系統 而且
00:13:03.991 → 00:13:13.528
它是在一個單一的 700KB 的 HTML 檔案中完成所有這些的 它大約花了 40 分鐘的運算時間來生成
00:13:13.528 → 00:13:18.676
但它沒有偷懶沒有中途停止 它完美地執行了一個複雜有創意
00:13:18.676 → 00:13:20.183
高度技術性的願景
00:13:20.660 → 00:13:27.779
這正是你如果想要信任 AI 在你的程式碼庫中扮演自主代理時 所需要的這種不偷懶
00:13:27.779 → 00:13:30.979
以目標為導向的執行能力 除此之外
00:13:30.979 → 00:13:37.270
OpenAI 還將對他們的語音互動進行大規模升級 自從 GPT-4 Omni 推出以來
00:13:37.270 → 00:13:42.749
語音助理領域一直在等待下一個大事件 現在GPT-BDI 1 語音模型登場了
00:13:42.940 → 00:13:48.578
這是一個文字轉語音的升級 更是模型處理即時音訊方式的根本性轉變
00:13:49.000 → 00:13:50.410
這個 BDI 模型
00:13:50.410 → 00:13:55.422
它的知識截止日期是更新到 2025 年 8 月 可以跟你流暢地互動
00:13:56.020 → 00:14:02.174
你不需要等它說完話你可以自然地打斷它 它會立即調整 在一個演示中
00:14:02.174 → 00:14:07.839
使用者要求模型計算一個冗長 語速很快的故事中提到的食物數量
00:14:08.480 → 00:14:13.880
模型即時聆聽處理音訊 並在中途準確地捕捉和計算了這些物品
00:14:13.880 → 00:14:18.233
沒有漏掉任何一個 這感覺非常像人類的互動
00:14:18.680 → 00:14:23.145
雖然這看起來可能只是一個有趣的消費者功能 但想想它對系統設計的影響
00:14:23.640 → 00:14:30.373
我們正朝著一個這樣的世界邁進你與本地代理作業系統的互動 不再只是在終端機中打字
00:14:30.840 → 00:14:37.614
它會是一個持續即時的語音對話 你邊口頭規劃系統AI 則在背景執行它們
00:14:37.820 → 00:14:40.162
當你把所有這些事情放在一起看
00:14:40.162 → 00:14:45.014
Sakana 的 Fugu 證明瞭協調系統可以媲美頂尖模型
00:14:45.014 → 00:14:49.029
Anthropic 在暗中訓練著被限制的超級模型
00:14:49.029 → 00:14:56.055
而 OpenAI 則推出了零樣本的 3D 環境和即時語音功能 這個發展趨勢就非常清楚了
00:14:56.220 → 00:15:02.509
技術優勢不再是誰能寫出最好的提示詞 而是誰更懂得系統架構 白話說
00:15:02.509 → 00:15:07.625
就是同一件事到底該丟給哪個模型做 要花多少錢做完誰來檢查
00:15:08.160 → 00:15:14.521
誰知道什麼時候該用像 Chinchilla 52 這樣便宜又快的模型來做簡單的介面
00:15:14.521 → 00:15:21.193
什麼時候該部署像 Fugu 這樣的協調器來處理複雜的多步驟推理任務 以及如何管理代幣經濟
00:15:21.193 → 00:15:27.581
才不會讓你的自主代理在你睡覺的時候把你搞到破產 如果你覺得今天的內容讓你有點收穫
00:15:27.581 → 00:15:32.737
那就幫我到 Apple Podcast 按讚追蹤 留個五星好評吧
00:15:33.080 → 00:15:40.117
FBIGThreads 搜AI懶人報就找得到我了 你的支援是讓我持續最佳化內容的最大動力
00:15:40.840 → 00:15:43.534
今天的AI懶人報就報到這我是湯懶懶 我們明天見掰啦