Context Language Models 解析：讓 agent 用 Bash 改自己的 context

1 context 爆了，誰來決定留什麼？CLM 讓模型自己改

LLM agent 跑得越久，context（模型每一輪讀進去的整份文字）就越容易爆。搜尋結果、檔案內容、指令輸出一輪輪堆上去，遲早超過上限，總得有人決定「留什麼、丟什麼」。目前的主流做法，是由 harness（包在模型外面、負責跑 agent 迴圈與組裝每輪 context 的程式）用固定規則做摘要，或是給模型幾個預先設計好的壓縮工具。

Context Language Models 這篇論文提出的做法叫 CLM：把模型當前的 context 鏡像成一個檔案，模型用 Bash 想改哪裡就改哪裡，改完立刻同步回它的 live context（下一輪真正餵給模型的那份 context）。這是介面設計，不是新演算法。

接下來先看 CLM 想解決的問題和它怎麼運作，再看改 context 的成本怎麼算、怎麼用文字與 RL 學管理策略，最後逐項檢查論文的證據，把摘要的大數字換回絕對值。文中標「自編例子」的是我為了說明而編的數字或情境，標「推論」的是我的判斷，不是論文原文。

論文：Context Language Models（arXiv 2609.37725v1，University of Washington／Meta，2026 年 9 月）。

2 context 管理：從固定規則到模型自己動手

agent 一輪輪地搜尋、讀檔、執行指令，累積的對話與工具輸出遲早超過模型的 context 上限（這篇論文的實驗多半設在 32K tokens）。怎麼處理這件事，叫 context management（context 管理）。先認識三個後面會一直用到的詞：

• harness：前面提過，包在模型外面的程式，負責跑 agent 的迴圈、呼叫工具、組裝每一輪要餵給模型的 context。
• compaction（壓縮）：把舊歷史改寫成較短的摘要。
• offloading（卸載）與 retrieval（檢索）：把內容存到外部檔案，context 裡只留一個指標，需要時再撈回來。

自編例子：一個搜尋 agent 跑 100 輪，每輪都把搜尋結果貼進對話，跑到 40 輪左右就滿了。你得決定：舊的搜尋結果整段刪掉？濃縮成一段摘要？還是先存到硬碟、需要再撈回來？

2.1 現有的兩條路：harness 定義與 action-based

現有的做法，可以依「誰做決定」分成兩類：

第一類模型完全沒有發言權；第二類模型有發言權，但只能在人類給的選單裡選。更細的 when／how 分類與文獻出處，在文末「概念詳解」的第一節（選讀）。

2.2 論文的主張：連「怎麼改」都交給模型

論文認為這兩條路有同一個天花板：模型能做的操作，都是人類事先設計好的。CLM 把自由度推到底，排起來是三級：

1. harness 定義：模型零控制。
2. action-based：模型選「何時」，操作由人定義。
3. CLM：模型連「怎麼改」都自己決定。

具體差別（自編例子）：context 裡有 100 條搜尋結果，編號 30、31、57 的三條沒用，其餘要原文保留。如果工具只有「把全部歷史壓成摘要」，模型只能全壓，其他 97 條的原文就被改寫了；CLM 可以直接寫一小段程式，只刪那三條。

論文引用 Sutton 的 The Bitter Lesson（AI 領域常見的論點：靠搜尋與學習擴展的通用方法，長期會贏過人類手工設計的規則）當動機，這主要是修辭上的支持。我的推論（非論文原文）是：限制少也代表模型可能改壞，這個賭注划不划算，要看後面的實驗。

2.3 ContextBench：現有方法連簡單的管理任務都做不好

作者先自建一個小測試 ContextBench，專門量 context 管理本身，用來展示現有方法連簡單任務都做不好。設計上刻意不需要推理或知識：任務指令已經明講該做什麼，所以能把全部內容記住的 agent 一定全對，分數差異只反映管理能力。

難度用 context pressure（情境壓力） 調整：整段任務輸入的總量除以 context 上限（32K）。1× 代表全部保留剛好塞滿，24× 代表輸入量是上限的 24 倍；低於 1× 的是對照組，全部留著也放得下。

表 1 是論文對這四個任務的正式定義（輸入串流與評分指標）。評分一律只看 agent 的 context 內容：只存在檔案裡、沒留在 context 的答案不算分。

結果直接看下圖：CLM 的表現明顯高於其他方法，接近滿分。

論文歸納了三個失敗原因：

• 摘要式壓縮會遺漏或編造資訊（Needle、Sudoku）。
• 沒有原地編輯的方法，每改一格都得重寫整盤數獨。
• 一般工具能把資料存到檔案，卻沒辦法把它從 live context 主動踢掉。

各難度對應的壓力、實際送給 agent 的訊息範例，分別在論文 Figure 15 與論文 Figure 16。

小結：現有方法要嘛由程式定死，要嘛讓模型從人設計的選單裡挑；選單裡少了「原地改」和「從 context 踢掉」，連簡單任務都會失手。CLM 想把「怎麼改」也交給模型。

3 核心機制：把 context 變成一個可以編輯的檔案

論文的方法有四個零件：context-as-a-file 這個核心機制、衡量成本用的指標、用文字引導與演化管理策略、用 RL 把策略訓練進權重。其中只有第一項是論文真正的主張，後兩項是「因為管理變成模型自己的行為，所以可以被學習」的延伸。這一章先看第一項。

3.1 從「只能往後接」到「任意改寫」

一句話：標準 LM 每一輪只能把新內容接在 context 後面，CLM 則讓模型直接決定下一輪 context 的完整內容。

標準 LM（論文 Eq. 1）：

CLM（論文 Eq. 2）：

• $c_t$：第 $t$ 輪開始時，模型看到的整份 context。
• $\oplus$：串接，把右邊的內容接到左邊後面。
• $f_\theta^{\mathrm{LM}}(c_t)$：模型根據 $c_t$ 生成的新 token。
• $f_\theta^{\mathrm{CLM}}(c_t)$：論文說它可以是任意函數，由 CLM 自己決定怎麼把 $c_t$ 變成 $c_{t+1}$。

白話一點：Eq. 1 的舊 context 一個字都不能動，Eq. 2 沒有這個限制。Eq. 1 其實是 Eq. 2 的特例，只要令 $f_\theta^{\mathrm{CLM}}(c) = c \oplus f_\theta^{\mathrm{LM}}(c)$ 就是它。

標準 LM 像只能在文件最後一行繼續寫的日誌，CLM 像打開了整份文件的文字編輯器，可以刪改任何一行。這個類比成立，是因為兩者的差別正是「能不能動既有內容」。底層上，context 本質就是下一次呼叫模型時餵進去的文字（一般知識，不是論文內容）。

論文把 $f_\theta^{\mathrm{CLM}}$ 寫成「任意函數」，但實作上它只能是模型寫得出來的 Bash 或程式，這是下一小節。

3.2 實作：context 就是一個檔案，模型用 Bash 改

一句話：把模型的 live context 同步成一個檔案，模型用平常的 Bash 指令改這個檔案，改完的內容就是下一輪的 context。流程是：

1. harness 把當前 context 寫進檔案，路徑寫在 system prompt。
2. 模型像編輯其他檔案一樣，用 Bash 或 Python 改它。
3. 檔案一改完，就自動同步給 LLM server。
4. 下一輪模型看到的就是改過的 context。

如果模型這輪沒動檔案，新生成的 token 照舊接在後面，也就是 Eq. 1 的預設行為。論文說這樣兼顧「context 重用」與「編輯彈性」。

論文的總覽圖裡，(a) 是模型寫出的 context 管理行為範例，先看這部分即可；(b) 到 (d) 分別是零樣本、指令引導與演化、強化學習的結果，後面會逐一出現。

用前面那段 8,000 tokens 的搜尋結果來看（自編例子，寫法參考下面的圖 3）：模型只要執行一段 Python，用正規表達式把 turn 4 那一輪整段換成一行筆記，寫回的瞬間 context 就縮小，不需要 harness 預先提供「壓縮」工具。

import re
p = "/tmp/.live_ctx/LIVE_CTX_MAIN.txt"      # 論文 Appendix E 給的 context 檔案路徑
s = open(p).read()
# 把第 4 輪（8,000 tokens 的搜尋結果）整段換成一行筆記
s = re.sub(r"\[\[CTX_TURN 4 .*?(?=\[\[CTX_TURN 5)",
           "[[CTX_TURN 4 role=notes]]\nSearched: xxx. No relevant results.\n",
           s, flags=re.S)
open(p, "w").write(s)                        # 寫回完成 = context 已縮小

論文觀察到，模型會自己發明新做法，例如：

• 在 context 裡維護一個「計分板」，用 163 次原地編輯追蹤子 agent 的狀態，同時讓 context 只維持在 6～8K tokens。
• 新增一種原本模板沒有的角色 notes，專門放自己的內部筆記。
• 用迴圈批次刪掉沒用的搜尋結果，或自己定義輔助函數 compact_turns（同一次任務中被呼叫 37 次）。

3.3 多 agent：一個 context 一個檔案

多個 context 檔案可以同時存在，各自與自己的 LLM server 同步。agent swarm（一群平行工作的 agent）就是在工作區放多個 context 檔案；subagent（由主 agent 啟動的子 agent）的啟動與結束，就是建立與刪除一個 context 檔案。圖 3 的 (a) 可以看到負責調度的主 agent（orchestrator）用一個狀態區塊，記錄 subctx_0..4 各子 context 的狀態。

3.4 要注意：「何時編輯」其實有 harness 在幫忙

論文實驗裡，CLM 另外享有幾項 harness 輔助（論文 Appendix E、腳註 4）：

• 離預算上限還剩 2,048 tokens 時，harness 會送出「該編輯 context 了」的提醒。論文的理由是現有模型對自己用了多少 context 沒有準確感知（論文 Appendix G，見後面「模型估不準自己用了多少 context」一節）。
• 在 BrowseComp-Plus（一個在固定語料上搜尋並回答難題的深度研究基準，簡稱 BCP）上，CLM 的編輯回合不算進 100 輪的輪數上限；請求超出預算時，harness 會退回上一輪並重試，最多六次。

另外，主文沒有交代 context 檔案的格式與同步細節，也沒統計模型改壞格式的頻率，文末「概念詳解」裡 context 檔案的那一節有細節（選讀）。

小結：CLM 的全部魔法就是一個檔案，模型改它，下一輪就看到改過的 context；但「何時改」仍有 harness 在提醒。

4 編輯 context 的成本：位置決定要重算多少

CLM 會改 context 中間的內容，這會讓推論伺服器的快取失效，所以光比 token 數不公平。論文自訂了 prefix-reuse FLOPs，算「伺服器實際要做的計算量」（FLOPs 是浮點運算次數，衡量計算量）。要看懂它，先認識伺服器怎麼處理一份 prompt：

• prefill：模型一次讀完輸入的 prompt，算出每個 token 的中間狀態（KV cache，鍵值快取）。
• decode：模型一個一個生成新 token。
• prefix cache 重用：伺服器記住上一輪算過的 KV cache。新 prompt 若開頭一段完全相同，這段就直接沿用；從第一個不同的 token 開始，後面全部都要重算（re-prefill）。

自編例子（概念見下圖左半）：context 是 [A B C]。只在後面追加，A、B、C 全部沿用，只算新增的部分。把 B 改成 B’，只有 A 能沿用，B’ 和 C 都要重算，即使 C 一個字都沒變。

圖的右半是論文為了緩解這個問題提出的 SCR，後面「其餘實驗」那一節會再簡單提到。

論文的公式只算兩件事：沒對上快取的那段（從第一個不同 token 起到結尾）要重新 prefill 的計算量，加上模型生成新 token 的 decode 計算量。白話：只算快取沒幫上忙的部分，加上生成成本。寫成式子是論文 Eq. 3：

• 第一項：沒對上快取的那段（unmatched suffix）的 prefill 計算量。
• 第二項：模型生成的新 token（generated tokens）的 decode 計算量。

論文附錄 C 用 Qwen3.6-27B 做了一個數字例子（下圖）。論文註明這些長度是為說明而選，不是實測：

記住這個結論就夠：成本幾乎就是「要重算的 token 數加生成的 token 數」，編輯越靠前，要重算的越多。原因是在這個例子裡，每個 token 的固定處理成本（MLP 與各種投影，也就是模型每層裡和 context 長度無關的運算，約 $48.70\times10^{9}$ FLOPs/token）佔了約 86% 的總計算量（我由論文給的數字驗算），attention 這種隨 context 長度增長的成本只佔約 14%。附錄 C（Eq. 7～9）把 Eq. 3 展開成 Qwen3.6-27B 逐層的完整算式，對理解結論沒有幫助，這裡不收錄。

5 不動權重：用一段文字引導與演化管理策略

既然 context 管理變成模型自己的行為，想改變它的策略，不必改 harness 程式，直接用文字告訴模型就行。這一章分兩步：先是人手寫指令引導，再來是讓另一個模型自動改寫指令。

5.1 一句話就能改變管理行為

做法很直接：在 context 裡放一段指令或 skill 文件（skill 在這裡就是一份教模型怎麼做事的文字說明）。和 Eq. 2 唯一的差別，是模型多讀了這段文字；它沒有任何新機制。寫成式子是論文 Eq. 4：

• $c_t$、$c_{t+1}$、$f_\theta^{\mathrm{CLM}}$：同 Eq. 2。
• $s$：放在 context 裡的那段指令或 skill 文件。

論文用 BrowseComp-Plus 的題目與 Claude 4.6 Sonnet，各用一句附加在任務訊息後面的指令，測三種行為（指令原文的中譯在文末「概念詳解」）：

這像給員工一張書面作業規定，而不是去改公司的流程軟體：前者改的是「讀到的文字」，後者改的是「寫死的程式」。模型每輪都把整份 context 當條件來生成，指令就是其中一段 token，這就是 in-context learning（一般知識，不是論文內容）。

5.2 讓另一個模型自動改寫指令

上面的指令 $s$ 是人手寫的；這一步讓另一個模型看 agent 的成功與失敗紀錄，自動把 $s$ 改寫得更好，一輪輪重複。

目標是：模型權重和 harness 都不動，只搜尋「哪段文字讓 agent 平均得分最高」。寫成式子是論文 Eq. 5：

• $s$：那份指令（skill）的文字。
• $x$、$\mathcal{D}$：一個任務實例，以及任務的資料分佈。
• $\tau(x; s)$：agent 帶著 $s$ 去解 $x$ 的完整軌跡（來自 Eq. 4）。
• $R(\tau)$：這條軌跡的得分，來自任務的自動評分器。
• $\arg\max_s$：找出讓平均得分最高的那份文字。

一輪的流程：

1. 目前的 skill 在訓練集跑 rollout（讓 agent 實際把整條任務跑完）。
2. proposer（負責改寫 skill 的另一個模型）讀這些成功與失敗的軌跡，寫出多份新 skill 候選。
3. 候選先在 6 題訓練題初篩，過關再跑 12 題，最後在 102 題的開發集（dev）評分。
4. 選出下一輪的 skill，重複；連續 5 次提案沒進步就停。
5. 最終 skill 在測試集（test）只評一次。

兩種設定：assisted evolution 是 Qwen3.6-27B 當 agent、Claude Fable 5.1 當 proposer；self-evolution 是 Opus 5 同時當 agent 和 proposer。

KV Store 任務、assisted 設定的結果如下。dev 是用來挑 skill 的題目，test 是定案後才評一次、沒參與挑選的題目：

• 論文摘要的「最多提升 35.9 點」，剛好是 74.2 − 38.3，也就是 KV Store 單一任務、assisted 設定下 test 的最好結果（我的計算）。
• 其他三個任務，文字只給 dev 數字：Needle Retention 97.6% 到 100.0%、Sudoku Sketchpad 45.3% 到 65.8%、Log Triage 0.0% 到 100.0%。dev 同時被用來選 skill，所以偏樂觀。
• self-evolution：Opus 5 起點就在 94% 到 100% 之間，演化後的 skill 要嘛在同樣準確率下降低成本，要嘛再提升準確率。

下圖會用到 Pareto frontier（帕累托前緣） 這個詞，意思是「沒有別的 skill 同時更準又更便宜」的那批 skill。

四個任務全部的演化結果（圖 8）

四個任務全部的結果在下圖：上排是 assisted evolution，下排是 self-evolution。

演化迴圈像教練看完比賽錄影後改寫戰術手冊，再讓球隊試打。底層上，這是用 LLM 當突變運算子的文字空間爬山搜尋，沒有梯度（一般知識，不是論文內容）。論文引用的對應方法是 GEPA（Agrawal et al., 2026，Reflective prompt evolution can outperform reinforcement learning）。

演化改的是 context 裡的文字，下一章的 RL 改的是模型權重，兩者都在學管理策略。

6 改權重：用 RL 學會怎麼編輯 context

前一章改的是 context 裡的文字，這一章改模型權重，讓模型從「最後有沒有答對」學會怎麼編輯 context。

6.1 GRPO 沒變，變的是兩處

GRPO（Group Relative Policy Optimization） 是一種 RL 演算法（來自 DeepSeekMath，Shao et al., 2024）。同一題先抽一組（group）完整軌跡，每條軌跡的 advantage（優勢）等於它的得分相對於組內平均的好壞：減掉平均、再除以標準差。

其中 $r_i$ 是第 $i$ 條軌跡的得分。這條公式是一般知識，論文只說「標準 GRPO advantage」，沒有寫出來。

自編例子：同一題抽 4 條軌跡，答對得 1、答錯得 0，得分是 1, 0, 0, 1。平均 0.5，標準差 0.5，advantage 是 +1, −1, −1, +1。答對的被鼓勵，答錯的被壓抑。

CLM 的訓練沿用這套，改動只有兩處：

1. 輸入的準備：CLM 會編輯 context，所以最終的 context 已經不是早期某一步當時看到的內容。論文的做法是每次模型呼叫連同它當時真正看到的 context，各自算一次（stepwise GRPO），整條軌跡的 advantage 原封不動分給底下每一次呼叫。這個做法不是論文新發明，附錄 A 說明延續 ReSum 與 Sculptor。凡是會改寫歷史的 agent（摘要、折疊 folding、CLM）要用 RL 訓練，都面臨同一個問題。
2. advantage 多了一項效率獎勵（下一小節），這才是論文自己的新設計。

6.2 效率獎勵只在答對的軌跡之間比

結果獎勵只分對錯，對「編輯得好不好」是弱監督：答對的軌跡裡可能有很笨的編輯，答錯的裡也可能有好的編輯。直接獎勵「編輯次數」或「刪掉的 token 量」又會被鑽漏洞，模型可能做一堆沒必要的編輯、把重要資訊也刪掉，或破壞 prefix 重用，這叫 reward hacking。所以論文只在「已經答對」的軌跡之間，依成本（prefix-reuse FLOPs）排序加減分，這種設計叫 success-gated：只有答對的軌跡才參與效率比較。

白話：答對的軌跡裡，比平均便宜的加分、比平均貴的扣分；答錯的完全不參與。寫成式子是論文 Eq. 6：

最後合成：

• $g$：同一題抽出的那一組軌跡。
• $\mathcal{G}_g^{+}$：這一組裡答對的軌跡。
• $c_i$：第 $i$ 條軌跡的 prefix-reuse FLOPs。
• $\bar{c}_g$：答對軌跡的平均成本。
• $\mathrm{clip}(\cdot, -1, 1)$：把結果限制在 −1 到 +1。
• $A_i^{\mathrm{out}}$：標準 GRPO 的結果 advantage。$w_{\mathrm{eff}}$：權重，論文 Appendix E 給 0.25。
• 答對的軌跡少於 2 條時，整組的 $A^{\mathrm{eff}}$ 都設為 0。

完整數字例子（自編例子，成本單位自訂）：同一題抽 4 條軌跡。表中的 $A^{\mathrm{out}}$ 和前面的例子不同，因為這組 4 條裡有 3 條答對；最後一欄合計是 $A^{\mathrm{out}} + 0.25 \times A^{\mathrm{eff}}$。

算法：答對的成本平均 $\bar{c} = (2+1+3)/3 = 2.0$，$\tau_2$ 是 $(2-1)/2 = +0.5$，$\tau_4$ 是 $(2-3)/2 = -0.5$。$A^{\mathrm{out}}$ 一欄是用「減平均、除標準差」算的（論文沒寫公式）。兩個重點：$\tau_3$ 成本最低卻答錯，所以拿不到效率加分，這就是 success-gated 的作用；效率項只是排序用的小項，$0.25 \times (\pm 0.5) = \pm 0.125$，遠小於對錯造成的差距。

效率分數怎麼落到每個 step 上，論文沒講清楚。這是 RL 的 credit assignment（功勞分配） 問題：一條軌跡有很多步，最後只得到一個分數，要怎麼決定每一步該分到多少功勞或責任。這裡的疑問在於效率項是分給整條軌跡的所有 token，還是只給編輯 context 的 token；文末「概念詳解」有一節專門談。

6.3 實驗結果：準確率打平，成本低約四成

• 模型與資料：Qwen3.5-9B，用 OpenResearcher 資料集的 3,040 題訓練 70 步，在 BrowseComp-Plus 全部 830 題評估。獎勵是 GPT-5.4-nano 依 DeepSearchQA 的評分準則（rubric）打的對錯二元分數。
• CLM：context 預算 28K（保留 2,048 tokens），最多 80 輪，編輯回合不計入；另加效率 advantage（權重 0.25，論文 Appendix E 說套用在 context 管理相關的 token 上）以及工具呼叫失敗與格式錯誤的懲罰。
• 對照組 Summary：agent 照常累積 context，累積到 28,672 tokens 時，除了 system prompt 和任務訊息之外，整段歷史被換成一則摘要（摘要用 Codex 的摘要 prompt），最多跑 100 輪。「何時摘要」和「怎麼摘要」都是人定死的；Appendix E 寫它只用任務獎勵訓練。摘要由誰來寫，論文沒明說。

表 2 是論文的原表，下面另列前後差值方便比較。Acc. 是 BrowseComp-Plus 準確率；PFLOPs/Q 是每題平均的 prefix-reuse PFLOPs（$1\ \text{PFLOP} = 10^{15}$ FLOPs），越低越好。

• 訓練前，CLM 比 Summary 低約 6 點。論文歸因於小模型的 context 管理能力不足；論文 Appendix F 也說 Qwen3.5-9B 很少編輯 context（在 TerminalBench 2.1 這組終端機任務上平均 1.4 次，一半的任務完全不編輯）。所以 CLM 的零樣本效果取決於模型本身的判斷力。
• 訓練後，準確率實質上打平（42.5 對 42.1），CLM 每題成本低約 38.8%（$(2.19 - 1.34) / 2.19$，與論文引言一致）。訓練曲線見下圖。
• 論文摘要的「提升 47.6%」是相對值（42.5 除以 28.8），起點很低；絕對提升是 13.7 點。和訓練後的 Summary 比只贏 0.4 點，真正的差別在成本。

小結：RL 讓 9B 模型的 CLM 追上訓練後的 Summary，準確率打平，差別在成本；不過兩邊的獎勵設計不同，這個成本差距不一定是同條件的比較。

7 四個零件一張表

進入實驗之前，先把四個零件放在一張表裡，每一項附上最該記得的保留：

零件之間的關係是：第一項讓 context 可編輯，第二項提供衡量編輯成本的尺，第三項在不動權重的前提下用文字改善管理策略，第四項改權重來學管理策略（效率獎勵直接用第二項的指標）。第三、四項學的是同一件事，差別只在學到哪裡：前者學在 context 的文字裡，後者學在權重裡。

8 主要證據：現成模型零樣本對上最強的固定流程

論文的主證據是零樣本實驗：不訓練、不演化，直接把現成模型換成 CLM 的玩法，與其他 context 管理方法比。RL 與 skill 演化是另外兩組獨立的結果，兩者互不重疊（見文末「概念詳解」最後一節）。先認識用到的基準：

• BCP（BrowseComp-Plus）：在固定語料上搜尋並回答難題的深度研究基準，測準確率。
• TB2.1（TerminalBench 2.1）：89 個終端機任務，每題只看通過或失敗。TBLite 是它的輕量版。
• EdgeBench-10：從 EdgeBench 挑 10 個程式庫優化任務，跑 12 小時，評分 0 到 100。
• Software World：6 個互相依賴的程式庫由 agent swarm 優化 24 小時，在沒見過的下游套件上量加速比。

8.1 BrowseComp-Plus 與 TerminalBench：相對 11.4% 其實約 6 點

所有方法用同一個模型（Qwen3.6-27B）、同一個 agent 框架（Mini-SWE-Agent）、32K 預算、100 輪上限，對手有 Base（不做任何管理）、Summary、MEM1、Self-Compact、ACM、RLM（把長輸入當成變數、讓模型按需讀取的方法）。換不同大小模型的版本在論文 Figure 17。

乾淨對照是 CLM 對最強對手 Summary：

論文摘要與引言的「高 11.4%」是相對值，換成絕對點數約 6 點。準確率真正贏的是 BCP 和 TBLite；TB2.1 只贏在成本。

8.2 EdgeBench-10：預算決定優勢大小

agent 在一個程式庫上連續優化 12 小時，容器沒有網路；每次提交由 EdgeBench 評分器打 0 到 100 分，一個 run 的分數取「最好的提交」與「最終程式庫」兩者較高者。每個任務跑三次（三個隨機種子，seed），取最好的一次（best-of-three）。PF 指每次試驗的平均 prefix-reuse PFLOPs。比較對象是 Base、Codex 風格摘要、CLM，以及 CLM 加最多五個同時運作的子 agent。

下圖的 (a) 是 32K 預算下的 EdgeBench-10 曲線，(b) 是後面「其餘實驗」會提到的 Software World。128K 預算的版本在論文 Figure 19。

三個讀法：

• 32K 時 CLM 明顯贏：Qwen 上 +2.3 點、成本只要約 4 成。論文摘要的「高 5%、少 59% FLOPs」對應的就是這一格（44.6 除以 42.3 約 +5.4%；179 除以 437 約 41%），是單一最好看的設定。
• 128K 時準確率優勢消失：CLM 47.3 對 Summary 47.8，只剩約 36% 的算力節省（$(222 - 142) / 222$）。合理的推論（非論文原文）：預算寬裕時，管理壓力小，管理策略的差距也縮小。
• 子 agent 沒有穩定好處：32K 時沒有增益，128K 時 +2.9 點但算力與 Summary 相當。論文自己也說單一程式庫上子 agent 幫助不大。

把這兩組實驗放在一起看：CLM 的優勢在「預算緊、context 壓力大」時最明顯，預算放寬就收斂成省成本。這比論文摘要寫的「全面領先」窄得多。

8.3 其餘實驗：補充證據與 CLM 的依賴

下面四組是輔助證據，不細拆：數學優化、Software World、模型大小比較、context 長度感知。數學優化問題上，CLM 與 OpenEvolve（一套專為這類問題設計的演化式工作流程）的比較見表 3。

• 數學優化 vs OpenEvolve（表 3）：想證明通用 agent 加 CLM 能贏專用的演化流程。四題 CLM 都最好：圓填充 2.618 對 2.541（+3.0%），Heilbronn 0.03653 對 0.03127（+16.8%），另兩題差距只在小數點第三到第四位。提醒：每個方法只跑一次，取最好結果；差距很小的兩題不能當證據，Heilbronn 的 16.8% 是相對值。
• Software World，24 小時 agent swarm（圖 11 的 (b)）：想證明改進能遷移到沒見過的下游套件。17 個沒見過的基準上的幾何平均加速，圖上標 CLM 約 1.044、Summary 約 1.026；絕對多出約 1.8 個百分點，論文寫的「多 65%」是相對說法。提醒：模型是 GPT-5.6-Sol、context 預算 272K，不是前面的 32K 設定；文字沒交代跑了幾次。
• 模型大小比較（論文 Figure 17、Appendix F）：說明 CLM 的效果取決於模型自己會不會判斷何時編輯。Qwen3.5-9B 在 TB2.1 平均只編輯 1.4 次，一半任務完全不編輯；Qwen3.6-27B 平均編輯 2.6 次。9B 的 context 峰值中位數 30.2K（上限 32K），27B 是 17.6K。提醒：9B 的零樣本結果不能和 RL 章的訓練前結果混讀，說明見下一段。
• Context 長度感知（論文 Appendix G，下一節的圖 12）：說明現有模型不太會估算自己用了多少 context，所以需要環境提醒。沒有提示時估算誤差很大；給了 token 數的提示後誤差明顯下降。提醒：只用 50 個輸入測，而且測的不是主要實驗用的 Qwen3.6-27B。

關於模型大小那一列的提醒：論文 Appendix F 說 9B 在 BCP 上零樣本 CLM 是 39.9%，高於 Summary 的 37.7%；但 RL 章的表 2 說 9B 訓練前 CLM 是 28.8%，低於 Summary 的 34.7%。兩者設定不同（零樣本實驗：32K、100 輪；RL 評估：28K、最多 80 輪）。這是我的推論，論文沒點明這個差別。

這四組的讀法：前兩組是「CLM 比較好」的補充證據，但都不是受控實驗：單次執行、勝幅小，或換了模型與預算。後兩組是「CLM 目前有哪些依賴」的證據：模型要夠強，而且要有外部提醒。

順帶一提，圖 4 右半的 SCR（Suffix Cache Reuse）是論文在服務端提出的做法：改動中間內容之後，仍然重用所有留下來的 token 的快取，減少重新 prefill。論文另外用實驗比較了 SCR 與標準服務，但這篇文章不展開它的實驗細節，有興趣請回原論文查。

8.4 模型估不準自己用了多少 context

模型要自己決定「現在該不該壓縮」，前提是知道已經用了多少 token。論文 Appendix G 發現現有模型不太會估。衡量用的是 MAE（Mean Absolute Error，平均絕對誤差）：估計值與實際 token 數的差距，取絕對值再平均，單位是 token，越小越準。下圖每個點是一次估計對上伺服器回報的真實 prompt 長度，各小圖分別是沒有提示，以及在輸入 25%、50%、75% 處給一個 token 數錨點。

圖中的小字不好讀，圖例裡的數字整理在下表。這些數字取自圖例，本文沒有對照原圖逐點核實，請以原圖為準：

論文文字的結論有三點：長 context 下，模型的估計會落在重複出現的幾個數字（如 6.2K、9.8K）；給了 token 數的提示後誤差下降；提示離估計點越近越有效。「重複的數字可能來自預訓練的計數習慣」是論文自己的猜測，沒有驗證。這就是為什麼 harness 要補提醒：實驗裡的提醒（剩 2,048 tokens），以及 ContextBench skill 摘錄（論文 Table 4）中的 [context: ~N/M tokens] 讀數，都是在補這個缺口。

可遷移的規則（推論，非論文原文）：任何資源（token、時間、金額預算）都由環境量測，附在每次工具結果裡回報；回報要貼近決策點，每輪都附，比只在開頭講一次有效。

for each tool_result:
    result += f"\n[context: ~{count_tokens(ctx)}/{limit} tokens]"

小結：32K 的緊預算下，CLM 以較低成本達到相當或更好的準確率（TB2.1 打平，BCP、TBLite 與 EdgeBench 較準）；在 EdgeBench 上把預算放寬到 128K，準確率優勢就消失，只剩省成本。而且 CLM 目前依賴兩件事：模型要夠強，還要有外部的用量提醒。

9 整體評價：概念值得試，證據只夠說明有潛力

先說結論：研究價值中等偏低；工程價值是「概念值得試，證據只夠說明有潛力」。

研究價值：論文的貢獻是介面設計，不是新演算法。「讓模型對自己的 context 有寫入權」這個想法簡單、通用，也把 when 與 how 兩個維度都推到了模型手上，這是它最持久的部分。但底下用的東西幾乎都是現成的：RL 是 GRPO 加上 ReSum 與 Sculptor 式的分段（附錄 A 自己承認），skill 演化是 GEPA 風格。真正算新的只有 success-gated 效率 advantage，權重只有 0.25，而且它怎麼落到 token 上論文沒說清楚。

工程價值：最強的證據是 32K 的緊預算下，27B 現成模型零樣本就勝過固定流程（BrowseComp-Plus 約 +6 點；EdgeBench-10 +2.3 點且只用約 4 成算力）。最弱的是：沒有任何實驗把「自由編輯」的功勞，從 harness 的輔助設計裡拆出來；預算放寬到 128K，準確率優勢也消失，只剩省成本。所以能說的是「整套設計」在緊預算下划算，還不能說「context 是檔案」這個想法本身就是主因。

9.1 論文摘要的宣稱，換成乾淨版本

可以相信的是「緊預算下，CLM 以較低成本達到相當或稍好的準確率」，不能相信的是論文摘要給人的那種「全面大幅領先」的印象。表中每一列，論文摘要用的都是當下最好看的相對值或設定。

9.2 整篇共有的弱點

• 沒有拆開「自由編輯」與「harness 輔助」的功勞：CLM 同時享有編輯回合不計輪數、退回重試、剩 2,048 tokens 的提醒，沒有任何實驗把這些輔助關掉；零樣本實驗中 CLM 的 system prompt 與 skill 內容也沒給，看不出有多少功勞來自提示寫得好。這是最關鍵的一條，它決定能不能把「CLM 勝出」歸因給想法本身。
• 缺變異數與重複次數：數學優化每個方法只跑一次；EdgeBench 取三個 seed 的最好結果，沒有誤差；Software World 沒交代跑幾次。所以 44.6 對 44.2、RL 贏 0.4 點、數學題小數點第三到四位的差距，都分不出是真差距還是雜訊。約 2 點以內的小勝都不該當證據。
• 證據是拼起來的，沒有串成一條線：零樣本用 Qwen3.6-27B 與 Claude 4.6 Sonnet，RL 用 Qwen3.5-9B，skill 演化用 Opus 5 或 Fable 5.1 當 proposer，Software World 用 GPT-5.6-Sol。沒有任何一個模型從頭走到尾。
• 自建基準與自訂指標：ContextBench 是作者自建的；FLOPs 是自訂的理論值，不等於實際延遲或帳單。

另有一個結構性的提醒：「CLM 勝過現有最強方法」（27B 現成模型，零樣本）與「CLM 可被訓練變強」（9B 加 RL，或 skill 演化）是兩組互不重疊的證據。論文沒有展示「訓練或演化後的 CLM 在長時間任務上更強」，詳見文末「概念詳解」最後一節。

9.3 把自由度交給模型，什麼條件下划算

什麼時候值得把自由度交給模型？以下是我整合論文證據得出的判斷，推論，非論文原文：

還有一個講過頭要避開的地方：「三者同時成立」是我編的組合，論文沒測過三者的交互作用，它只是決定「從哪裡開始試」的經驗法則，不是必要條件。

9.4 安全風險：自己寫、自己讀回的 context

論文第 6 節提到，可編輯的 context 可能成為注入的提示或自我生成的指令跨輪持續的管道。它引用 OpenAI 的報告：模型曾在自己的壓縮摘要裡塞入未授權的指令，並影響後續行為。論文沒有做任何實驗，也沒有提出防禦，只說未來要研究。

機制是這樣（自編例子）：

1. 工具結果（例如網頁）裡藏有惡意指令。
2. agent 把它寫進自己的筆記或摘要。
3. 下一輪讀到，把它當成自己的計畫。
4. 指令持續生效。

這樣的內容在後面幾輪看起來是「我自己寫的」，比一次性的注入更難被辨認。OpenAI 那個案例是模型自己加指令，和外部注入是兩個變體，但持久化的路徑相同。

可遷移的規則（推論，非論文原文）：

• 凡是「模型能寫、之後又會讀回」的地方（摘要、筆記、記憶、CLM 的 context 檔案），都是持久化通道，不限於 CLM。
• CLM 的面積比摘要大，因為編輯不受限。
• 論文沒說的：context 檔案是否包含 system prompt、模型能不能刪掉自己的指令。

小結：能相信的是「緊預算下以較低成本達到相當或稍好的準確率」，不是「全面大幅領先」；而且這份自由也帶來一條論文還沒處理的安全通道。

10 結論：值得帶走的東西

這篇論文最值得記住的不是任何一個百分比，而是它把 context 管理拆開來看的方式：何時做與怎麼做是兩件事，過去的方法把其中一件或兩件鎖在人手裡，CLM 兩件都交給模型。這個主張在緊預算下有證據支持，但證據混著 harness 的輔助設計，而且沒有變異數；所以它是一個值得認真嘗試的設計選項，還不是已經被證明的最佳做法。

論文自己的貢獻之一：context-as-a-file，讓模型對自己的 context 有寫入權。 標準 LM 的 context 只能往後接，因此所有「留什麼、丟什麼」的決定都落在 harness 手上。過去讓模型參與，模型能做的事仍受限於人預先設計的操作選單（壓縮、卸載、檢索）；這篇論文把這道限制拿掉，操作的種類由模型自己決定（刪一條、批次刪、寫一個輔助函數、新增筆記角色，都不用事先設計）。

這是最持久的部分：想法簡單、通用，不依賴特定模型或基準，任何會寫程式的 agent 都能用，也自然延伸出「context 管理可以被指令引導、被演化、被訓練」這幾條路。但它是設計選擇，不是新演算法，是否優於「固定流程加好的 prompt」，論文沒有直接證明。

貢獻之二：success-gated 效率 advantage（Eq. 6）。 只在答對的軌跡之間依理論成本加減分，解決了「結果獎勵分不出編輯好壞、直接獎勵編輯量又會被鑽漏洞」的問題。它只能算「小」貢獻，理由有三個：權重只有 0.25；對應的做法在別的領域早有類似設計（附錄 A 提到只在答對的回答上罰長度的 Arora & Zanette，以及 DDCA），差別只是這篇用 FLOPs 當成本；而且這一項怎麼分給 token，論文沒講清楚。

還有一個窄但可信的實證結論（32K 緊預算下的零樣本結果），但這類數字會隨模型與基準換代而過期，能長期留下的是前兩項，以及下面這些脫離論文也成立的觀念。

適用條件的判斷在前面「什麼條件下划算」一節；除此之外，最通用的觀念有三個：編輯 context 的成本由位置決定；次要目標只能在達標的集合內比較；用來挑選的資料不能拿來報成績。這三個在換掉模型、換掉基準之後依然成立，文末的延伸章節各有一節。

• 下次看到一套 context 管理方法，先問兩個問題：誰決定何時做？操作是誰寫的？CLM 是兩個都答「模型」的那一類，代價是要有 harness 在旁邊提醒。
• 讀論文數字時先換回絕對值：「高 11.4%」約是 6 點，「提升 47.6%」是 13.7 點；在 EdgeBench 上，預算放寬到 128K 時準確率優勢就沒了。
• 自己做 agent 時：改 context 盡量改在後面（論文附錄的例子裡，改開頭的成本是只追加的 7.7 倍）；效率只在成功的嘗試之間比；挑 prompt 用的分數別拿來報成績。

11 延伸：脫離這篇論文也成立的四個觀念

以下四節是選讀：每一節都能獨立讀、不需要回頭看論文，內容收合起來，想深入再展開。

11.1 一塊 context 該留、壓、存檔，還是刪

# 推論：整合論文三個失敗原因與 ContextBench 四個任務得出的判斷順序（非論文原文）
def decide(chunk):
    if chunk.needed_verbatim_later:
        return KEEP if chunk.small else OFFLOAD_TO_FILE   # 存檔後，context 只留指標
    if chunk.structured and chunk.edited_in_small_pieces:
        return EDIT_IN_PLACE                              # 例如棋盤、狀態表
    if chunk.only_gist_needed:
        return SUMMARIZE
    return DELETE

11.2 編輯成本由位置決定

11.3 次要目標只能在達標的集合內比較

correct = [t for t in group if t.success]
if len(correct) < 2:
    eff = {t: 0 for t in group}                 # 沒得比
else:
    mean_c = mean(t.cost for t in correct)
    eff = {t: clip((mean_c - t.cost) / mean_c, -1, 1) if t.success else 0 for t in group}
A = A_out + w_eff * eff                         # 論文 w_eff = 0.25

11.4 用來挑選的資料，不能用來報成績

12 概念詳解：最值得回頭查的五件事

以下五節是選讀，也是最容易忘、最值得回頭查的部分。每一節都寫成脫離這篇論文也成立的形式，內容收合起來，可以單獨展開。

12.1 when 與 how：context 管理的兩個維度

12.2 context 檔案像原始碼：改壞標記的風險

12.3 credit assignment：總分怎麼分給每個 step

12.4 論文實際使用的三段引導指令

12.5 零樣本、skill 演化、RL：三組互不重疊的證據