重點
- 華盛頓大學、Meta Superintelligence Labs、MIT 與 Trillium Labs 的研究者提出 Context Language Models（CLM）：把模型的即時 context 鏡像成一個檔案，讓模型用 Bash 自由改寫。
- 不經訓練、直接套在 Qwen3.6-27B 上，CLM 在 BrowseComp-Plus 達 59.4%，比最強基線（Codex 式摘要壓縮）相對高 11.4%，計算量少 21.5%。
- 在 12 小時的 repo 優化任務與 24 小時的多 repo agent 群任務上，CLM 也勝過摘要壓縮。
- 用強化學習訓練 Qwen3.5-9B 後，BrowseComp-Plus 從 28.8% 升到 42.5%，與同樣訓練的摘要 harness 相當，計算量少 38.8%。
- 主要風險是模型可能刪掉之後需要的資訊，可編輯的 context 也可能讓 prompt injection 跨輪留存。
要解決的問題
Agent 長時間工作時，context 會一直變長。常見做法是交給 harness 管：Cursor、Codex、Terminus2 在達到長度門檻時摘要壓縮，MEM1 則每輪更新一次。近期的研究讓模型自己決定何時壓縮或卸載（AutoCompact、Self-Compact、Context-as-a-Tool、ACM、Sculptor），但能用的動作仍是人預先設計好的幾種。
作者先做了診斷基準 ContextBench，把 context 管理從推理與知識能力中分離出來。這些任務不需要推理，只要把該留的都留住就能全對：
| 任務 | 測什麼 |
|---|---|
| Needle Retention | 從大量填充文字中逐字保留關鍵句子 |
| Sudoku Sketchpad | 隨使用者逐步落子，原地更新 16×16 盤面 |
| KV Store | 把大量鍵值卸載出去，查詢時精確取回 |
| Log Triage | 卸載工作紀錄，回答查詢與計數問題 |
用 GPT-5.4、context 上限 32K、輸入總量最高達上限 24 倍來測，沒有一種既有方法全部做對：
- 摘要壓縮會遺失或捏造內容
- 沒有原地編輯能力的方法，每次落子都要重寫整個數獨盤面
- 一般的程式工具能把資料存到檔案，從即時 context 中移除卻做不到
方法：context 當成檔案
標準語言模型的 context 只會往後接：( c_{t+1} = c_t \oplus f_\theta(c_t) )。CLM 改由模型產生下一輪的整個 context：( c_{t+1} = f^{\mathrm{CLM}}_\theta(c_t) )。既有的壓縮、卸載工具都是這個形式的特例，差別在於 CLM 要模型自己定義這些操作。
實作很直接：
- 把模型的即時 context 鏡像成一個檔案，路徑寫在 system prompt 裡
- 模型用一般的 Bash 指令編輯它，跟編輯其他檔案一樣
- 編輯後自動同步回模型的 context，送到推論伺服器繼續生成
- 沒有編輯時，新產生的 token 照常接在後面
多個 context 檔案可以並存，所以 agent 群與子 agent 也用同一機制：建立檔案就是開一個子 agent，刪掉就是結束它。
論文從零樣本實驗中整理出模型自己發展的做法：
- 管理多個子 agent 時，在 context 裡維護計分板，原地編輯 163 次，context 始終維持在 6–8K token
- 改寫 context 時新增一個「notes」角色，放自己的內部筆記
- 寫迴圈刪掉過去沒用的搜尋結果，或壓縮過長的輸出
- 定義
compact_turns函式並重複呼叫 37 次，壓縮細節觀察的同時維護進度筆記
計算成本怎麼算
編輯 context 中段會讓推論伺服器的 prefix cache 失效，編輯點之後的 token 都要重新 prefill，包括沒有改動的文字。為了把這筆代價算進去，作者定義 prefix-reuse FLOPs：重新 prefill 不匹配後綴的計算量，加上解碼新 token 的計算量。後文的 FLOPs 都是這個口徑。
論文以 Qwen3.6-27B、20,000 token 的提示和 500 token 的回應示範（示意數字，非實際執行）：
| 情況 | 可重用的前綴 | 單輪 FLOPs |
|---|---|---|
| 只往後接 | 18,000 token | 1.41 × 10¹⁴ |
| 中段編輯 | 10,000 token | 5.74 × 10¹⁴ |
| 開頭編輯 | 0 | 10.81 × 10¹⁴ |
開頭編輯的成本是只往後接的 7.7 倍。CLM 要省計算，得靠 context 整體變短來抵掉重新 prefill 的代價。
Suffix Cache Reuse
作者另外為 SGLang 寫了 Suffix Cache Reuse（SCR）。標準做法在第一個不匹配的 token 之後全部重算；SCR 會比對新舊提示，找出編輯後仍存在的片段，重用它們的 KV cache，把 key 的 RoPE 位置編碼旋轉到新位置後接回去，只 prefill 新插入的內容。
- 每次編輯最多搬移 K 個最長的片段，論文用 K=6；在 64 題的敏感度分析中，不同 K 值都沒有造成準確率下降
- 重用的狀態是在編輯前的 context 下算出來的，所以是近似值
- Qwen3.6-27B 是混合架構，64 層裡有 48 層是線性注意力，這些層沒有逐 token 的 cache，SCR 改用編輯前的遞迴狀態快照
- 在 BrowseComp-Plus 上，SCR 以標準 SGLang 65% 的計算量達到相同表現
SCR 在完整的 830 題上額外重用了 7.8% 的提示 token。其中 5.3 個百分點來自推理 token 被剝除（推理模型的 chat template 會刪掉前幾輪的推理內容），只有 2.5 個百分點來自模型自己的編輯。也就是說，一般推理模型的服務也能受惠。
結果
不經訓練直接套用
| 基準 | 模型與設定 | CLM 的結果 |
|---|---|---|
| BrowseComp-Plus（830 題） | Qwen3.6-27B，32K 上限 | 59.4%，比 Codex 式摘要相對高 11.4%，FLOPs 少 21.5% |
| TerminalBench 2.1 | Qwen3.6-27B | 與 Codex 式摘要持平，FLOPs 為其 70% |
| TBLite | Qwen3.6-27B | 73.7% 對 67.0%，FLOPs 為其 91% |
| 數學最佳化四題 | Claude 4.6 Sonnet | 四題都勝過 OpenEvolve，Heilbronn 三角形問題高出 16.8% |
| EdgeBench-10（12 小時） | Qwen3.6-27B，32K | 44.6 對 42.3，179 對 437 PFLOPs |
| EdgeBench-10（12 小時） | Claude 4.6 Sonnet，32K | 51.0 對 42.3 |
| Software World（24 小時以上） | GPT-5.6-Sol，272K | 同樣花費下，下游加速幅度多 65% |
表中的「對」是跟 Codex 式摘要相比。摘要基線在 75% 上限時壓縮，其他基線包括 MEM1、Self-Compact、ACM 與遞迴語言模型（RLM），全部用同一個 Mini-SWE-Agent 骨架。
Software World 是六個 agent 同時優化 requests、urllib3 等六個互相依賴的 Python repo，再用 agent 沒看過的四個下游套件、17 個 CPU 基準評分，檢驗改進能不能傳到下游。
用提示引導與演化
在任務提示後加一句話，就能改變模型管理 context 的方式，例如指定在多長時壓縮、在子問題的邊界壓縮，或壓縮前先備份。harness 與模型參數都不用動。
作者也用提示演化迴圈改進 context 管理的 skill 文件：由 Claude Fable 5.1 根據 rollout 提出新 skill，Qwen3.6-27B 執行，從沒有任何 context 管理指示開始。開發集準確率的變化：
| 任務 | 演化前 | 演化後 |
|---|---|---|
| Needle Retention | 97.6% | 100.0% |
| Sudoku Sketchpad | 45.3% | 65.8% |
| KV Store | 22.3% | 83.8% |
| Log Triage | 0.0% | 100.0% |
KV Store 在保留測試集上從 38.3% 升到 74.2%，就是摘要裡「最多提高 35.9 個百分點」的來源。
強化學習
作者用 stepwise GRPO 訓練 Qwen3.5-9B，資料是 3,040 個 OpenResearcher 深度研究題目，訓練 70 步。
只用最終成敗當獎勵，對 context 編輯的監督太弱：成功的軌跡可能含有沒效率的編輯，失敗的也可能有好的編輯。直接獎勵編輯次數或刪掉的量，又會讓模型亂刪重要資訊。作者的做法是「以成功為前提的效率優勢」：只在同組的成功軌跡之間比較，計算量低於平均的得到正的額外優勢；成功軌跡少於兩條時不給。
| 方法 | 準確率（訓練前 → 後） | PFLOPs／題（訓練前 → 後） |
|---|---|---|
| 摘要 harness | 34.7% → 42.1% | 4.01 → 2.19 |
| CLM | 28.8% → 42.5% | 1.52 → 1.34 |
訓練前 CLM 比摘要 harness 低約六個百分點，作者認為原因是小模型管理 context 的能力不足；訓練後兩者準確率相當，CLM 的計算量少 38.8%。
跟既有做法的差別
- AutoCompact、ACM 等讓模型決定何時使用預設的動作；CLM 讓模型自己定義動作，甚至寫成可重用的函式。
- RLM 把長輸入放在 REPL 變數裡按需讀取，處理的是要讀什麼進來，讀進來的內容仍接在即時 context 後面。CLM 管的是即時 context 本身。
- 摘要壓縮把整段歷史換成一段摘要；CLM 可以只改其中一部分，其餘保留原文。
作者把這個方向比作 Sutton 的 The Bitter Lesson：與其由人設計 context 管理策略，不如讓模型自己搜尋與學習。他們也提出未來可以把現有 harness 的策略蒸餾進 CLM 的權重裡。
限制與爭議
- 模型可能刪掉之後才發現需要的資訊，而且找不回來。
- 效果取決於模型本身的判斷力。在 TerminalBench 2.1 上，Qwen3.5-9B 平均每題只編輯 1.4 次、一半任務完全沒編輯，峰值 context 中位數 30.2K（上限 32K）；Qwen3.6-27B 則是 2.6 次、17.6K。
- 現有模型對自己用了多少 context 估得不準，實驗中要在接近上限前 2,048 token 提醒模型，作者視為暫時措施。
- 可編輯的 context 是新的攻擊面：prompt injection 或模型自己寫進去的指令可能跨輪留存。論文引用 OpenAI 9 月的報告，曾有模型把未授權的指令寫進自己的壓縮摘要，影響後續行為。
- SCR 是近似做法；混合架構在 SGLang 的前綴快取只在請求邊界存遞迴狀態，這個瓶頸還沒解決。
- InfoQ 整理的社群評論指出，數據來自特定任務；改寫 context 會讓模型快取失效，論文的快取解法也有取捨，離正式部署還有距離。