Tmux + Fable：手把手複刻「砍 35% token」的 coding agent 工作流

瀏覽次數: 9

本文大綱

開一整天 Claude Code，最貴的 token 花在「讀」不是「想」

先問一個你可能沒算過的問題：你昨天那筆 coding agent 帳單，最貴的部分是模型在幫你想架構，還是它在幫你「讀」東西？

答案通常很掃興——是讀。讀 grep 出來的三百行結果、讀整包 build log、讀你貼進去的長 transcript、讀它自己上一輪塞爆的 context。這些搬運雜訊的動作沒有任何技術含量，卻用你選的那顆最貴模型、在最貴的主 context 裡跑，一路把 token 帳單墊高。

AI Jason（Jason Zhou，YouTube 頻道 @AIJasonZ）最近一支影片示範了一套組合技來對付這件事：用 tmux 把 coding agent 拆成「一顆負責決策的主腦 + 幾個負責幹活的分身」，主腦掛 Fable、分身掛便宜模型，實測把一個真實任務的 token 用量砍掉約 35%。

這篇不打算停在「哇 35%」。我們要拆的是：這 35% 到底從哪三個地方來、每個機制你都能單獨開，以及最重要的——你怎麼在自己機器上一步步設起來。搞懂原理，你就不必照抄任何人的 script，也能自己調出適合你專案的比例。

誠實標註：我沒能從 YouTube 抓到這支影片的逐字稿，「35%」是影片方回報的單一任務結果，不是我獨立實測的數字；但下面每一個機制與設定，都對得到官方文件或公開 repo 這種一手來源。

這套工作流其實是三個獨立機制疊在一起

很多人看到「tmux + 多 agent」直覺以為省 token 靠的是「開很多視窗看起來很酷」。不是。真正省下來的是三件事，分開講：

機制一：分層計費（tier routing）。 你跟主腦講話，主腦只做四件事——理解目標、拆任務、決定誰做、驗收結果。真正的粗活（實作、測試、重構、讀檔、grep、寫 brief）全部丟給 subagent。關鍵在：subagent 花的 token，是按「subagent 那顆模型的費率」計價，不是按主腦的費率。所以你把主腦掛在最會判斷但最貴的 Fable、把 subagent 掛在便宜很多的 Sonnet，同一份工作的加權平均費率就被拉下來。

機制二：context 隔離。 Claude Code 的每個 subagent 都跑在自己獨立的 context window。這代表 subagent 讀進來的那三百行 grep、那包 log，全部關在它自己的 context 裡，做完只把「結論」回傳給主腦——雜訊不會回流污染主腦那條又貴又寶貴的對話。主腦的 context 越乾淨，它後續每一輪要重讀的 token 就越少，這是複利。

機制三：fork 子代共用 cache prefix。 這是 Claude Code 補上的一個大殺器。過去並行開五個 subagent 很貴，因為每個 child 都要從頭重建 system prompt、整包工具定義、整段對話歷史——五個 agent 就是五份完整輸入帳單。開了 CLAUDE_CODE_FORK_SUBAGENT=1 之後，fork 出來的子代直接沿用父層「已經 render 好的那串 bytes」，共用同一段 cache prefix；根據官方文件情境，48.5k token 的共用前綴下，不 fork 時每個 child 約要 48.7k token，fork 之後子代 2–N 每個只要約 5k（快取讀取只算 0.1x 費率）。五個並行子代從約 243.5k token 掉到約 68.9k。

那 tmux 在這裡到底扮演什麼角色？它不是省 token 的主因，而是讓上面三件事「能同時看得見、又不互相踩到」的執行場。Kaushik Gopal 在他的 agent-forking 做法（kau.sh/blog/agent-forking）裡講得很清楚：tmux 給你的是沙盒化的 pane、可存活的 session、即時可見的畫面，而且零額外框架成本。主腦一個 pane、每個分身一個 window，你隨時能切過去看某個分身卡在哪、要不要插話——這是「互動式、不是一次性」的關鍵。

手把手：把這套設起來的最小步驟

不用一次全上。照下面順序開，每一步都能單獨驗證有沒有省到。

第 0 步：把主腦換成 Fable、effort 收一格。 在專案裡開 Claude Code，然後：

/model      → 選 Fable 5
/effort     → 選 high（不用 max，省 token 而且判斷力夠）

這裡有個常被誤會的點要先說清楚：省 token 是靠「把粗活換便宜模型」，不是靠「把 effort 調低讓它變笨」。分層計費的省法，是讓每一段工作都在對的費率上、但都全力跑，不是全面降智。

第 1 步：定義兩個 subagent。 在專案的 .claude/agents/ 下建兩個檔：

fast-worker.md —— 掛 Sonnet 5，負責實作、測試、重構、讀檔、grep、寫摘要這些「量大但機械」的活。
deep-reasoner.md —— 掛 Opus 4.8，只在安全審查、高風險或高度不確定的判斷時才叫上場（升級車道）。

第 2 步：在 CLAUDE.md 寫路由規則。 專案根目錄的 CLAUDE.md 就是給主腦看的分工守則，直白寫：「凡是讀檔／grep／跑測試／大量機械修改，一律派給 fast-worker；只有規劃、仲裁、最後驗收留在你身上；碰到安全或高風險判斷才升級 deep-reasoner。」路由規則越具體，主腦越不會手癢自己下海幹粗活。

第 3 步：打開 fork。 這是機制三的開關：

export CLAUDE_CODE_FORK_SUBAGENT=1

一個要注意的細節：fork 只有在你呼叫 Agent 工具、但「不指定」subagent_type 時才會觸發；一旦你指定了明確的 subagent 類型，就走另一條邏輯、不吃 fork 的快取共用。另外它和 --print 模式、coordinator 模式不相容，CI 裡要在 pipeline 層設這個變數。

第 4 步（進階，想要現成的就用）：套 fable5-orchestrator plugin。 如果你不想自己手刻守則，開發者 Rylaa 做了一個 fable5-orchestrator plugin，把上面的分工變成有硬性護欄的機制：

/plugin marketplace add Rylaa/fable5-orchestrator
/plugin install orchestrator@fable-orchestrator

它做幾件蠻聰明的事：主腦動工前先把每一條需求、限制、edge case 寫成 checkbox 存進 ./.workflow/LEDGER.md（這份「需求帳本」比對話歷史更能扛住 context 壓縮）；再用三個 hook 強制執行——Spawn Guard 擋掉「沒帳本卻想丟超過 1500 字任務」的動作、Close Guard 在還有未結帳本項目時不讓你關 session、SessionEnd 的 Cleanup Hook 會去收掉沒關乾淨的 tmux agent pane（作者說他真的遇過「63 個孤兒 agent 佔了約 5GB」）。這個 plugin 明講：省，是省在「分層」，不是省在調低 effort——所有外包出去的活都跑滿 effort。

tmux 分身那一半怎麼接？ 如果你要的是 Kaushik Gopal 那種「把當下 context 原封不動 fork 給另一個分身」的做法，核心就是一支 bash script 加 tmux：它用 tmux 的 capture 把當前 pane 的 transcript 抓下來，問你這個分身要幹嘛，然後在背景開一個新 tmux window 跑你選的 agent，把 <context>（transcript，可選摘要）加 <task>（你的指令）貼進去。當原始 transcript 太長時，它會先用另一顆便宜模型壓縮再送——這樣既隔離了不相干的討論、又餵了該給的上下文。

數字要標清楚：哪些是文件、哪些是某人的實測

這套工作流在網路上被講到的省幅，數字很跳，容易被行銷腔混在一起。拆開看：

fork 快取那條：「子代 2–N 輸入 token 最多省約 90%」是快取讀取只算 0.1x 費率推出來的，這是特定情境（並行多個共用長前綴的子代）下的輸入 token，不是你整天總帳單省 90%。長對話下前綴會越長，成本仍會隨 session 變長而墊高，快取不是免死金牌。
分層計費那條：省多少完全看你「粗活佔比」。多篇社群指南把 Fable 對 Sonnet 的費率差抓在約 3–5 倍，但要注意——Data Science Dojo 那篇也老實說了，它沒有給實測 benchmark，只是照公開定價推的理論值，是社群使用者各自測出來的 pattern，不是 Anthropic 官方數字。
35% 這條：這是 AI Jason 影片對「單一真實任務 end-to-end」回報的結果。它同時吃到上面三個機制，所以落在 fork 的 90%（單一情境輸入）和分層的理論倍數「之間」是合理的——真實任務永遠是混合工作，有判斷、有粗活、有來回，不可能全部吃到最理想的那個數字。把它當成「這套組合在真實任務上大概能砍三成上下」的量級參考，別當成保證。

一句話：90% 是零件在實驗室的極值，35% 是整車在路上的實測，兩個不衝突，但別互相冒充。

什麼時候該上、什麼時候別碰

值得上的場景： 任務裡有大量「讀」跟「機械改」——大型 repo 探索、跨很多檔的重構、要並行跑一堆獨立小任務（每個子任務彼此不依賴，fork 的快取共用效益最大）、或你就是會開 Claude Code 一整天、usage 額度是硬限制。這幾種情況，分層加隔離的複利最明顯。

別急著上的場景： 任務很短、一次性、就改個三五行——你多花在設定 subagent、寫路由、開 tmux 的心力，省下的 token 根本補不回來。還有一種是任務高度線性、每一步都要主腦全程盯著前一步的細節，這種硬拆反而讓主腦一直在「重新讀分身回傳的東西」，隔離的好處被來回溝通吃掉。另外，多分身並行對「同一份檔案」動手時要特別小心寫入衝突，這也是為什麼 tmux 的沙盒 pane 和 fable5-orchestrator 的 cleanup hook 存在——孤兒 agent 佔記憶體是真的會發生的事。

對工程團隊的三個可操作結論

先量再改。 開這套之前，先跑一次你的典型任務、記下 token 用量當 baseline。三個機制一個一個開（先分層、再隔離、最後 fork），每開一個量一次，你才知道自己專案的省幅長什麼樣——別直接信任何人的 35%。
把路由規則寫進 repo，不要靠記性。 CLAUDE.md 的路由守則和 .claude/agents/ 的定義檔應該進版控、全隊共用。這樣「什麼派 Sonnet、什麼才升級 Opus」是一套團隊約定，而不是每個人各自的手感。
護欄比省幅重要。 真正會咬人的不是省得不夠多，是孤兒 agent 佔滿記憶體、或主腦漏掉需求。fable5-orchestrator 的需求帳本和 cleanup hook 值得抄——就算你不裝那個 plugin，也該在收工流程裡加一步「關掉所有背景 agent pane」。

這套工作流的精神其實很單純：讓最貴的那顆腦只做只有它能做的判斷，其他全都外包、隔離、共用快取。 tmux 給你看得見的執行場，Fable 給你夠強的判斷力，分層與 fork 給你便宜的執行力——三者疊起來，才是那三成 token 的來源。

來源

AI Jason（Jason Zhou，@AIJasonZ）YouTube 影片：https://www.youtube.com/watch?v=wCSPgHpcxdc（35% 實測數字出處；本文未能取得逐字稿，數字為影片方回報）
Claude Code 官方文件 — Subagents：https://code.claude.com/docs/en/sub-agents
Kaushik Gopal，〈Forking subagents in an AI coding session with tmux〉：https://kau.sh/blog/agent-forking/
Rylaa，fable5-orchestrator plugin（GitHub）：https://github.com/Rylaa/fable5-orchestrator
Data Science Dojo，〈Fable 5 as Orchestrator, Sonnet as Executor〉：https://datasciencedojo.com/blog/claude-code-fable-5-orchestrator-workflow/