使用 subagent 或多 agent 工作流，通常都會增加 token 用量。差別不在於「會不會增加」，而在於增加多少、換來的並行效率和穩定性是否值得。
如果任務很小，直接讓主 agent 完成通常更省。只有當任務可以清楚拆分，或需要獨立複查時，subagent 才更容易體現價值。
subagent 不是更便宜的並行執行緒
很多人第一次看到 subagent，會下意識把它理解成「並行執行緒」：主 agent 做一部分，subagent 做另一部分，速度變快，所以應該更划算。
實際不是這樣。subagent 本質上也是一個獨立的模型呼叫。它需要讀任務說明、理解上下文、讀取檔案、分析問題，再輸出結果。也就是說，它不是主 agent 的免費副本，而是額外啟動了一條推理鏈路。
所以使用 subagent 的核心判斷不是「能不能並行」，而是「並行帶來的時間節省、品質提升，是否值得額外 token 成本」。
為什麼會增加 token
一次 subagent 呼叫通常會額外消耗這些 token：
- 主 agent 寫給 subagent 的任務說明；
- 傳遞給 subagent 的上下文；
- subagent 自己讀取檔案和分析問題；
- subagent 產生結果或修改說明；
- 主 agent 回收結果後的複查、整合和驗證。
如果多個 agent 讀取同一批大檔案，重複消耗會更明顯。尤其是程式碼庫分析、長文件翻譯、批量內容整理這類任務，如果拆分不好，token 會花在重複理解上下文上。
重複讀取上下文是最大的 token 浪費
subagent 真正浪費 token 的地方，往往不是「多開了一個 agent」，而是多個 agent 反覆讀同一批材料。
例如一個任務要處理 6 篇文章，如果 4 個 agent 都先讀完整站點結構、完整技能文件、完整文章列表，再各自處理一小塊內容，那麼並行會很貴。更好的做法是先由主 agent 確定邊界，再讓每個 subagent 只讀自己負責的文章目錄。
更省 token 的拆法通常是：
- 每個 agent 只負責一個明確目錄；
- 給 subagent 的上下文越短越好；
- 不讓多個 agent 重複做同一類探索；
- 主 agent 最後統一複查，而不是讓每個 agent 都做全量複查；
- 能用腳本統一檢查的部分，不交給多個 agent 反覆檢查。
換句話說，subagent 的成本控制重點是邊界，而不是數量。
大概會增加多少
下面是一個粗略估算，實際消耗取決於上下文長度、檔案大小、任務複雜度和 agent 數量。
| 場景 | token 增加 |
|---|---|
| 單個 subagent 處理一個小任務 | 約 1.2x - 2x |
| 2-4 個 agent 並行處理可拆分任務 | 約 2x - 5x |
| 多個 agent 各自讀取大量檔案、做長分析 | 可能 5x+ |
| 主 agent 和 subagent 重複讀同一批大檔案 | 浪費最明顯 |
這不是精確計費公式，只是經驗範圍。真正的消耗還要看每個 agent 是否需要讀完整檔案、是否需要長推理、是否會反覆等待和補充上下文。
如何給 subagent 寫更省 token 的任務說明
任務說明越寬泛，subagent 越容易自己去探索上下文，token 消耗也越高。更省的寫法是把邊界寫清楚。
一個好的 subagent 任務說明應該包含：
- 只允許處理哪些檔案或目錄；
- 哪些檔案只能讀，哪些檔案可以寫；
- 已有檔案是否允許覆蓋；
- 需要保留哪些欄位，比如
date、slug、aliases； - 輸出時只回報什麼結果；
- 不需要做哪些事情，比如不要跑完整建置、不要改無關檔案。
例如，處理翻譯時，不要只寫「把文章翻譯成多語言」。更省 token 的寫法是：「只處理 content/post/2026/05/240，讀取 index.zh-cn.md，只建立缺失的 index.en.md、index.zh-tw.md、index.ja.md、index.es.md，已存在則跳過，保留 date 和 slug。」
這種說明更長一點，但能減少 subagent 自行猜測和重複探索，整體通常更省。
按檔案/目錄拆分，比按語言/步驟拆分更省
如果是批量文章翻譯，按「文章目錄」拆通常比按「語言」拆更好。
例如要翻譯 6 篇文章，每篇都要產生英文、繁體、日文、西語。更推薦讓一個 agent 負責一篇文章目錄內的所有語言，而不是讓一個 agent 負責所有英文、另一個負責所有日文。
原因很簡單：一篇文章的 front matter、程式碼區塊、連結、表格和語義上下文只需要讀一次。如果按語言拆，多個 agent 會重複讀取同一篇源文，token 會被放大。
同樣的邏輯也適用於程式碼任務。優先按模組、目錄、元件拆分，而不是按「先分析、再實作、再測試」這種步驟拆分。步驟拆分很容易讓每個 agent 都重新讀一遍上下文。
什麼情況下值得用
subagent 的價值主要在兩點：並行和獨立視角。
適合使用的場景包括：
- 多篇文章批量翻譯；
- 多個目錄可以獨立修改；
- 前端、後端、測試可以明確分工；
- 一個 agent 寫實作，另一個 agent 做風險複查；
- 高風險修改需要第二視角檢查。
這類任務裡，token 會增加，但總耗時可能明顯下降，而且每個 agent 只盯一塊內容，注意力更集中。
什麼時候值得用一個 agent 做複查
複查型 agent 不一定總值得用。它適合風險高、影響面大、主 agent 容易遺漏細節的任務。
比較值得加複查 agent 的情況包括：
- 修改涉及登入、支付、權限、資料刪除；
- 多語言內容會影響分類、URL、站內連結；
- 大範圍重構後需要獨立找回歸風險；
- 使用者明確要求 code review 或風險審查；
- 主 agent 已經做了實作，但需要第二視角看邊界條件。
不值得加複查 agent 的情況也很明確：單檔小改、標題微調、簡單 front matter 修正、只跑一個命令。這些任務主 agent 自查就夠了。
什麼情況下不值得用
不適合使用 subagent 的場景很常見：
- 單檔小改；
- 簡單問答；
- 只需要跑一個命令；
- 改動範圍很小；
- 任務不能清楚拆分；
- subagent 必須反覆等待主 agent 提供上下文。
這類任務用 subagent 往往只是增加開銷。主 agent 直接處理更快，也更省 token。
我的預設策略：省 token 優先，風險任務才加複查
如果目標是盡量節省 token，可以採用下面這套策略：
- 小任務：不用 subagent。
- 中等任務：不用 subagent。
- 大批量任務：預設也不用 subagent，除非使用者明確要並行提速。
- 高風險任務：可以多用一個 agent 做複查，用 token 換穩定性。
這套策略更偏保守。它犧牲了一部分並行速度，但能減少重複讀取上下文和重複推理帶來的 token 消耗。
如果任務很大但不高風險，我也會優先考慮腳本、批量檢查和本地結構化處理。只有當拆分非常清楚，或者使用者明確希望並行提速時，才更適合引入多個 agent。
更均衡的策略
如果既想控制成本，又不想完全放棄並行，可以採用折衷方案：
- 預設主 agent 直接做；
- 只有任務能按檔案或目錄明確拆分時才考慮 subagent；
- subagent 只讀取自己負責的檔案；
- 不讓多個 agent 同時讀同一批大檔案；
- 主 agent 最後統一複查關鍵欄位、測試結果和 Git diff；
- 高風險任務才增加一個獨立複查 agent。
這能避免「為了並行而並行」。subagent 應該服務於明確的效率或品質目標，而不是成為預設動作。
小結
subagent 和多 agent 一定會增加 token 用量。單個 subagent 可能只是增加一點，多個 agent 並行時則可能成倍增加。
是否值得用，取決於任務本身：如果任務能清楚拆分，或者風險高到需要獨立複查，額外 token 可能是值得的；如果只是單檔小改、簡單問答或常規檢查，直接由主 agent 完成更省。
一句話總結：小任務省 token，大任務看拆分，高風險才用額外 agent 換穩定性。