承昨日多代理系統最要命的失敗模式「上下文爆炸」——每多一個代理、每多一輪訊息，token 就往上疊，最後把模型塞到動彈不得——今天我們正面拆解這件事的核心：怎麼管理一個 LLM 的上下文視窗（context window）。多代理只是把問題放大了，真正的病灶在於，上下文本身就是一種稀缺資源，而大多數人都在浪費它。
📖 學
context window 是稀缺資源，不是免費倉庫
很多人把 200K token 的上下文視窗當成一個「先塞再說」的大倉庫：把整份文件、整段對話歷史、所有工具回傳的原始結果全部倒進去，反正裝得下。這是根本性的誤解。上下文視窗更像是注意力預算（attention budget）——模型每讀一個新 token，都要花注意力去跟前面所有 token 計算關聯，token 越多，這份預算被稀釋得越薄。Anthropic 在 2025 年 9 月的工程部落格裡把它講得很白：上下文工程的目標，是「在推論的每一刻，維持一組最精簡而最有效的 token」。塞得多不等於知道得多，往往剛好相反。
上下文工程 vs 提示工程：一句話 vs 整條管線
提示工程（prompt engineering）處理的是「你怎麼把一句話寫好」——措辭、範例、指令格式。上下文工程（context engineering）處理的是「在模型生成的那一刻，整個上下文視窗裡到底該裝哪些東西」。用一個比喻：提示工程是雕琢一個句子，上下文工程是設計那條產生並圍繞這個句子的整條管線——系統提示、對話歷史、檢索到的文件、工具定義、工具回傳結果、記憶體，全都是它的管轄範圍。這個詞在 2025 年 6 月由 Shopify 執行長 Tobi Lütke 帶起討論，本質是一種心態轉變：從「把視窗做大」轉向「把上下文做聰明」。
context rot：視窗還沒滿，品質就先崩了
最反直覺、也最該記住的一件事是：模型並不會均勻地使用它的上下文。Chroma 在 2025 年 7 月的技術報告《Context Rot》測了 18 個模型（含 GPT-4.1、Claude 4、Gemini 2.5、Qwen3），結論很殘酷——輸入越長，表現越不可靠，而且這種衰退在視窗遠未填滿時就開始了。一個標稱 200K 的視窗，可能在輸入才 50K token 時就出現明顯的準確度下滑。這現象叫「上下文腐爛（context rot）」：不是你塞爆了它，而是你塞得越多，它對每一塊資訊的掌握就越鬆。
lost in the middle：U 型的注意力曲線
和 context rot 一體兩面的是「迷失在中間（lost in the middle）」。Liu 等人的經典研究發現，模型取用資訊的準確度隨位置呈 U 型：關鍵資訊放在開頭或結尾，模型抓得很準；一旦被埋在中間，準確度可掉超過 30 個百分點。這個現象在六個模型家族上都複現了。技術根因大致是 RoPE 位置編碼的長距離衰減，加上 softmax 會把注意力集中在少數最高分的 token 上，於是開頭（primacy）和結尾（recency）天生佔便宜，中段吃虧。實務啟示很直接：最重要的指令與資訊，放頭或放尾，別埋在一大坨脈絡的正中央。
五個關鍵技巧
把上面的病理翻成可操作的解法，大致是這五類：
| 技巧 | 在做什麼 | 什麼時候用 |
|---|---|---|
| 壓縮 / 摘要（compaction） | 把長對話或長結果換成精簡摘要 | 對話快撐爆視窗、跨階段交接時 |
| 檢索式注入（retrieval / RAG） | 只在需要時撈進最相關的片段，而非全塞 | 知識庫龐大、只用得到一小塊 |
| 結構化記憶（structured memory） | 把該長期記住的事寫到視窗外的儲存，用時再讀 | 跨對話、跨 session 的持久狀態 |
| 工具結果裁剪（tool result pruning） | 只留工具回傳裡真正有用的欄位/行 | 工具吐回大量 JSON、原始網頁 |
| KV cache / 快取 | 讓固定不變的前綴重用計算，省成本與延遲 | 系統提示、範例等穩定前綴 |
- 壓縮 / 摘要：當對話累積到某個門檻，用模型自己把前面的內容濃縮成一段結構化摘要，再拿摘要接著跑。Claude Code 等工具的「compact」就是這招。
- 檢索式注入：與其把整個 wiki 塞進去，不如在每一步用查詢撈出當下最相關的幾段。這正是 RAG 的核心——但要小心，撈太多同樣會觸發 context rot。
- 結構化記憶：把「要長期記住」的東西（使用者偏好、專案狀態、已完成步驟）寫到視窗外的檔案或資料庫，需要時再讀回來，讓上下文視窗保持輕盈。
- 工具結果裁剪：工具常回傳一大包原始資料，但模型只需要其中幾個欄位。在 scaffold 層先裁剪，能省下驚人的 token。
- KV cache 與快取：固定不變的前綴（系統提示、工具定義、few-shot 範例）可以被快取重用，避免每輪重算，直接降成本與延遲——代價是你不該頻繁改動前綴，否則快取失效。
在 agent 迴圈裡怎麼做 context 管理
單次問答還好，難的是長時程的 agent 迴圈——它會一輪一輪呼叫工具、累積結果，上下文只會單調成長。可操作的原則有四條：
- 每一輪都在編輯上下文，而不是只往後追加。Anthropic 把這稱為 context editing / context awareness：以規則在 scaffold 內主動裁剪，並讓模型知道「還剩多少視窗」。
- 及時 compaction：接近門檻就把舊歷史換成摘要，只保留最近幾輪原始細節加一份長摘要。
- 記憶外置：中間結果寫進 scratchpad 或記憶工具，需要時再撈，而不是一直掛在視窗裡。
- 回到多代理：昨天說的「傳摘要還是傳全文」，本質就是上下文工程——子代理之間交接的，應該是壓縮過的結論，不是整段原始對話。這也是為什麼多代理若不做 context 管理，token 會爆到約一般對話的 15 倍。
常見誤解：以為「視窗變大了就不用管上下文」。恰恰相反——視窗越大，越容易不知節制地塞，context rot 反而更嚴重。大視窗是餘裕，不是免死金牌。
🧠 記
- context window 是注意力預算，不是免費倉庫；塞得多常常讓模型知道得更少。
- 上下文工程 = 管整條管線裝什麼；提示工程 = 把一句話寫好。
- context rot：視窗還沒滿，品質就開始崩；模型並不均勻使用上下文。
- lost in the middle：注意力呈 U 型，重要資訊放頭或尾，別埋中間。
- 五招：壓縮/摘要、檢索注入、結構化記憶、工具結果裁剪、KV cache 快取。
- agent 迴圈要「每輪編輯上下文」＋及時 compaction＋記憶外置，代理交接傳摘要不傳全文。
✍️ 實踐
今天的練習：替一段長對話做一次「上下文瘦身」（約 25 分鐘） 1.（5 分）找一段你最近跟 AI 跑很長、後段開始變笨的對話，粗估它累積了多少內容。 2.（8 分）手動分三類標記：必留（當前任務指令、關鍵事實）、可摘要（前面的探索過程）、可丟（工具吐回的原始長資料、已無關的岔題）。 3.（5 分）把「可摘要」那塊自己濃縮成 5–8 行結構化摘要（決策、結論、待辦）。 4.（5 分）重開一個新對話，順序這樣放：系統指令 → 摘要 → 最新問題（讓關鍵資訊落在頭與尾，避開中段）。 5.（2 分）比較新舊對話同一個追問的回答品質，寫一句話記下差異——這就是 context rot 的體感。
🔗 延伸學習
- Effective context engineering for AI agents — Anthropic — 官方定義上下文工程，含 context editing、記憶工具、程式化工具呼叫等實作策略。
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma — 18 個模型的實測，證明表現隨輸入變長而非均勻衰退。
- Lost in the Middle: How Language Models Use Long Contexts — Liu et al. (arXiv) — U 型注意力曲線的經典來源，解釋為何中段資訊吃虧。
- Context Engineering: A Practical Guide for AI Agents — Sourcegraph — 從工程實務角度整理 agent 的上下文管理手法。
💬 問 AI
把你今天那段變笨的長對話丟給 AI，請它當「上下文工程師」幫你診斷並瘦身。試試這個提示詞：
以下是我跟 AI 的一段長對話（後段品質變差）：
<貼上對話，或描述它大致累積了哪些內容>
請你以「上下文工程師」的角色：
1. 判斷這裡最可能發生了 context rot 還是 lost in the middle，說明理由。
2. 把內容分成「必留 / 可摘要 / 可丟」三類，並實際幫我產出一份 5–8 行的結構化摘要。
3. 給我一個重組後的上下文擺放順序，讓關鍵資訊落在開頭與結尾。
4. 指出我原本哪些習慣在浪費注意力預算，各給一個更省 token 的替代做法。