如何讓 Fable 比 Opus 更便宜：用委派改寫 Agent 的成本結構

Fable 像帶著資深工程師的經理，早早交派、寫清楚規格、少親自動手；Opus 則像帶實習生的微觀管理者。本文源自 Joon Lee X 文章，用 3,000 場評測拆解背後的成本結構。
（前情提要：Anthropic 推出「Claude for Small Business」：瞄準中小企業 AI 自動化工作，幫你催發票、算薪水..）
（背景補充：Anthropic 要求實名 KYC 驗證！Claude 部分功能將需上傳身分證件，合規壓力擴大）

我們把 Opus 4.8 換成 Fable 5，而 Devin 的帳單反而降低了。

Fable 5 每 token 的成本是 Opus 4.8 的兩倍。但當我們用全新的 Fusion 架構，在 FrontierCode 1.1 上同時跑這兩個模型時，Fable 反而更便宜。不意外地，它的分數也更高。這篇文章會解釋為什麼，以及這對「為 agentic 工作定價」意味著什麼。

引言

每個跑程式 agent 的人都知道，更強的模型會給你更好的結果，但你得吞下成本。

當我們推出 Devin Fusion 時，我們展示了一條出路：讓一個前沿模型坐鎮指揮，讓它把工作委派給一個更便宜、更快的副手，於是你能以低 35% 的成本，獲得前沿等級的表現。

但一旦主導模型把大部分工作都委派出去，它每 token 的單價還會主宰整張帳單嗎?Fable 5 每 token 的成本比 Opus 4.8 貴兩倍，所以由 Fable 主導的 agent 照理說應該更貴。為了找出答案，我們在 FrontierCode 1.1 上跑了 3，000 場評測工作階段，橫跨四種配置：Fable 與 Opus 各自坐上主導席，並各自在「有」與「沒有」同一個便宜副手的情況下執行。

純粹的執行(pure runs)表現完全如直覺所料：Fable 的分數勝過 Opus(60.8 對 55.4)，成本也更高。更好的模型，更大的帳單。

有副手加持的執行，才是事情變得有趣的地方。

在給定同一個副手的情況下，成本排序反轉了：Fable + 副手比 Opus + 副手更便宜($1.86 對 $2.04)，分數卻更高(60.7 對 54.6)。和純粹的 Fable 相比，Fable + 副手把成本砍掉 54%，分數卻幾乎沒變。

結果證明，「每 token 貴兩倍」是個看錯了的數字。一個 agent 的成本，主要取決於主導模型走了多少回合、拖著多少上下文一起走，以及最重要的——它決定「不」自己做哪些事。差別歸結到管理風格：Opus 表現得像個帶著實習生的微觀管理者；Fable 則像個帶著能幹工程師的經理。

實驗設定

快速複習一下 Fusion 的副手架構如何運作。主導 agent 擁有整個工作階段：它和使用者對話、規劃、審查工作，並提交(commit)。它還有一個常駐的副手子 agent 用來委派任務。主導模型用白話寫下一份交接簡報，而由一個便宜得多的模型驅動的子 agent，在它自己的上下文裡執行，並回報結果。主導模型審查結果，決定接下來怎麼做。

為了找出成本流向哪裡，我們做了兩件事。第一，我們解析了全部 3，000 場工作階段裡的每一次 LLM 呼叫：是哪個模型在說話、它呼叫了什麼工具、讀寫了多少 token，以及每次呼叫花了多少錢。第二，我們挑了 40 個任務做更近距離的觀察：Fable 明顯更便宜的那些、Opus 明顯更便宜的那些，以及另一批來自中間地帶的隨機樣本。對每一個，我們把 Fable 主導的執行和 Opus 主導的執行並排分析，檢視它們的軌跡，觀察錢花到哪裡去了。

一個 agent 的成本

以下是在我們的實驗中，成本如何在主導模型與副手之間分配：

Fable 花在副手上的錢比 Opus 多——每次執行多花 $0.27。但它花在自己身上的錢少了 $0.45。Fable 的主導每次執行走 11.5 個回合，對比 Opus 的 26.5 個；寫出的 output token 只有三分之一(6.1k 對 19.0k)，消耗的 input token 也只有三分之一。Fable 每 token 明顯更貴，卻在上下文管理和回合數上勝出。

Fable 的 token 節省，來自於它乾脆地避開了工作。有趣的是，在 81% 由 Fable 主導的執行裡，主導模型從頭到尾沒有做過任何一次程式碼編輯。對 Opus 來說，只有 24% 的執行是如此。在 13% 由 Fable 主導的執行裡，主導模型甚至從未親自讀取過任何一個 repo 檔案。

帶實習生的微觀管理者 vs 帶資深工程師的經理

讓這個落差變得有趣的地方在於：兩個主導模型委派的次數一樣多，每次執行大約 3 次交接。逐次呼叫的日誌，推翻了「Fable 只是單純委派得比較多」這個簡單解釋。真正不同的，是它們「何時」委派、「委派什麼」。Fable 的第一次交接來得很早。

Opus 則常常很晚才委派，在一長段獨自探索與實作之後；到那時候，設計決策都已做完、重要檔案都已進了它的上下文，昂貴的工作也已經做完了。

一場典型的、由 Fable 主導的執行，會先對 repo 做幾個偵察動作，然後寫一份規格等級的簡報，把整個「實作 + 測試 + lint」的迴圈一次委派出去。接著一個 git show 來審查 diff，然後提交。

一場典型的、由 Opus 主導的執行，則會歷經 20 到 45 個回合的獨自探索、設計與實作，再加上一次很晚才發生、只交派機械性收尾工作的交接。

有時候，Fable 在一個工作階段裡的第一個動作就是交接。在同一個任務上，兩個主導模型的開場是這樣的：

顯而易見的修法，是強迫 Opus 多委派一些探索，但強加這種行為往往會降低表現。知道一項調查什麼時候可以安全地交派出去、什麼時候是你必須親自做的，這本身就是一種判斷。一個被脅迫著去委派的模型，並不會因此獲得那種判斷力；它只會把不該委派的東西委派出去。

每個模型的管理風格，也在交接簡報本身裡顯露無遺。當 Opus 委派實作時，它是在下指令；而 Fable 則是在寫一份設計文件：

委派不只是把成本挪來挪去；它也改變了工作的品質。上面那個雜湊(hashing)任務就是個鮮明的例子。任務規格要求一個雜湊函式在指標(pointer)長度上必須是 O(1)。Opus 親手實作它，卻從沒把這條要求寫在任何地方。過程中的某一步，它忘了這條限制，交出了一個線性時間的實作，得分 25。相對地，Fable 用高層次的限制來委派。它的簡報寫著：「operator() 在指標長度上必須是 O(1)：不得做完整的 token 掃描。」副手成功地實作了它，拿下 94 分。

我們發現這個模式在各個任務間都能通用。Fable 的交接會列舉出各種限制、邊界情況，以及一份「何謂完成」的定義，既替自己省下力氣，又讓副手能便宜且正確地完成實作。

交接之後

另一半，是主導 agent 拿副手交回來的成果做了什麼。兩個主導模型常常都會跑同樣的便宜檢查：兩三次 git diff / git show 呼叫。但 Opus 不會停在那裡。它把副手的檔案拉回自己的上下文的頻率高出 2 倍，並以主導模型的價格做出多達 4 倍的修正性編輯。在最極端的情況下，它把副手的成果整個還原，親手重寫了一遍：

而 Opus 的不信任，也並沒有讓正確性提高。在某些評測任務裡，Fable 單單一次的 diff 審查就抓到了副手真正的 bug，並選擇再做一次便宜的交接，而不是 Opus 那麼常訴諸的、主導模型等級的重寫。

當委派幫不上忙時

Fable 的委派策略並非放諸四海皆有用；當任務沒有可委派的組成部分時，它就會失效。以下這幾類任務，似乎很難被拆解：

• 只包含少數幾個主導模型回合的短任務，在「決定」與「交付」之間沒有東西可以委派。
• 序列式的除錯任務，其根因追查是一長串連續的判斷。在這裡，累積起來的上下文本身就是工作。

值得注意的是，在這些任務上，Fable 幾乎完全不委派。那份能寫出好簡報的判斷力，同樣也知道什麼時候不該寫。但當一個任務沒有任何值得交派的東西時，委派對成本就毫無施力點。

在正式生產環境裡，Fusion 會在另一個層次處理這件事：委派決定哪些工作留在昂貴的模型手上，而路由(routing)則決定昂貴的模型到底要不要被牽涉進來。

結語

我們開始這個實驗時，原本預期要衡量的是 Fable 那 2 倍的溢價會讓成本增加多少。結果我們很驚訝地發現，Fable 有效的委派實際上讓整體成本下降了。它指明限制與結果，而不是把實作一步步寫死；它給出回饋，而不是自己動手修；而且在大多數情況下，它根本從未碰過程式碼。這些，都是一個好經理的習慣。

隨著副手模型變得更便宜、更好，更多的工作可以交給它們。而未來仍值得付前沿價格的，將是判斷力：要做什麼、要限制什麼，以及該由誰來寫。

📍相關報導📍

Anthropic 開源金融分析外掛：41 個 Skills 一鍵研究股票、財報分析、財富管理

神救援！他靠 Claude 翻 11 年前舊電腦，成功找回 5 枚 BTC

OpenAI推出Claude Code「搬家工具」，不演了讓用戶無痛跳槽Codex