記憶三部曲處理的是萃取後的知識，今天回頭處理原料本身：窗口裡那一大坨對話歷史和工具輸出。Compaction（壓縮）指的就是把這些累積的歷史變小的工程。先把問題的規模算給你看。

第 15 輪的帳單

拿一個典型配置算一次：一個分析 agent，每輪呼叫三個工具（搜財報、抓歷史數據、查評分），每份輸出平均 2000 token。跑到第 15 輪，messages 陣列裡躺著前 14 輪的所有工具輸出：14 輪 × 3 個工具 × 2000 token，將近 85,000 token 的歷史記錄留在 context 裡，而當前的問題多半只需要最近兩輪的資訊。第 15 輪的單輪費用輕鬆變成第 5 輪的三倍，agent 每輪做的事卻沒有變多。

這暴露了 context 膨脹的結構性來源：工具輸出預設永久留存。system prompt 是固定的，對話輪次有自然的節奏，但工具輸出每呼叫一次就進 messages 陣列，沒有任何機制主動清它。而且這類內容多半是 JSON 陣列（搜尋結果、查詢回傳），一百筆記錄裡欄位結構大量重複，真正有資訊量的只有幾筆。模型每輪推理都在重讀一遍它不再需要的東西，你每輪都在為此付費。

通用解法：分層，最貴的手段最後用

Day 8 提過 Claude Code 的七層防禦，原則是能用規則解決就不呼叫 LLM。現在可以講得更細一點：前面幾層做的是限制單輪工具輸出上限、刪最舊訊息、清舊的工具結果，全是便宜操作；真正的大招在後面 — 用 LLM 把整段歷史摘要成一份總結，也就是你在 Claude Code 裡看到的 auto-compact。

這層摘要有一個值得記住的設計細節：摘要什麼都能壓，唯獨使用者說過的話要求完整保留。工具輸出可以壓、中間推理可以壓，使用者的原話是整個 session 裡最不允許失真的資訊，因為所有後續動作的「為什麼」都錨在那裡。做自己的壓縮策略時，這條優先序值得直接抄。

更細的刀：Headroom 的三個設計原則

摘要是全量手段，還有一種更外科手術式的做法。Headroom 是一個開源的壓縮層，插在 agent 和 LLM provider 之間，專門對付工具輸出。它的三個設計原則，每個都對應一個真實的坑：

只壓最新一輪，舊的一個字節都不動。 原因你已經很熟了：provider 的 prompt cache 按前綴匹配（Day 4），改了第 3 輪的內容，第 4 輪之後全部 cache miss，省下的壓縮費瞬間被重算的帳單吃掉。已送出的 bytes 一律凍結，壓縮只作用在新進來的內容。這個原則的另一面要誠實講：它讓 context 長胖的速度變慢，但不會幫你清掉已經累積的存量，存量還是要靠上面那種全量摘要。

壓縮必須可逆。 壓縮的根本張力是壓越多省越多、但模型遺失資訊的風險越高。Headroom 的解法叫 CCR（Compress-Cache-Retrieve，壓縮、快取、取回）：壓縮時把原文存進本地快取，並給模型一個取回工具，模型推理到一半發現摘要不夠用，可以自己把原文撈回來。有了保底，壓縮就敢下重手。

失敗就放行。 壓縮可能出錯（解析失敗、壓完反而更大），出錯時直接回傳原始內容、記個 log，絕不把例外丟給 agent。最壞的結果是沒省到錢，而非 agent 掛掉。

實際壓的時候用統計取樣：一份大 JSON 陣列保留時序開頭、最新狀態、加上重要性評分高的項目；含 error、數值異常、突然轉折的紀錄直接豁免，永遠保留。

誠實版適用範圍

壓縮的效果由內容的冗餘度決定，這張表值得先看再上：

最大的風險叫 context dilution：取樣保留的是「代表性樣本」，如果你的業務有罕見但關鍵的 edge case，數值又剛好落在正常範圍（不觸發異常豁免），它可能被靜默丟掉。防法很直接：業務關鍵的工具（資料庫查詢、金融數據）直接設成不壓縮。壓縮該用在「量大但單筆不重要」的輸出上，量小但每筆都要看的資料，別讓它進取樣。

L2 的工具箱到此集齊

檢索把外部知識找進來、記憶讓資訊跨呼叫存活、壓縮讓歷史不吃垮預算。窗口內容的管理，也就是 Context Engineering（這系列的 L2），策略層面該講的都講了。但你可能已經隱約感覺到一件事：這幾天講的每一個機制，都預設了有「某個東西」在窗口外面執行它 — 誰觸發記憶寫入？誰決定壓縮的時機？檢索工具是誰給的？明天面對這件事：Context 的極限，以及為什麼策略再好，沒有執行系統就只是願望。