Codex 如何用不同方式解決 Compaction 問題

如果你曾認真用 Claude Code 寫過程式，一定看過這個畫面：終端機出現「Compacting conversation…」，從那一刻起，一切開始不對勁。模型開始忘記你十分鐘前討論過的內容，回應延遲攀升，你問起剛才一起重構的函式，它卻像第一次聽到一樣。

這是因為 Claude Code 的 200K token context window 填滿的速度比多數人預期的快。一次大型重構、幾次檔案讀取、幾個輸出冗長的 tool call，容量就滿了。當使用量超過門檻（大約是 75-92%，但我曾看過早在 65% 就觸發），Claude Code 會把對話摘要起來，丟棄原始訊息，只保留摘要繼續執行。沒有被摘要捕捉到的資訊，就此消失。

我持續聽說 OpenAI 的 Codex 用不同方式處理這個問題，所以我花時間閱讀了所有能找到的公開分析。最有趣的研究來自 Krafton 的 CAIO Kangwook Lee，他利用 prompt injection 逆向工程了實際的處理流程。

Compaction 損失了什麼，以及為何重要

核心問題很直接。摘要是有損壓縮。當 Claude Code 執行 compaction 時，它會在背景對完整對話做摘要，建立一個 compaction block，然後丟棄這個 block 之前的所有內容。CLAUDE.md 檔案能存活，因為它們是從磁碟重新讀取的，但你在對話中說過的任何內容，除非被摘要器捕捉到，否則全部消失。

Tool call 的結果是最受傷的地方。當你請 Claude Code 讀取一個檔案，完整的檔案內容會進入 context。當你執行指令，完整的輸出也會進入 context。這些 tool 結果往往是對話中資訊密度最高的部分，而它們恰好是摘要時最容易被壓扁的。一個讀取了 500 行的檔案，可能變成一句「讀取了設定檔並記錄了資料庫設定」。你討論過的具體數值、邊緣案例、引用的行號，全部消失。

我親眼目睹這件事發生了幾十次。Compaction 之後，我問「我們剛才看的那個 helper function 回傳型別是什麼？」，得到的是充滿自信但錯誤的答案。模型並不是在一般意義上幻覺，而是從一份根本不包含我所詢問內容的摘要中運作。

在一次長時間的 session 中經歷 9 次以上的 compaction 之後，問題會累積。每次摘要都會進一步壓縮前一次的摘要。session 早期的決策理由會完全流失。到了第 10 個小時，模型完全不記得你為什麼選擇方案 A 而非方案 B，即使你花了二十分鐘討論取捨。

Codex 加密 compaction 流程的內部機制

Kangwook Lee 的分析相當聰明。他使用兩個連鎖的 prompt injection 來提取 Codex compaction 系統的內部行為。

第一個 injection 針對 compactor LLM 本身。當 Codex 觸發 compaction 時，它不是在本地做摘要，而是把對話送到 OpenAI 伺服器上一個獨立的 LLM，由它產生摘要。Lee 的 injection 騙這個 compactor 把自己的 system prompt 包含在摘要輸出中。伺服器接著用 AES 加密這份摘要（此時已包含洩漏的 prompt），並以不透明的 blob 形式回傳。

第二個 injection 利用了解密步驟。把加密的 blob 加上一段精心設計的使用者訊息傳回 Responses API，伺服器便會解密這個 blob 並組裝模型的 context。由於第一個 injection 已將 compactor 的 system prompt 嵌入摘要中，解密後的 context 揭示了整個流程的運作方式。

他的發現如下：當你呼叫 Codex 的 compact() API 時，一個獨立的 LLM 會摘要對話，結果以 AES 加密回傳。在下一個 turn，伺服器解密這個 blob，在前面加上一段交接提示（「這是上一段對話的摘要」），然後把整個內容送給模型。加密金鑰存放在 OpenAI 的伺服器上，客戶端永遠看不到明文摘要。

Compaction 的提示本身，事實上與開源 Codex CLI 針對非 Codex 模型所使用的 compaction 範本幾乎相同。Prompt engineering 沒有什麼秘密配方。有趣的部分在於架構：摘要的伺服器端加密、伺服器端解密與注入，以及客戶端只能傳遞卻無法檢視或修改的不透明 blob。

為何要加密？Lee 的分析並未給出明確答案。一種理論是加密的 blob 不只包含文字摘要，還有 tool call 還原資料、內部狀態標記，或 OpenAI 不想公開的結構化 metadata。另一種可能性更簡單：加密的 blob 可以防止使用者篡改摘要來操控模型行為。我認為第二種解釋更有可能，但兩者都尚未得到確認。

OpenAI 也透過 Responses API 在伺服器端支援這個功能。設定 compact_threshold 值，當 token 數量超過門檻，伺服器就會在回應過程中內嵌執行 compaction。Compaction item 會在回應中串流回來，你把它附加到後續請求中，最近一次 compaction item 之前的項目都可以安全丟棄。

對比 Claude Code 的做法：compaction block 是人類可讀的。你可以直接檢視，也可以透過 instructions 參數或在 CLAUDE.md 中加入自訂 compaction 指令來調整行為。更透明，但資訊損失的本質問題一樣存在。

Session 交接模式

拋開 compaction 機制不談，更有趣的問題是：當你需要開啟新 session 卻不想丟失 context 時該怎麼辦。這讓我看到了一位開發者的自動化方案，徹底改變了我對這個問題的思考方式。

這個模式的運作方式如下。在 compaction 觸發之前，一個 pre-compact hook 會封鎖所有寫入工具。這可以防止模型在半清醒狀態下修改程式碼，這是我踩過多次的地雷：compaction 在重構進行到一半時觸發，模型忘記了哪些檔案已經修改，最後寫出互相衝突的變更。

封鎖寫入之後，系統從 JSONL session 日誌中只提取使用者訊息和 thinking blocks，其餘所有內容（tool call、檔案內容、模型回應）都被丟棄。這樣可以把日誌縮減到原始大小的約 2%。

接著三個子代理平行執行，各自在原始未壓縮的 JSONL 日誌中搜尋提取過程遺漏的資訊。它們尋找的是落差：在對話中討論過但未被使用者訊息捕捉的架構決策、只出現在 tool 輸出中的錯誤模式、被拒絕方案的決策理由。這些代理將發現彙整成一份 resume-prompt.md 檔案，包含 session 摘要、落差分析結果，以及修改過的檔案清單。

一個 VS Code 檔案監聽器偵測到新的 resume-prompt.md，自動開啟新 session 並載入它作為初始 context。新 session 從清晰、完整的上一個 session 交接點開始。

據報告，這讓開發效率提升了 10 倍。這個數字難以獨立驗證，但架構本身說得通。不再是一份越來越退化的摘要，而是一個擁有完整 context window、且經過精心整理與落差補充的交接文件。

我自己也嘗試實作了一個簡化版本。落差分析步驟是價值集中的地方。沒有它，你只是用不同格式做了 compaction 本來就會做的事；有了它，你才是在積極補回摘要丟失的資訊。我的版本使用單一子代理而非三個，結果明顯比直接 compaction 好，但可能不如完整三代理方案那麼徹底。

KV cache 這個隱藏的成本槓桿

這個問題有個大多數討論完全忽略的效能面向。KV cache（attention 過程中計算的 key-value pair）可以在 prompt prefix 相同時跨請求重複使用。兩個請求共享相同的開頭 token，就能跳過那些 token 的重新計算。

數字相當可觀。在一個比較穩定與擾動過的 system prompt 的對照測試中，穩定的 prefix 達到 85% 的快取命中率，首次 token 時間（TTFT）中位數為 953ms；擾動過的 prefix：0% 快取命中，TTFT 為 2,727ms。每次請求的成本從 $0.033 降到 $0.009。僅憑保持 prompt prefix 一致，就帶來了 65% 的延遲降低和 71% 的成本降低。

這對 session 交接模式有直接影響。如果你的 resume-prompt.md 總是以相同的結構 prefix 開頭（system prompt、交接指令，然後才是變動內容），固定的部分就會被快取。新 session 中的每個後續請求都能受益於這個快取。如果你讓 prefix 結構不固定，或在早期注入變動內容，每次請求都要從頭重新計算。

我就是根據這個洞察設計了我的 session 資料夾結構。以 session ID 為基礎的歸檔讓交接文件保持有序，而 resume prompt 的固定 prefix 慣例意味著每個新 session 的前 40-50K token 都能命中 KV cache。使用 QMD（我在另一篇文章介紹過的工具）預先索引 session 歸檔，可以讓子代理需要搜尋歷史 session 時的檢索步驟更快。

真正重要的是什麼

真正的結論不是 Codex 的做法比 Claude Code 好或差。兩者在 compaction 時都會損失資訊，都在長 session 上掙扎。架構差異（加密不透明 blob vs. 人類可讀的 compaction block）反映了不同的設計哲學，但根本限制是一樣的：context window 是有限的，而摘要是有損的。

重要的是你在這個限制之上建立了什麼。Session 交接模式、落差分析、基於 JSONL 的檢索、KV cache 優化，這些都是工程解法，針對的是無論模型再怎麼進步都無法完全解決的問題。500K 或 1M token 的 context window 只是延後問題，並不能消除它。

AI 程式開發工具的瓶頸不在模型智能，而在 context 管理。打造能可靠地找回遺忘資訊的系統，比打造能更準確摘要的系統更有價值。我親身體驗過：一個平庸的摘要加上良好的檢索，每次都勝過一個出色的摘要加上沒有檢索。

技術細節來源：Kangwook Lee 的分析，以及 OpenAI 和 Anthropic 的公開 API 文件。