跳轉到

Context Engineering 實作篇：Context Budget、Memory、Retrieval 與 Tool Result 壓縮怎麼組合

整理自 Anthropic 官方工程文件與學術論文（見文末），2026-06-20。這是 Context Engineering 概念篇 的實作配套：不談「為什麼重要」，談「四個槓桿怎麼搭」——context budget、memory、retrieval、tool result 壓縮。

實證標記：〔Anthropic〕= 出自 Anthropic 官方工程文件；〔論文〕= 出自學術論文；〔實務〕= 業界慣例或本人整理。預設 under-claim。

為什麼要管 context：更多 token 不等於更好

直覺以為「context window 越大、塞越多越好」。實際相反——塞越滿，模型對其中資訊的掌握越差。這個現象有幾個名字：〔論文〕

  • Lost in the Middle（Stanford）：長 context 中，開頭與結尾的資訊取用率高，中間明顯掉。準確率在邊緣約 70–75%、掉到中間約 55–60%，呈 U 型。〔論文〕
  • Context Rot：隨 session 變長，早期的相關資訊逐漸「被淹沒」而失效；更大的視窗只是延後、不是消除這個問題。〔論文〕
  • 機制面與 RoPE（旋轉位置編碼）的長距離衰減有關，使模型偏重序列頭尾、淡化中段。〔論文〕

〔論文〕一個更新的觀察：U 型只在 context 未過半時成立；超過 50% 滿時，模型轉為「離結尾越遠越差」——偏好最近的 token。實務含義一致：context 是稀缺資源，要主動管理，不是有空間就填。

四個槓桿

Context engineering 的實作，核心是這四個互補的槓桿：〔實務〕

槓桿 解決什麼 代表手法
Context Budget 整體別塞爆、留住關鍵資訊 context editing / 修剪、compaction
Memory 跨回合/跨 session 記住事情 外部 memory 工具、持久儲存
Retrieval 需要時才把相關資訊拉進來 RAG、即時檢索
Tool Result 壓縮 工具輸出別把視窗灌爆 tool result clearing、programmatic tool calling

關鍵不是「用哪一個」，而是怎麼組合：retrieval 決定「拉什麼進來」，budget/壓縮決定「留多少、丟什麼」，memory 決定「什麼要跨回合留著」。

1. Context Budget：把視窗當預算管

把 context window 當成有限預算，用規則在 scaffold 裡主動修剪（context editing），讓視窗維持在可控範圍，而不是無限累積。〔Anthropic〕

〔Anthropic〕Anthropic 內部評估：context editing 單獨帶來約 29% 的表現提升；搭配 memory 工具可到約 39%。Claude Developer Platform 也把 tool result clearing（清掉舊工具結果）這類「最輕量、最安全」的壓縮做成平台功能，並推出生產級的自動 compaction。

〔實務〕數字是 Anthropic 自家評估、特定設定下的結果，當「方向證據」看：主動修剪 > 放任累積，幅度視任務而定，別當保證值。

2. Memory：把該留的搬到視窗外

長流程不可能把所有歷史都留在 context 裡。memory 工具讓 agent 把資訊持久化到視窗外、需要時再取回，跨對話保留狀態——這也是上面「39%」裡 memory 的貢獻。〔Anthropic〕

實作要點：〔實務〕 - 區分短期（本次任務的工作記憶）與長期（跨 session 的事實/偏好）。 - memory 要可檢索、可更新、可刪除——錯的記憶比沒記憶更危險（會持續誤導）。 - 寫進 memory 的應是「蒸餾後的事實」，不是原始對話逐字。

3. Retrieval：需要時才拉，而非預先全塞

與其把所有可能相關的文件預先塞進 prompt，不如需要時才檢索。這直接呼應 lost-in-the-middle：少而準的脈絡，勝過多而雜。retrieval 的進階手法（chunking、reranking、query rewriting）見 RAG 進階系列。〔實務〕

4. Tool Result 壓縮：別讓工具輸出灌爆視窗

Agent 反覆呼叫工具，工具輸出往往是視窗膨脹最快的來源（一次 API 回傳可能幾千 token）。兩個有效手法：〔Anthropic〕

  • Tool result clearing：把舊的、已用完的工具結果清掉，只留摘要或結論。
  • Programmatic tool calling：讓程式碼去消化中間工具輸出，只把最終處理結果回給模型——大量中間資料根本不進 context。

〔實務〕本站的 Caveman skill 是另一種角度：壓縮 agent 自己的輸出溝通成本。兩者方向不同（一個壓工具輸入、一個壓 agent 輸出），但目標一致：守住 context budget。

怎麼搭：一個組合心法〔實務〕

  1. 預設少塞：system prompt 與初始 context 只放「每次都需要」的，其餘走 retrieval 按需拉。
  2. 工具輸出即時壓：能用程式消化的就別丟原始結果進視窗；用完的工具結果清掉。
  3. 跨回合的搬進 memory：本次用完即丟的留在工作記憶，要跨 session 的蒸餾成事實寫 memory。
  4. 設修剪規則：context 逼近預算時，有明確規則決定丟什麼（通常是舊工具結果 > 舊對話 > 摘要）。
  5. 監控視窗佔用：給模型/scaffold「還剩多少容量」的即時感知（context awareness），別等爆掉。〔Anthropic〕

延伸閱讀（本站）

來源