昨天的三類故障（知識不在窗口、窗口被塞滿、窗口之間沒有連續性）都指向同一個決策：每一次呼叫，誰來決定模型看到什麼？從今天開始的第二層就在回答這件事。Andrej Karpathy（OpenAI 創始成員、前 Tesla AI 總監）給過一個很準的定義：Context Engineering 是「在正確的時機，把正確的資訊填入 context window」的工程。跟 Prompt Engineering（這系列的 L1）的邊界也順便畫清楚：怎麼措辭是 prompt engineering，選什麼資訊進窗口是 context engineering。

先看一個真實場景

你用 coding agent 改一個 bug，session 跑了兩個小時。窗口裡現在有什麼？幾十次工具呼叫的完整輸出、三次失敗的嘗試、早就改完的另一個檔案的討論、每一輪的中間結果。這時你問它一個新問題，它開始答非所問。

把這個窗口攤開看，問題很直觀：真正跟當前任務相關的內容可能不到兩成，剩下的八成在做三件壞事 — 佔掉 window 上限（session 遲早卡死）、每一輪重複計費（Day 3 講過歷史會累積）、稀釋注意力（Day 2 講過零和競爭）。窗口不是免費的置物櫃，它是一份每輪都要重編的預算。

塞錯東西的四種病

窗口裡的內容不只有「多」的問題，還有「錯」的問題。Drew Breunig 在《How Long Contexts Fail》（連結在文末）整理過四種典型，這組分類現在被廣泛沿用：

• 污染（poisoning）：錯誤資訊或幻覺進了窗口，之後被反覆引用，整條推理鏈跟著歪。RAG 檢回一段錯的文件，模型就拿著錯的事實一路推下去
• 分心（distraction）：context 長到一個程度，模型過度依賴窗口裡的歷史，反而不用它在訓練中學到的能力
• 混淆（confusion）：多餘的資訊被模型拿去用，例如處理圖片請求時，卻從記憶裡撈出使用者的地理位置塞進了回應
• 衝突（clash）：窗口裡同時有過時版本和最新版本的資訊，互相矛盾，模型自己挑，挑到哪個看運氣

再加上 Day 2 講過的 Lost in the Middle（放對東西但放錯位置），這五種病共同說明一件事：窗口內容的品質管理，跟數量管理一樣重要。

分層防禦：便宜的手段先用

知道要管理之後，下一個問題是怎麼管。Claude Code 的做法值得攤開看，它的 context 管理是一套七層遞進的防禦，核心原則一句話：能用規則解決的，絕不呼叫 LLM；能輕量處理的，絕不做全量壓縮。

前幾層全是便宜操作：限制單輪工具輸出的上限（純規則）、直接刪掉最舊的訊息（零 API 呼叫）、精細清理舊的工具結果。到第五層才動用最貴的手段：用 LLM 把整段歷史摘要成一份總結。每一層的代價都比前一層高，只有前一層擋不住才啟動下一層。

它還有一個聰明的分離：使用者看到的和模型看到的是兩份視圖。你在畫面上滾動的是完整歷史，實際送進 API 的是精煉後的投影。這個設計讓「給人看的完整性」和「給模型看的精煉度」可以分開最佳化，不用二選一。

按需載入：預算花在刀口上

另一個方向是從源頭少塞。Anthropic 對新一代模型的 context engineering 指引裡，最核心的一條是 progressive disclosure（漸進式披露）：不要把所有資訊前置載入。agent 有十個工具，不用每次呼叫都附上十份完整說明書，附名稱和一行描述就好，需要用到時再載入細節。

同一份指引對 CLAUDE.md（Claude Code 的專案說明檔）的建議也是同一個邏輯：只記專案的「陷阱」，別陳述模型自己看得出來的東西。這跟 Day 7（Prompt 的極限）的結論接上了：窗口預算應該花在模型不具備的事實上，模型已經會的事，每寫一行都是浪費。

這一層的工作清單

把今天的原則落到工程，Context Engineering（這系列的 L2）的核心工作就浮出來了：模型缺的知識怎麼找進來（檢索）、有用的資訊怎麼跨呼叫留下來（記憶）、累積的歷史怎麼變小（壓縮）。接下來幾天一項一項拆。

明天先講檢索。RAG 這個詞你大概聽過一百次了，但從窗口經濟學的角度看，它的本質比「讓模型讀你的文件」精確得多：檢索是在動態決定這次呼叫的窗口內容，而檢回什麼品質的東西，直接決定你是在補知識還是在投毒。

參考：How Long Contexts Fail（Drew Breunig）