目錄
很多用 Claude Code 或者各類終端 Agent 寫程式碼的開發者，最近都在吐槽同一件事。
明明自己只是讓 AI 查了個小函式，或者改了兩行樣式，幾輪對話下來，後臺提示額度又快見底了。如果按 API 用量計費，月底帳單一拉，常常莫名其妙飆到幾百美元。大家的第一反應往往是模型變貴了，或者覺得自己程式碼寫得太頻繁。
如果把每次請求的底層資料包拆開看一眼，你會發現一個讓人倒吸一口涼氣的真相：
你的帳戶裡有將近一半甚至七成以上的 Token 開銷，根本不是在幫你分析邏輯或者生成程式碼。這些真金白銀全耗在了 AI 每次開口前，一遍又一遍反反覆覆朗讀給它自己的自我介紹和背景說明書上。
在駭客新聞（Hacker News）社群曾經有一篇討論度極高的對比評測。有開發者專門抓取了 Claude Code 和 OpenCode 這兩款工具在啟動階段的標記消耗：資料對比極其刺眼，在使用者還沒有敲下任何實際業務需求之前，Claude Code 僅僅是初始化環境，就已經悄無聲息地吞掉了將近 33,000 個 Token；而在精簡架構的開源工具裡，這個初始數字只要 7,000 左右。
這意味著每次你剛開啟終端，還沒開始幹活，底層的計費計數器就已經為你跑完了三萬多字的基礎開銷。
搞清楚這筆糊塗帳到底是怎麼算出來的，是每一個重度使用 AI 程式設計的人必須補上的一課。
一、 那幾萬個 Token 究竟裝了什麼
很多人以為，自己給模型發一句「幫我看看這個報錯」，上傳的資料包就真的只有這十幾個字。
在普通網頁對話框裡可能確實接近這個狀態，但在真實的終端 Agent 體系裡，情況完全不同。為了讓大模型表現得像一個熟悉你電腦作業系統的全能程式設計師，用戶端在暗地裡為你打包了一個極其龐大的背景環境。
這個背景包主要由三堆沉重的內容拼裝而成：
| 注入層級與內容類別 | Token 估算消耗 | 核心構成與具體項 |
|---|---|---|
| 1. 系統人格與全域安全邊界 | ~4,000 – 8,000 | 身分宣告、安全禁令、互動準則、階段性彙報契約 |
| 2. 工具全量函式宣告 (Tool Definitions) | ~15,000 – 20,000 | Read, Write, Edit, Bash, Grep, Glob 及全部 MCP 工具參數 Schema |
| 3. 工作區與上下文環境快照 | ~5,000 – 10,000 | 專案目錄樹、Git 狀態、全域規則檔案、環境變數與環境記憶 |
⬇️ 單次請求開局基線：30,000+ Tokens（尚未輸入一行有效程式碼與提問，起步已消耗 3 萬 Token）
- 第一堆是巨幅的系統人格與行為準則：告訴大模型它叫什麼名字，必須遵守哪些安全規則，遇到危險命令要怎麼拒絕，什麼時候該簡短回答，什麼時候該分步排查。光是這一套行為框架，在底層往往就佔去了幾千個 Token。
- 第二堆是所有工具的完整函式描述（Tool Use Schemas）：Agent 之所以能查你的目錄、讀你的檔案、跑終端命令，全靠大模型的函式呼叫機制。模型自己其實不知道電腦裡有什麼工具，用戶端必須在每一次對話的開頭，把所有可用工具的名稱、參數類型、可選欄位、輸入限制以及錯誤說明，完完整整、一字不漏地全部序列化成一段巨大的 JSON Schema，塞進上下文的最前端。
- 第三堆則是你自己的設定檔：你的專案規則檔案（
CLAUDE.md/AGENTS.md）、當前目錄的結構樹、Git 狀態摘要，甚至連環境變數和歷史記憶，都會被一股腦打包塞進去。
最要命的是，這種「自我介紹」在很多場景下不是發一次就結束了。
只要你中途派生了一個子代理（Subagent）去後臺跑測試，或者開了一個分支任務去檢索另外幾個檔案，每個新派生出來的代理程序，都會在它自己的上下文裡，把這三萬多字的自我介紹從頭到尾再複製一遍。
如果有 7 個子任務在並行跑，光是這套背景說明書，就憑空消耗了 20 多萬個 Token。
二、 快取的蜜糖與陷阱：Prompt Caching 為什麼頻頻失效
這時候熟悉技術的朋友可能會反駁：Anthropic 官方不是推出了 Prompt Caching（提示詞快取） 技術嗎？相同的背景不是能享受低至一折的讀取優惠嗎？
快取機制確實幫大家省了不少錢，但很多人沒有算清楚它的隱性門檻與命中條件：
| 計費環節 | 標準單價（以旗艦級 Sonnet 模型為例） | 緩存摺扣 | 關鍵前提 |
|---|---|---|---|
| 首次寫入快取 (Cache Write) | $3.75 / 百萬 Token | +25% 溢價 | 需完整處理並序列化字首 |
| 快取命中讀取 (Cache Read) | $0.30 / 百萬 Token | -90% 折扣 | 必須在 5 分鐘生命週期內命中 |
| 常規輸入 (Uncached Input) | $3.00 / 百萬 Token | 基準價 | 快取未命中或被破壞 |
官方設立了一個約 5 分鐘的過期時間視窗（Cache TTL）。這就帶來了一個極其隱蔽的成本陷阱：
- 密集寫程式碼時：如果你正在全神貫注地密集互動，每隔一兩分鐘發一條指令，這套 3 萬多字的系統提示確實能穩穩命中快取，花銷看起來微乎其微。
- 思考與除錯間歇：程式設計師的日常工作從來不是連續敲鍵盤的打字機。你讓 AI 寫完一段複雜邏輯，往往需要停下來看十分鐘程式碼，或者切到瀏覽器裡測一下真實效果，又或者去喝杯咖啡構思下一個模組。只要你的停頓時間超過了 5 分鐘，之前的快取就會被靜默清空。等你再次回到終端輸入一個「繼續」，系統又必須把那 3 萬多字的說明書重新按原價、甚至加上首次寫入溢價，徹徹底底重新計算一遍！
更隱蔽的殺手是字首破壞（Prefix Invalidation）：
Prompt Caching 機制極其挑剔：它要求整個文字序列從第一個字元開始完全一模一樣才能命中快取。
如果你的自動化腳本在系統提示的最前端動態插入了一個隨時在跳動的毫秒級時間戳，或者每輪對話因為併發排序改變了工具註冊的先後順序，整條快取鏈條就會當場失效，隨後的所有請求都會退化成全額計費。
三、 幾百小時日誌實測：真實開銷佔比
我對這筆帳的敏感，也是在真實開發裡被狠狠教訓出來的。
前段時間我手上同時跑著好幾份訂閱，日常用 Claude Code、Codex 配合各種自動化工作流。有幾天我在做開源閘道器 Magpie 的多模型動態路由調優，後臺掛著幾個長期會話做監控。那幾天我明顯感覺額度掉得快得出奇。
一開始我以為是某個推理模型太消耗計算量，後來我抓出閘道器的全部呼叫日誌，把所有的輸入與輸出做了分詞統計：
[Token 消耗真实构成分析]
■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 72% 系统人格 + 工具描述 + 全局规则文件重复传递
■■■■■■■■ 21% 检索历史上下文 + 冗长错误日志堆栈
■■■ 7% 真实业务代码与核心解答
在這幾千次互動裡，真正用於業務程式碼邏輯的 Token 佔比不到三成。整整七成的開銷，全在周而復始地重複傳送我寫在專案根目錄下的全域規則檔案，以及那幾個沒怎麼用過的第三方工具說明。
我當時為了圖省事，把團隊的工程規範、發布禁令、瀏覽器操作指南甚至樣式要求，全寫進了一個巨大的引導檔案裡。結果不管當前任務是改一個字母還是重構一個模組，系統每輪對話都要把這幾萬字的大全集在各個子代理之間搬運一遍。
更糟糕的是，我當時寫的一個狀態列探針，每隔幾秒鐘會在上下文裡更新當前會話的執行時長。這個毫秒級的動態數字正好嵌在最前面，無意中直接破壞了整套快取的字首匹配。
我本以為自己搭了一套全自動的極客開發流，實際是在拿真金白銀給模型的自我介紹充當背景音樂。
四、 四步給你的 Agent 帳單徹底瘦身
如果你也想把這種無謂的隱藏浪費堵住，建議立刻按下面這四步給你的環境做一次全面體檢：
1. 規則檔案的物理拆分（從單體臃腫到按需載入）
不要在全域根規則（如 CLAUDE.md）裡堆砌萬字百科全書。把那些低頻的操作指南剝離出去，只保留最核心的停止點與安全邊界：
- 常駐根規則（< 150 行）：只寫架構邊界、核心技術棧、檔案操作禁忌和核心提交契約；
- 低頻流程（按需喚起）：關於瀏覽器交接、發布打包、技術表達審改的詳細說明，全部封裝成獨立的技能（Skills）或區域性 Reference。只有當具體任務確實命中對應場景時，才由工具區域性讀取那幾百字，絕不讓普通寫程式碼的會話扛著發布腳本的全部說明書。
2. 嚴格保護快取字首的絕對靜態
檢查所有會注入到上下文裡的內容：
- 絕對禁止將動態時間戳、隨機數、易變的環境變數寫在系統提示詞的最前列；
- 固定字首結構：將長期不變的內容（系統身分、核心約束、固定工具描述）死死鎖定在上下文最前端；
- 將動態變數、當前活躍檔案內容、使用者最新輸入的 Query 安排在佇列末尾。只有這樣，底層的快取機制才能穩定命中，享受 90% 的成本折扣。
3. 剋制子代理（Subagent）的無序併發
很多開發者看到工具支援派生代理就特別喜歡多開，動不動讓系統併發啟動五六個後臺會話。每一次派生不是簡單的函式呼叫，它是在複製一套完整的上下文生態：
- 對於幾行程式碼的區域性驗證，或者目標明確的單檔案修改，優先在主會話裡直接執行，不要動輒呼叫後臺並行群；
- 把高開銷的獨立代理，留給真正需要隔離環境的大型重構或長流程調研。
4. 閘道器層意圖分流（Model Routing）
如果你的業務呼叫量很大，不要讓昂貴的主力旗艦模型去通吞所有的前置環境嗅探：
- 藉助開源 AI 閘道器（如 Magpie）或者本機路由腳本，把任務做意圖分層；
- 讓響應極快、單價極低的輕量高吞吐模型去處理早期的檔案檢索、路徑確認和環境準備；
- 只有當真正需要深度推理和核心架構推導的那一刻，再把整理乾淨的精煉上下文遞交給旗艦模型。
五、 結語
使用新工具的快樂，往往很容易掩蓋掉系統設計上的粗糙與浪費。
大模型確實賦予了單兵作戰極其強悍的生產力，但越是強大的能力，越需要精細化的工程邊界去駕馭。
真正成熟的技術人，不會只看終端裡游標飛速跳躍的快感，更會算清楚每一次系統呼叫背後真實的代價。看清帳單背後的秘密，把每一份算力和費用，都結結實實地花在解決真實業務問題的刀刃上。