Token on KnightLi的博客

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

大模型 API 為什麼按 Token 收費：一文講清輸入、輸出和上下文成本

Sat, 25 Apr 2026 08:44:32 +0800

在大模型 API 的計費方式裡，最容易讓人困惑的一點，就是為什麼幾乎所有平台最後都會落到 token 這個單位上：大模型為什麼按 token 收費，而且不同 token 還會有不同價格。

很多人剛接觸模型 API 時，最困惑的不是模型能力，而是帳單。明明只問了幾個問題，為什麼費用會漲得這麼快？為什麼輸入便宜、輸出更貴？為什麼上下文一長，成本就開始明顯失控？

如果把這件事講簡單一點，可以先記住一句話：模型收費，買的不是「一次回答」，而是整段推理過程中消耗的計算與帶寬資源。

1. 什麼是 token

在大模型計費裡，token 不是「字數」也不是「單詞數」，而是模型處理文字時使用的切分單位。

它可能是：

一個漢字
一個英文單詞的一部分
一個標點符號
一小段常見詞組

所以 API 平台通常不會按「每句話」或「每次請求」收費，而是按模型實際讀入和生成的 token 數量收費。
這比按請求次數計費更合理，因為同樣是一次請求，可能只輸入 20 個字，也可能塞進 20 萬 token 的上下文，兩者消耗完全不是一個量級。

2. 為什麼輸入和輸出要分開定價

現在大多數模型 API，都會把價格拆成兩部分：

輸入 token 價格
輸出 token 價格

而且常見情況是：輸出 token 比輸入 token 更貴。

原因並不難理解。

模型處理輸入時，本質上是在「讀」和「編碼」已有內容；但生成輸出時，它需要一步一步預測下一個 token，再繼續預測下一個 token。這個過程不只是讀取，而是持續進行推理和採樣，所以通常更耗算力。

你可以把它粗略理解成：

輸入：像把材料遞給模型
輸出：像讓模型現場寫答案

「現場寫」的計算成本，通常比「把材料讀一遍」更高，所以輸出價格更貴是很常見的設計。

3. 為什麼上下文越長，費用越容易失控

很多人以為自己只是在「多貼一點背景資料」，但從模型帳單的角度看，這件事的影響往往比想像中大。

原因在於：模型每次調用時，通常都要重新處理目前請求裡帶進去的整段上下文。

也就是說，如果你目前請求裡包含：

系統提示詞
歷史對話
工具返回結果
長文件片段
程式碼檔案內容

這些內容都會一起進入輸入 token 計費。

所以真正讓帳單變大的，往往不是最後那一句提問，而是它前面拖著的一大串上下文。
當對話輪數增加、工具調用變多、歷史訊息不斷回灌時，token 成本就會一輪一輪被放大。

4. 工具調用為什麼特別容易漲 token

在 Agent、程式碼助手、工作流自動化這類場景裡，token 消耗通常比普通聊天高得多。

問題不只是「模型回答了一段話」，而是整個流程裡會不斷出現這些內容：

讀檔案
看日誌
調 API
返回 JSON
把工具結果再回填給模型

每一次工具調用的結果，只要被重新塞回下一輪上下文，就會繼續變成新的輸入 token。

這就是為什麼很多開發者最後會發現：
不是模型本身單價特別離譜，而是工作流把 token 帳單一層層疊上去了。

例如一個編碼 Agent 連續做下面這些事：

讀取專案結構
打開幾個原始碼檔案
跑一次測試
把報錯日誌餵回模型
再讀更多相關檔案

每一步都可能讓後續請求背著更長的上下文繼續跑。這樣即使單價不變，總帳單也會很快增長。

5. 為什麼同樣是模型，價格會差很多

不同模型的 token 價格差異，背後通常不只是「廠商想賣貴一點」，而是和幾個因素直接相關：

模型規模
推理效率
上下文長度
部署成本
目標市場

模型越大、活躍參數越多、推理鏈路越複雜，單次生成一個 token 的成本通常就越高。
如果模型還支援超長上下文、複雜推理、工具調用優化，那它的基礎設施壓力也會進一步增加。

所以定價本質上是在覆蓋幾類成本：

GPU / 加速卡資源
顯存占用
推理延遲
網路與服務穩定性
峰值並發能力

便宜模型不一定差，貴模型也不一定適合所有場景。很多時候價格差，反映的是「這類能力大概值多少基礎設施成本」。

6. 為什麼快取輸入會更便宜

不少模型平台現在會提供：

cached input
prompt caching
prefix caching

這類能力的共同思路是：如果一大段輸入已經算過，就不要每次都從頭按原價重算。

比如一段固定 system prompt、固定工具說明、固定長文件前綴，如果每輪都完全重複發送，平台就有機會把其中一部分計算快取下來。這樣同樣是輸入 token，命中快取的部分就可以按更低價格計費。

這也解釋了為什麼很多 API 價格頁會出現三檔甚至更多價格：

普通輸入
快取輸入
輸出

它們反映的不是文字內容不同，而是底層計算是否可以重用。

7. 「便宜 token」為什麼不等於「總成本更低」

很多人看到某個模型「每百萬 token 超便宜」，第一反應是總成本一定更低。實際上不一定。

因為總帳單大致等於：

token 單價 × 實際消耗量

而實際消耗量又會被很多因素放大：

提示詞寫得太長
歷史訊息不清理
工具結果回填過多
輸出太囉唆
一個任務反覆重試

所以真正決定帳單的，通常不是單價一個變數，而是：

模型單價
每輪輸入長度
每輪輸出長度
調用次數
工作流設計

這也是為什麼「低單價模型」在某些 Agent 任務裡，最後總費用仍然可能不低。因為它可能需要更多輪互動、更多補充上下文、更多失敗重試。

8. 開發者該怎麼估算 token 成本

如果你想在專案裡更穩地控制預算，可以先用一個很樸素的估算方式：

統計平均每次請求的輸入 token
統計平均每次請求的輸出 token
估算一個任務會調用多少輪
再乘上對應模型單價

舉個思路上的例子：

每輪輸入 8k tokens
每輪輸出 1k tokens
一個任務跑 10 輪

那它真正消耗的就不是「一次問答」，而是：

輸入約 80k tokens
輸出約 10k tokens

如果中途還有日誌、工具結果、檔案內容不斷追加，總量還會繼續上升。

所以做預算時，最好不要只看單輪，而要看一個完整任務閉環到底會吃掉多少 token。

9. 怎麼實際控制帳單

如果你已經在用 API 或 Agent，下面這些做法通常最有效：

縮短 system prompt，避免重複廢話
定期裁剪歷史訊息
工具返回結果只保留必要欄位
長文件先檢索，再餵局部片段
控制輸出長度，避免模型無上限展開
高價值任務用貴模型，低價值任務用便宜模型

很多時候，省錢最有效的方式不是一味換更便宜的模型，而是先把工作流裡沒有意義的 token 消耗砍掉。

10. 這件事真正該怎麼理解

大模型 token 定價，說到底是在替「模型讀了多少、想了多少、寫了多少」計費。

它不是傳統軟體那種按帳號、按次數、按包月就能完全描述的資源模型，因為模型調用本身就是一個動態計算過程。你塞進去的上下文、拉起的工具、要求的輸出長度，都會直接影響成本。

所以理解 token 定價，最重要的不是背價格表，而是先建立一個直覺：

長上下文會漲輸入成本
長輸出會漲生成成本
工具鏈會放大總 token
快取和工作流設計會明顯影響帳單

只要把這幾個點想清楚，大多數模型 API 的價格結構其實都不難理解。

AI 名詞解釋：用白話講清楚 Agent、MCP、RAG 和 Token

Thu, 23 Apr 2026 13:13:40 +0800

剛開始接觸 AI，最容易讓人卻步的通常不是模型本身，而是討論裡那些一串一串的名詞。Agent、MCP、RAG、AIGC、Token 看起來都很常見，但如果沒有人先用白話講一遍，很多人其實只是「看過」，不是真的懂。

這篇就順著一組常見入門解釋的思路，把 10 個高頻 AI 名詞壓縮成一套更容易記住的意思。目標不是講得多學術，而是先幫你建立一個能跟上日常 AI 討論的基本框架。

10 個常見 AI 名詞，分別是什麼意思

1. Agent：不只會聊天的執行型 AI

Agent 可以先理解成「會做事的 AI 助手」。

一般聊天機器人比較像是你問一句、它答一句；Agent 則更進一步，它會把任務拆開、安排步驟、調用工具，最後把結果交回來。比如你叫它整理資料、查資訊、生成文件，它不只是給建議，而是可能直接把這些動作串起來完成。

所以 Agent 的重點，不在「會不會說」，而在「能不能做」。

2. OpenClaw：駐留在電腦裡的 AI 助手

這裡的 OpenClaw 被形容成一種住在你電腦裡的 AI 助手。

你可以把這類工具理解成更貼近桌面操作的 AI 幫手。它不只是接收文字，也可能直接觀察介面、調用本地工具、按流程執行任務。和一般網頁聊天相比，這類工具更強調實際操作能力。

如果說 Agent 是抽象層面的執行型 AI，那這種桌面型助手就是它在個人電腦上的一種具體落地形式。

3. Skills：替 Agent 裝上的能力包

Skills 可以理解成 Agent 的功能模組或操作說明。

同一個 Agent，裝上不同的 Skills，就會展現出不同的專長。有些偏文案，有些偏資料整理，有些偏程式處理。它們有點像手機裡的 App，也有點像一套套可重複利用的工作流程。

所以很多時候，不是模型突然變聰明了，而是它背後多了一組更明確的規則、工具和步驟。

4. MCP：AI 連接外部工具的統一方式

MCP 全稱是 Model Context Protocol。

如果用生活化的比喻，它有點像 AI 世界裡的 Type-C 介面。以前模型要接不同工具，往往得一套一套分開整合；有了統一協議之後，接入方式就會更標準，也更容易重複使用。

對大多數使用者來說，最值得記住的一點是：MCP 解決的不是模型會不會回答，而是模型怎麼安全、穩定地接上外部工具和資源。

5. 抽卡：AI 生成結果本來就有隨機性

「抽卡」這個說法常見於 AI 繪圖、影片生成和內容創作場景。

意思很簡單。就算是同樣的提示詞、同樣的大方向，每次生成出來的結果也可能不同。有時候效果很好，有時候明顯翻車，所以很多人會把反覆生成這件事形容成像遊戲裡抽卡。

它真正提醒我們的是：AI 生成不是固定公式，而是一個帶有機率波動的過程。

6. API：應用和模型之間的連接方式

API 全稱是 Application Programming Interface，也就是應用程式介面。

你可以把它理解成程式之間溝通的標準入口。當你在自己的應用、腳本或編輯器裡呼叫模型服務時，本質上就是透過 API 發送請求，再拿回結果。

如果把模型服務比作一家餐廳，那麼：

菜單像 API 文件
點餐像發起 API 請求
廚房出餐像模型回傳結果

所以很多工具表面看起來不一樣，但底層其實都在呼叫某種 API。

7. 多模態：AI 不只會處理文字

「多模態」說的是 AI 不再只會讀寫文字，而是可以同時處理多種形式的資訊。

例如它可以看圖、聽語音、理解影片、生成圖片，甚至支援即時語音和視訊互動。和早期只能處理文字的模型相比，多模態模型更接近同時具備「看、聽、說、寫」的能力。

這也是為什麼現在很多 AI 產品，已經不再只圍繞一個文字輸入框來設計。

8. RAG：先找資料，再組織答案

RAG 是 Retrieval-Augmented Generation，通常譯作檢索增強生成。

它適合用來解決一個很實際的問題：模型的訓練資料有時間邊界，也不會自動知道你公司最新的文件、客服紀錄或業務規則。RAG 的做法是先從指定資料裡找出相關內容，再根據這些內容生成回答。

它的價值通常體現在三點：

答案更容易貼近真實資料
可以追溯答案依據來自哪裡
新文件加入後，知識也能快速更新

所以很多企業知識庫、AI 客服和內部問答系統，底層都會用到 RAG。

9. AIGC：AI 生成內容的總稱

AIGC 是 AI Generated Content 的縮寫。

它不是某一個單獨工具，而是一個總稱，泛指 AI 生成出來的內容，包括文字、圖片、音訊、影片等各種形式。你看到的 AI 寫稿、AI 製圖、AI 做短影片、AI 配音，都可以放進 AIGC 這個大框架裡理解。

這個詞真正重要的地方在於，它描述的是一種內容生產方式，而不是某一個具體模型。

10. Token：模型處理內容時的計量單位

Token 可以理解成模型處理文字時使用的基本計量單位。

它不完全等於「一個字」或「一個單詞」，但在實際使用時，你可以先把它當成模型計算和計費的通用單位。你的輸入會消耗 Token，模型輸出的內容會消耗 Token，上下文裡保留的歷史內容同樣也會占用 Token。

所以為什麼很多模型服務一直強調上下文長度、成本控制和提示詞壓縮，本質上都和 Token 有關。