上下文經濟學：Token 就是預算

上下文視窗是有限資源

這一章要說的事情很直接：上下文視窗有上限，Token 有成本，怎麼花比能花多少更重要。

Claude Code 對 Token 的管理方式不是「盡量塞更多資訊」，而是「確保最相關的資訊在視窗裡，其餘的壓縮或丟棄」。這個思路貫穿了整個上下文管理系統的設計。

四道壓縮機制

最輕量的是 Snip：單個工具結果超出 resultBudget 時直接截尾，附上「共 X 行，顯示前 Y 行」的提示。損失細節，保留結構。

稍重一層的是 Micro Compact，針對對話歷史裡的中間輪次：某一輪的工具呼叫不再和當前任務直接相關時，用一句話摘要替換原始內容。視窗裡還是有「發生過什麼」的記錄，但 Token 佔用大幅降低。

Context Collapse 是全局壓縮，把整個對話歷史濃縮成結構化摘要後重啟上下文。細節會丟，但能釋放大量空間，讓長任務繼續跑。通常在接近視窗上限時觸發，或使用者手動執行 /compact 時觸發。

Auto Compact 是 Context Collapse 的自動觸發版，主迴圈偵測到使用率超閾值時自動執行，用獨立子 Agent 做壓縮。聽起來方便，但子 Agent 本身也要消耗 Token 和時間。在長任務的階段性節點手動 /compact 一次，通常比等它自動觸發划算。

Reactive Compact：API 413 兜底

四道壓縮機制都是主動管理。但如果全部失效，API 回傳 413（請求體過大）怎麼辦？

Reactive Compact 是這個場景的兜底機制。收到 413 時，query.ts 自動觸發緊急壓縮——比 Context Collapse 更激進，把歷史壓縮到最小可用狀態，然後重試這次 API 請求。這個過程對使用者透明，沒有錯誤提示，只是感覺到一次稍長的停頓。

兜底機制的存在讓系統在各種極端情況下（超長程式碼貼入、工具結果爆炸式增長）仍然能繼續工作，不是直接報錯退出。

Token Budget：按類別分配

每輪迴圈開始時，query.ts 計算當前可用的 Token 預算，然後按類別分配：

對話歷史拿大頭（約 60%），這是讓模型理解當前任務的最關鍵資訊。工具結果預算（約 25%）控制這輪執行工具後結果的最大 Token 量，超出就觸發 Snip。System prompt 佔固定比例（約 10%），這部分壓縮空間不大，主要靠快取降低成本而不是降低 Token 量。剩餘的緩衝給動態注入的內容（Skill 指令、MCP 說明、Memory 片段）。

預算分配不是精確計算，是帶容差的估算——確保即使工具結果比預期長，也不會把整個視窗撐爆。

按需注入：讓視窗用在刀口上

按需注入是 Token 管理的主動端。不是所有資訊都在啟動時塞進上下文，而是根據當前任務的需要動態決定注入什麼。

Skill 指令只在 skill 載入期間存在，對話結束後清出。MCP 工具的行為說明跟著工具的可用狀態走，工具不在就不占位。Memory 片段按相關性排序後只取前 N 條——記憶庫可以很大，但每次注入的是當前最相關的那幾條，不是全倒。工具執行結果也是同樣邏輯：主 Agent 拿到結構化摘要，原始輸出留在執行層，不進視窗。

按需注入的邏輯是：模型不需要知道所有事情，它需要知道當前這一步要做的事情。其餘的資訊存在磁碟上，用到時再取，比永遠放在視窗裡佔著空間划算。

---

參考來源： 本文內容參考 Xiao Tan（@tvytlx）的《Claude Code 源碼架構深度解析 V2.0》，基於原報告的分析框架和研究成果整理。