subagent 會多花多少 token？多 agent 成本與使用策略

Sun, 31 May 2026 14:17:42 +0800

使用 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 換穩定性。

成本優化 on KnightLi的博客