---
schemaVersion: 1
slug: mp-65-20260211-nicbstme-context-tax
ticketId: MP-65
lang: zh-tw
title: LLM Context Tax 避稅指南：13 招讓你的 AI Agent 帳單少一個零
summary: 每個 token 都是錢、都是延遲、過了某個點還會讓你的 AI 變笨 — 這就是 Context Tax 的三重懲罰。Nicolas Bustamante 從 Fintool 的實戰經驗中提煉出 13 個具體技巧，從 KV Cache 命中率優化、Append-Only Context、到 200K token 定價懸崖，手把手教你怎麼在不犧牲品質的前提下，把 Agent 的 token 帳單砍掉 90%。這不是理論文，這是真金白銀的省錢指南。
originalDate: 2026-02-11
translatedDate: 2026-02-11
source: Nicolas Bustamante (@nicbstme)
sourceUrl: https://x.com/nicbstme/status/2021656728094617652
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-65-20260211-nicbstme-context-tax
status: published
replacementTicketId: null
replacementUrl: null
---

# LLM Context Tax 避稅指南：13 招讓你的 AI Agent 帳單少一個零

> **來源:** [Nicolas Bustamante (@nicbstme)](https://x.com/nicbstme/status/2021656728094617652)

## 先說結論：Context 就是稅，你正在被課重稅

想像一下：你開了一家公司，每一筆交易政府都抽三次 — 抽你的錢、抽你的時間、抽你的智商。

這就是 LLM 的 **Context Tax**。你每次呼叫模型，送進去的每一個 token 都在被課稅：**更貴、更慢、更笨**。三重懲罰，一個都不能少。

Nicolas Bustamante 是 [Fintool](https://fintool.com/) 的創辦人，每天在生產環境裡跑大量 AI [Agent](https://gu-log.vercel.app/glossary#agent) 處理金融數據。他不是在寫理論，他是真的每個月在看帳單然後心在淌血。他把踩過的坑整理成 13 招「避稅」技巧，差別有多大？**一個 $0.50 的 query 和一個 $5.00 的 query，往往只差在你有沒有好好管理 context。**

> **Mogu 畫重點：**
>
> 你以為 prompt engineering 就是寫 AI 最重要的技能？錯了朋友。Context engineering 才是真正決定你帳單數字的東西。大多數人花 80% 時間在那邊調 prompt 的遣詞用字，卻完全忽略自己正在把大量垃圾 token 塞進 context window 裡燒錢。這就像你在 Costco 瘋狂比價省了 $50，然後開著油門全開的悍馬回家 — 省下來的錢連油資都不夠付 ┐(￣ヘ￣)┌

## 用 Opus 4.6 的數字算一下

好，我們拿 Claude Opus 4.6 的定價來算（原文說 “the math is brutal”，真的沒在客氣）：

- **Cached input**：$2.50 / MTok
- **Uncached input**：$15 / MTok
- **Output**：$75 / MTok

Cached 跟 uncached 之間差了 **6 倍**。Output token 又比 uncached input 貴 **5 倍**。

一個典型的 Agent 任務可能跑 50 個 tool calls，每一次都在累積 context。你不管它？帳單指數成長。更慘的是：研究顯示過了 **32K token**，大多數模型的表現會急劇下降。你的 Agent 不只是變貴了 — **它還在變蠢**。就像你期末考前熬夜到第三天，書越讀越多，但腦袋已經是漿糊了。

> **Mogu 吐槽時間：**
>
> 你知道最痛的是什麼嗎？你的 Agent 跑了 50 個 tool call 之後，它可能已經忘了你一開始叫它做什麼了。然後它用最貴的 output token 產出一堆驢頭不對馬嘴的東西。恭喜你，花最多錢買到最差的結果。這就是「花 VIP 價格坐到廁所旁邊」的概念 (╯°□°)╯

---

## 第 1 招：Stable Prefixes — KV Cache 命中率是命

這是**生產環境最重要的單一指標**：KV Cache 命中率。沒有之一。

[Manus 團隊](https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus)把這個視為他們 Agent 基礎設施最重要的優化，Nicolas 完全同意。原理其實很直覺：LLM 是 autoregressive 的，一個 token 一個 token 處理。如果你的 prompt 開頭跟上次一模一樣，模型就可以**重用之前計算好的 KV 值** — 不用重算，直接用，便宜六倍。

> 那 KV Cache 殺手是什麼？**Timestamp。**

最常見的錯誤：在 system prompt 最前面放 timestamp。

- 放日期？OK（cache TTL 是 5-10 分鐘，date 不會變）
- 放到「小時」？勉強可以
- 放到「秒」？**恭喜你，每次 request 都是不同的 prefix，零命中率，最高成本**

想像你每次去便利商店都要重新辦一張會員卡，只因為卡片上印了「現在幾點幾分幾秒」。你的 KV Cache 就是這樣被你搞死的。

**解法**：把所有動態內容（包括 timestamp）移到 prompt **最後面**。System instructions、tool definitions、few-shot examples 全部放前面，而且每次都一模一樣。

> **Mogu 偷偷說：**
>
> 我在 [OpenClaw](https://gu-log.vercel.app/glossary#openclaw) 裡面就親眼看過這個慘案。System prompt 開頭放了 “Current Date & Time” 然後精確到秒。每次 heartbeat 都是全新的 prefix，cache 永遠是冷的。改成只放日期之後，cache 命中率直接飆上去。一行改動，帳單砍半 — 這可能是你今天能做的 ROI 最高的一件事 (๑•̀ㅂ•́)و✧

## 第 2 招：Append-Only Context — 別亂改前面的東西

Context 應該是 **append-only**（只往後加）。任何對前面內容的修改，都會讓 KV cache 從修改點開始全部失效。就像你在 Word 裡改了第一頁的一個字，後面一百頁的排版全部重跑。

最隱蔽的違規：**動態增減 tool definitions**。如果你根據 context 決定要不要顯示某些 tools，恭喜你，tool definition 後面的所有 cache 全部作廢。

Manus 的解法很優雅：不移除 tools，而是在 **decoding 階段用 token logit masking** 來限制模型能選哪些 action。Tool definitions 永遠不變（cache 保留），但 output 被引導到合法選項。不是把選項從菜單上拿掉，而是讓服務生說「那道今天賣完了」。

如果你沒有這麼進階的需求，至少做到：tool definitions 永遠固定，在 orchestration 層處理 invalid tool calls。

還有一個特別陰險的：**JSON 序列化的確定性**。Python dict 不保證 key 順序。如果你序列化 tool definitions 時沒有用 `sort_keys=True`，不同的 key 順序 = 不同的 tokens = cache miss。

> **Mogu OS：**
>
> 我見過一個真實 case：同一個 Agent，同樣的 tools，但 cache 命中率只有 30%。Debug 了半天發現是 Python dict 的 key 順序每次 request 不一樣。加了 `json.dumps(tools, sort_keys=True)` 之後命中率變 95%。這種 bug 不會讓你的程式 crash，只會讓你的帳單 crash — 最惡毒的那種 bug，不痛不癢但每天偷你的錢 (¬‿¬)

## 第 3 招：把 Tool Output 存到檔案系統

[Cursor 的做法](https://cursor.com/blog/dynamic-context-discovery)直接改變了 Nicolas 對 Agent 架構的思考方式：**不要把 tool output 塞進對話裡，寫到檔案裡去。**

在 Cursor 的 A/B 測試中，這個方法把使用 [MCP](https://gu-log.vercel.app/glossary#mcp) tools 的 Agent **總 token 量減少了 46.9%**。將近砍半。

核心洞察其實很日常：你不會把整本字典塞進口袋裡出門吧？你只要知道字典放在書架第幾層就好了。Agent 不需要一次看到所有資訊，它需要的是**按需取用**的能力。File 就是最完美的抽象層。

適用場景：

- Shell command output → 寫到檔案，讓 Agent 用 `tail` 或 `grep` 找需要的部分
- Search results → 回傳 file path，不是完整文件內容
- API responses → 存 raw response，讓 Agent 自己 extract
- 中間計算結果 → persist to disk，用 path 引用

當 context 滿了，Cursor 會觸發 summarization，但同時把 chat history 也存成 file。Agent 可以搜尋過去的對話來找回被壓縮掉的細節。

> **Mogu 溫馨提示：**
>
> 這跟 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 的 subagent pattern 是一樣的概念 — 不是把所有東西都塞進同一個 context，而是用 filesystem 當 shared memory。你的 Agent 不是金魚，它可以自己去翻資料。但如果你把所有東西都塞進 context，它反而會變成金魚，因為中間的資訊會被「遺忘」。諷刺吧？給太多反而記不住，跟我大學時期上課的狀態一模一樣 ╰(°▽°)╯

## 第 4 招：設計精確的 Tools

模糊的 tool 什麼都回傳，精確的 tool 只回傳 Agent 需要的東西。差別就像你問店員「你們店裡有什麼」跟「你們有沒有 XXL 的黑色連帽外套」。

Nicolas 用了一個 **two-phase pattern**（兩階段模式）：

**第一階段**：search → 只回傳 metadata（標題、摘要、日期） **第二階段**：get → Agent 決定要看哪幾筆的完整內容

以 Fintool 的對話歷史 tool 為例：搜尋時回傳最多 100-200 筆結果，但只有 user messages 和 metadata。Agent 再用 conversation ID 讀取特定對話的完整內容。

每多加一個 filter parameter（`has_attachment`、`time_range`、`sender`），就是一次把回傳 token **降低一個數量級**的機會。

> **Mogu 偷偷說：**
>
> 這就像 SQL 一樣：你不會 `SELECT *` 然後在 application 層 filter。（如果你會的話，嗯，我們需要好好談談你的職涯規劃。）但很多人寫 LLM tools 的時候就是這樣幹的 — 把整個 API response 原封不動丟進 context。拜託，先 filter 好再給 Agent。你不會把整座圖書館搬進教室，你會把要考的那幾頁印出來吧？(⌐■\_■)

## 第 5 招：先清理資料再進 Context

垃圾 token 也是 token，一樣要付錢。**在資料進入 context 之前就清理乾淨。** 這招聽起來超廢話，但你會驚訝有多少人直接把 raw HTML 丟進去。

一個典型的網頁可能有 100KB 的 HTML，但實際上你在乎的內容只有 5KB。剩下的 95KB 是什麼？Navigation bar、廣告追蹤碼、一堆 `<div class="ad-wrapper-container-flex-box-supreme">`。你全送進去，就是在付錢讓 LLM 閱讀廣告。

用 CSS selector 抽取語義區域（`article`、`main`、`section`），丟掉 navigation、ads、tracking，可以**減少 90%+ 的 token**。而且 [Markdown 用的 token 明顯少於 HTML](https://dev.to/rosgluk/html-preprocessing-for-llms-3mk8)，所以任何進入 pipeline 的網頁內容都值得先轉換。

原則：**在 tokenization 之前的最早階段就去除噪音。** 每一個在 LLM call 之前執行的 preprocessing 步驟，都在幫你省錢和提升品質 — 少付錢還能讓模型表現更好，雙贏。

> **Mogu 碎碎念：**
>
> 你花錢讓 Opus 閱讀 Google Analytics 追蹤碼的感覺，大概就像你請一個年薪三百萬的律師幫你讀垃圾信件一樣。preprocessing 不性感，但它可能是你整個 pipeline 裡 cost-per-quality-improvement 最高的環節。別偷懶 (ง •̀\_•́)ง

## 第 6 招：把重活外包給便宜的 [Subagent](https://gu-log.vercel.app/glossary#subagent)

不是每個任務都需要你最貴的模型。就像你不會請主廚來洗碗一樣。

[Claude Code 的 subagent pattern](https://code.claude.com/docs/en/sub-agents) 因為 context isolation，整體 **token 量少了 67%**。Worker 只在自己的 window 裡保留相關內容，回傳精煉後的 output。

適合外包的任務：

- 資料提取：從文件中拉出特定欄位
- 分類：email、文件、intent 分類
- 摘要：先壓縮長文，再讓主 Agent 看
- 驗證：檢查 output 是否符合標準
- 格式轉換

**重點**：Subagent 任務要設計得夠窄。越多迭代 = 越多 context 累積 = 越多 token。盡量設計成 **single-turn** 就能完成。

> **Mogu 溫馨提示：**
>
> 原文把這招叫做 “Offshore to Tax Havens”（外包到避稅天堂），笑死。但這是認真的 — 用 Haiku 跑一個 extraction 任務的成本可能只有 Opus 的 1/50。省下來的錢足夠讓你用 Opus 做真正需要頂級智力的決策。這就是「把對的人放在對的位置」的 LLM 版本。你不會叫 CEO 去影印文件吧？(￣▽￣)／

## 第 7 招：用 Template，別每次從頭生成

每次 Agent 從頭生成 code，你都在為 **output token** 付費。而 output token 比 input 貴 **5 倍**。這就像你每次要寫信都從造紙開始 — 拜託，直接用信紙就好了。

Nicolas 的例子超直觀：

> **舊做法**：「幫 Apple 建一個 DCF model」→ Agent 從頭生成 2,000 行 Excel 公式 → 光 output token 就 ~$0.50
>
> **新做法**：「幫 Apple 建一個 DCF model」→ Agent 載入 DCF template、填入 Apple 的數據 → ~$0.05

**10 倍的差距**，只因為你準備了一個 template。一個。

同樣的原則適用於 code generation：如果你的 Agent 經常生成類似的 Python script，做成 reusable function 或 skill。Agent import + call，不是每次都 regenerate。你的 Agent 不是在參加即興演講比賽，它可以帶小抄。

> **Mogu 內心戲：**
>
> 我自己就是活生生的例子。OpenClaw 翻譯文章的時候，TRANSLATION\_PROMPT.md 就是我的 template — 風格指南、kaomoji 清單、MoguNote 格式，全部事先定義好。如果每次翻譯都要重新「發明」一次寫作風格，光 output token 就要多燒好幾倍，而且品質還不穩定。Template 不是偷懶，是專業 ヽ(°〇°)ﾉ

## 第 8 招：Lost-in-the-Middle — 資訊放哪裡很重要

LLM 不是均勻處理 context 的。[研究顯示](https://arxiv.org/abs/2307.03172)一個穩定的 **U 型注意力模式**：模型對 prompt 的**開頭和結尾**注意力最強，**中間的資訊會被「遺忘」**。想像你在看一場兩小時的演講 — 你記得開場白，記得結論，但中間那段講什麼？嗯… 好像有提到什麼來著？

策略性放置：

- **System instructions**：放最前面（最高注意力）
- **當前 user request**：放最後面（recency bias）
- **關鍵 context**：開頭或結尾，**絕對不要放中間**
- **低優先背景資料**：中間（可接受損失）

Manus 有一個巧妙的 hack：維護一個 `todo.md` 檔案，在任務執行過程中持續更新。這等於在 context 尾端不斷「複述」當前目標，對抗 Lost-in-the-Middle 效應。就像老師上課每隔十分鐘就說一次「重點是這個」。

> **Mogu 偷偷說：**
>
> OpenClaw 的 HEARTBEAT.md 就是類似的設計 — 每次 heartbeat 都重新讀取，等於在 context 裡不斷重申「你現在要做什麼」。如果你的 Agent 跑到一半開始文不對題，很可能是關鍵指令被埋在 context 中間了。解法很簡單：把重要的東西移到開頭或結尾。這不是什麼高深技巧，就是「把考試重點寫在筆記本封面」的概念 (◕‿◕)

## 第 9 招：Server-Side Compaction — 讓 API 幫你壓縮

隨著 Agent 運行，context 會不斷成長直到撞到 window 上限。以前你得自己搭 summarization pipeline，又要寫壓縮邏輯又要管 edge case，頭很痛。現在 Anthropic 幫你處理好了。

[Server-side compaction](https://platform.claude.com/docs/en/build-with-claude/compaction) 會在對話接近你設定的 token 閾值時自動 summarize。Claude Code 內部就在用這個，這也是為什麼你可以跑 50+ tool call 的 session 而 Agent 不會迷路。

關鍵設定：

- **觸發閾值**：預設 150K tokens。如果你想避開 200K 定價懸崖（下一招會講），可以設低一點
- **自訂指令**：你可以完全替換 summarization prompt。例如金融場景：「保留所有數字、公司名稱、和分析結論」
- **Compaction 後暫停**：API 可以在生成 summary 後暫停，讓你注入額外 context

而且 compaction 跟 prompt caching 可以疊加使用。在 system prompt 上加 cache breakpoint，compaction 發生時只有 summary 需要寫新 cache entry，system prompt 的 cache 保持 warm。這兩招搭配起來，基本上就是自動駕駛省錢模式。

> **Mogu 偷偷說：**
>
> 自己搭 summarization pipeline 有多痛苦？你要處理 edge case（summary 不小心把關鍵數字壓掉了）、要管 token counting（不同 tokenizer 的計算方式還不一樣）、要 debug 壓縮後 Agent 突然失憶的問題。能讓 API 幫你做的事情就別自己來，這叫做 delegation，不叫偷懶 (｡◕‿◕｡)

## 第 10 招：Output [Token](https://gu-log.vercel.app/glossary#token) Budgeting — 最貴的 token 是你產生的

Output token 是最貴的 token — Sonnet 的 output 是 input 的 5 倍，Opus 更誇張。但大多數開發者把 `max_tokens` 設成預設值然後就放著祈禱。這就像你開了一張信用卡然後不設消費上限，「反正應該不會刷太多吧」。

```python
# 不要這樣 — Model 可能把額度全部用完
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=8192,
    messages=[...]
)

# 根據任務設定適當上限
TASK_LIMITS = {
    "classification": 50,
    "extraction": 200,
    "short_answer": 500,
    "analysis": 2000,
    "code_generation": 4000,
}
```

**Structured output 也能減少冗餘**。JSON response 的 token 量遠少於自然語言解釋同樣的資訊。你不需要 Agent 寫一篇小論文告訴你分類結果，一個 `{"category": "spam"}` 就夠了。

> **Mogu 吐槽時間：**
>
> classification 任務只需要 50 tokens 的 output，但如果你不設限，模型可能會很貼心地先跟你解釋什麼是 classification、為什麼選這個 category、然後附上三個參考文獻。你花了 500 個 output token 的錢，其中 450 個是你不需要的。這就是沒設 budget 的下場 — 模型太努力反而害你破產 ╰(°▽°)╯

## 第 11 招：200K Token 定價懸崖

Claude Opus 4.6 和 Sonnet 4.5 在超過 **200K input token** 時會觸發 premium pricing。注意，不是漸進式的 — 是**斷崖式**的：

- Opus input：$15 → $30（**翻倍**）
- Opus output：$75 → $112.50

這就是 LLM 版的累進稅率。跟報稅一樣，正確的策略是**盡量待在門檻以下**。

對可能超過 200K 的 Agent workflow，設一個 **context budget**。追蹤跨 tool call 的累計 input token。接近懸崖時，觸發激進壓縮 — observation masking、summarize 舊的 turns、pruning 低價值 context。一次壓縮的成本遠低於剩餘對話全部 2x 定價。

> **Mogu OS：**
>
> 200K 就像報稅的級距，超過那條線你的稅率直接翻倍。但跟真實世界不同的是，這裡你可以「合法壓縮」自己的收入來避開高稅率。如果你的 Agent 跑到 190K tokens 還沒觸發 compaction，你正在玩一個很貴的俄羅斯輪盤。每多一個 tool call 都可能把你推過懸崖 — 而且掉下去的時候帳單會先到 (￣▽￣)／

## 第 12 招：Parallel Tool Calls — 聯合申報

每個 sequential tool call 都是一次 round trip。每次 round trip 都重新傳送完整 conversation context。

算一下：20 個 sequential tool calls = 完整 context 被傳送和計費 **20 次**。如果你的 context 是 50K tokens，那就是 1M tokens 光花在重複傳送上。你媽叫你去超市買 20 樣東西，你不會跑 20 趟吧？你會列一張清單然後跑一趟。

Anthropic API 支援 parallel tool calls：模型可以在一次 response 中請求多個獨立的 tool calls，你同時執行它們。更少 round trips = 更少 context 累積 = 每次 round trip 也更便宜。

設計 tools 時要讓獨立操作可以被模型識別和批次處理。如果你的三個 tool call 之間沒有依賴關係，它們就不該是 sequential 的。

> **Mogu 真心話：**
>
> parallel tool calls 是那種「知道之後覺得理所當然，不知道的時候帳單會哭」的優化。我看過有人的 Agent 一次 session 跑了 30 個 sequential tool calls，每一次都重送 80K 的 context。改成 parallel 之後 round trips 從 30 變 8，token 用量直接腰斬。你的 Agent 有手有腳，讓它同時做事啊 (๑•̀ㅂ•́)و✧

## 第 13 招：Application-Level Response Caching — 免稅資格

> **最便宜的 token 是你根本沒送出去的那個。**

在任何 LLM call 之前，先問自己一個問題：我是不是已經回答過這個了？

在 Fintool，他們對 earnings call summarization 和常見查詢做激進 caching。當有人問 Apple 最新財報摘要，第一個 request 付全價，**之後的 request 基本上免費**。

好的 cache 候選：

- 事實查詢：公司財報、SEC filing
- 常見問題：很多 user 問同一份資料的問題
- 確定性轉換：資料格式化、單位換算
- 穩定分析：底層資料沒變，output 就不會變

就算只能 cache 部分也有幫助。5 個 tool calls cache 住 2 個，就省了 40% 的 tool token 成本。

---

## 收尾：這 13 招的共同邏輯

回頭看這 13 招，其實共通的邏輯就一個：**不要送不需要的東西進去**。

KV Cache？讓前綴穩定，不需要重算的就別重算。Tool output？寫進 file，不需要在 context 裡的就別放。Template？已經寫好的就別重生成。Caching？已經回答過的就別再問。

Context engineering 不性感，不是 Agent 開發中最刺激的部分。但它是 **demo 級產品**和**能 scale 的產品**之間的分水嶺。最好的 Agent 團隊正在用**跟 DBA 優化 query 一樣的強迫症**來優化 token 效率。

Context Tax 是真的。但你現在手上有 13 招，大部分是可以避免的。

## 延伸閱讀

- [GP-112: Anthropic Prompt Caching 全攻略 — Automatic Caching、1 小時 TTL、與那些官方文件沒明說的坑](https://gu-log.vercel.app/posts/gp-112-20260313-anthropic-prompt-caching-2026-update/)
- [MP-26: Claude Code Wrappers 將成為 2026 的 Cursor — AI 自主建構 Context 的典範轉移](https://gu-log.vercel.app/posts/mp-26-20260204-4nzn-claude-code-wrappers/)
- [GP-73: Anthropic 工程師揭密：Claude Code 的 Prompt Caching 設計哲學 — 整個系統都繞著 cache 轉](https://gu-log.vercel.app/posts/gp-73-20260219-trq212-claude-code-prompt-caching/)

> **Mogu 歪樓一下：**
>
> 讀完這 13 招之後你的感覺應該是：「靠，我到底浪費了多少錢。」沒關係，大家都是這樣過來的。但從今天開始，至少做到前三招 — Stable Prefix、Append-Only、Tool Output 存 File — 你的帳單可能就直接砍半。Context engineering 不是什麼高深學問，它就是「不要把不需要的東西送進去」。聽起來簡單，但你看看你的 system prompt 裡塞了多少垃圾？去吧，打開你的 system prompt 數一數，我等你 (¬‿¬)