讓 Fable 比 Opus 更具成本效益

我們用 Fable 5 取代了 Opus 4.8，Devin 的帳單反而變便宜了。

Fable 5 每個 token 的成本是 Opus 4.8 的兩倍。但當我們使用全新的 Fusion 架構，在 FrontierCode 1.1 上同時跑這兩個模型時，Fable 的成本反而更低。毫不意外的是，它的分數也更高。這篇文章說明了原因，以及這對 AI 代理工作的定價意味著什麼。

引言

所有執行程式碼 AI 代理的人都知道，更強大的模型能帶來更好的結果，但你必須承擔更高的成本。

當我們推出 Devin Fusion 時，我們展示了一條出路：讓一個頂尖模型主導，讓它將任務委派給一個更便宜、更快的副手，就能以降低 35% 的成本，獲得頂尖水準的表現。

但一旦主要模型委派了大部分工作，它的每 token 價格是否仍主導整體帳單？Fable 5 每個 token 的價格是 Opus 4.8 的 2 倍，因此由 Fable 主導的 AI 代理成本應該更高。為了找出答案，我們在 FrontierCode 1.1 上進行了 3,000 次評估，涵蓋四種配置：Fable 和 Opus 分別擔任主導角色，每種配置再分別搭配與不搭配同一個便宜的副手。

純模型運行的結果完全符合直覺：Fable 的分數高於 Opus（60.8 比 55.4），成本也更高。更強的模型，更高的帳單。

啟用副手的配置才是真正有趣的地方。

在相同的副手配置下，成本順序反轉了：Fable + 副手的成本低於 Opus + 副手（1.86 美元 比 2.04 美元），同時分數更高（60.7 比 54.6）。 與純 Fable 相比，Fable + 副手將成本降低了 54%，而分數幾乎保持不變。

結果顯示，2 倍的每 token 溢價其實是錯誤的觀察重點。AI 代理的成本主要由主要模型執行的步驟數量、它攜帶的上下文量，以及最重要的是，它決定 不 親自處理的事項所決定。差異歸結於管理風格：Opus 就像一個帶著實習生的微觀管理者；Fable 則是一個帶著能幹工程師的管理者。

設定

快速回顧一下 Fusion 副手架構的運作方式。主要代理擁有整個會話的控制權：它與使用者交談、規劃、審查工作並提交。它還有一個持久的副手子代理，用於委派任務。主要代理用簡單的語言撰寫交接簡報，而由一個更便宜模型驅動的子代理，則在自己的上下文中執行該簡報並回報結果。主要代理審查結果並決定下一步行動。

為了找出成本花在哪裡，我們做了兩件事。首先，我們分析了所有 3,000 次會話中的每一個 LLM 呼叫：哪個模型在說話，它呼叫了什麼工具，它讀寫了多少 token，以及每次呼叫的成本。其次，我們挑選了 40 個任務進行更仔細的觀察：包括 Fable 成本顯著較低的任务、Opus 成本較低的任务，以及另外一個來自中間範圍的隨機樣本。對於每個任務，我們並排分析了 Fable 主導的運行和 Opus 主導的運行，檢查軌跡並觀察資金流向。

AI 代理的成本

以下是我們實驗中成本在主要代理和副手之間的分佈情況：

Fable 在副手上的花費比 Opus 多 —— 每次運行多 0.27 美元。但它在自己身上少花了 0.45 美元。Fable 的主要代理每次運行僅需 11.5 個步驟，而 Opus 需要 26.5 個步驟，輸出 token 數是 Opus 的三分之一（6.1k 比 19.0k），輸入 token 數也是三分之一。Fable 每個 token 的成本明顯更高，但在上下文管理和步驟數量上佔了優勢。

Fable 的 token 節省源於它直接避免了某些工作。有趣的是，在 81% 由 Fable 主導的運行中，主要代理從未進行過任何程式碼編輯。對於 Opus，這個比例僅為 24%。在 13% 由 Fable 主導的運行中，主要代理甚至從未自行讀取過倉庫檔案。

帶著實習生的微觀管理者 vs. 帶著工程師的管理者

這其中的差異之所以有趣，原因在於：兩個主要代理委派的次數相同，每次運行大約 3 次交接。每次呼叫的日誌排除了 Fable 只是更頻繁委派這種簡單的解釋。真正的區別在於何時以及委派什麼。Fable 的第一次交接來得很早。Opus 常常在長時間獨自探索和實現之後才委派；到那時，設計決策已經做出，重要的檔案已經載入它的上下文，昂貴的工作已經完成。

GIF

典型的 Fable 主導運行會先對倉庫進行幾次偵察操作，然後撰寫一份規格級別的簡報，將整個「實現 + 測試 + 格式化」循環委派出去。接著再進行一次 git show 來審查差異，然後提交。

典型的 Opus 主導運行則會經歷 20 到 45 個步驟的獨自探索、設計和實現，最後才進行一次遲來的交接，處理機械性的收尾工作。

有時，Fable 在會話中的第一個動作就是一次交接。在同一個任務上，兩個主要代理開始的方式如下：

顯而易見的解決方案是讓 Opus 委派更多的探索工作，但強制這種行為往往會降低效能。判斷何時可以安全地將調查工作交接出去，以及何時需要親力親為，這本身就是一種判斷力。被迫委派的模型並不會獲得這種判斷力；它只會委派錯誤的事項。

每個模型的管理風格也體現在交接簡報本身。當 Opus 委派實現工作時，它傾向於直接下達指令；而 Fable 則會撰寫一份設計文件：

委派不僅僅是轉移成本；它也會改變工作的品質。上述的雜湊函數任務就是一個鮮明的例子。任務規格要求雜湊函數的執行時間與指標長度成 O(1) 關係。Opus 親手實現了它，但從未在任何地方記錄這個要求。過程中它忘記了這個限制，並交付了一個線性時間的實現，得分為 25。相比之下，Fable 使用高階約束進行委派。它的簡報中寫道「operator() 必須在指標長度上達到 O(1)：不允許完整 token 掃描。」副手成功實現了這一要求，得分為 94。

我們發現，這個模式適用於各種任務。Fable 的交接內容列舉了約束條件、邊界情況以及「完成」的定義，為自己節省了精力，同時讓副手能夠廉價且正確地完成實現。

交接之後

另一半重點在於主要代理如何處理副手回傳的工作。兩個主要代理通常都會執行相同的廉價檢查：進行兩到三次 git diff/git show 呼叫。但 Opus 不僅於此。它將副手的檔案拉回自己上下文的次數是 Fable 的 2 倍，並以主要代理的成本進行了 4 倍的修正性編輯。在極端情況下，它甚至撤銷了副手的工作並親手重寫：

Opus 的不信任也並沒有提高正確性。在某些評估任務中，Fable 的單次差異審查確實發現了副手的錯誤，但它選擇了再次進行廉價的交接，而不是像 Opus 那樣頻繁地進行主要代理級別的重寫。

當委派沒有幫助時

Fable 的委派策略並非萬能；當任務本身沒有可委派的部分時，它就會失效。以下這類任務似乎難以分解：

• 簡短任務：只包含少數幾個主要代理模型步驟，在決策與交付之間沒有什麼可以委派的。
• 序列除錯任務：根本原因追查是一連串的判斷。在這種情況下，累積的上下文本身就是工作。

值得注意的是，在這類任務中，Fable 幾乎不進行委派。能夠寫出好簡報的同一種判斷力，也知道何時不該寫簡報。但當一個任務沒有值得交接的部分時，委派對於成本就沒有槓桿作用。

在生產環境中，Fusion 在另一個層面處理這個問題：委派控制哪些工作留給昂貴的模型，而路由則決定是否根本不需要動用昂貴的模型。

結語

我們開始這個實驗時，預期是衡量 Fable 的 2 倍溢價會增加多少成本。結果我們驚訝地發現，Fable 有效的委派實際上全面降低了成本。它會指定約束條件和結果，而不是詳細說明實現方式；它會提供回饋，而不是自己動手修正；而且在大多數情況下，它從未碰觸過程式碼。這些都是優秀管理者的習慣。

隨著副手模型變得更便宜、更強大，更多的工作可以交給它們處理。真正值得頂尖模型價格的，將是判斷力：該建構什麼、該設定什麼約束條件、以及該由誰來撰寫程式碼。