# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Joon Lee (@joon_h_lee) · 平台：X (Twitter) · 日期：2026-07-14

> 原始來源：https://x.com/joon_h_lee/status/2076714221837173097

## 中文摘要

# 讓 Fable 比 Opus 更划算

我們將 Opus 4.8 替換為 Fable 5，結果 Devin 的帳單反而變便宜了。

Fable 5 的每個 token 成本是 Opus 4.8 的兩倍。但當我們使用全新的 Fusion 架構在 FrontierCode 1.1 上運行這兩個模型時，Fable 的成本反而更低。不出所料，它的評分也更高。這篇文章將解釋其中的原因，以及這對於 Agentic 程式開發的定價意味著什麼。

## 簡介

每個運行程式開發 Agent 的人都知道，更強大的模型能帶來更好的結果，但你也必須付出更高的成本。

當我們推出 Devin Fusion 時，我們展示了一種解決方案：讓一個頂尖模型（frontier model）負責指揮，並將任務委派給一個更便宜、更快速的「助手（sidekick）」，這樣你就能以降低 35% 的成本獲得頂尖水準的效能。

但一旦主導模型委派了大部分工作，它那高昂的每個 token 成本是否仍會主導帳單總額？Fable 5 的每個 token 成本是 Opus 4.8 的兩倍，因此由 Fable 主導的 Agent 理應更貴。為了找出答案，我們在 FrontierCode 1.1 上針對四種配置進行了 3,000 次評估：分別以 Fable 和 Opus 作為主導模型，且每種配置都包含與不包含相同的廉價助手。

純粹的運行結果與直覺完全一致：Fable 的得分高於 Opus（60.8 對 55.4），成本也更高。模型越好，帳單越貴。

而啟用助手的運行結果則變得有趣了。

![在 FrontierCode 1.1 Extended 基準測試中，搭配 Sidekick 的 Fable 5 相較於搭配 Sidekick 的 Opus 4.8，成本降低了 9% 且表現提升了 11%。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/8f485ff3a41bc880.jpg)

<details class="chart-data"><summary>展開數據表</summary><table><thead><tr><th>項目</th><th>X</th><th>Y</th></tr></thead><tbody><tr><td>Fable 5 + Sidekick</td><td class="rank-bar num bar-w-50"><span class="bar-val">$1.86</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">60.7</span></td></tr><tr><td>Opus 4.8 + Sidekick</td><td class="rank-bar num bar-w-50"><span class="bar-val">$2.04</span></td><td class="rank-bar num bar-w-90"><span class="bar-val">54.6</span></td></tr><tr><td>Opus 4.8 (medium)</td><td class="rank-bar num bar-w-80"><span class="bar-val">$3.06</span></td><td class="rank-bar num bar-w-90"><span class="bar-val">55.4</span></td></tr><tr><td>Fable 5 (low)</td><td class="rank-bar num bar-w-100"><span class="bar-val">$4.03</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">60.8</span></td></tr></tbody></table></details>

在配備相同助手的條件下，成本順序發生了逆轉：Fable + 助手比 Opus + 助手成本更低（1.86 美元對 2.04 美元），同時得分更高（60.7 對 54.6）。與純 Fable 相比，Fable + 助手在幾乎不影響得分的情況下，將成本降低了 54%。

| 配置 | 分數 | 每次運行成本（平均） |
| --- | --- | --- |
| Fable 5 (low) + 助手 | 60.7 | **$1.86** |
| Opus 4.8 (medium) + 助手 | 54.6 | $2.04 |
| Fable 5 (low) | 60.8 | $4.03 |
| Opus 4.8 (medium) | 55.4 | $3.06 |

事實證明，每個 token 的兩倍溢價並不是衡量成本的正確指標。Agent 的成本主要取決於主導模型執行了多少輪次、攜帶了多少 context，以及最重要的是，它決定了哪些事情「不親自做」。差異歸根究柢在於管理風格：Opus 表現得像個對實習生事必躬親的微觀管理者；而 Fable 則像是一位帶領著稱職工程師的經理。

## 設定

簡單回顧一下 Fusion 的助手架構是如何運作的。主導 Agent 掌控整個對話：它與使用者溝通、規劃、審查工作並進行提交。它還有一個持續運作的助手子 Agent 用於委派任務。主導模型會用簡單的語言撰寫交接簡報，而由更便宜模型驅動的子 Agent 則會在自己的 context 中執行任務並回報結果。主導模型審查結果並決定下一步。

為了找出成本花在哪裡，我們做了兩件事。首先，我們解析了所有 3,000 次對話中的每一次 LLM 呼叫：哪個模型在發言、呼叫了什麼工具、讀取與寫入了多少 token，以及每次呼叫的成本。其次，我們挑選了 40 個任務進行深入觀察：包括 Fable 明顯更便宜的任務、Opus 明顯更便宜的任務，以及從中間隨機抽樣的任務。針對每一個任務，我們並排分析了 Fable 主導與 Opus 主導的運行過程，檢查其軌跡並觀察資金流向。

## Agent 的成本

以下是我們實驗中主導模型與助手之間的成本分配：

| | 主導模型 $ | 助手 $ | 總計 $/運行 | 主導模型輪次/運行 | 主導模型輸入 token (累計) |
| --- | --- | --- | --- | --- | --- |
| Fable + 助手 | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok |
| Opus + 助手 | $1.73 | $0.31 | $2.04 | 26.5 | 1,679k tok |

Fable 在助手身上花的錢比 Opus 多——每次運行多出 0.27 美元。但它在自己身上少花了 0.45 美元。Fable 的主導模型每次運行僅需 11.5 輪，而 Opus 需要 26.5 輪；Fable 寫出的輸出 token 僅為 Opus 的三分之一（6.1k 對 19.0k），輸入 token 的消耗量也只有三分之一。雖然 Fable 的每個 token 成本顯著較高，但它在 context 管理和輪次數量上勝出。

Fable 的 token 節省來自於直接避免了不必要的勞動。有趣的是，在 81% 的 Fable 主導運行中，主導模型從未進行過任何程式碼編輯。對於 Opus 而言，這一比例僅為 24%。在 13% 的 Fable 主導運行中，主導模型甚至從未親自讀取過任何儲存庫檔案。

## 微觀管理者與實習生 vs. 經理與工程師

這就是差距變得有趣的地方：兩位主導模型委派的次數相同，每次運行大約 3 次交接。逐次呼叫的日誌反駁了「Fable 只是單純委派更多任務」這種簡單的解釋。真正的區別在於它們「何時」以及「委派什麼」。Fable 的第一次交接發生得很早。Opus 往往在經過長時間的單獨探索和實作後才進行委派；到那時，設計決策已經做出，重要的檔案已經進入它的 context，而昂貴的工作也已經完成了。

<video src="https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0d24c8a171578df9.mp4" poster="https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b77e13e3fcc81153.jpg" autoplay loop muted playsinline preload="metadata" style="max-width:100%;height:auto;display:block;margin:1rem 0"></video>

典型的 Fable 主導運行會對儲存庫採取幾次偵察行動，然後撰寫一份規格級別的簡報，委派整個「實作 + 測試 + Lint」循環。接著執行一次 `git show` 來審查差異，然後提交。

典型的 Opus 主導運行則會經歷 20 到 45 輪的單獨探索、設計和實作，最後才進行一次針對機械性收尾工作的委派。

有時 Fable 在對話中的第一個動作就是交接。在同一個任務上，兩者的開局如下：

![這張圖表對比了 Fable 5 與 Opus 4.8 在處理相同任務時的行為差異。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/f89b9d928554a153.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片展示了兩個模型在執行「Sidekick Handoff」任務時的行為模式對比：

1. Fable 5 (ACTION #1 - SIDEKICK HANDOFF)：
   - 指令內容：「Explore the repo to map out how OIDC SSO is implemented... Don't change anything yet; just report back with file paths and relevant snippets.」（探索儲存庫以規劃 OIDC SSO 的實作方式……暫時不要做任何更改；只需回報檔案路徑與相關程式碼片段。）

2. Opus 4.8 (SAME TASK - AFTER RECEIVING THE SAME KIND OF SIDEKICK REPORT)：
   - 指令內容：「Let me read the key files myself to make the design decisions.」（讓我親自閱讀關鍵檔案以做出設計決策。）
   - 備註：[proceeds to re-read ~12 files the sidekick had already summarized]（隨後重新讀取了 Sidekick 已經總結過的約 12 個檔案。）</div></details>

顯而易見的修正方法是讓 Opus 委派更多的探索工作，但強迫這種行為往往會降低效能。判斷什麼時候可以安全地交接，以及什麼時候必須親力親為，這本身就是一種判斷力。一個被強迫委派的模型無法獲得這種判斷力；它只會委派錯誤的事情。

每個模型的管理風格也體現在交接簡報本身。當 Opus 委派實作時，它採取的是「指令式」；而 Fable 則是撰寫一份「設計文件」：

![兩則關於軟體開發任務交接的指令說明，分別針對 Fable 與 Opus 模型。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/c095f4f2ace34e74.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片展示了兩段針對不同模型進行實作交接（Implementation Handoff）的指令內容：

1. 第一段針對「FABLE」模型：
   - 任務主題：Hashing Task（雜湊任務）。
   - 指令要求：`operator()` 函式在指標長度上必須達到 O(1) 的時間複雜度，且明確禁止進行完整的 Token 掃描。
   - 備註：包含演算法（algorithm）、限制條件（constraints）與測試矩陣（test matrix）。
   - 執行要求：在提交（committing）程式碼之前，必須回報完整的差異比對（full diff）與測試結果。

2. 第二段針對「OPUS」模型：
   - 任務主題：Changesets Migration（變更集遷移）。
   - 指令要求：將 `.changeset/config.json` 檔案內容覆寫為指定的 JSON 格式內容。
   - 備註：檔案內容已在行內直接指定（full file contents dictated inline），並要求提供每個檔案的完整程式碼。</div></details>

委派不僅僅是轉移成本，它還改變了工作的品質。上述的雜湊（hashing）任務就是一個鮮明的例子。任務規格要求雜湊函式在指標長度上必須為 O(1)。Opus 手動實作了它，卻從未在任何地方寫下該要求。在過程中，它忘記了這個限制，並交付了一個線性時間複雜度的實作，得分僅為 25。相比之下，Fable 使用高階限制進行委派。它的簡報寫道：「operator() 在指標長度上必須為 O(1)：禁止完整的 token 掃描。」助手成功實作了這一點，得分為 94。

我們發現這種模式在各類任務中具有普遍性。Fable 的交接內容列舉了限制條件、邊緣案例以及「完成」的定義，這既節省了它自己的精力，又使助手能夠以低成本且正確地完成實作。

## 交接之後

另一半的關鍵在於主導 Agent 如何處理助手回傳的工作。兩者通常都會執行相同的廉價檢查：兩到三次 `git diff` 或 `git show` 呼叫。但 Opus 不會就此打住。它將助手產生的檔案拉回自己 context 的頻率是 Fable 的兩倍，並且以主導模型的價格進行了 4 倍的修正性編輯。在極端情況下，它甚至會撤銷助手的成果並親手重寫：

![比較 Fable 與 Opus 在處理程式碼重構任務時的不同行為反應。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/8ff2e3b3b2f826ab.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片展示了兩個模型（Fable 與 Opus）在面對相同程式碼重構任務時的處理方式：

1. **FABLE**：
   - 評論：「REVIEWING THE SIDEKICK'S DIFF, FINDS IT OVER-ENGINEERED」（審查 Sidekick 的差異檔，認為其過度設計）。
   - 指令：「Try simpler alternatives in this order and keep the first that passes.」（按此順序嘗試更簡單的替代方案，並保留第一個通過的）。
   - 結果：[issues a second handoff; the sidekick fixes it]（發出第二次交接；Sidekick 修復了它）。

2. **OPUS**：
   - 評論：「SAME COMPLAINT, SAME TASK」（同樣的抱怨，同樣的任務）。
   - 指令：「This is over-engineered... ugly cast.」（這過度設計了……醜陋的轉型）。
   - 結果：[reverts the change; reimplements it itself at lead prices]（撤銷更改；以領先價格自行重新實作）。</div></details>

Opus 的不信任感並沒有提高正確性。在一些評估任務中，Fable 僅透過一次差異審查就發現了助手真正的 Bug，並選擇進行另一次廉價的交接，而不是像 Opus 那樣頻繁地選擇親自重寫。

## 當委派無效時

Fable 的委派策略並非萬能；當任務沒有可委派的組件時，它就會失敗。以下幾類任務似乎很難分解：

- 僅包含少數主導模型輪次，且在決定與交付之間沒有什麼可委派的短任務。

- 序列式除錯任務，其中尋找根本原因是一連串判斷的長鏈。在這種情況下，累積的 context 本身就是工作內容。

在這些任務中，Fable 幾乎不委派。正是那種能寫出優秀簡報的判斷力，也知道什麼時候不該寫。但當任務沒有任何值得交接的部分時，委派對成本就沒有槓桿作用。

在生產環境中，Fusion 在另一個層級處理這個問題：委派控制哪些工作保留給昂貴的模型，而路由（routing）則決定是否要讓昂貴的模型參與其中。

## 結語

我們開始這項實驗時，預期會測量 Fable 的兩倍溢價會增加多少成本。我們驚訝地發現，Fable 有效的委派實際上降低了總體成本。它指定了限制條件和預期結果，而不是詳述實作細節；它提供回饋，而不是親自進行修正；在大多數情況下，它甚至完全沒有觸碰程式碼。這些都是優秀經理的特質。

隨著助手模型變得越來越便宜且強大，更多的工作可以交給它們。而真正值得頂尖模型價格的，將是判斷力：決定要建構什麼、設定什麼限制，以及由誰來撰寫程式碼。

## 標籤

Agent, AIGC, 教學資源, 產業趨勢, Cognition