Token 經濟學進階：當 Agent 一天燒掉 $50，你怎麼控制成本

Agentic Engineering 實戰手冊第 11 / 14 篇

這是「Agentic Engineering 實戰手冊」系列的第十一篇。上一篇：Multi-Agent 編排實戰

上個月帳單 $287，這個月 $148

上個月我的 AI coding 總帳單是 $287。嚇了一跳。

不是用太多，工作量其實差不多，問題出在使用方式：超長的 session 導致 context window 持續膨脹、探索性的 codebase 搜尋吃掉大量 token、該用便宜 model 的地方用了貴的。

花了一個週末分析之後，這個月在相同工作量下壓到了 $148。差距來自三個改變：context pruning、model routing，還有更有紀律的 session management。

重點不是「少用」，是「聰明用」。如果你也有 token 燒光的焦慮，這篇從工程面給你具體的解法。

Token 成本解剖學

要省錢，先搞懂錢花在哪。

三種 Token，三種價格

Token 類型	什麼時候產生	你能控制嗎
Input tokens	你給 model 的一切：system prompt、CLAUDE.md、conversation history、code context	是——context engineering 直接影響
Output tokens	Model 回給你的一切：code、解釋、tool calls	部分——精準的 spec 讓 agent 少寫廢話
Thinking tokens	模型推理時的內部 token（extended thinking）	部分——簡單任務關閉 extended thinking

真正隱藏的成本殺手是 input tokens。

大部分人以為成本主要來自 output（agent 寫的 code），其實不是。在一個典型的 agentic session 裡，input tokens 通常是 output 的 3-5 倍。因為每一輪對話，整個 conversation history + system prompt + context 都會被重新送一次。

一個 session 跑了 50 輪對話，最後幾輪每次都要送入幾十萬 token 的 history——光是這些重複的 input 就占了帳單的大頭。

一次「幫我修這個 bug」的 Token 分解

一個看似簡單的 bug fix request：

System prompt + CLAUDE.md:     ~5,000 tokens
Conversation history (20 輪):  ~40,000 tokens
Agent 讀的 code files:         ~15,000 tokens
Agent 的 tool calls:            ~8,000 tokens
Agent 的 output (code + 說明):  ~3,000 tokens
Extended thinking:              ~5,000 tokens
─────────────────────────────────────────────
Total:                         ~76,000 tokens

Agent 最後寫出來的 code（3,000 tokens）只佔總消耗的 4%，而 conversation history（40,000 tokens）佔了 53%。最大的省錢機會不在「少寫 code」，在「管理 conversation history」。

每種任務的成本對照

根據我三個月的追蹤數據（approximation based on usage patterns）：

任務類型	平均 Token 消耗	大約成本	備註
Simple bug fix	50K-100K	$0.20-0.50	通常 1-3 輪對話
New feature (small)	150K-300K	$0.50-1.50	5-10 輪，含 review
New feature (medium)	500K-1M	$2-5	多輪 iteration
Refactor	800K-2M	$3-10	大量 codebase 探索
Code review	100K-200K	$0.30-1.00	讀多寫少
Codebase exploration	300K-800K	$1-4	Token 黑洞
Documentation	200K-400K	$0.50-2.00	Output-heavy

Token 黑洞排行：

Refactor——agent 需要讀很多檔案，理解整體架構，然後做大量修改
Codebase exploration——「幫我搞懂這個系統怎麼運作」類型的任務，agent 會讀幾十個檔案
Long debugging sessions——一來一回的 debug loop，conversation history 指數增長

優化策略一：Context Pruning

回到 Context Engineering 的核心觀念：context 不是越多越好，剛好夠就行。

精簡 CLAUDE.md

每多一行 CLAUDE.md，就多花幾個 token 在每一輪對話裡。乘以 session 裡的對話輪數，成本累積驚人。

Before：400 行的 CLAUDE.md，每輪 ~4000 tokens × 30 輪 = 120,000 tokens 浪費在重複載入上

After：100 行的 CLAUDE.md，每輪 ~1000 tokens × 30 輪 = 30,000 tokens

光這一項就省了 90K tokens（約 $0.30/session）。看起來不多，但每天做 10 個 session，一個月就是 $90。

Session 管理紀律

黃金法則就一句：一個 session 做一件事。

一個 session 跑太久，conversation history 會指數膨脹。第 50 輪的對話要送入前面 49 輪的 history，那可能是 200K+ 的 input tokens。

改善做法：

一個 task 一個 session。task 做完就關，開新 session 做下一個。
如果 task 需要多輪 iteration，中途做 checkpoint（更新 plan/TODO），然後開新 session 繼續。
利用 Claude Code 的 context compaction，當 context 太大時它會自動壓縮舊的對話。但與其依賴自動壓縮，不如主動控制 session 長度。

Sub-Agent 模式

探索性的任務（「幫我搞懂這個模組的架構」）特別燒 token。解法是用 sub-agent：

主 agent: 「研究 auth 模組的架構」
  → 派出 sub-agent（cheap model、獨立 context）
  → sub-agent 讀 20 個檔案，消耗 200K tokens
  → 回報 2000 token 的摘要給主 agent

主 agent 的 context 只增加了 2000 tokens，而不是 200K。

優化策略二：Model Routing

不是所有任務都需要最貴的模型。

我的 Model 選擇框架

任務類型	推薦 Model	原因
簡單問答、分類	Haiku	快、便宜、準確度足夠
日常 coding、bug fix	Sonnet	性價比最高
複雜架構決策	Opus	需要深度推理
Code review	Sonnet	理解力夠、比 Opus 快
Commit message	Sonnet/Haiku	不需要 Opus 的推理能力
長篇寫作	Opus	需要一致性和深度
Codebase exploration	Sonnet + sub-agents	用便宜的 model 做大量探索

實際省下多少？

以一天的典型工作量為例：

Before（全部用 Opus）：

10 個 tasks × 平均 300K tokens × Opus 價格 ≈ $15/天

After（model routing）：

2 個 complex tasks → Opus：600K tokens ≈ $4
6 個 standard tasks → Sonnet：1.2M tokens ≈ $4
2 個 simple tasks → Haiku：200K tokens ≈ $0.10
Total ≈ $8/天

同樣的工作量，成本掉了 47%，品質幾乎沒差。Sonnet 在日常 coding 任務上的表現跟 Opus 非常接近。

怎麼切換

在 Claude Code 裡，隨時可以用 /model sonnet 或 /model opus 切換。我的 commit skill 裡就有提醒：做 git commit 用 Sonnet 就好，不需要 Opus。

優化策略三：Prompt Caching & Batching

Prompt Caching

Anthropic 的 prompt caching 機制讓相同的 system prompt 只需要在第一次完整傳送，後續的 request 可以使用 cache，大幅降低 input token 成本。

怎麼提高 cache hit rate：

CLAUDE.md 保持穩定——頻繁修改 CLAUDE.md 會導致 cache miss
System prompt 放在 context 的最前面（cache 是 prefix-based 的）
避免在 system-level context 裡放動態內容（timestamp、random ID 等）

Batching 策略

把相似的小任務合成一個 request：

Before（5 個獨立 request）：

1. "修正 Button component 的 hover color"
2. "修正 Card component 的 border radius"
3. "修正 Input component 的 focus style"
4. "修正 Modal component 的 backdrop color"
5. "修正 Toast component 的 animation"

5 次 system prompt 載入 + 5 次 CLAUDE.md 載入 = 大量重複的 input tokens。

After（1 個 batch request）：

修正以下 5 個 component 的 CSS 問題：
1. Button: hover color
2. Card: border radius
3. Input: focus style
4. Modal: backdrop color
5. Toast: animation

1 次 system prompt 載入 + 1 次 CLAUDE.md 載入。Token 節省 ~60%。

月度預算框架

Agentic engineering 合理的月成本是多少？取決於你的使用強度：

使用級別	月成本	誰適合
Light ($20-50)	Pro 訂閱 + 少量 API	兼職使用、學習階段
Medium ($50-150)	Pro + 日常 API 使用	全職 agent-first 開發
Heavy ($150-300)	大量 API + multi-agent	多專案、multi-agent 架構
Enterprise ($300+)	Team 帳號 + 自建工具	團隊級別使用

ROI 計算

$150/月的 agent 成本值不值得？算一下：

假設 agentic workflow 讓你每天省 2 小時（保守估計，根據 Post 7 的 4x 效率提升）。

一個月工作 22 天 × 2 小時 = 44 小時
以台灣軟體工程師平均時薪 $25 USD 計算：44 × $25 = $1,100
ROI：$1,100 / $150 = 7.3x

即使你用最貴的 Opus model 跑所有事情，只要它讓你省下的時間值超過 $300/月，就是值得的。

大部分 agent-first 工程師的 sweet spot 在 $100-200/月。這個範圍可以覆蓋每天 8-10 小時的 agent-first 工作方式，如果你做好 model routing 和 context management。

我具體做了什麼把帳單從 $287 降到 $148

Session 拆分：從平均 45 分鐘/session 降到 20 分鐘/session。對話輪數從 30 降到 12。
Model routing：70% 任務改用 Sonnet（之前 90% 用 Opus）。
Sub-agent 探索：codebase exploration 任務全部丟給 sub-agent，主 context 不膨脹。
CLAUDE.md 瘦身：從 400 行精簡到 100 行。任務特定的指令移到 rules files 和 skills。
Batch 處理：小任務合併。一天 15 個 request 降到 8 個。

每一項單獨看都不是巨大的改變。但加在一起，就是 48% 的成本降低。

Takeaway

Token 成本的最大殺手是不必要的 context 膨脹，不是使用量。Conversation history 佔了帳單的一半以上。控制 session 長度、精簡 CLAUDE.md、善用 sub-agent，這三招就能省 30-40%。
Model routing 可以在不犧牲品質的前提下省 40-50% 成本。日常 coding 用 Sonnet，只有複雜架構決策才需要 Opus。Commit、simple Q&A 用 Haiku 就夠了。
$100-200/月是大部分 agent-first 工程師的 sweet spot。這個成本對應的 ROI 通常在 5-10x。不要為了省 $50 犧牲工作流的效率，但也不要因為「反正有用」就不管成本地亂燒。

上一篇：Multi-Agent 編排實戰 下一篇：Agent 安全網設計