token 都花去哪了：從分工模式、選模型到寫出 /dispatch skill

我同時訂了 Claude Code、Codex 和 agy（Google 的 Antigravity CLI），平常在這個部落格的 repo 裡叫它們分工：做地下城遊戲、生圖、討論 SEO。用久了想知道哪種分工方式最划算，就讓 Claude 把這個專案過去 32 段對話紀錄全部翻出來算帳。算完的結論有點出乎意料：token 主要花在對話拉太長，用哪種分工模式影響不大；選模型也不是越強越好，要看任務卡在哪裡。最後我把這些判斷收成一個叫 /dispatch 的 skill，開工前先替我決定分工方式和模型。

這篇照討論的順序走一遍，附上實際算出來的數字。

起點：兩種「叫 AI 分工」的方式

我常用的分工方式有兩種：

1. herdr 監工：herdr 是給 coding agent 用的終端機分割工具。Claude 在旁邊的窗格（pane）開一個 Codex 或另一個 Claude，用指令丟任務給它、等它做完、再讀它畫面上的輸出。
2. 內建子代理：Claude Code 自己的 Agent 工具，開出去的子代理（subagent）各自做完會把報告交回來。需要時還能開 worktree，也就是同一個 repo 的獨立工作副本，讓幾個子代理同時改程式碼不會互相覆蓋。

翻紀錄後，32 段對話裡用過 herdr 監工的有 6 段，用子代理分工的有 5 段。兩者實際跑起來的差異：

子代理最順的一次是整理小工具目錄：4 個子代理（2 個 Sonnet、2 個 Haiku）分別搬 4 個工具的檔案，每個跑 4～6 回合、26～34 秒就交回報告。herdr 的價值則在跨廠商：SEO 檢查、從 D&D 玩家角度評估玩法、UI 版型提案，都是 Codex 給了跟 Claude 不同的觀點。

用對話紀錄算帳

接著我問了一個實際的問題：兩種模式的 token 差很多嗎？

Claude Code 每一回合都會把整段對話（context）重新送給模型一次。重複的部分走快取讀取（cache read），比較便宜，但量會隨回合數疊上去。下面是幾段代表性對話的原始數字：

地下城那段我在裡面「玩一下、回饋一句、小改」來回了幾十次，跑了將近一整天，中途被壓縮兩次，還撞到一次用量上限。它的總量比其他段多出一個數量級，原因是對話一直沒有收掉。至於它用的是 herdr，影響反而小。

Codex 抓到的盲點：cache read 有打折

我把上面的數據整理成簡報，用 herdr 開 Codex 請它給第二意見。它 18 秒就回覆，而且直接反駁：cache read 的單價打了很大的折扣，拿累計量直接當成本會誇大。另外它也提醒，多代理本身有協調、各自重讀程式碼、合併結果的成本，不能因為任務「大」就自動平行。

這點說得對。所以寫這篇時我照 Anthropic 公開的計價比例重算：以一般輸入為 1，cache read 算 0.1、寫入快取算 1.25、輸出算 5，換成「等效 token」：

打折之後，長對話裡重讀 context 的成本還是佔八成以上，結論沒變，反而更站得住。被修正的是 herdr 的監工成本：我原本粗估「148 次 herdr 指令 × 每回合 40 萬」約佔 17%，逐回合加權後實際是 12～13%。這些回合大多是等它跑完、讀畫面、按 esc 解卡住，幾乎不產出東西；子代理做完會自己回報，這部分接近零。

還有一個常被忽略的差別：誰付錢。herdr 開 Codex 或 agy 時，它們幹活的 token 算在 OpenAI、Google 那邊的額度，Claude 只付監工費；子代理則全部吃 Claude 額度，而且用量不記在主對話裡，上表沒算到。

背景指令算不算「討論」？

子代理之外，Claude 也能在背景跑 codex exec。我一度覺得這也算跟 Codex 討論，但兩者其實不同：

背景指令比較像寄信等回信。問題明確、一兩輪就收斂，用它就夠，還不會卡在啟動提示；要反覆激盪、可能中途轉向，才需要 herdr。紀錄裡也是這樣分的：60 張圖的生圖批次走背景 Codex 加 Monitor 逐張回報，要真的討論的都走 herdr。

再往上一層：dynamic workflow

後來我看到 Claude Code 官方的 workflows 文件，以為跟我的分工是同一件事。讀完發現它比子代理再高一層：先寫一支腳本定義要開哪些子代理、哪些平行、結果怎麼彙整，再交給背景執行。三者的差別在誰握著計畫：

它解決了上面的 token 問題（中間結果不進主對話），還能安排 agent 互相挑錯、存成指令重跑、撞到額度上限後續跑。但文件也寫明跑的途中不能插話，只能開 Claude 子代理，一次執行通常比在對話裡做更耗 token。所以它適合「兩套劇本 × 四職業跑平衡模擬」這種量大、規格固定的工作，不適合討論。

選模型不是越新、越深越好

決定分工方式之後，下一個問題是用哪個模型。不特別指定的話，子代理會沿用主對話的模型，也就是連搬檔案都用最貴的 Opus。

但「選最強的」也不對。這次討論裡剛好有個對照：同一份簡報，Codex 先用 gpt-6-sol medium 回答，後來我切到最貴的 gpt-6-astra xhigh 又問了一題：

這題的資料都已經放在簡報裡，難點是看懂我的工作型態，不需要深度推理，所以 xhigh 的錢花在了不是瓶頸的地方。

整理下來，選模型先問四件事：

1. 難點是推理還是資訊？ 多個條件互相牽制（遊戲平衡、架構取捨、難重現的 bug）才需要深度思考。難點是「有沒有讀到對的檔案」時，想再深也沒用，該做的是把資料給它。
2. 錯了能不能回頭？ 能 git revert 的小改用快的；資料庫 schema、跨大量檔案的架構決定才值得花錢想清楚。
3. 要來回幾輪？ 迭代幾十輪的 UI 微調，每輪慢一分鐘會累積得很明顯，速度比深度重要。
4. 要更聰明，還是要不一樣？ 討論時要的是不同觀點，換一家廠商的中階模型，通常比同一家升到最大模型更有收穫。

另外要分開兩件事：新舊不用猶豫，同一等級選新一代（這次順便發現我 Codex 的預設還是上一代的 gpt-6-sol）；要取捨的是大小與思考深度。實際操作就是預設中階模型、medium effort，答案只是在重述問題、前後矛盾，或同一個問題修兩次沒好，才升一級。

不綁一家：三家共用一套分級

既然判斷方式是「先定難度，再挑模型」，就不必綁定某一家。我讓 Claude 讀這台電腦的 agy models 和 Codex 的模型快取，再用 herdr 同時問 Codex 和 agy，修正成這張表：

兩家都修了 Claude 的草案。Codex 認為重級不該直接用 astra，先用 sol high 再升級；它也說明自己不適合需要看實際畫面的視覺微調。agy 指出它沒有獨立的生圖模型 ID，要用預設模型在指令裡呼叫內建的 image-generator。

也有沒照單全收的：agy 建議背景執行加 --dangerously-skip-permissions，最後改成較保守的 --mode accept-edits，只允許自動改檔。agy 說透過它呼叫 Claude 模型吃的是 agy 的訂閱額度，但扣點倍率它自己也不確定，所以只當 Claude 額度見底時的備案。

把結論收成 /dispatch

討論到這裡，判斷規則已經夠具體，可以寫成 skill（Claude Code 的可重用指令包）。幾個設計決定：

• 手動叫用，不自動觸發：我大部分的問題是小改，每次都先判斷模式只會多花 token；真的要分工時我自己知道，打 /dispatch 需求 就好。
• 預設是「直接做」：這是 Codex 那輪最重要的修正。由上往下比對，命中第一條就停：

• 開工前只宣告一行：例如「子代理：搬檔 Haiku ×2、架構 Opus ×1，理由：可依目錄切開、只有架構需要判斷」，然後直接做，不等確認。
• 模型表獨立成 models.md：新模型推出時只改這個檔，判斷規則不動。
• 把踩過的坑寫進去：Codex 啟動卡在更新提示要按 esc、agy 停在新功能說明、herdr 的 pane 要等 shell 提示出現才能啟動 agent、等待時用 --wait 不要一輪一輪讀。
• 派工共通規則：寫清驗收條件、把專案 CLAUDE.md 的硬性規則轉交給子代理（它們從零開始）、只回傳結論與改動、驗收留在主對話。

安裝則照我平常管 skill 的方式：寫進自己的 skills repo、push 到 GitHub，再用 npx skills add 裝到 ~/.agents/skills/，由它建軟連結給 Claude Code。這樣 Codex 和 agy 那邊也讀得到同一份。

最省的一招不在 skill 裡

回頭看，整段討論最有效的建議其實跟選模式無關：一個功能 commit 完就 /clear 開新對話。這段討論本身就是例子：53 回合、不到一小時，等效 token 約 90 萬，大約是地下城那段的 2%。地下城每回合要重讀約 40 萬 token，換成新對話只要 10 萬上下。

這篇文章本身就是 /dispatch 的第一次實跑。它的判斷是「直接做」：素材都在上一段對話紀錄裡，交給子代理反而要它從頭重讀一次，不如主對話自己寫。

參考來源

• Dynamic workflows（Claude Code 官方文件）
• Prompt caching 計價（Anthropic）