為什麼上下文塞越多，AI 反而越笨？Anthropic 官方拆解「context rot」與四種解法

企業導入 AI 常見的一個直覺是：既然模型能讀 20 萬 token，那就把整套 SOP、整年的會議紀錄全部塞進去，它應該什麼都答得出來。

Anthropic 工程團隊在官方部落格〈Effective context engineering for AI agents〉裡直接否定了這個直覺。他們的說法是：「隨著上下文視窗中的 token 數量增加，模型從該上下文中準確回想資訊的能力會下降。」這個現象被稱為 context rot（上下文腐化）。

先界定：context engineering 不等於 prompt engineering

兩個詞常被混用，但 Anthropic 把它們分得很清楚。

Prompt engineering 指的是「撰寫與組織 LLM 指令以獲得最佳結果的方法」——也就是你怎麼把問題問好。

Context engineering 的範圍大得多，官方定義是「在 LLM 推論期間，策展與維護最佳 token 集合的一整套策略」，涵蓋系統指令、工具、MCP、外部資料、對話歷史等等。

差別在於：寫 prompt 是一次性的動作，而 context engineering 是每一輪都要重新決定「這次要把什麼放進去」。對企業應用來說，後者才是真正決定成敗的工程。

機制：為什麼塞越多越糟

原因藏在 transformer 的架構裡。官方的說明是：這個架構讓「每個 token 都能關注到上下文中的每一個其他 token，因此 n 個 token 會產生 n² 組兩兩關係」。

這個 n² 用生活的例子最好懂：一場 10 個人的會議，要維持的兩兩關係是 45 組；換成 50 個人，就變成 1,225 組。人數變 5 倍，關係數變 27 倍。每個人能分給每段對話的注意力，自然被稀釋。

模型也一樣。Anthropic 的原文說得很直接：隨著上下文長度增加，「模型捕捉這些兩兩關係的能力會被攤薄」。

所以 context rot 不是模型偷懶，是結構性的限制。這也解釋了一個很多人遇過但講不出原因的現象：把整本 200 頁手冊丟進去，問開頭和結尾的問題都答得不錯，問中間段落就開始失準。

官方建議的四種解法

Anthropic 在同一篇文章裡提出四種策略，可以對照成一個團隊怎麼處理資訊爆炸：

• Compaction（壓縮）　「摘要其內容，並用該摘要重新初始化一個新的上下文視窗」。就像會議開三小時後，把結論整理成一頁紀錄，然後帶著那頁紀錄開新的會，而不是要求所有人記得三小時的每一句話。
• Structured note-taking（結構化筆記）　讓代理「定期把筆記寫到上下文視窗外的記憶體，之後再拉回上下文」。等於白板——不必一直放在腦子裡，需要時抬頭看。
• Sub-agent architectures（子代理架構）　「專門的子代理可以用乾淨的上下文視窗處理聚焦的任務」，主代理負責高層計畫。這就是分組討論：每組帶著自己的題目去查，回來只報結論。
• Just-in-time retrieval（即時檢索）　只保留「輕量識別碼（檔案路徑、儲存的查詢、網址）」，執行時才動態載入。像是會議室裡不搬整個檔案櫃進來，只帶索引卡，需要哪份再去抽。

邊界：什麼時候不必操心這件事

這套工程不是每個專案都需要。判準很簡單：你的資料量會不會成長，以及一次任務要跨幾個回合。

• 單次問答、資料量小且固定——例如把一份合約丟進去問三個問題。直接塞，不需要任何策略。
• 資料量大但每次只用一小部分——這時 just-in-time retrieval 或 RAG 才有價值。
• 長時間、多回合的自動化任務——這是 compaction 與子代理架構真正發揮作用的地方，也是最容易踩到 context rot 的場景。

換句話說，先看任務長度，再決定要不要做這套工程。一次性的短任務套用複雜架構，只是把簡單問題變複雜。

對台灣企業的意義

這篇文章對正在評估 RAG 的企業有一個很實際的推論：「長上下文模型出來了，所以不需要 RAG」這個結論下得太快。

塞得進去不等於讀得同樣仔細。這正好呼應我們先前在多模態與長上下文那篇提過的判準：資料量小又穩定，用長上下文；資料量大又常變，用檢索。Anthropic 這篇等於從架構層面給出了理由。

另外一個容易被忽略的成本面：每次提問都把整本手冊重讀一遍，跟只讀相關的三頁，在高頻使用下費用差距很可觀。對用量計費的企業來說，context engineering 不只是準確度問題，是直接反映在月結帳單上的問題。

如果你正在選向量資料庫，這篇提供了另一個角度：檢索策略（何時載入、載入多少）的影響，往往大於資料庫選型本身。

需要保留的懷疑

這篇是 Anthropic 的官方工程部落格，內容有明確的架構論證，但也要記得作者同時是模型供應商。文中推薦的四種策略，有幾項（如 compaction、MCP 整合）也正好是其平台提供的功能。

這不代表論述有問題——n² 的數學是公開的，context rot 也有多篇獨立研究佐證。但在評估「該不該採用某家的架構建議」時，把供應商的立場一起考慮進去，是基本的判斷習慣。

實務上更可靠的做法仍然是：用你自己的資料，建 30 到 50 題的測試集，換設定就重跑一次。別人的架構建議是起點，不是答案。

常見問題

什麼是 context rot（上下文腐化）？

指隨著上下文視窗中的 token 數量增加，模型從中準確回想資訊的能力反而下降的現象。成因是 transformer 架構讓每個 token 都需關注其他所有 token，n 個 token 會產生 n² 組兩兩關係，上下文越長，模型捕捉這些關係的能力越被攤薄。這是結構性限制，不是模型品質問題。

Context engineering 和 prompt engineering 有什麼不同？

Prompt engineering 指撰寫與組織指令以獲得最佳結果的方法，是一次性的寫作動作。Context engineering 範圍更廣，涵蓋系統指令、工具定義、MCP 連線、外部資料與對話歷史的整體管理，而且每一輪推論都要重新決定放入哪些內容。長時間運行的自動化任務中，後者影響成敗的程度更高。

有了長上下文模型，還需要建 RAG 向量庫嗎？

視資料特性而定。資料量小且穩定（單一合約、單本手冊）時直接使用長上下文較簡單。但由於 context rot 的存在，塞得進去不等於讀得同樣仔細；資料量大、更新頻繁，或需要控制每次查詢成本時，檢索式架構仍較有優勢。此外每次重讀完整文件的 token 費用，在高頻使用下差距可觀。

企業導入時，四種策略該從哪一個開始？

建議先看任務長度。單次問答、資料固定的情境不需要任何策略。資料量大但每次只用一小部分，優先做 just-in-time retrieval 或 RAG。需要跨多回合、長時間執行的自動化任務，才需要 compaction 與子代理架構。短任務套用複雜架構只會把簡單問題變複雜。

下一步

如果你正在評估企業內部知識庫，這篇的重點其實是「先確認任務型態，再選架構」。我們整理了一份《企業 AI 導入檢核表》，涵蓋任務盤點、資料權限確認與測試集建立方式，可從白皮書專區取得。

出處

本文引述內容出自 Anthropic 工程部落格〈Effective context engineering for AI agents〉，原文網址：anthropic.com/engineering/effective-context-engineering-for-ai-agents。文中加註引號之定義與說明均為該文原始表述之中譯，讀者可對照原文查證。

n² 兩兩關係之數學（10 人 45 組、50 人 1,225 組）為組合數 C(n,2) 的推算，讀者可自行驗算。