影片筆記：当AI学会了管理，普通模型涌现专家能力

一句話總結

日本 AI 公司 Sakana AI 提出 Fugu（河豚）模型，透過強化學習訓練模型具備「管理能力」，調度多個開源與閉源模型協作，在複雜任務中湧現出超越單一強大模型的專家能力。

核心重點

1. Fugu 模型的本質：Fugu 並非傳統意義上單一參數量巨大的「天才模型」，而是基於集體智慧（Collective Intelligence）與強化學習（Reinforcement Learning）訓練出的具備「管理能力」的模型。其核心在於能夠調度、組織並協同多個開源與閉源模型進行工作。
2. 兩篇支撐論文：

• Trinity：針對簡單任務調度。通過識別上下文，將模型劃分為思考者（Thinker）、執行者（Worker）與驗證者（Verifier）三種角色，由一個小參數量（0.6B）模型作為「生產線經理」進行即時調度。
• Conductor：針對複雜任務的多智能體協作。類似指揮家，通過強化學習訓練出一個約 7B 參數的模型，負責規劃多個 Agent 的角色、信息交互與譜系結構，類似「職業經理人」。

1. Harness Engineering（編排工程）的演進：Fugu 將傳統透過編排（Orchestration）實現的多智能體協作能力沉澱在模型內部。這使得模型具備泛化能力，能在未見過的任務上產出良好水平，並在交易收益、魔方還原速度等測試中表現優異。
2. 未來展望：

• 集體智慧 vs. 單個天才：講者認為從「超級個體」到「超級團隊」是演變趨勢。雖然協作能拉高上限，但單個天才模型（如 Fugu 5）與一堆普通模型的價值差異巨大。未來數據中心將是「天才之國」，集體智慧與天才模型將長期共存。
• 軟體公司的轉型：未來軟體公司將轉變為「模型公司」，價值在於針對特定場景、數據、條件，調用多個模型解決問題，在效率、成本、速度間取得平衡。
• 開發者角色變化：手寫 Multi Agent 約束的重要性降低，人類注意力可解脫，轉向更擅長的端到端及線下事務。OpenAI 將 HCI 實現劃分的第五級定義為 Organizer（協調者/組織者），Sakana AI 在此方向取得突破。

詳細大綱

I. Sakana AI 與 Fugu 模型介紹

• 公司背景：
• Sakana AI 被認為是日本最有希望的 AI 公司。
• 兩位創始人背景：一位來自 Google Brain（負責複雜系統研究），另一位是 Transformer 論文（Attention is all you need）的八位作者之一。
• 核心理念：從自然界（魚群、風群、自組織、湧現、集體智慧）中學習，啟發模型研發。
• Fugu 模型特點：
• 名稱含義：河豚。
• 本質：非單一強天才模型，而是靠訓練模型的管理能力強化出來的全新模型。
• 能力：組織調度開源和閉源模型，協同工作。
• 表現：在各種評測中表現優異，超過 OPUS 4.8、FUGU5、NESOS，並在 Humanity Last Exam 上超過 Gemini 3.1 Pro。

II. 背後的兩篇論文與技術路線

• 論文一：Trinity
• 目標：探索模型在簡單任務調度中的快速響應。
• 方法：通過演化方法探索路徑，讓模型識別下一步操作應由哪個模型以何種身份參與。
• 角色劃分：

1. Thinker（思考者）
2. Worker（執行者）
3. Verifier（驗證者）

• 架構：0.6B 小模型，通過上下文感知識別狀態，類似生產線上的「排班經理」。
• 論文二：Conductor
• 目標：複雜任務中的多智能體（Multi Agent System）協作。
• 方法：類似指揮家，進行任務拆解、角色規劃、信息交互與譜系結構設計。
• 架構：約 7B 模型，類似「職業經理人」。
• 訓練方式：通過強化學習給予激勵，若調度不同模型產生好結果則給予獎勵，從而提升調度能力。

III. 與 Harness Engineering 的關聯與比較

• Harness Engineering：
• 當前做法：通過編排（Orchestration）實現多智能體協作。
• 案例：Workbody 中的股票交易專家，通過不同模型（唱空、唱多、基本面分析、技術形分析）進行判斷。
• Fugu 的優勢：
• 將 Harness 的能力沉澱在模型中。
• 具備泛化能力：在未見過的任務上也能產出良好水平。
• 架構：復古（Fugu）模型架構，可訪問開源、閉源及自身模型。
• 評估場景：交易收益、魔方還原速度等測試中表現優異。

IV. 未來展望與哲學思考

• 集體智慧 vs. 單個天才：
• 從「超級個體」到「超級團隊」的演變。
• 協作可以拉高上限，但單個天才模型（如 Fugu 5）與一堆普通人（模型）的價值差異巨大（十倍、幾十倍）。
• 未來數據中心將是「天才之國」，集體智慧與天才模型並存。
• 軟體公司的未來形態：
• 未來軟體公司將變成「模型公司」。
• 價值在於：針對特定場景、數據、條件，調用多個模型解決問題，在效率、成本、速度間取得平衡。
• 通用 Conductor（如 Fuku 公司提供）與專用場景優化（軟體公司）將同時存在。
• 對開發者的影響：
• 手寫 Multi Agent 約束的重要性降低。
• 人類注意力可解脫，轉向更擅長的端到端及線下事務。
• OpenAI 將 HCI 實現劃分的第五級：Organizer（協調者/組織者），Sakana AI 在此方向取得突破。

工具 / 模型 / 名詞整理

• Sakana AI：日本 AI 公司。
• Fugu：Sakana AI 提出的模型名稱（意為河豚）。
• OPUS 4.8：評測對比對象。
• FUGU5：評測對比對象。
• NESOS：評測對比對象。
• Humanity Last Exam：評測項目名稱。
• Gemini 3.1 Pro：評測對比對象。
• Trinity：支撐 Fugu 的其中一篇論文名稱。
• Conductor：支撐 Fugu 的另一篇論文名稱。
• Google Brain：創始人背景機構。
• Attention is all you need：Transformer 論文名稱。
• Transformer：模型架構名稱。
• Multi Agent System：多智能體系統。
• Workbody：提及的編排案例或平台名稱。
• Fuku：講者口語中提及的公司或產品名稱（疑點：可能指 Sakana AI 或 Fugu 的誤讀/口誤）。
• OpenAI：提及的 AI 公司。
• HCI：講者提及的 OpenAI 劃分等級中的概念（疑點：具體含義需查證，逐字稿中未明確展開）。
• 必源模型：逐字稿中與「閉源模型」混用或並列出現（疑點：聽寫錯誤或口誤）。
• 阿茂 Day：講者提及的人物或概念（疑點：聽寫錯誤）。
• 地規：講者提到的架構名稱（疑點：聽寫錯誤）。
• 魚形：講者提到的分析對象（疑點：聽寫錯誤）。

操作流程整理

1. 任務輸入：系統接收簡單或複雜任務。
2. 角色識別與調度：

• 簡單任務（Trinity 架構）：0.6B 小模型識別上下文狀態，將任務劃分為思考者（Thinker）、執行者（Worker）與驗證者（Verifier）角色，進行即時調度。
• 複雜任務（Conductor 架構）：約 7B 模型作為「職業經理人」，進行任務拆解、角色規劃、信息交互與譜系結構設計。

1. 模型協作：調度多個開源、閉源及自身模型進行協同工作。
2. 強化學習訓練：

• 通過強化學習給予激勵。
• 若調度不同模型產生好結果則給予獎勵，從而提升調度能力。

1. 結果輸出：在交易收益、魔方還原速度等測試場景中輸出結果。

值得注意的限制或風險

• 模型泛化能力：雖然 Fugu 具備泛化能力，但在未見過的任務上是否能持續產出良好水平仍需觀察。
• 單一模型與集體智慧的價值差異：講者指出單個天才模型（如 Fugu 5）與一堆普通模型的價值差異巨大（十倍、幾十倍），這暗示集體智慧方法可能在某些極端場景下不如單一強大模型。
• 軟體公司轉型挑戰：未來軟體公司需轉變為「模型公司」，這要求企業具備針對特定場景調用多個模型的能力，並在效率、成本、速度間取得平衡，這對現有軟體公司構成轉型壓力。
• 人類角色轉變：手寫 Multi Agent 約束的重要性降低，人類注意力需轉向更擅長的端到端及線下事務，這可能對現有開發者技能樹提出新要求。

逐字稿辨識疑點

• 必源模型：逐字稿中多次出現「閉源模型」與「必源模型」混用或並列，疑為「閉源」的聽寫錯誤或口誤，但依規則標為疑點。
• Fuku：講者提到「未來比如說像富庫這個公司」，疑為「Fugu」或「Sakana AI」的口誤或聽寫錯誤。
• NESOS：評測對比對象，需查證是否為特定模型或評測基準名稱。
• Humanity Last Exam：評測項目名稱，需查證是否為特定 benchmark 名稱。
• OPUS 4.8：評測對比對象，需查證是否為特定模型版本。
• Gemini 3.1 Pro：評測對比對象，需查證是否為特定模型版本。
• Trinity：論文名稱，疑點在於是否為正式發表名稱或內部代號。
• Conductor：論文名稱，疑點在於是否為正式發表名稱或內部代號。
• Workbody：提及的編排案例，需查證是否為真實存在的產品或平台名稱。
• HCI：OpenAI 劃分的第五級，需查證具體指代何種技術或概念。
• 阿茂 Day：講者提及的人物或概念，疑為「Andrew Ng」（吳恩達）或其他人物的聽寫錯誤，但依規則標為疑點。
• 地規：講者提到「是一個地規的架構」，疑為「多規」或特定術語的聽寫錯誤。
• 魚形：講者提到「對魚形做分析」，疑為「技術形」或「圖形」的聽寫錯誤。

可延伸追問

1. Trinity 與 Conductor 的具體技術細節：這兩篇論文中，強化學習的獎勵函數（Reward Function）是如何設計的？如何確保調度模型不會陷入局部優解？
2. Fugu 模型的實際部署成本：調度多個開源與閉源模型進行協作，其計算資源消耗與延遲如何？與單一強大模型相比，成本效益如何？
3. OpenAI HCI 第五級 Organizer 的具體定義：OpenAI 將 HCI 實現劃分的第五級定義為 Organizer，這與 Sakana AI 的 Fugu 模型有何異同？
4. 軟體公司轉型為模型公司的具體路徑：現有軟體公司應如何逐步轉型為「模型公司」？需要具備哪些核心能力？
5. 集體智慧與單一模型的長期共存機制：在未來數據中心中，集體智慧模型與單一天才模型如何分工協作？是否存在特定的場景適配原則？