如果你用 Claude Code、Cursor、Devin，或任何一個會跑超過幾個回合的程式代理來出貨，那麼你最該在意的變數並不是底層模型。真正決定成敗的是 每一步最後究竟有哪些內容留在上下文視窗裡。2025–2026 年的前沿研究，其實已經悄悄地圍繞這件事重新洗牌。這篇文章就是把那些真正重要的論文、它們記錄下來的失敗模式，以及能撐過生產環境的模式，整理成一份綜述。

我不會在這裡去抄基準（benchmark）數字。基準數字會過時；論證的形狀不會。讀完這篇之後，你該帶走的是一個心智模型——為什麼長上下文會壞掉——以及一小組你下週一就可以拿來用的上下文塑形手法。

一切論證的錨點

2025 年 7 月，Chroma Research 發表了一份技術報告，標題是 Context Rot: How Increasing Input Tokens Impacts LLM Performance。這份報告在刻意保持任務不變、只改變輸入長度的條件下，測試了 18 個前沿大語言模型——Claude 4、GPT-4.1、Gemini 2.5、Qwen3。結論是：每一個模型都會隨著上下文變長而退化，即使是相同模型在短輸入下能完美處理的任務也不例外。不是「某些」模型，也不是「大部分」模型，而是全部 18 個。

這是接下來所有論述的實證錨點。一個 200K token 的視窗，並不代表 200K 個可用 token；一個百萬 token 的視窗，也不代表百萬個可用 token。容量與可用容量會分岔，而且分岔可以被量測到，並且遠低於名義上的上限。從 2025 年末到 2026 年初的獨立復現，也在更新的模型與更大的視窗上確認了這個規律。

對程式代理來說，這件事比純聊天更嚴重，因為程式代理會用非常激進的方式累積上下文：它讀的每個檔案、每個工具回傳結果、每一次失敗的測試、每一段 diff 都要吃進來。一個長會期很輕易就會逼近 100K–500K token，即使最後真正需要的答案其實只佔其中一小部分。所以真正務實的問題不是「視窗有多大」，而是「隨著會期變長，我要怎麼讓訊號雜訊比維持在高檔」。

長上下文為什麼會壞：三個相互重疊的機制

文獻大致收斂到三個機制，每一個都有自己的論文脈絡。

注意力稀釋（attention dilution）。 自注意力分數本質上是一個機率分佈——它們的總和為 1。在 10K token 的情境下，每個 token 平均能分到一塊有意義的份額；到了 1M token，每個 token 就只剩百萬分之一。就算訊號沒變弱，雜訊的底線也會隨著長度上升。這就是 context rot 背後的機制敘事，也是為什麼「模型好像沒注意到」某個關鍵的早期指示，並不是幻覺，而是一個根本的注意力預算問題。

Lost in the middle。 Liu 等人 2023 年的論文 Lost in the Middle: How Language Models Use Long Contexts 確立了：模型從上下文的開頭與結尾抓取資訊時是可靠的，但從中間抓取時表現很差。表現曲線呈 U 型。2026 年的一篇新論文 Lost in the Middle at Birth: An Exact Theory of Transformer Position Bias 更進一步證明：這條 U 型曲線是因果遮罩（causal masking）加上殘差連接（residual connections）本身就內建的——它在初始化的瞬間就出現，還沒經過任何訓練、也還沒有 RoPE 編碼作用。換句話說：這不是靠 scaling 就能修掉的 bug，而是這個架構本身的拓撲性質。

干擾項的干擾（distractor interference）。 Chroma 的報告與後續研究都顯示：加入語義相似的干擾項——那些看起來相關、實際上不相關的內容——會以非線性的方式劣化表現。四個相似干擾項造成的傷害，遠超過單一干擾項的四倍。反直覺的是，結構良好、內容連貫的文件其實比打散重排的還糟，因為連貫性提供了看起來很合理、卻是錯誤的路徑。對程式代理來說，這是最危險的機制：你的程式碼庫裡到處是近似重複的內容（相似的 helper、同個函式的不同版本、被棄用的變體），這些東西會跟正確的那一段互搶模型的注意力。

大家最先嘗試的天真解法：把視窗做大

每一代模型出來都會帶著更大的視窗。Gemini 2.5 提供了 1M token；Llama 4 更宣稱到了 10M。天真的讀法是：把所有東西塞進去，讓模型自己分辨。這行不通，而且原因現在已經有很扎實的文獻紀錄。到了 2025 年末，每一個被量測過的前沿模型，在 256K 到 1M token 之間，處理困難任務時的檢索準確率都出現實質下滑。Claude Opus 保有最佳的長距離召回；即便如此，從 256K 到 1M，它在較難的基準上的準確率也跌了兩位數。GPT 與 Gemini 掉得更多。

結論並不是大視窗沒用。當你真的需要的時候——一次性文件分析、少見的評估任務、研究原型——大視窗極為好用。但如果你把它當成工程的替代品，那就危險了。要優化的指標不是容量，而是訊號密度。

目前正在互相競爭的上下文管理典範

代理該如何處理不斷成長的上下文，目前有四個典範在互相競爭。它們並不互斥；生產系統會把它們組合起來用。

1. Compaction（摘要壓縮）。 定期把較舊的回合替換成一段由 LLM 產生的摘要。這是 Cursor 與 OpenHands 的預設做法。它是有損的——細節是最先流失的——而且會引入自己的幻覺，因為摘要本身也是一次生成步驟。Compaction 可以緩解注意力稀釋，但代價是那些程式代理最需要的具體細節（變數名、行號、設定值）被犧牲掉。

2. Observation masking（觀察遮蔽）。 2025 年 12 月，JetBrains 的研究者在 NeurIPS Deep Learning for Code workshop 發表了 The Complexity Trap。他們的發現是：複雜的 LLM 摘要方法，實際上被一個非常簡單的技術打平甚至超越——那就是把舊的工具輸出替換成類似「前面 8 行為求簡潔已省略」的占位文字，同時完整保留代理的推理與動作歷史。觀察類 token 平均佔了一個 SWE-agent 回合的約 84%。遮蔽掉它們，可以把成本相對於「完全不做上下文管理」腰斬，而且在任務完成度上與 LLM 摘要打平，甚至略勝一籌。兩者結合又可以再省下約 10%。這件事的教訓是：業界一頭衝去做複雜壓縮，結果一個蠢到不行的簡單過濾器就能拿走絕大部分收益。

3. 子代理隔離（sub-agent isolation）。 Anthropic 官方的子代理指南 把這個論證講得非常直白：讓每個專職任務擁有自己乾淨的上下文視窗。主代理負責統籌；子代理（code-reviewer、debugger、planner）在乾淨的上下文中執行、回傳一份壓縮後的結果，然後退出。Anthropic 自己的多代理研究系統報告指出：「token 使用量解釋了成果品質 80% 的變異」——換句話說，每個代理看到什麼的架構，比它是哪個代理更重要。這也是 Claude Code 憑藉具名子代理與獨立上下文視窗，握有實質架構優勢的地方。

4. 把上下文當成可呼叫的工具。 北航等單位的 Context as a Tool (CAT)（ACL 2026 Findings）主張：上下文管理不該只是外部啟發式規則，而應該是代理可以規劃、可以呼叫的一等公民動作——就像 edit_file 或 run_tests 一樣。他們的 SWE-Compressor 在 SWE-Bench Verified 上達到 57.6%，同時把上下文控制在有限的預算內。核心想法是：教模型什麼時候要壓縮，而不只是怎麼壓縮。

一個容易被忽略的第五典範：把程式代理當成長上下文處理器

Coding Agents are Effective Long-Context Processors（Cao et al., 2026）把慣常的問題框架整個翻轉。他們不去問「怎麼把更多 token 塞進注意力」，而是問：如果讓代理把長上下文外化到檔案系統，並用 grep、awk、Python 去操縱它，會怎麼樣？結果：現成的前沿程式代理在跨越基準的表現上，平均超越已發表的 SOTA 17.3%，且處理的上下文可以達到三兆個 token。它的機制是：對原生工具的熟練加上對檔案系統的熟悉，能讓代理在一個原本無法駕馭的語料庫上，逐次建構出小而聚焦的視野。這正是過去一年在 Claude Code 進階使用者之間流傳的「少放進上下文、多放在檔案裡」派系，一次實證上的平反。

再結合子代理隔離，這給了我們一個可運作的原則：檔案系統就是你的延伸上下文視窗。凡是代理可以 grep 出來的東西，都是你不用付出注意力代價就能取得的上下文。

一個既省錢、又間接減緩 rot 的做法：prompt caching

Anthropic 的 prompt caching 於 2024 年 12 月正式全面上線，目前已被廣泛採用。機制如下：用 cache_control 區塊標記前綴；後續請求只要共用該前綴，就以基礎輸入價格的 10% 計費（預設 TTL 5 分鐘，另有 1 小時可用但寫入成本較高）。一個常被引用的例子：一份 100K token 的書本快取提示，能把 time-to-first-token 從 11.5 秒降到 2.4 秒——延遲減少 79%，快取 token 上的成本最多可省 90%。

2026 年 1 月 PwC 的評估報告 Don't Break the Cache 在 DeepResearchBench 上，跨 OpenAI、Anthropic、Google 三家測試了三種快取策略。關鍵發現：天真地把整個上下文都拿去做快取，反而可能增加延遲，因為位在提示尾端的動態工具結果會不斷打破快取邊界。策略性的擺放位置——系統提示放最前、靜態上下文其次、快取斷點放在穩定前綴的末端、動態工具輸出放在斷點之後——可以將成本降低 45–80%，TTFT 降低 13–31%。

Prompt caching 並不會直接修好 context rot。但有兩個次級效應很重要：(a) 使用大型上下文的經濟懲罰大幅下降，意味著你可以在每次有意義的動作時重播一份完整乾淨的上下文，而不是跨回合累積一份髒掉的上下文；(b) 快取命中率的設計會強迫你把提示結構化為「[穩定、可快取的前綴] + [很小的動態尾巴]」，而這正是能把重要資訊放在 U 型注意力曲線兩端的結構。

六個能撐過生產環境的模式

理論可以落地成一小組具體動作。以下大致按「單位努力換取的效益」由高到低排列：

1. 把關鍵指令同時放在提示的兩端

Agrawal 等人（EMNLP 2024） 的 R&R（reprompting）研究顯示：在長文件中週期性重複任務指令，可以讓 GPT-4 Turbo 與 Claude-2.1 的 QA 準確率提升約 16 個百分點。對程式代理來說，這個原則的推廣版本是：把最重要的約束同時放進 CLAUDE.md（上下文的開頭）和當前使用者回合（上下文的結尾）。不要指望模型還記得 40 個回合以前講過的約束。U 型曲線是不留情的。

2. 把狀態外化到檔案系統

用檔案系統做為持久記憶：TODO.md、DECISIONS.md、一個放子任務筆記的暫存資料夾。這正是 Coding Agents are Effective Long-Context Processors 所驗證的機制。這樣代理的上下文視窗裡就只放指標，不放內容本身。當某件事真的重要時，代理會重新去讀一個小而聚焦的檔案，而不是靠「記得」。這也是你能撐過代理重啟、或不小心觸發 compaction 的方法。

3. 設計子代理邊界時，要考量上下文量，不只考量技能

直覺上大家會按角色來拆：planner、coder、reviewer。但也要按「這個任務有多吵」來拆。任何會產生大量工具輸出的任務——一次範圍很廣的 grep、一次 find、一次依賴掃描、一份很長的測試日誌——都是可以獨立成一個子代理上下文的候選。主代理只拿回一份五行的綜整結果，不必看到原始輸出。這裡正是 JetBrains 論文那個「84% 觀察類 token」的統計最有意義的地方：這些觀察內容應該住在子代理的上下文裡，而不是統籌者的上下文裡。

4. 拼接之前先重新排序（rerank）

對於任何檢索步驟（在程式碼庫、文件、過往對話上做語意搜尋），檢索完後要重新排序，讓相關度最高的區塊落在上下文區塊的兩端——最前面與最後面。向量搜尋的距離排序不等於位置重要性排序。以 U 型曲線的行為來看，這是一個做起來很直接、效益卻超乎比例的修正。

5. 快取穩定的部分，動態化尾端

把提示結構化：可快取的前綴依序是系統提示 → 工具定義 → CLAUDE.md → 前次決策摘要 → 快取斷點。所有會變動的內容（當前檔案 diff、最新的工具輸出、當前使用者訊息）都放在斷點之後。這正是 Don't Break the Cache 評估認定的、在各家供應商上都能穩定勝出的模式。額外好處：它會逼你發現什麼時候你的「靜態」上下文其實正在變動（這是一個很常見、會默默把快取命中率殺掉的 bug）。

6. 寧可重播乾淨上下文，也不要累積髒上下文

當成本允許時，讓代理在每次有意義的動作前從乾淨狀態重啟對話，只餵給它最小狀態檔案、當前任務、工具定義。跑很久的會期會累積錯誤、矛盾與過時的推理。從持久狀態做一次便宜的重播，往往比一次聰明的 compaction 更好。Prompt caching 讓這件事在經濟上變得可行，這是 18 個月前還做不到的事。

誠實面對邊界案例

領域還沒有完全底定，這裡有幾個誠實的但書。

Compaction 在某些工作負載上仍然勝出。 如果你的任務真的需要模型針對一串長長的決策（不是工具輸出）進行推理，那麼 LLM 摘要在保留結構上比 masking 更好。JetBrains 的發現最適用於觀察類 token 佔多數的工作負載。選擇之前，先看你的 token 分佈。

子代理編排並非免費。 主代理與子代理之間的每一跳都會增加延遲、多一份提示、多一份協調成本。如果你的任務在一個 30K 回合的單一對話裡就能舒服跑完，那麼一個把快取用得很好的單體代理，可能贏過一個多代理系統。隨著任務變大、快取變好，這個損益平衡點會移動。

Rerank 的好壞取決於你的相關度訊號。 如果只用嵌入向量與查詢的餘弦相似度做 rerank，你只是把看起來最像的區塊放到邊緣，這不見得是最有用的區塊。對於高風險的檢索，兩階段檢索（bi-encoder 召回 → cross-encoder 重排）是值得投資的成本；單階段則不夠。

壓縮後摘要的忠實度是真正的風險。 一個被摘要過的回合，可能會把一個被幻覺出來的承諾往後傳。如果代理之後開始推理「我們決定要用 PostgreSQL」，請去驗證這個決定是不是真的被下過，而不是摘要器製造出來的。

一份下週一就能用的清單

延伸閱讀，我建議的順序

  1. Lost in the Middle（Liu et al., 2023） — 實證基礎。短、清楚，是關於「為什麼提示結構重要」的單篇最有用的論文。
  2. Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma, 2025） — 2025 年在 18 個模型上的復現與泛化。讀起來比較像工程報告，不像論文。
  3. The Complexity Trap（JetBrains, NeurIPS DL4C 2025） — 觀察遮蔽的結果。簡單、反直覺、影響很大。
  4. Context as a Tool（CAT, ACL 2026 Findings） — 把上下文管理當成一個可學習、可呼叫的動作。
  5. Coding Agents are Effective Long-Context Processors（Cao et al., 2026） — 把檔案系統當成延伸的上下文視窗。
  6. Don't Break the Cache（PwC, 2026） — 實用取向的 prompt caching 評估。
  7. Anthropic 的子代理文件 — Claude Code 上做上下文隔離的操作手冊。
  8. Can't Remember Details in Long Documents（R&R, EMNLP 2024） — 用 reprompting 與上下文內檢索作為提示層級的緩解手段。

一句話版本

如果 context rot 是病，那麼解法就不是更大的視窗——而是能維持高訊號密度的工程：快取穩定的、遮蔽吵鬧的、用子代理做隔離、把資訊外化到檔案系統，並在提示的兩端重複陳述你的意圖。

這篇文章其他所有內容，都是這一句話的註腳。