Agent 上下文工程：視窗是預算，不是檔案櫃

前言：prompt 工程之後的下一課

做了幾年 prompt engineering 之後，應用 AI 的重心正在轉移。Andrej Karpathy 在 2025 年把這件事說得很直白：真正的工程工作，是把「正確的資訊」填進模型的上下文視窗——指令、檢索到的知識、記憶、工具定義、之前的輸出，結構化地放進去，讓模型用得上。

Anthropic 在 2025 年 9 月的 engineering blog《Effective context engineering for AI agents》中給了正式定義：context 是「從 LLM 採樣時包含的 token 集合」；而 engineering 要解決的問題，是「在 LLM 的固有限制之下，優化這些 token 的效用，以穩定達成期望的結果」。

為什麼這件事在 agent 時代突然變關鍵？因為 agent 跑的不是一輪問答，而是在迴圈裡越轉越久的多回合推理：對話歷史越堆越長、工具結果越叫越多、檢索文件越塞越滿。你以為視窗越大越安全，實際上剛好相反。

一、為什麼「全部倒進去」會壞事

有三條研究線索，都指向同一個結論：

1. Context rot（上下文腐化）。 Chroma 在 2025 年的研究測了 18 個生產級模型（包含 Claude、GPT、Gemini 系列）：準確率隨輸入長度「單調下降」——不管模型宣稱的視窗有多大。200K token 的視窗，用到一半可能就已經掉了幾十個百分點。

2. Lost in the Middle。 Liu 等人 2023 年的經典研究：模型對上下文「中段」資訊的召回率明顯低於開頭與結尾。agent 把越多 turn、越多工具輸出、越多檢索文件串在一起，真正需要的關鍵事實就越容易滑進那個低召回的中段地帶。

3. 注意力預算。 Transformer 的 attention 是 n² 複雜度；訓練資料裡本來就很少超長序列。每一個 token 都在消耗模型「注意其他東西」的能力。Anthropic 的說法：效能衰減是「漸層」，不是懸崖——你不會收到錯誤訊息，只會得到一個越來越平庸的 agent。

把三條線索合起來，就是 2026 年大家掛在嘴邊的一句話：視窗是預算（budget），不是檔案櫃（filing cabinet）。 倒得越多，drift 越嚴重。如圖一所示。

二、四支柱：Write、Select、Compress、Isolate

Anthropic 把 agent 的上下文拆成四種成分：system prompt（指令）、tools（工具定義）、knowledge（知識）、memory（記憶）。管好它們的實作框架，業界在 2026 年收斂成四個支柱：

Write（寫入）：把狀態寫到視窗外。 讓 agent 把學到的東西寫進外部檔案：CLAUDE.md / AGENTS.md 放持久指令、任務筆記檔放進度、結論寫成結構化 log。檔案的好處是跨 session 生存——compaction 壓掉對話也壓不掉它。設計假設要反過來：隨時可能被中斷，沒寫進檔案的狀態就當它不存在。

Select（選取）：需要時才取，不要預載。 RAG、MCP resources、技能的三層漸進載入（progressive disclosure），本質都是 just-in-time 檢索。2026 年的 ContextBench（1,136 個任務）發現 agent 會「系統性過度檢索」——先取回再說反而傷效能；正確劃定範圍的上下文同時改善準確率與成本。

Compress（壓縮）：compaction 與工具結果清除。 長任務中途把歷史摘要成短版；關鍵在「摘要模板」：每次固定輸出目標、約束、已驗證結論、待辦清單四欄，丟掉的是推理過程，不是事實。用完的工具結果直接清掉（stale、可重取的資料不值得佔位）：LOCA-bench 顯示，單純遮罩過時工具輸出，效能 +2.6%、成本 -52%。Anthropic 內部評估更驚人：在 100-turn 的網頁搜尋評測裡，context editing 讓 token 消耗降低 84%，還讓原本會爆掉的任務得以跑完。

Isolate（隔離）：用 subagent 切分上下文。 token 重的探索工作丟給 subagent：它用自己的視窗做完，只把結論回傳。Anthropic 的實測例子：subagent 讀了 6,100 tokens 的檔案，父 agent 只收到 420 tokens 的摘要——省下來的就是品質。如圖二所示。

三、實作要點與程式碼範例

落地時的檢查清單：

給 context 設預算。 例如：單次工具結果不超過 8K tokens；總量超過視窗 60% 就觸發 compaction。預算先行，不要等爆掉。
摘要模板化。 compaction 不要自由發揮，固定四欄：目標／約束／已證實結論／待辦。每次壓縮都長一樣，下游才接得住。
工具定義精簡。 工具集膨脹是最常見的失敗模式——連人類工程師都說不清該用哪個工具，模型更不行。工具要少、要正交、回傳要省 token。
指令分層。 persistent（寫檔，跨 session）／session（system prompt）／turn（當下訊息）三層，別把所有東西都塞進 system prompt。
量測，不要憑感覺。 追蹤每任務 token 數、compaction 觸發頻率、prompt cache hit rate，以及「任務成功率 vs 上下文長度」的曲線。context engineering 是工程，有指標的。

一個最小可用的上下文預算管理器長這樣：


class ContextBudget:
    """Track token spend; compact or trim before the window becomes a swamp."""
    def __init__(self, window=200_000, warn_at=0.6, hard_at=0.85):
        self.window = window
        self.warn_at = warn_at
        self.hard_at = hard_at
        self.used = 0

    def add(self, label: str, tokens: int) -> str:
        self.used += tokens
        ratio = self.used / self.window
        if ratio >= self.hard_at:
            return "compact"   # 觸發摘要：保留目標/約束/結論/待辦四欄
        if ratio >= self.warn_at:
            return "trim"      # 清掉可重取的工具結果
        return "ok"

    def after_compact(self, summary_tokens: int):
        # 摘要後只保留：system prompt + 摘要 + 待辦
        self.used = summary_tokens

重點不在這個類別本身，而在它背後的紀律：每一次推理呼叫之前，你都應該能回答「這次視窗裡的 token 是花在哪、為什麼值得」。 答不出來，就是該工程介入的時候。

結論

模型負責推理；你的工作是確保它「在正確的資訊上」推理，粒度對、成本對。
Context engineering 量得到：每任務 token、cache hit、成功率曲線——這是工程指標，不是玄學。
2026 年的方向是「動態演化」：ACE（Agentic Context Engineering，ICLR 2026）證明，讓上下文從 agent 自己的執行回饋中演化，比靜態的 context file 好上一大截（coding +10.6%）。檔案會過時，回饋不會。

下次你的 agent 在長任務裡開始答非所問，先別怪模型——先看看視窗裡到底倒了多少垃圾。

資料來源

Anthropic, "Effective context engineering for AI agents" (2025-09-29) — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Anthropic, "Building effective agents" (2024-12-19)
Andrej Karpathy 談 context engineering（2025）
Chroma 長上下文研究（2025，18 個生產級模型）
Liu et al., "Lost in the Middle" (2023)
Zhang et al., "Agentic Context Engineering (ACE)", arXiv:2510.04618 (ICLR 2026)
ContextBench / SWE Context Bench / LOCA-bench（2026）

Dylan House