openai/codex 倉庫裡三個已經合併進主線的提取請求，把 Codex 上下文視窗管理的改造方向攤了出來：對話超出視窗範圍時，系統不再產生摘要來壓縮歷史，改為直接啟用一個全新視窗繼續工作。相關功能統一掛在 Feature::TokenBudget 這個功能旗標後面，尚未正式上線。
現在的做法是摘要式壓縮。視窗快滿時，系統會請後端把先前的對話濃縮成一段摘要，用它取代原始歷史。這套做法有兩筆固定成本：產生摘要本身要燒 token，而且壓縮是有損的，API 約定、路徑名稱、幾輪前敲定的取捨，都可能在濃縮過程中被抹平。用 Codex 跑過長任務的人對後一種失敗模式並不陌生——模型忘了兩小時前定下的規則，回答時卻還是一副信心滿滿的樣子。
模型可以自己申請換一張新紙
第一步是 6 月 11 日合併的 #27488，標題就叫「Add new context window tool」。它給模型加了一個 new_context 工具，僅開放給模型自己使用，作者在說明裡把它稱作目前視窗變得不好用時的「escape hatch（逃生口）」。
請求被記在 AutoCompactWindow 上，取樣之後就會被消耗掉，同一輪裡緊接著的後續請求就會落在新視窗裡。新視窗的起點是一個不帶摘要的壓縮檢查點，只保留初始上下文，先前的對話歷史不會跟著帶過去。
手動清理也走同一條路
第二步是 6 月 23 日合併的 #29743。它把手動壓縮和自動壓縮統一進 compact_token_budget 這一條生命週期，token budget 開啟時，壓縮不再向後端要摘要，而是在本地直接載入一套全新的初始上下文。
這一步的工程細節裡藏著克制：對外可見的行為被保留下來，compact 掛鉤照常觸發，ContextCompaction 生命週期事件照常發出。也就是說，依賴這些事件的用戶端不用改，底層換掉的只是實作方式。
找回來的部分交給歷史與筆記處理
前兩步只解決了「丟掉」的問題，8 月 21 日合併的 #39827 才補上「找回來」。這個 PR 的說明寫得很直白：token budget 對話需要一條路徑，能還原先前的對話上下文，並在視窗切換之間保住工作狀態。
它加了兩組工具。歷史工具負責列出視窗與條目、讀取特定條目、在對話內容裡搜尋；筆記工具負責列出、讀取、搜尋、附加與寫入永久筆記。呼叫要經過 Codex 後端，需要 OpenAI 供應方與後端驗證，同樣掛在功能旗標 features.token_budget.use_history_notes_history 之下。
工程上做了幾處限流：輸出會以感知截斷的方式處理，請求參數也有邊界。自動審查提出的意見集中在純文字結果的一萬 token 上限、筆記操作的參數綁定限制，以及建議分階段灰度釋出。
換掉的到底是什麼
摘要壓縮與換視窗加檢索，本質上是兩種記憶策略。前者是隱性的有損壓縮，模型不知道自己丟了什麼，也沒辦法找回來；後者是顯性的無狀態重啟，模型很清楚舊內容還在某個地方，需要時就去查。
代價也跟著換了個位置。有損壓縮的失敗是悄悄發生的，換視窗的失敗則會變成「該查的時候沒去查」，或是「查了但沒查準」。前者難以除錯，後者至少能在紀錄裡看見。對執行長任務的 Agent 來說，看得見的失敗比悄悄發生的失敗好處理得多。
省下來的錢是另一頭的收益。摘要要跑一次模型呼叫，長對話裡這筆開銷會反覆發生；換視窗不會產生這次呼叫，檢索也只在需要時按條目取用。對每天把額度用滿的重度使用者來說，這是實實在在的帳。
需要說清楚的是節奏：PR 合併不等於功能上線。這三項改動全都藏在功能旗標後面，自動審查也還在建議分階段放量。從 6 月的第一版工具，到 8 月的歷史與筆記補完，OpenAI 在這條路上磨了兩個多月，旗標什麼時候打開、開放給誰，倉庫紀錄裡沒有答案。
參考來源：openai/codex 倉庫三份已合併的提取請求、CocoLoop、GitHub 自動審查意見；工具名稱、功能旗標名稱與合併狀態均按倉庫紀錄逐條核對。