四層 Context 壓縮:200K 窗口的真實調度
本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 3 篇。前一篇談了 Agent Loop,這一篇會進入這個系列裡技術密度較高的主題。如果你之前對「為什麼我的 context 會突然不夠用」、「/compact 到底何時該按」、「Claude 為什麼突然開始忘東西」這些問題感到困惑,這篇會把這些機制一起拆開來看。 為什麼需要整整一篇寫這件事 前一篇講了 Agent Loop —— 每一輪模型呼叫,都要把整段對話歷史送進 API。 這件事在對話短的時候沒人會在意。但當任務開始變長: 一個跨 10 個檔案的重構 一次完整的事件排查 一份規格文件從草稿到定稿的對話 你會發現一個令人焦慮的現象:Claude Code 開始回應變慢、帳單變貴、有時候甚至主動告訴你「context 快滿了」。 根本原因在於 context window 的物理上限。以目前主流的 Claude 模型來說: 舊一代模型(例如 Sonnet 4、Sonnet 4.5):上限 200K tokens 新一代模型(Opus 4.6 / 4.7、Sonnet 4.6):上限提升到 1M tokens,且自 2026 年 3 月起已 GA 無溢價 聽起來 1M 似乎什麼煩惱都沒了?實際沒這麼簡單 —— 稍後會有一節專門談「1M 不是萬靈丹」。這裡先建立一個共識:不論你用哪一代模型,壓縮管線的設計原理都一樣,只是觸發閾值不同。 一個五小時的維運任務,搭配幾份被讀進 context 的大型設定檔,即使在 200K 窗口也會消耗得比你想像快。 如果 Claude Code 對這件事不做任何處理,用戶體驗會是這樣: ...