Devin Fusion 實戰：讓 Fable 5.1 規劃審查、SWE-2 動手實作，本機 coding agent 的設定、派工 prompt 與成本判讀

瀏覽次數: 1

本文大綱

為什麼值得關注：你付的是「每題」，不是「每 token」

如果你每天開 Claude Code 或 Codex，用最貴的模型跑完整個 session，錢到底花在哪？Cognition 在 9/11 發布的〈Introducing Fusion in Devin Desktop & CLI〉裡放了一張圖：在 FrontierCode 上，一個 agent 的回合（turns）大約 32% 花在規劃，34% 在實作，17% 在驗證，其餘是 setup（3%）、除錯（5%）、收尾（9%）。

換句話說，真正需要前沿模型「動腦」的部分大約三分之一，其餘多半是照計畫改 code、跑測試、看結果。

Fusion 的做法就是把這兩類工作拆給兩個模型：前沿模型當 lead，成本較低的模型當 sidekick。它原本只在雲端的 Devin 上跑，現在搬進本機的 Devin CLI 和 Devin Desktop。Cognition 給的主要數字是：在 Artificial Analysis 的 Coding Agent Index v1.5 上，Devin Fusion（Fable 5.1 + SWE-2）拿 61.7 分、每題 $7.90；Claude Code 跑 Fable 5.1（max）拿 62.2 分、每題 $12.36。分數差 0.5，成本低 36%。

這篇不談「多模型是趨勢」。我們要做的事情很具體：把它裝起來、選對組合、寫出讓 lead 好派工的 prompt，再用數據決定哪類任務該開 Fusion。

背景：為什麼「模型路由」不夠用

想省錢，最直覺的做法是路由（routing）：簡單任務丟便宜模型，難的丟貴的。Cognition 在文中直接點出兩個問題：

開頭看不出難度。「修 xyz bug」可能是一行 edge case，也可能得重構整個產品，沒讀過程式碼之前你不會知道。路由在第一句 prompt 就下注，押錯的話整個 session 都用錯模型。
中途換模型會打破 prompt cache。 快取綁在同一個模型的上下文前綴上，換模型就得重新付全額 input。對前沿模型來說這筆錢很可觀，會把路由省下的錢吃回去。

Cognition 在 6/29 雲端版的〈Devin Fusion〉文章裡還提到另一類做法：他們自己更早做的「Smart Friend」工具，以及 Anthropic 推出的類似「Advisor」工具，都是讓一個模型呼叫另一個模型問意見。問題一樣：每次呼叫時，任務上下文沒辦法用可快取的方式共享，每問一次就要付一次高價。

運作原理：兩個 agent、兩份快取，只交換三種東西

Fusion 的核心可以濃縮成一句話：同時跑兩個平行的 agent，各自有持久的 context 和自己的工具。

Lead（前沿模型）：掌管整個 session，負責計畫、解讀模糊的需求、審查成果。你對話的對象永遠是 lead。
Sidekick（成本較低的模型）：接下 lead 派的任務，自己探索程式碼、實作、跑測試，然後回報。

兩者之間不傳整段對話，只交換三種東西：

方向	內容
Lead → Sidekick	Brief：要做什麼、限制條件、成功標準
Sidekick → Lead	Result：改了什麼、測試結果
Lead → Sidekick	Feedback：審查後要修的地方

為什麼能省錢？sidekick 實作一個改動，不需要 lead 的完整歷史；lead 審查時，也不需要看 sidekick 每一次 grep 和測試輸出。兩邊各自累積自己的上下文，各自吃滿 prompt caching，這是路由和 Advisor 類工具做不到的。

跟路由的第二個差別：前沿模型永遠在場。 Cognition 的原話是「我們不是把任務丟給便宜模型，然後祈禱路由判斷正確」。lead 每次都會審查 sidekick 的成果、找出問題，發現 sidekick 能力不夠時，可以把工作收回來自己做。另外，因為使用者只跟 lead 對話，互動體驗維持在前沿模型的水準。Cognition 的看法是，很多小模型愈來愈強，但當「面對使用者的 agent」還不夠成熟。

Harness 會依組合調三個旋鈕

Cognition 強調，光是選好 lead 和 sidekick 還不夠：同一套指令對某個組合有效，換個組合可能就是反效果。所以他們依組合調整 harness，主要調三件事：

Lead 的 brief 要寫多細？ 搭較弱的 sidekick 時，Fable 5.1 要寫更具體的 brief，前期多花 lead 的 token，換後面少幾輪審查。搭 SWE-2 時，可以把更多實作細節留給 sidekick 自己決定。
Sidekick 可以反駁嗎？ 強的 sidekick 會被鼓勵質疑計畫，幫忙抓出 lead 的錯。弱的 sidekick 太有主見，反而拖累表現和成本。
探索要不要交出去？ 為了「規劃」所做的探索，不該交給弱的 sidekick，因為它不見得判斷得出哪些資訊重要，而這會影響 lead 的計畫。強的 sidekick 則會被鼓勵協助初期探索。Cognition 說這條邊界仍在研究中。

這三點會影響你怎麼寫 prompt，下面的實作段會用到。

手把手：在本機把 Fusion 用起來

1. 安裝與版本

依官方 Quickstart：

# macOS / Linux / WSL
curl -fsSL https://cli.devin.ai/install.sh | bash

# 或用 Homebrew（macOS）
brew install --cask devin-cli

Windows 請在 PowerShell 執行 irm https://static.devin.ai/cli/setup.ps1 | iex。

Fusion 文件寫明：需要付費方案，Devin CLI 要 3000.10.20 以上，Devin Desktop 要 3.10.0 以上，免費和試用方案都沒有。版本太舊的話，在 session 裡跑 /update（Homebrew 安裝的改用 brew upgrade --cask devin-cli）。

2. 選 Fusion

進專案目錄輸入 devin，然後：

/fusion

會打開 Fusion 選擇器，要設定四個項目：

Lead：主導 session 的前沿模型
Effort：lead 回應前花多少運算推理
Sidekick：負責執行的模型，每個 lead 都會標出推薦的 sidekick
Fast Mode：有快速版的模型就換成快速版，同樣聰明、更快，但更貴

/model fusion 會打開同一個選擇器；想退回單一模型，就用 /model opus 之類的指令。官方推薦組合是 Fable 5.1 + SWE-2。SWE-2 是 Cognition 9/10 發布的自家模型，官方部落格寫它以 Moonshot AI 的 Kimi K3 為基底，提供 medium／high／max 三種 effort 等級。9/10 的 v3000.10.21 changelog 另外寫到：模型家族會記住你上次的設定（推理等級、effort、fast 都算），所以同一組只要設一次。

計費要先搞清楚：兩個模型各按各的費率計。lead 用前沿費率，sidekick 用較低費率，兩個價格在選擇器上都看得到。企業方案則換算成 ACU 或 credits。

3. 寫一個「好派工」的任務

brief 是 lead 寫的，但素材來自你的 prompt。既然 brief 的內容是「限制＋成功標準」，你就先把這兩樣寫清楚，再把需要判斷的部分明確標出來，留給 lead（和你自己）：

任務：把 src/billing/retry.ts 的重試改成指數退避（exponential backoff）
限制：
- 不改 public API（retryRequest 的簽名不變）
- 不新增相依套件
完成條件：
- pnpm test billing 全綠
- 新增測試，覆蓋 429、503、timeout 三種情況
先跟我確認：
- 退避上限與最大重試次數，先提 2 個方案與取捨，確認後再動手

這樣寫，「限制」和「完成條件」可以直接變成 sidekick 的 brief 和驗收標準；「先跟我確認」那段把判斷留在 lead 這一層，不會一路被外包下去。

另外兩個搭配技巧：

不必替 Fusion 決定「誰來做」。 Cognition 已經針對推薦組合調好探索和派工的邊界。在 prompt 裡寫「先派 sidekick 去掃整個 repo」這種指令，可能反而干擾它。你只要講清楚要什麼、限制什麼、做到什麼程度算完成。
把驗證指令寫進 AGENTS.md，而且要短。 Devin CLI 會自動讀專案根目錄的 AGENTS.md（全域規則放 ~/.config/devin/AGENTS.md）。sidekick 的工作包含跑測試回報，測試指令越明確，回報越可靠，lead 的審查輪數也越少。官方文件也建議規則越短越好，情境性的流程改寫成 Skills。

# Project Rules
- 套件管理用 pnpm，不要用 npm / yarn
- 測試：pnpm test <package>；型別檢查：pnpm typecheck
- 改動 src/billing/ 必須補測試
- 資料庫 migration 先提案，不可直接產生

（文件沒說 sidekick 會不會載入同一份 AGENTS.md；不管是哪一種，規則越短，每輪要付的上下文成本越低。）

4. 用 /session-stats 看錢花到哪

每個 session 結束前跑一次：

/session-stats    （別名 /stats）

Fusion 文件說它會顯示 token 用量、各模型的成本，有價格資料時還會估算 Fusion 省了多少；v3000.10.21 起，最後還會附一張「by model」圖，列出每個模型的合計。

值得實測的點是：同一類任務，分別用單一前沿模型和 Fusion 各跑幾次，比較總成本和結果品質。官方文件自己的建議也是「比較相似任務的總成本與品質，不要只看每 token 價格」。可以開一張簡單的表：

任務類型	單一模型：成本／結果	Fusion：成本／結果	結論
機械式重構（改名、搬檔）
補測試、跑很慢的 e2e
需要產品判斷的新功能

數據與限制：數字背後的前提

Cognition 找了 Artificial Analysis 和 Vals AI 合作評測。Fable 5.1 組合的結果（分數／每題成本）：

Benchmark	Fable 5.1 單跑	Fusion（+ SWE-2）	成本變化
DeepSWE 1.1	64.3 / $14.63	63.1 / $7.88	−46%
Terminal-Bench 4	57.6 / $17.46	56.1 / $13.37	−23%
SWE-Atlas QnA	64.8 / $7.57	65.9 / $5.00	−34%
Vals Code Migration	54.6 / $70.97	57.3 / $42.00	−41%
FrontierCode 1.1（Extended）	63.6 / $2.68	63.5 / $1.67	−38%

讀這些數字要注意四件事：

成本是用 API 牌價算的每題成本，不是你的訂閱額度。 Artificial Analysis 的方法論寫明，成本是依供應商 token 定價計算的每題平均 API 成本。你實際扣的是方案 quota、ACU 或 credits，比例不一定相同。
比較的基準是別家的 harness。 AA 指數那張圖比的是「Claude Code + Fable 5.1（max）」與「Codex + Astra（max）」。AA 指數是 DeepSWE v1.1、Terminal-Bench 4.0、SWE-Atlas-QnA 三項等權平均。我們把表中這三列按題數（113／66／124）加權回算，正好得到 $12.36 和 $7.90，可見前三列的單跑基準就是 AA 跑的 Claude Code。所以「省 36%」是 harness 加模型組合一起比出來的，不是單純的模型對模型。後兩列的基準用了哪個 harness，原文沒有寫明。
Astra 組合的分數損失更明顯。 GPT-6 Astra + SWE-2 在 AA 指數拿 58.9，Codex + Astra 是 61.6，少了 2.7 分；Terminal-Bench 4 從 55.6 掉到 50.0，Vals Code Migration 從 67.7 掉到 61.3。標題那個「便宜 39%」就是這一組，代價是比 Fable 組合更大的分數落差。
FrontierCode 是 Cognition 自己的 benchmark。 它由 Cognition 團隊發表，衡量「維護者會不會 merge 這個 PR」。下面兩個實驗都跑在 FrontierCode 上，屬於研究方自行回報的數字。

兩個反直覺的發現：貴的模型讓整體更便宜

換更貴的 lead，session 反而更便宜。 Cognition 把 lead 從 Opus 4.8 換成 Fable 5。Fable 每 token 的名目價格是兩倍，但搭配同一個 sidekick，Fable 主導的 session 平均便宜 9%，FrontierCode 分數還更高。原因是 Fable 更早派工、brief 寫得更好；Opus 則會微管理 sidekick，把很多工作重做一遍。

換更貴的 sidekick，成本也幾乎沒增加。 lead 固定用 Astra（high），在 FrontierCode 上：

Sidekick	牌價	分數 @ 每題成本
GPT-5.6 Luna（high）	$0.20 / Mtok	62.0 @ $2.39
SWE-2（medium）	$0.75 / Mtok（+275%）	63.4 @ $2.34（−2%）

每 token 貴了將近四倍，每題反而便宜 2%，分數也更高。強的 sidekick 回合少、token 用得少，出錯少也讓 lead 少做幾輪審查和修正，而 lead 的 token 才是真正貴的。Cognition 的結論是：2026 年評估模型（以及模型＋harness 的組合），要看每題成本，不是每 token 價格。

對你選組合的啟示很直接：別為了省錢，在選擇器裡挑最便宜的 sidekick。

什麼時候用、什麼時候別用

雲端版文章有一組很誠實的案例（取自 FrontierCode 任務樣本）：

適合的：把 search.js 改寫成 ES6，並跑完整套 Playwright e2e。成本在測試不在程式碼，把慢測試交出去省了 62%，分數 98 → 100。移除 Mattermost 伺服器的 OpenTracing 整合，屬於跨多檔的機械式刪除，省 32%，分數 98 → 97。
不適合的：在搜尋列加入「跨團隊搜尋」的團隊選擇器（受 feature flag 控制，React／Redux，多檔修改）。寫程式交給 sidekick 之後，細微的意圖不見了，成本省 28%，分數卻從 54 掉到 27。Cognition 的評語是：「當判斷本身就是交付物，把它外包會適得其反。」

整理成可以直接照用的判斷：

開 Fusion：

驗證成本高的任務（很慢的測試套件、要跑完整 build）
跨很多檔案的機械式修改：棄用 API、升級套件、搬遷
規格清楚、有明確完成條件的功能

切回單一前沿模型（/model）：

產品判斷就是重點的 UI／互動功能
需求還很模糊、要邊做邊跟你討論設計的探索期
很短的一次性問答：兩個 agent 的協調成本未必划算（這是我們的推論，官方沒有給數據）

對工程團隊的意義

把「每題成本」變成團隊指標。 用 /session-stats 蒐集幾週的數據，按任務類型比較單一模型和 Fusion。Cognition 自己的論點就是每 token 價格會騙人，內部數據也該照這個邏輯算。
把任務寫成可以派工的格式。「限制＋完成條件＋需要確認的判斷點」這個格式對 Fusion 有用，對 Claude Code、Codex 的 subagent 也一樣有用，可以直接做成 issue template。
搞清楚 Devin CLI 的 subagent 是另一套機制。 Devin CLI 本來就有 subagent：subagent_explore 唯讀，跑預設的便宜模型（預設 SWE-1.6）；subagent_general 沿用主 agent 的模型。開啟 Fusion 時 subagent 怎麼選模型，文件沒寫清楚，建議看 /session-stats 的 by-model 圖，確認錢到底花在哪個模型上。
雲端版的機制別直接套到本機。 雲端版文章提過「在 context compaction 時動態換模型」的中途路由；本機版文章沒提到這點，不要假設本機也有。
不用 Devin 也能借用這個思路，但別期待一樣的數字。 例如在 Claude Code 的自訂 subagent 的 frontmatter 指定較便宜的 model，就能拼出「主模型規劃審查、便宜模型實作」的簡化版。不過 Cognition 一再強調，效果來自針對每個組合調 harness（brief 寫多細、能不能反駁、探索的邊界），自己拼的版本得自己量。