【2026 最新】Context Compaction 怎麼驗收？用 Reacquisition Cost 抓出成功率看不見的成本

Context Compaction 最容易製造的假象，不是 Agent 直接失敗，而是它仍把任務做完，背後卻重新搜尋同一個路徑、重讀同一份檔案、再問一次早就取得的限制。只看 completion，你會以為「壓縮成功」；帳單、延遲與工具軌跡卻可能已悄悄變差。

這篇專為會寫一點 Python、正在做檔案搜尋或 Coding Agent 的讀者而寫。我們不綁定特定模型，也不把某篇新論文的門檻當成標準答案；你會得到一份可移植的固定 24-turn A/B 驗收協定，分開量 retrieval、execution 與 Reacquisition Cost（資訊找回成本），再把自己 runner 產生的軌跡變成可部署的 compaction gate。本文交付的是實驗設計、事件 schema 與判定規則，不是假裝已替你的模型跑完 benchmark 的下載式 harness。

Context Compaction 是什麼？先把「刪掉」和「保留」分開

Context Compaction 是把過長的模型可見歷史，轉成更短的表示：可能丟掉舊 turn、清除大型 tool result，也可能產生一份摘要。它不是把原始世界變小，而是縮小「下一次模型呼叫真正看見的工作面」。你可以把它想成搬家：倉庫裡的箱子仍在，桌面只留下標籤與目前要用的東西。

這也是為什麼 event log、client history 與 model-visible context 要分開。現有的 DeepSeek Harness 教學已解釋 append-only session 如何衍生出較短的模型工作面；Context Engineering 白話教學則補足 context 為何是有限的工作記憶。本文再往前一步：不是問「壓掉幾個 token」，而是問「模型為了補回那些資訊，多做了什麼」。

和既有文章的邊界也要畫清楚：Claude 省 token 實戰談 prompt、cache 與使用習慣，Headroom 教學檢視特定壓縮產品與官方節省主張，CLAUDE.md 指令膨脹教學處理持久規則的新增、到期與安全刪除，Claude Code Token A/B 測試建立配對的 completed-task cost 基礎；本文不重做這四題，只比較同一 frozen checkpoint 的 full baseline 與 compaction arm，用 dropped observation ID＋content hash 量 excess_reacquisition，並要求完成品質對 baseline 非劣。

Reacquisition Cost：被 completion 蓋住的第二張帳單

Reacquisition 指的是：某項狀態、路徑或限制已在壓縮前被 Agent 觀察，壓縮後不在有效 context 裡，Agent 因而再次呼叫 retrieval tool 取得同一資訊。第一次讀檔是 acquisition；壓縮後又讀同一版本，才是 reacquisition。這個定義比「工具呼叫變多」更精準，因為有些新搜尋本來就是任務推進所需。

最小可用的成本向量可以寫成 Y = (Q, C_R, C_E)：Q 是完成品質，C_R 是搜尋／讀檔等 retrieval calls，C_E 是寫檔／執行測試等 execution calls。壓縮造成的 retrieval overhead 先看配對差 excess_reacquisition_events = reacquisition(compacted) - reacquisition(full)，並另加總重讀結果的 repeat_acquisition_tokens。真正的淨 token 節省則定義成 net_savings_tokens = all_in_billable_tokens(full) - all_in_billable_tokens(compacted)；兩邊都必須納入失敗嘗試、重試與 compaction iteration，不能再重複扣一次已包含在總量內的 reacquisition token。

2026 年 8 月 17 日提交的 arXiv v1 預印本〈What Does Context Compression Cost an Agent?〉，正是用這種拆法研究固定 24 個模型回合的 IRBench。論文在六個「模型 × 資訊環境」的 5× sliding-compression 比較裡，六組 retrieval 點估計都增加，其中五組通過作者對這六項比較所做的 Holm 校正；completion 的配對檢定則都未檢出差異。後一句不等於完成率相同，因為它不是等效性檢定，統計單位也只有 10 個配對 seed。

以其中 GPT-5.5／High-IR cell 為例，completion 是 80%→85%、配對檢定 p=1.0，retrieval calls 卻增加 42.9、原始 p=.002。這裡的 80% 是平均完成 10 個子任務中的 8 個，不是「80% 的 run 全部成功」；42.9 也不是多 42.9 個 turn，因為一個模型回合可以包含多次工具呼叫。

把研究當方向提示可以，把它當可直接複製的 benchmark 不行。截至 2026 年 8 月 18 日，該 arXiv 頁面與官方 source archive未列出 code、raw data 或可核對的 preregistration URL，source archive 也未提供文中所稱 serving-details appendix。它的 ALFWorld probe 成功率接近地板，且未交代模型、壓縮比與 horizon；所以本文採用它的量測問題，不採用任何單一最佳門檻。

實作協定：固定 24-turn 的 Context Compaction A/B test

先挑一個結果可機械驗證的小任務，例如：「在固定 fixture repo 找出三個設定來源，修改一個值，保持兩條 load-bearing constraints，最後讓指定測試通過。」fixture 每個 arm 都從同一 commit 或唯讀 checkpoint 重建，並開一個全新的模型 session；不要沿用上一組已經暖過的 history、tool cache 或 workspace，也不要直接拿每天會變的 production repo 當第一組實驗。

1. 凍結任務與模型：一次只改 compactor

痛點：若模型版本、prompt、tool schema 和任務同時變，差異就不能歸因；若總是先跑 full、後跑 compacted，供應商或時段漂移也會和 condition 混在一起。解法：把 model ID／snapshot、temperature、seed（provider 支援時）、max output、24 個模型回合、fixture commit 與工具定義寫入每次 run 的 manifest。以 task_id + seed + repeat 建立配對 block，事前隨機或平衡四個 arm 的順序，交錯執行；每個 arm 都還原相同 checkpoint、使用獨立 workspace 與全新 session。相同 seed 只代表可配對條件之一，不保證供應商端完全決定性，因此要先用 pilot 估變異，再事前決定足夠的 task／repeat 數；下方五個 seed 只是 smoke-test 排程，不是足以發表結論的固定樣本數。

experiment_id: cc-24turn-v1
pair_key: [task_id, seed, repeat, checkpoint_sha256]
fixture_commit: 7d3a9c1
session_prefix_sha256: YOUR_FROZEN_PREFIX_HASH
tool_schema_sha256: YOUR_FROZEN_SCHEMA_HASH
max_model_turns: 24
model: YOUR_PINNED_MODEL_ID_OR_SNAPSHOT
temperature: 0
paired_trials: YOUR_PREDECLARED_N
arm_order: DETERMINISTIC_SHUFFLE_BY_PAIR_ID
restore_each_arm: [fresh_isolated_session, clean_fixture_commit]
retrieval_tools: [search_files, read_file]
execution_tools: [write_file, run_check]

2. 同預算比較四條路：不要讓摘要偷拿更多 context

痛點：fact-preserving 策略如果比 aggressive 多拿一倍 token，贏了也不代表結構較好。解法：設四個 condition：full 不壓縮；normal 保留最新 40%；aggressive 保留最新 20%；fact_preserving 同樣只有 20% 預算，但先放結構化 digest，再用剩餘額度放最新 turn。真正公平的是相同有效 context budget，不是相同摘要字數。

3. Digest 只留承重資訊，不要寫成流水帳

痛點：摘要保留「做過很多搜尋」卻丟掉不得改的條件，字很多仍沒有用。解法：固定 digest schema，只允許六個欄位：goal、load_bearing_constraints、tool_inventory、files_observed、decisions_and_evidence、next_action。其中 constraints 要保留原始字串或穩定 ID；tool inventory 要存名稱與 schema hash，不能只寫「工具都還在」。

{
  "load_bearing_constraints": ["C01: do_not_edit_lockfile", "C02: tests_green"],
  "tool_inventory": {"sha256": "...", "names": ["search_files", "read_file", "write_file", "run_check"]},
  "files_observed": [{"path": "config/app.yaml", "sha256": "...", "facts": ["timeout comes from env"]}],
  "decisions_and_evidence": ["edit service/config.py because test X imports it"],
  "next_action": "patch service/config.py, then run check_timeout"
}

這不是宣稱「結構化摘要一定最好」。論文的 fact digest 是研究者設計的 deterministic extractive control，且和部分 sliding 結果來自不同 batch；描述性數字可以啟發設計，不能拿來保證任意 LLM summary 都安全。

4. 在 compaction 邊界標記事件，才能抓到真正重讀

痛點：read_file 變多，可能只是 Agent 探索了更多必要檔案。解法：每次工具呼叫記錄 canonical key，例如 read_file:path@content_hash；壓縮時記下 active context 中被移除的 observation IDs。若後續 retrieval key 曾出現、對應 observation 被移除、底層內容版本又沒變，就標為 reacquisition=true。

def classify_retrieval(event, seen, dropped_ids):
    key = canonical_key(event)  # 例如 read_file:config/app.yaml@sha256
    reacquired = key in seen and seen[key].observation_id in dropped_ids
    seen[key] = event
    return {"retrieval_key": key, "reacquisition": reacquired}

最少保存穩定的 event_id、run_id、pair ID、arm order、session／checkpoint hash、condition、seed、repeat、turn、tool、arguments hash、result／content hash、result token、started／ended time、input／output／cache／compaction token、error type、compaction boundary 與 reacquisition flag。每個 run 再彙總所有失敗／重試的 billable token、工具／基礎設施費用與實際費用；這樣才算得出 all-in 成本。若你還沒有軌跡層，先讀 Agent Observability 教學；要自己接最小 loop，可搭配 AI Agent Harness 實作。

5. Completion 改成兩層：結果分數＋硬性 invariant

痛點：測試綠燈不代表 Agent 沒刪 lockfile，也不代表 tool inventory 完整。解法：一層是 task score，例如 8 個 assertion 通過幾個；另一層是 hard gate：所有 load-bearing constraints 必須保留、tool schema hash 必須精確相符、不得發生未知工具或 execution error。任何 hard gate 失敗，即使最後測試偶然通過也判定該 run 不可接受。

你真正要看的 7 個指標

1. Task score：不是單一 yes/no，而是通過 assertion 的比例、全數通過率，以及 compacted−full 的配對差。
2. Constraint retention：承重限制逐條驗收，預設要求 100%。
3. Tool inventory integrity：壓縮前後 tool name、必填參數與 schema hash 是否一致。
4. Reacquisition：同版本 observation 被移除後又取得的次數、repeat_acquisition_tokens，以及相對 full arm 的 excess_reacquisition 配對差。
5. Retrieval／execution calls：兩類分開看；總工具數相同也可能掩蓋結構改變。
6. All-in 成本與 latency：把所有嘗試、重試、fallback 與 compaction iteration 的 input／output／cache token、工具／基礎設施費用納入；延遲至少看 p50 與 p95。
7. Error taxonomy：unknown tool、schema mismatch、permission、timeout、test failure 各自計數；零完成時直接判不可部署，而不是除以零後忽略。

每個派生量都以同一個 pair_id 的 full arm 為基準。repeat_acquisition_tokens 只加總標為 reacquisition=true 的 retrieval call arguments，以及用固定 tokenizer 計算、重新送回模型的未變更 result payload；不要把所有後續 token 都武斷歸因給壓縮。所有 retry／fallback 必須沿用同一個 logical task ID，不能包裝成新的成功樣本。

repeat_acquisition_tokens(arm, pair) =
  SUM(tokens(call_arguments) + tokens(unchanged_result_payload))
  FOR retrieval events WHERE reacquisition = true

excess_reacquisition(arm, pair) =
  repeat_acquisition_tokens(arm, pair)
  - repeat_acquisition_tokens(full, same_pair)

all_in_cost(arm, pair) =
  SUM(price_weighted_usage_cost_for_each_model_iteration
      + tool/infrastructure cost)
  ACROSS compaction, message, failed, retry and fallback iterations/attempts

net_savings(arm, pair) =
  all_in_cost(full, same_pair) - all_in_cost(arm, pair)

cost_per_completed_task(arm) =
  SUM(all_in_cost for every attempt)
  / COUNT(distinct tasks that pass the predefined completion rubric)

net_savings > 0 才表示配對後真的省；若無法可靠換算美元，就把 billable token、工具費與 latency 分帳呈現，不要硬合成單一成本。cost_per_completed_task 的分子必須保留失敗與重試成本，分母不得把失敗任務刪掉後重新編號。

官方實作也提醒你不能只讀一個總數。Anthropic 的 server-side compaction 文件說明 compaction 會產生獨立 sampling iteration，計費與 rate-limit 統計要檢查 usage.iterations；OpenAI 的 compaction 文件則區分 Responses 內的自動 context_management 與 stateless /responses/compact。API 細節會變，實驗 manifest 應保存當天實際 request／response 欄位，而不是把本文參數硬編碼進長期儀表板。

把 Context Compaction 結果變成 fail-closed gate

先定硬門檻，再定效率門檻。下面是起始範例，不是論文結論：若你的產品有寫入 production、付款或刪除權限，hard gate 應更嚴格，甚至先禁止自動壓縮。completion tolerance 也要用歷史變異與風險成本估計，不能照抄 2 個百分點。

hard_gates:
  load_bearing_constraints_retained: 1.00
  tool_inventory_exact_match: true
  unknown_tool_errors: 0
  execution_schema_errors: 0
quality_gate:
  primary_metric: task_score
  noninferiority_margin_pp: 2       # 示例；須事前依風險設定
  paired_ci_level: 0.95
  minimum_pairs: SET_BY_POWER_OR_SIMULATION
  pass_rule: "lower_CI_pp(Q_compacted - Q_full) > -2"
efficiency_gates:
  pass_rule: "lower_95CI(paired_net_savings) > 0 AND upper_95CI(cost_per_completed_task_change) < 0"
  excess_reacquisition_tokens_max: PREDECLARED
  p95_latency_change_max: 0.05

做統計時，對每個 pair_id 先算 d = Q_compacted - Q_full，再呈現配對差值與信賴區間；bootstrap 時重抽 pair，不能把 turn 或 tool event 當成獨立樣本。若事前門檻是 Δ=2 個百分點，只有 95% 信賴區間下界嚴格高於 -Δ，而且所有 hard gate 都通過，才能說品質非劣於 baseline。下界沒有跨過門檻時是證據不足／fail closed，不是「品質相同」。五個 seed 可用來 smoke-test 儀表，但正式 minimum_pairs 要依預期變異與 power／模擬事前決定。這和 AI Evals 教學強調的固定資料集、grader 與回歸 gate 是同一件事。

三種結果，該怎麼決定要不要壓縮？

• 品質非劣、all-in 成本也降：才是可部署候選；還要確認 excess reacquisition／p95 guardrail 未越線，再用不同 task family 與更長 horizon 回歸。
• 品質過、reacquisition 或 all-in 成本升：先修 digest 或延後 trigger。別因 completion 看起來正常、prompt 看起來較短就上線。
• hard gate 失敗：直接 fail closed；tool inventory 或承重限制遺失不是效率 trade-off。
• 不同環境方向相反：按 task family 分策略，不要尋找一個全站通用的 token／turn 門檻。

論文自己的 ALFWorld probe 就沒有觀察到 retrieval-like action surge，但該 probe 的 success 約 10% 且 adapter 設定不完整，適合用來提醒「環境依賴」，不適合證明壓縮安全。最實用的 trigger 通常是多訊號：context pressure 達門檻，且下一階段已有可驗證 digest，且 hard state 已外部化。本文的新增邊界是：在同一 frozen checkpoint 上做隔離、隨機化的配對 arm，用 retrieval／execution 拆分與 dropped observation ID＋content hash 判定超額 reacquisition，再把 all-in 每完成任務成本納入 gate。

常見 5 個坑：數字漂亮，結論仍可能錯

1. 把 cache hit 當 context reduction：快取影響重算成本、處理延遲與價格，不告訴你哪些事實仍在模型可見 context。
2. 只算重複路徑：同一路徑內容已更新就不是純 reacquisition；一定要加 content hash。
3. 摘要額外吃預算：fact-preserving 組必須與 dropper 使用相同有效 context budget。
4. 把 tool count 當意圖：工具 schema 只能近似分類；抽樣人工檢查 trace，確認 retrieval label 沒包到 execution。
5. 把 issue 當產品現況：例如 Codex issue #34719 是使用者提交、截至本文研究時仍 open 的特定環境報告，只能轉成「壓縮後重驗 tool inventory」的測試需求；Microsoft Agent Framework #7011 則已有合併修復。issue 可指引回歸案例，不能代替當前官方規格。

若你只想先做最小版本，從三件事開始：把 read_file 與 write_file 分類、在 compaction boundary 保存 dropped observation IDs、把兩條承重限制寫成 assertion。等這三件穩定，再補 token、cache 與 latency；不要一開始做漂亮 dashboard，卻沒有可判定的 ground truth。

Context Compaction 常見問題 FAQ

1. Reacquisition Cost 就是多花的 token 嗎？

不是。本文先把它定義成壓縮後為找回已見資訊而重複發生的 retrieval event；token、延遲與美元是相關但不同的成本軸，必須另記。

2. Completion 沒有顯著下降，就能說壓縮無損嗎？

不能。未檢出差異可能是差異小，也可能是樣本不足；「不劣於」需要預先定義 margin 與對應統計設計。

3. 24-turn 是最佳測試長度嗎？

不是。24-turn 只是對照論文與建立第一個固定 horizon 的方便起點；正式驗收應加入你的 p50、p95 長任務與跨階段工作流。

4. Fact-preserving compactor 一定勝過 sliding window 嗎？

不一定。摘要可能遺漏、誤寫或過度凸顯某些事實；它必須在相同 budget 下，對你的 task family 實測。

5. 應該用 token、step 還是品質觸發 compaction？

用多訊號。token／step 只表示壓力，品質 probe、digest 完整度與 hard-state 外部化才決定此刻能否安全壓縮。

6. Tool-result clearing 也要做同一套測試嗎？

要。它刪的是較窄的 context 類型，但同樣可能造成重抓。Anthropic 的 context editing 文件提供 cleared tool uses／tokens 等回應欄位，可和自己的 retrieval trace 對照。

7. 沒有 provider seed，A/B test 還有意義嗎？

有，但要增加重複。固定可控項、配對相同 fixture 與 task，記錄確切模型識別，報告分布與信賴區間，不把單次 run 當結論。

8. 新手第一個 gate 應該設什麼？

先設 hard gate。要求承重限制 100% 保留、tool inventory 精確相同、unknown-tool 與 schema error 都是 0；有了安全底線，再優化 reacquisition 與 token。

給新手的 5 個重點

1. Completion 是投影，不是完整成本。
2. 先分 retrieval 與 execution，再標記真正 reacquisition。
3. baseline 與 compaction arm 必須同模型、同任務、同 frozen checkpoint；互相比較的壓縮 arm 還要使用相同 context budget。
4. 承重限制與 tool inventory 是 hard gate，不能拿 token 節省交換。
5. 門檻來自自己的 task family 回歸，不來自單篇預印本。

完成第一輪後，把這份 gate 放進每次模型、prompt、tool schema 或 compactor 更新的回歸流程。若你想把評測、Context Engineering 與 Agent observability 串成完整能力，可到 AlphaLab 課程沿著實作路線繼續學。