為什麼你的 Agent 一跑就「越跑越慢、越用越貴」？關鍵多半不在模型，而在 上下文工程（Context Engineering）。本文整合 LangChain 工程師 Lance Martin、Chroma 共同創辦人 Jeff Huber、Anthropic、Cognition、Manus 等一線團隊經驗，提煉 Offload／Reduce／Retrieve／Isolate／Cache 五大策略，並對照 The Bitter Lesson 的啟發，給打算在 2025 佈署生產級 Agent 的專業讀者一套可落地的框架。
什麼是「上下文工程」？
定義：上下文工程=為 LLM 的下一步動作，精準填充所需的最小充分上下文。它涵蓋並超越傳統的 prompt engineering 與 RAG，因為 agent 的輸入不只來自人類對話，還來自工具呼叫、檢索結果、思維鏈（chain-of-thought）副產物、長流程狀態等動態訊息。
內、外雙迴圈
- 內迴圈（Inner Loop）：每次模型推斷前，快速篩選當下必要的上下文。
- 外迴圈（Outer Loop）：長期優化上下文策略，確保隨著任務推進與版本演進，視窗內始終只保留相關資訊。
為何此刻關鍵？
實務上，一個生產級 agent 可能進行數十到上百次工具呼叫；如果每次呼叫輸出都原封不動塞回模型，不僅成本失控、觸碰視窗上限，還可能導致性能衰減（context decay）——上下文越長，注意力越分散、推理更不穩。
痛點與現狀：為什麼僅靠 Prompt 或 RAG 不夠？
- 來源多樣且動態：人指令 + 工具輸出 + 檢索內容 + 任務狀態，造成上下文爆炸。
- 長流程特徵：deep research、資料抓取、程式碼修改等長任務，容易產生錯誤路徑與冗餘狀態。
- 效能-成本雙壓力：token 消耗與延遲攀升，甚至在超長上下文下出現推理退化。
五大核心策略總覽（O/R/R/I/C）
- Offload（轉移）：把「大且常用不到」的內容移出上下文，改存外部系統（檔案、URL、物件儲存），只回傳標識與摘要。
- Reduce（壓縮）：對訊息歷史與工具輸出做摘要/剪裁，在必要時保留可回溯線索，降低不可逆丟失風險。
- Retrieve（檢索/記憶）：以多模檢索動態取回當下所需的片段（向量、關鍵字、結構化知識、文件工具、生成式搜尋）。
- Isolate（隔離）：拆分上下文歸給不同角色或子代理，降低互相干擾，讓每個 agent 聚焦在最小必要子集。
- Cache（快取）：對高重用前綴與固定描述做 KV-cache/訊息快取，大幅降低成本與延遲（但不解決長上下文本質問題）。
方法一：Offload 轉移──把長上下文移出模型
典型用法（Lance Martin）
- 用檔案系統記錄筆記與進度（如
todo.md）。 - 把大體量的工具輸出（長文本、網頁全文）寫入檔案，只回傳摘要或 URL。
- 以檔案作為長期記憶（long-term memory）。
核心思路與原理
基礎型 agent 每次工具呼叫都把完整輸出塞回模型，導致 context window 膨脹、token 成本飆高。Offload 的做法是：
- 工具輸出寫入外部存儲（檔案/對象儲存）；
- 給模型只回傳「可索引的指標」（摘要、URL、路徑）；
- 按需讀取原文。
這能顯著降低 token 使用並維持可回溯性與可擴充性。
關鍵：摘要與中繼資料（metadata）
- 深度研究時常要 offload 整頁內容，摘要品質即可用性。
- 以 Open Deep Research 為例：透過精心設計的 prompt 產生「要點化摘要」，讓 LLM 準確判斷何時再取回原文。
- Cognition 甚至主張用 微調模型專職做摘要，以降低遺漏關鍵資訊的風險。
工程實作建議
- 設計 摘要 schema（如：來源、時間、主題、關鍵實體、決策相關性分數）。
- 以「可恢復」為原則：永遠保留 URL/路徑，模型上下文只放摘要。
- 針對不同來源（網頁/程式碼/日誌）用不同摘要 prompt 模板。
方法二：Reduce 壓縮──摘要與剪裁，但先保命再省錢
典型用法與注意事項
- 摘要 agent 的訊息歷史與工具輸出。
- 剪裁不相關的歷史片段。
- 在 agent 交接時做壓縮摘要。
- 小心資訊流失：不可逆壓縮會埋下長期風險。
運作與風險控制
- 典型觸發：當 context 使用率逼近上限（如 Claude Code 的 95%）。
- 最佳實務：先 Offload、後 Reduce。先把原文寫到檔案，再對上下文做有損壓縮；必要時可回溯原始內容。
- Cognition 同樣強調摘要品質，必要時投入專模。
是否保留錯誤路徑（wrong paths）？
- 反對：錯誤訊息會「持續汙染」決策（如 Drew Breunig 的討論；Gemini 玩遊戲的幻覺案例）。
- 支持：在工程上，判斷何時刪錯很複雜；保留錯誤可讓 agent 從失敗中學習（Manus、Claude Code 的錯誤日誌實務）。
- 務實建議：
- 對話/研究類：標註錯誤並降權，保留可回溯。
- 程式開發類：保留較完整歷史 + 明確錯誤原因與修補紀錄，利於後續修改。
方法三：Retrieve 檢索 & Memory 記憶──把讀取記憶視為一種檢索
檢索策略範型
- 經典向量/語義檢索（RAG）：如 Windsurf 以語義邊界切分、embedding + 向量搜索；同時輔以 grep 與知識圖譜，最後重排序統整。
- 生成式/簡化檢索：有團隊僅用抓取與簡單文字工具；Anthropic 的 Claude Code 亦強調不建立複雜索引、善用生成式工具探索。
Lance 的基準測試（LangGraph 相關任務）
比較三種方法：
- 向量資料庫（約 300 萬 tokens）；
- 檔案工具檢索（提供整體目錄的 Markdown + 簡述 + URL，agent 再按需打開）；
- Context stuffing（把 300 萬 tokens 全塞進去）。
結果：#2 表現最佳。簡單的文字導覽 + 檔案工具，往往就能覆蓋 80% 場景，成本低、維運簡單。
「文字化」的優勢（特別在程式碼倉庫）
- Cognition DeepWiki：將 GitHub 倉庫轉為可讀的 wiki（架構圖、來源鏈接、摘要）。
- 也可自動遍歷 repo → 逐頁摘要 → 彙整成導覽文本，讓 LLM 先讀導覽，再定位目標 URL。
記憶：四種類型與讀寫模式
- 情景/語義/程序/背景記憶。
- 讀記憶 vs. 寫記憶 + 自動化程度：
- 極簡模式（如 Claude Code）：啟動自動載入 repo；寫入需使用者明確指定。
- 全自動記憶：有隱私與「非預期檢索」風險（如誤用地理位置）。
- 結論：在大規模場景，「讀記憶 ≒ 檢索」。複雜記憶系統 ≒ 複雜 RAG。
方法四：Isolate 隔離──把上下文拆給正確的角色
用法與警示
- 將 context 拆分給多個子 agent，各自管理不同內容，避免互相干擾。
- 但 multi-agent 容易產生衝突決策，尤其在程式任務存在狀態依賴（寫測試 vs. 改邏輯）。
- Cognition 因此反對過度依賴子 agent；Anthropic 則在 deep research 中成功採用「子 agent 併行讀、主 agent 統一寫」的架構。
什麼時候該用 Isolate？
- 易並行、偏只讀的工作（如資料蒐集、文獻整理）。
- 不適合高度協同、雙向耦合強的任務（大型 refactor / 跨模組設計），除非有成熟的跨 agent 通訊與鎖定機制。
方法五：Cache 快取──降延遲與成本，但不治長上下文
實務做法
- 快取輸入 token（KV-cache）：在 Claude Sonnet 等模型上可見 ~10 倍成本差。
- 把指令、工具描述放在可快取的前綴；把最近觀測放後綴。
- 指標導向：KV-cache 命中率是生產環境中最重要的單一指標之一（影響 TTFT 與成本）。
限制與取捨
- Cache 只解決延遲/成本，不解決長上下文衰減（context decay）。
- 供應商差異與廠商鎖定：有的 API 需顯式設定 cache header；自託管/開源模型則可完全掌控策略。
The Bitter Lesson 的啟發
核心觀點
OpenAI 的 Hyung Won Chung 在 The Bitter Lesson in AI Research 演講中指出：在相同成本下，計算能力約每 5 年提升十倍；長期來看，歸納偏置較少、通用且依賴大量數據與計算的方法往往勝出。重點：讓模型透過大量數據與計算自行學會如何思考，比「人為教它怎麼思考」更有效。
名詞釐清：歸納偏置（Inductive bias）
在資料有限時，系統為了能泛化而內建的先驗假設／偏好。它讓模型在眾多解釋中偏向某些方向以提高學習效率，但同時也可能限制上限。
短期結構 vs. 長期瓶頸
Hyung 指出：在早期或計算受限階段，加入更多結構（structure）／建模假設能帶來短期性能；但當算力快速增加，這些人為結構反而會成為上限的瓶頸。對工程的啟發是：
- 優先採用可隨規模持續受益的路線（資料、算力、通用算法）。
- 對「手工規則／強歸納偏置」抱持審慎、可拔除的態度。
架構選型：抽象 vs 編排
- 避免過度「Agent 抽象」黑箱：難以隨模型能力提升而重構。
- 擁抱低階編排（orchestration）：可觀測、可測試、可替換；像 Shopify Roast 類的「無判官狀態（no-judge state）」工作流元件更易演進。
- 標準協定（如 MCP）減少工具整合的混亂與心智負擔。
架構與流程實戰建議
1) 上下文生命週期（Context Lifecycle）
- 產生：工具輸出/檢索/人輸入 → 標記：來源、時間、可信度、引用。
- 壓縮/轉移：摘要（可回復）、Offload 到外部儲存。
- 取用：多模檢索與重排，根據任務態勢（Stage-aware）動態取回。
- 淘汰：過期/失效/被推翻內容加註「失效標籤」，避免污染。
2) 關鍵度量（Metrics）
- KV-cache 命中率、輸入:輸出 token 比（許多 agent 可達 100:1）、每步延遲、檢索精確率/召回率、摘要覆蓋率、錯誤路徑復發率、成本/成功任務。
3) 安全與合規
- 記憶檢索的可控性：限制自動調取敏感個資/位置；為記憶與檢索加上用途範圍（Purpose Limitation）。
- 來源可追溯：對外輸出（報告/程式碼修補）需附引用/來源與時間戳。
給專業人士的兩個常見誤區
- 只強化 RAG，而忽略 Offload 與 Cache：檢索做得再好，也敵不過海量原始輸入不節食。
- 盲目多 Agent：讀多寫少才有正效益；寫密集且互依高（如 coding）的場景，單 Agent＋清晰中間產物更穩。
典型落地場景
A. Deep Research
- 以 Isolate 平行蒐集 → Offload 全文 → Reduce 產出研究卡 → Retrieve 回補引用 → Cache 穩定成本。
B. Coding Agent
- 保留錯誤日誌以利修正，但標註失效/已解；
- 子代理需慎用：高度耦合的改動讓「反向書寫」溝通成本高，建議以單一裁決者整合。
給不同角色的快速清單
架構師
- 設計「外部記憶優先」；及早訂中繼資料與目錄規範。
- 工作流程用透明節點與標準工具協定（例如 MCP 類型）組裝。
平台／後端
- 提供統一 摘要服務 與 資源清單 Facade；快取層抽象清楚。
- 建立觀測性：記錄每次檢索、提示組裝與可追溯鏈（provenance）。
應用／產品
- 把「交接摘要包」當一等公民；UI 讓人看得懂 Agent 在想什麼、用了哪些來源。
- 定期檢討：哪些任務可把「厚結構」降成「薄支架」。
總結
2025 的關鍵不是把更多內容硬塞進上下文，而是讓 對的資訊，在對的時間，用對的形式 進到模型。把 Offload／Reduce／Retrieve／Isolate／Cache 做到位，再配合「薄而透明」的工作流程，你的 Agent 才能跑得快、跑得久、跑得穩，也能跟上模型能力的下一個跳躍。
未來實務建議
- 從「內容導向」轉向「決策導向」上下文：未來的上下文工程會更強調決策所需最小證據集（Minimal Decision Set），並以可驗證引用與動態可信度加權。
- SSM + 外部記憶 的新型代理：若以檔案/物件存儲作為結構化外部記憶，搭配更高速、長距依賴較弱的 SSM 模型，可能開啟「低成本長程任務」的新架構範式。
- 標準化工具協定與審計：MCP 等協定成熟後，上下文審計（Context Audit）與可追溯引用將成為企業採用門檻。
- 指標驅動的自動化調度：以KV-cache 命中率、檢索品質、上下文長度等指標驅動策略切換（例如自動調整 Offload/Reduce 門檻），形成自適應上下文管控。
