脈絡腐化 Context Rot：為什麼你的 Coding Agent 越跑越笨——而 benchmark 不會告訴你

三組嚴謹研究串成的證據鏈與決策框架。

AI Academy 編輯部2026年07月15日
本文目錄（15 節）▾
  1. 這篇文章適合你，如果你是…
  2. 前言：早上還好好的 agent，為什麼下午就變笨了？
  3. TL;DR
  4. 核心概念：吞得下，不等於消化得了
  5. 方法對比：在 harness 層對抗腐化的六種手段
  6. 決策框架：依 session 長度、任務類型與預算選組合
  7. 實戰最佳實踐：為什麼 coding agent 是重災區
  8. 長脈絡的三重稅：更慢、更貴、更笨
  9. 效能調優：三個可以立刻做的動作
  10. 工具與資源推薦
  11. 總結與展望
  12. 金句
  13. 延伸思考
  14. FAQ 常見問題
  15. 參考資料

這篇文章適合你，如果你是…

  • Advanced AI Engineer（1-3 年）：正在把 LLM / coding agent 搬進生產環境，卻發現長 session 跑到後面品質崩掉，需要知道「為什麼」與「怎麼救」
  • Technical Leader / Architect：要為團隊的 agent 架構做選型與預算決策，需要一套「不被廠商 1M token 行銷牽著走」的判斷框架
  • 正在評估長脈絡模型的決策者：想搞清楚「200K / 1M context window」到底能不能當可用容量來規劃系統與成本

前言：早上還好好的 agent，為什麼下午就變笨了？

先講一個用過 coding agent 的人大概都遇過的場景。

早上開一個新 session，agent 讀了幾個檔案、跑了測試、修了一個 bug，一切順暢。同一個 session 跑到下午，trajectory 越拉越長，它開始像換了一個人：三十分鐘前自己定下的架構決定忘得一乾二淨，重新造了一次你已經叫它別造的輪子；或者做到一半就收手，丟給你一個模稜兩可、沒有結論的答覆。它沒有報錯，沒有 crash，CI 也是綠的。它只是悄悄變笨了。

從系統架構來看，這不是模型壞掉，而是一個可預測的失敗模式：你餵給它的脈絡（context），已經超出它真正能可靠處理的範圍。 規格表上寫的 200K、1M token，回答的是「這個視窗吞得下多少」，但吞得下不等於消化得了。搜尋輸出、試錯死路、工具往返一層層堆上去，模型的注意力被稀釋，中段資訊開始被漏掉，先前的決策被新湧入的雜訊淹沒。這個現象有個名字：Context Rot（脈絡腐化）。

這也不是零星個案。Chroma 在 2025 年 7 月測了 18 個前沿模型，結論很直接：每一個模型都隨輸入變長而退化，連最簡單的檢索與文字複製任務都不例外。NoLiMa（ICML 2025）的數字更難看：13 個號稱支援 128K 以上脈絡的模型，有 11 個在 32K 就跌破自己短脈絡基準的一半；GPT-4o 從近乎完美的 99.3% 掉到 69.7%。

問題的核心是一個賣模型時不太會被強調的事實：廣告視窗（advertised context window）不等於有效脈絡（effective context）。 前者是廠商宣稱能塞多少，後者是模型還能維持可靠表現的實際範圍，兩者之間的落差很大。

所以這篇不是叫你等更大的視窗，而是談怎麼把手上的視窗用對。這篇文章會給你：

  • 「廣告視窗 vs 有效脈絡」的定義落差，以及 Chroma、NoLiMa、LOCA-bench 等一手研究的數據
  • context rot 為什麼是「沉默的失敗模式」，以及它在 coding agent 上如何被放大
  • 六種緩解方法的完整對比：原理、優劣、適用場景、成熟度、支撐數據
  • 依 session 長度、任務類型、預算給出的選型決策框架
  • 「長脈絡是三重稅」的成本視角：更慢、更貴、更笨，以及為什麼壓縮脈絡能一次處理三個問題

讀完這篇，你將能夠：

  1. 用「有效脈絡預算」而非「廣告視窗」做架構與成本決策
  2. 辨識 context rot 的早期警訊，而不是等它安靜地拖垮你的 agent
  3. 為你的 agent 選對緩解策略組合，並知道每個選擇背後的取捨與數據

TL;DR

  • 1M、200K 是「吞得下」，不是「消化得了」：Chroma 測的 18 個前沿模型全數隨輸入變長而退化。保守的做法是先把有效脈絡抓在廣告視窗的 25–50%，再用自己的任務實測。
  • Context rot 是沉默失敗：agent 不報錯，只會悄悄放棄，或過早給出不確定的答案；vanilla NIAH 因為有字面重疊而高估模型，不會警告你。
  • Coding agent 受害最深：搜尋、回溯、工具往返持續累積干擾項。LOCA-bench 裡，Claude-4.5-Opus 從 8K 的 96% 掉到 256K 的 14.7%。
  • 解法在 harness，不在等更大的視窗：RAG、compaction、sub-agent 隔離、context editing、memory tools、context awareness，能疊就疊。
  • 長脈絡是三重稅：更慢、更貴、更笨同時發生。實務上刪掉無關內容可縮減 50–70% 的脈絡，省錢和變準是同一件事。

核心概念：吞得下，不等於消化得了

廣告視窗 vs 有效脈絡

先把兩個詞釘死，因為全文都繞著它們轉：

  • Advertised context window（廣告視窗）：廠商宣稱可塞入的 token 上限，例如 200K、1M。它回答的是「能不能吃下去」。
  • Effective context（有效脈絡）：模型還能維持可靠表現的 token 範圍。它回答的是「吃下去還能不能好好消化」。

打個比方：廣告視窗像餐廳招牌上的「吃到飽」，有效脈絡是你的胃真正能舒服消化的量。招牌沒騙你，你確實可以一直夾；但夾到第十盤之後，你嚐不出味道，也記不得吃過什麼。模型也一樣：token 塞得越滿，分到每個 token 上的注意力就越稀薄。

為什麼會腐化：四個機制

1. 注意力是二次方成本，也是有限資源。 Anthropic 指出，在 transformer 架構下，n 個 token 會產生 n² 組兩兩關係（pairwise relationships），注意力因此被稀釋；加上模型的訓練資料分布偏向較短的序列，對超長脈絡本來就訓練不足。他們用「attention budget（注意力預算）」來比喻：就像人類有限的工作記憶，每多一個 token 就消耗一分預算。

2. Lost in the Middle（中段遺失）。 放在長 prompt 開頭與結尾的資訊最容易被取回，埋在中段的事實可能整個被漏掉，形成一條 U 形的位置效應曲線（Liu et al., TACL 2024）。

3. 語意相似度越低，退化越快。 當「問題」與「答案」之間的字面或語意重疊越少，模型越難在長脈絡裡定位答案，退化就越劇烈。Chroma 與 NoLiMa 都證實了這一點。這也是傳統 NIAH 會嚴重高估模型能力的原因：它的 needle 通常和問題有明顯的字面重疊，等於考試前先把答案畫好重點。

4. 干擾項與結構的反直覺效應。 Chroma 發現，即使只加入一個干擾項（distractor），表現就會下降，加到四個則累積惡化。更反直覺的是：把 haystack 打亂（shuffle），模型表現反而變好，代表「結構連貫」本身會傷害長脈絡的可靠度。這對 coding agent 是壞消息，因為 agent 的脈絡裡天生充滿相關但已經過時的內容，例如試錯走過的死路、被改掉的舊版程式碼。

為什麼你的 benchmark 沒警告你

這是整件事最麻煩的部分。Vanilla NIAH（Needle in a Haystack） 在長文裡埋一句話，再要模型取回，是最常被拿來宣傳「我們支援 1M context」的測試。問題是它有字面重疊，模型靠字面比對就能找到答案。於是多數模型在 vanilla NIAH 拿到近乎滿分，讓你以為長脈絡沒問題；換到更接近實戰的測試，例如 RULER（13 個任務，涵蓋檢索、多跳追蹤、聚合與問答）、NoLiMa（刻意移除字面重疊）、LOCA-bench（真實 agent 情境），退化就藏不住了。

說白了：你信錯了 benchmark，所以你以為安全。

關鍵術語表

術語英文說明
脈絡腐化Context Rot輸入越長、輸出品質越差的可量測退化現象
廣告視窗Advertised Context Window廠商宣稱的 token 上限（200K、1M）
有效脈絡Effective Context模型仍能維持可靠表現的實際 token 範圍
大海撈針NIAH長文埋一句話再取回的經典測試；有字面重疊時會高估能力
注意力預算Attention Budget把注意力視為隨 token 數增加而被攤薄的有限資源
中段遺失Lost in the Middle埋在中段的資訊最容易被漏掉的位置效應
干擾項Distractor與答案相關但不是正解、會誘導模型出錯的內容
脈絡工程Context Engineering策展與維護「最佳 token 集合」的一整套策略
壓縮Compaction接近上限時把對話歷史摘要壓縮，保留關鍵決策
子代理隔離Sub-agent Isolation讓子代理各自處理細節，只回傳 1–2k token 的摘要
脈絡編輯Context Editing / Pruning主動刪除已過時或冗餘的工具輸出與內容
harnessHarness / Scaffold包住模型的外層工程系統（狀態、記憶、流程控制）

方法對比：在 harness 層對抗腐化的六種手段

先講結論：解法在 harness 層（工程），不在等更大的模型視窗。 下面六種方法多半可以疊加使用。每一種我都用同一組維度拆解：原理、優勢、劣勢、適用場景、成熟度、支撐數據。

RAG / Just-in-time 檢索

原理簡述：不預載一切，只在當下需要時，把少量相關內容檢索進脈絡，讓 active context 一直停在有效區間內。資料的重量留在外部索引，模型只拿它此刻用得到的那一小部分。

優勢：把脈絡長度和知識庫大小脫鉤。知識庫再大，進到脈絡的都只有一小撮，自然避開 rot；成本也低。

劣勢：要維護檢索管線，chunking 與 embedding 的品質直接決定成敗；檢索漏掉關鍵片段，模型就在資訊不全的情況下硬答。

適用場景：大型知識庫問答、企業內部文件、程式碼庫定位，也就是知識量大、查詢稀疏的情境。

成熟度：高，已是生產成熟的做法。

支撐數據：Chroma 用 LongMemEval 比較，聚焦的 prompt（約 300 tokens）明顯優於完整的 prompt（約 113,000 tokens），Claude 系列的落差最明顯。這不是直接測 RAG，但它說明了 RAG 背後的前提：少即是多，在數據上成立。

Compaction（壓縮 / 摘要）

原理簡述：當脈絡接近上限時，把對話歷史摘要成一段更短的表述，保留關鍵決策與狀態，丟掉過程中的雜訊，讓長 session 可以一直延續下去。

優勢：長時間 session 幾乎可以無限延續，而且同時降低成本與 rot，這是它最被低估的價值。

劣勢：摘要一定會遺失細節。Anthropic 也明白指出，壓縮不一定能把清楚的指令傳給下一棒。壓縮時機也難調：太早會丟資訊，太晚則已經腐化。

適用場景：長對話、長時間運行的 coding agent session。

成熟度：高。Claude Code、Codex CLI、OpenCode 都已內建 auto-compaction。

支撐數據：arXiv:2606.29718 在 deep search 任務上比較了 7 種脈絡管理方法，分成 Compaction、Trimming、Isolation 三類。成本與抑制 rot 之間最平衡的是 Trimming 類裡的 keep-latest（含摘要）：只保留最新的內容，並附上摘要。它把 Qwen3.5-397B-A17B 的整體準確率從 baseline 的 54.4% 拉到 62.9%。嚴格說，它在論文裡不歸在 Compaction 類，但做法同樣是用摘要取代舊歷史，所以放在這裡一起看。成本面，實務整理指出，逐字刪除無關行的壓縮可縮減 50–70% 的脈絡（Codex 知識庫，屬實務數據，不是論文結論）。

Sub-agent Isolation（子代理隔離）

原理簡述：把探索、搜尋這類會產生大量雜訊的工作交給子代理。子代理在自己獨立的脈絡裡翻箱倒櫃，只回傳 1–2k token 的摘要給主代理，主代理的脈絡始終保持乾淨。

優勢：干擾項被關在子代理的脈絡裡，主代理不受污染；天然支援平行任務。

劣勢：協調複雜，跨代理的狀態一致性難維護；摘要品質是瓶頸，子代理漏講的，主代理永遠不會知道。

適用場景：多步驟研究、大規模 codebase 探索、平行任務。

成熟度：中高，主流 agent 框架都支援。

支撐數據：這一項沒有像 LOCA-bench 那樣的單獨增益數字。arXiv:2606.29718 把 Isolation（用 FoldAgent 做子代理委派）列為三大類方法之一，但在它的比較裡，成本與抑制 rot 最平衡的是前面提到的 keep-latest（含摘要）。所以 sub-agent 隔離的價值主要在架構面：讓主代理的脈絡不被探索雜訊污染。

Context Editing / Pruning（脈絡編輯）

原理簡述：主動、逐字地刪掉脈絡裡已經過時或冗餘的工具輸出，例如回溯之後那條死路的完整 grep 結果、已經被覆蓋的舊檔案內容，在污染累積成 rot 之前先清掉。

優勢：逐字刪除無關行可縮減 50–70% 的脈絡，同時降低 rot 與成本；比整段摘要更精細，不必把關鍵決策一起壓掉。

劣勢：有誤刪風險；需要一套判斷「什麼算過時」的邏輯，判斷錯了，就會刪掉之後還需要的東西。

適用場景：累積大量工具輸出的 agent 迴圈、回溯之後的清理。

成熟度：中，工具化還在進行中。

支撐數據：與 compaction 共用 50–70% 縮減率的實務數據。概念上，它直接對應 Chroma 的發現：單一干擾項就會拉低表現，那主動移除干擾項就是對症下藥。

Memory Tools / 結構化筆記

原理簡述：把狀態外置到檔案，例如 NOTES.md、progress 檔、feature list JSON，讓 agent 跨回合、跨 session 讀寫持久記憶，而不必把所有狀態都塞回 active context。

優勢：狀態持久，而且不佔用 active context；支援跨 session 交接與回溯，是長專案的救命稻草。

劣勢：需要 agent 有紀律地讀寫；讀回時如果一次全部載入，仍然可能塞爆脈絡，讓外置記憶又變回 rot 的來源。

適用場景：跨 session 的長專案、需要回溯或交接的工作。

成熟度：中高。

支撐數據：LOCA-bench 在 128K 處，Memory Tools 讓 GPT-5.2-Medium 從 38.7% 提升到 44%（+5.3 分）。

Context Awareness（剩餘預算回饋）

原理簡述：由 harness 主動告訴 agent「你還剩多少 token 預算」，讓它自己決定該壓縮、該收尾，還是該把細節丟給子代理，而不是在不知情的狀況下一路撐爆。

優勢：讓 agent 從被動撐爆，變成主動管理預算。

劣勢：需要 harness 提供這個訊號；模型仍可能誤判剩餘預算，做出不恰當的決策。

適用場景：任何長時間運行的 agent。

成熟度：中。

支撐數據：LOCA-bench 在 128K 處，Context Awareness 讓 Gemini-3-Flash 從 21.3% 提升到 33.3%（+12 分），在 LOCA-bench 列出的三種手段裡，增益僅次於下面的 programmatic tool calling。

額外一招：Programmatic Tool Calling

LOCA-bench 還有一個結果值得單獨提：Programmatic Tool Calling（程式化工具呼叫）在 128K 處讓 DeepSeek 從 10.7% 提升到 24%（+13.3 分），而且同時縮短了 trajectory 長度。用更少的往返做更多事，等於從源頭少產生雜訊。這是「不只緩解，還從根源減量」的思路，適合環境探索型、工具往返密集的 agent。代價是需要工具介面支援，開發成本較高，目前也還在新興階段。

對比矩陣總表

方法原理一句話主要優勢主要劣勢適用場景成熟度代表數據
RAG / JIT 檢索只取當下需要的少量內容脈絡與知識庫脫鉤、成本低檢索品質決定成敗、可能漏檢大知識庫、稀疏查詢高約 300 token 的聚焦 prompt 明顯勝過約 113K 的完整 prompt（Chroma）
Compaction接近上限時摘要壓縮歷史近乎無限延續、省錢又降 rot摘要遺失細節、時機難調長 session、長對話高keep-latest（含摘要）54.4% → 62.9%（2606.29718）；縮減 50–70%（實務）
Sub-agent 隔離雜訊交給子代理、只收摘要主脈絡乾淨、支援平行協調複雜、摘要品質是瓶頸大規模探索、平行任務中高主代理只收 1–2k token 摘要（設計模式）
Context Editing逐字刪除過時輸出精細、降 rot 又降成本誤刪風險工具輸出爆量、回溯清理中縮減 50–70%（實務）
Memory Tools狀態外置到檔案持久、支援跨 session需要紀律、讀回可能塞爆跨 session 長專案中高+5.3 分（LOCA-bench）
Context Awareness回饋剩餘 token 預算主動管理需要 harness 訊號、可能誤判任何長 agent中+12 分（LOCA-bench）
（反面）等更大視窗開發者零改動無治標不治本、成本與延遲隨輸入上升反面教材無有效脈絡仍遠低於廣告值

決策框架：依 session 長度、任務類型與預算選組合

沒有「最好的方法」，只有「最適合這個 session 的組合」。用三個維度來選：session 長度、任務類型、預算。

決策樹

你的 agent session 會跑多久、累積多少脈絡？
│
├─ 短（單次任務、脈絡穩定在有效區內）
│   → 先別過度工程。用對的 benchmark 驗證有效區間即可。
│
├─ 中（會累積工具輸出，但在單一 session 內結束）
│   ├─ 知識量大、查詢稀疏  → RAG / just-in-time 檢索為主
│   ├─ 工具往返密集        → Programmatic Tool Calling + Context Editing
│   └─ 探索型、雜訊多      → Sub-agent 隔離（主代理只收摘要）
│
└─ 長（長時間單一任務、跨 session）
    ├─ 基礎盤：Compaction + Context Awareness（讓它主動管理預算）
    ├─ 需要回溯、交接      → 疊加 Memory Tools（狀態外置）
    └─ 追求正確率、可離線  → 再疊 rot-aware rejection sampling（平均 +2.6% 到 4.9%）

預算是硬約束？→ Compaction 優先：它同時省錢又降 rot（見下文「長脈絡的三重稅」）

這裡提到的 rot-aware rejection sampling（腐化感知取樣） 來自 arXiv:2606.29718：對多條 trajectory 事後過濾掉已經腐化的樣本，跨三種聚合方法平均提升 2.6% 到 4.9%。代價是要多次取樣、推論成本上升，目前還在研究階段，所以只建議用在能離線批次跑的場景。

三個場景

場景 A：企業內部文件問答 bot

  • 環境：知識庫有 10 萬份文件，使用者查詢分散，單次查詢只會碰到少數文件。
  • 需求：答得準、成本可控、不要亂答。
  • 推薦：RAG / just-in-time 檢索為主，脈絡裡永遠只放檢索到的少量片段。
  • 理由：知識量大但查詢稀疏，把一切塞進 1M 視窗只會招來干擾項與中段遺失；Chroma 的數據也顯示，聚焦的 prompt 明顯勝過完整的 prompt。

場景 B：長時間運行的 coding agent

  • 環境：一個要跑好幾個小時、讀幾十個檔案、反覆試錯的重構任務。
  • 需求：跑到後面別忘記早上的決定，別重複造輪子。
  • 推薦：Compaction + Context Awareness + Memory Tools 三件套；探索階段搭配 Sub-agent 隔離。
  • 理由：這正是 context rot 的重災區（下一節詳談），單一手段不夠，要多層防線；關鍵狀態外置到 progress 檔，才能在每次壓縮後存活。

場景 C：追求最高正確率的離線 deep search

  • 環境：可以批次跑、可以多次取樣，對延遲不敏感，對正確率極敏感。
  • 需求：把準確率榨到最高。
  • 推薦：用 keep-latest（含摘要） 打底，再疊 rot-aware rejection sampling。
  • 理由：arXiv:2606.29718 顯示 keep-latest（含摘要）把準確率從 54.4% 拉到 62.9%，rejection sampling 再平均多 2.6% 到 4.9%；只有離線場景付得起多次取樣的成本。

實戰最佳實踐：為什麼 coding agent 是重災區

常見錯誤 → 正確做法

錯誤 1：把廣告視窗當成可用容量來做架構決策，把 1M 當 1M 用。
→ 正確：把「有效脈絡預算」當成硬約束。保守起見抓廣告值的 25–50%。這是實務經驗值，不是論文結論：以 RULER 交叉檢核的第三方歸納約為廣告值的 50–65%，實務社群更保守，抓 25–30%。更重要的是用你自己的任務實測，別直接套通用經驗值。

錯誤 2：只看 vanilla NIAH，就相信長脈絡沒問題。
→ 正確：改用 RULER、NoLiMa、LOCA-bench 這類接近真實 agent 情境的 benchmark 做選型。NoLiMa 移除字面重疊後，GPT-4o 從 99.3% 掉到 69.7%，這件事 vanilla NIAH 不會告訴你。

錯誤 3：「把所有檔案都塞進去，讓模型自己找」。
→ 正確：just-in-time 優於預載一切。干擾項與中段遺失會讓脈絡越塞越差，Chroma 已經證實，單一干擾項就會拉低表現。

錯誤 4：以為 context rot 會報錯。
→ 正確：它是沉默失敗。模型會安靜地放棄，或過早給出不確定的答案，不會 raise exception。把 trajectory 長度，以及「放棄、給不確定答案」的比例拿來監控，當作 rot 的早期警訊。

錯誤 5：忽略成本與延遲。
→ 正確：把長脈絡的三種代價一起算進來，下一節會細談。

coding agent 為什麼特別慘

長時間運行的 coding agent 會透過四條途徑持續累積脈絡雜訊，把自己推出有效脈絡區：

  1. 搜尋與探索：grep、讀檔、列目錄的原始輸出大量灌進脈絡。
  2. 回溯（backtracking）：試錯走過的死路仍然留在歷史裡，變成干擾項，正好呼應 Chroma「單一干擾項就會傷害表現」的發現。
  3. 工具往返累積：每次 tool call 的完整輸出層層堆疊，trajectory 越長，越逼近「放棄或給不確定答案」的臨界點。
  4. 跨 session 交接：沒有外置記憶時，狀態只能塞回脈絡，造成二次污染。

這不是理論。 LOCA-bench 用可控的環境狀態，把 agent 的脈絡幾乎無限地拉長，同時保持任務語意不變，測的是探索、執行、抽取、決策這類真實 agent 情境，而不只是單步檢索。它量到的崩塌是這樣的：

模型8K128K256K退化幅度
Claude-4.5-Opus96%34%14.7%−81.3 分
GPT-5.2-Medium72%38.7%21.3%−50.7 分
DeepSeek-V3.278.7%10.7%6.7%−72 分

前沿模型在長脈絡下的準確率約為開源模型的 2 到 3 倍，但仍然全面崩塌。arXiv:2606.29718 則用 GLM-4.7、GLM-5.0、Qwen3.5-397B-A17B、MiniMax-2.5 四個開源旗艦模型，在 BrowseComp、BrowseComp-Plus、xbench-DeepSearch 三個 deep search benchmark 上進一步指出：脈絡一長，模型的兩大失敗模式是直接放棄，或過早給出不確定的答案；trajectory 越長，這兩類錯誤越佔主導。這就是「沉默失敗」的實證。

真實的 harness 怎麼對抗？Claude Code、Codex CLI、OpenCode 都內建 auto-compaction 與 prompt caching，但 Anthropic 明白指出，單靠壓縮不夠，還需要外部 scaffolding：init.sh、progress 檔、feature list JSON，以及用 git 歷史做狀態回滾。Meta 與 Harvard 的 Confucius Code Agent（arXiv:2512.10398）則用「階層式工作記憶（hierarchical working memory）」把 trajectory 切成多個 scope 逐步摘要，再加上持久化筆記做跨 session 學習，是「用 harness 對抗 rot」的工業級範例。

長脈絡的三重稅：更慢、更貴、更笨

前面講的都是「笨」。但長脈絡的代價不只一種，這三種代價是同時發生的。以下成本與延遲數字來自 Morph 與 Codex 知識庫的實務整理，屬於實務數據而非論文結論，請當作量級參考。

更貴：token 成本隨 input 線性成長。在 coding agent 上，單一任務累積的 input 可以達到 400K 到 2M tokens；重度自動化的情況下，每位工程師每月的花費可以到 500 到 2,000 美元。

更慢：在 5 分鐘 cache TTL 的條件下，500K 脈絡的冷啟動要 30 秒以上；外推到 1M 脈絡，會到 60 到 90 秒。

更笨：也就是前面 Chroma、NoLiMa、LOCA-bench 一路量到的退化。

反過來看，這也是好消息：處理其中一項，另外兩項會一起改善。 實務整理指出，逐字刪除無關行可縮減 50–70% 的脈絡；把一份 2M token 的 feature profile 壓到 800K，Sonnet 的單次成本從 2.28 美元往 1.10 美元降，同時降低 context rot 造成的失敗率。省錢和變準，在這裡是同一件事。

效能調優：三個可以立刻做的動作

  1. 設一條「有效脈絡水位線」，過線就自動觸發壓縮。 別等撞到廣告上限才處理。水位線設在你實測出來的有效脈絡範圍內；還沒實測之前，先用 25–50% 這個保守範圍。觸發後的做法可以參考 keep-latest（含摘要），它在 arXiv:2606.29718 的比較中是成本與抑制 rot 最平衡的方法。
  2. 回溯之後立刻做 context editing。 每當 agent 走進死路、退回來，就主動刪掉那條死路的完整工具輸出，它現在只是純粹的干擾項。逐字刪除無關行可縮減 50–70% 的脈絡。
  3. 把探索外包給 sub-agent，只收 1–2k token 的摘要。 大型 codebase 的定位、掃描這類「雜訊高、結論密度低」的動作，讓子代理在隔離的脈絡裡做完，主代理只拿結論。可以再搭配 programmatic tool calling 縮短 trajectory：它在 LOCA-bench 上帶來 +13.3 分，同時減少往返次數。

工具與資源推薦

工具 / 資源一句話描述連結
Chroma Context Rot 報告18 個模型全數退化的一手實測，理解問題的起點trychroma.com
NVIDIA RULER13 個任務的長脈絡壓力測試，取代 vanilla NIAH 做選型GitHub
NoLiMa移除字面重疊的長脈絡評測，逼模型靠潛在關聯推理arXiv
LOCA-bench可控、極端脈絡成長下的 agent benchmark 與程式碼GitHub
GAIR-NLP/ContextRotdeep search 場景下 7 種脈絡管理方法的實作GitHub
Anthropic：Effective context engineering for AI agents注意力預算與 context engineering 的一手實務anthropic.com
Anthropic：Effective harnesses for long-running agents長時間運行 agent 的 harness 設計anthropic.com

總結與展望

一表看完所有方法

方法什麼時候用成熟度一句話取捨
RAG / JIT 檢索知識量大、查詢稀疏高檢索品質就是天花板
Compaction長 session（幾乎都該用）高省錢又降 rot，代價是細節遺失
Sub-agent 隔離大規模探索、平行任務中高主脈絡乾淨，代價是協調複雜
Context Editing工具輸出爆量、回溯清理中精細降 rot，代價是誤刪風險
Memory Tools跨 session 長專案中高狀態持久，代價是需要紀律
Context Awareness任何長時間運行的 agent中讓 agent 主動管理預算，代價是需要 harness 提供訊號

按讀者類型的推薦

  • AI Engineer（剛把 agent 上線）：先做對兩件事：用 RULER 或 NoLiMa 驗證你的有效脈絡區間，並打開 compaction。這兩步的投報率最高。
  • Architect / Tech Lead（做選型與預算）：把「有效脈絡先抓廣告值的 25–50%，再用實測校正」寫進容量規劃與成本模型；用上面的決策樹替不同任務類型指定緩解組合。
  • 決策者（算 ROI）：記住三重稅。實務數據顯示，把脈絡從 2M 壓到 800K，Sonnet 單次成本從 2.28 美元往 1.10 美元降，同時降低 rot 造成的失敗率。省錢與變準是同一筆投資。

未來趨勢

  1. rot-aware 的做法會從研究走向生產：rot-aware rejection sampling 目前還在研究階段，但「偵測並處理已經腐化的 trajectory」這個思路，很可能會被做進 agent 框架裡。
  2. benchmark 會從 vanilla NIAH 移往貼近 agent 的評測，例如 RULER、NoLiMa、LOCA-bench；單看「1M token」的宣傳數字，會越來越說服不了人。
  3. harness 會成為競爭護城河：模型能力逐漸趨同之後，誰的 context engineering 做得好，誰的 agent 才跑得久、跑得準。

今天就能開始的四步

  1. 挑一個你正在跑的長 session agent，量它的 trajectory 長度，以及「放棄、給不確定答案」的比例。
  2. 用 RULER 或 NoLiMa 測一次你正在用的模型，找出真正的有效脈絡區間。
  3. 打開 compaction，把觸發水位線設在你量到的有效區間內；還沒量之前，先用 25–50% 的保守範圍。
  4. 把關鍵狀態外置到一個 progress 檔，讓它能在每次壓縮後存活。

金句

「1M token 是餐廳的『吃到飽』招牌，有效脈絡才是你的胃真正消化得了的量。」

「Context rot 不會 raise exception，它只會讓你的 agent 安靜地放棄，或丟給你一個沒有結論的答案。」

「別再問模型的視窗有多大，先問你的 harness 能把脈絡管得多乾淨。」

「省錢與變準是同一件事：壓縮掉的每一段雜訊，既是成本，也是 rot。」

延伸思考

  1. 你目前是用「廣告視窗」還是「有效脈絡」在做架構與成本決策？如果現在把可用容量砍到廣告值的 30%，你的 agent 還跑得動嗎？
  2. 你的 coding agent 上一次「跑到後面突然變笨」，你當時歸咎於什麼？是模型不夠強，還是你的 harness 讓脈絡腐化了？
  3. 如果 context rot 是沉默失敗，你現在有任何一個訊號，能在它發生時主動告訴你嗎？還是只能等使用者回報「怎麼變笨了」？

FAQ 常見問題

Q1：把模型換成 1M context 的版本，是不是就不用管 context rot 了？
不會。有效脈絡仍遠低於廣告值：Chroma 測的 18 個前沿模型全數隨長度退化，第三方以 RULER 歸納的結果，1M 模型實際可靠的範圍大約只有 500K 到 650K（實務歸納，不是論文結論）。而且成本與延遲會隨 input 上升。換更大的視窗是治標不治本，真正的槓桿在 harness 層。

Q2：我的 NIAH 測試都近乎滿分，是不是代表長脈絡沒問題？
很可能是假象。Vanilla NIAH 有字面重疊，會嚴重高估模型能力。改用移除字面重疊的 NoLiMa（GPT-4o 在這裡從 99.3% 掉到 69.7%），或多任務的 RULER 再測一次，你大概會看到不一樣的結果。

Q3：compaction 的摘要會遺失細節，會不會反而害到我？
有這個風險，Anthropic 也明白指出，壓縮不一定能把清楚的指令傳給下一棒。但從 arXiv:2606.29718 的結果看，keep-latest（含摘要）的淨效果是正的（54.4% → 62.9%），丟掉雜訊的好處大過遺失細節的代價。關鍵是保留「決策與狀態」、丟掉「過程輸出」，並搭配 memory tools 把關鍵狀態外置。

Q4：這些緩解方法要全部都上嗎？成本會不會太高？
不用全上，依決策框架按 session 長度、任務類型、預算挑組合。而且方向要反過來想：compaction 和 context editing 本身就降低成本，實務上可縮減 50–70% 的脈絡。多數情況下，「壓縮＋context awareness」就是很好的起手式。

Q5：怎麼知道我的 agent 正在 context rot，而不是任務本身太難？
看兩個訊號。一是 trajectory 長度：腐化通常隨脈絡累積出現。二是失敗型態：如果模型從「會做」變成「放棄」，或給出模稜兩可、不確定的答案，就很可能是 rot，這正是 arXiv:2606.29718 指出的兩大失敗模式。把同一個任務用短脈絡重跑一次，就能對照確認。

Q6：選模型時，應該看哪個 benchmark？
別只看 vanilla NIAH。RULER 用 13 個任務測模型隨序列變長還能不能維持表現；NoLiMa 移除字面重疊，逼模型靠潛在關聯定位答案；LOCA-bench 則在真實 agent 情境下把脈絡拉長。三者都比 vanilla NIAH 更接近你在生產環境會遇到的狀況。

Q7：Chroma 說把文件打亂反而表現更好，那我應該把文件打亂嗎？
不是這個意思。這個發現的重點是：結構連貫的長脈絡，並不保證模型讀得更可靠。它提醒你，別以為「整理得很好的一大包文件」就可以放心整包塞進去；真正有效的做法，仍然是減少進入脈絡的內容。

Q8：compaction 和 context editing 差在哪？
compaction 是把一段歷史改寫成摘要，context editing 是逐字刪掉已經過時的內容。前者適合讓長 session 延續下去，代價是摘要會遺失細節；後者更精細，代價是可能誤刪之後還需要的東西。兩者都能同時降低 rot 與成本，實務上常一起用。

參考資料

一手來源（論文、研究報告、工程部落格）

  1. Chroma Research — Context Rot: How Increasing Input Tokens Impacts LLM Performance（2025-07；18 個前沿模型、194,480 次 LLM 呼叫）

  2. Modarressi et al. — NoLiMa: Long-Context Evaluation Beyond Literal Matching（arXiv:2502.05167，ICML 2025，Adobe Research）

  3. Anthropic — Effective context engineering for AI agents（2025-09-29）

  4. Anthropic — Effective harnesses for long-running agents（2025-09-29）

  5. Xia et al. — Diagnosing and Mitigating Context Rot in Long-horizon Search（arXiv:2606.29718）

  6. Zeng, Huang, He — LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth（arXiv:2602.07962）

  7. Confucius Code Agent（arXiv:2512.10398，Meta / Harvard）

  8. NVIDIA — RULER

  9. Liu et al. — Lost in the Middle: How Language Models Use Long Contexts（arXiv:2307.03172，TACL 2024）

實務歸納（文中已標為實務數據）

  1. Acing AI — Effective Context Length（以 RULER 歸納的 50–65% 有效範圍）
  2. Morph — AI Coding Costs 2026（token 成本與每月花費數字）
  3. Codex 知識庫 — Context Compaction Deep Dive（逐字刪除無關行可縮減 50–70% 脈絡）

最後更新：2026年10月24日