隨著大型語言模型（LLM）的進步，我們已經不再只靠「提示詞設計」來追求效果，而是必須思考如何在有限的上下文視窗裡，選擇最重要的資訊。這就是所謂的 上下文工程（Context Engineering）。本文以 Anthropic 的最新研究為基礎，整理實務上的上下文管理方法，並加入適合團隊落地的檢核清單與量化指標，幫助專業讀者更有效地打造高效且穩定的 AI 智慧代理。
為何需要「上下文工程」：注意力預算與上下文退化
- 上下文是有限資源：當 Token 數量增加，模型的推理成本提高，同時準確回憶關鍵資訊的能力會逐步下降，這種現象被稱為 上下文退化（context rot）。可以把 LLM 想像成一個有「注意力預算」的系統，每多加入一個 Token，都會稀釋模型的專注度。
- 技術原因：Transformer 架構會讓每個 Token 嘗試關注所有其他 Token，導致關聯數近似 n² 成長。雖然有位置編碼延伸（RoPE scaling 等技術）可以處理較長序列，但對長距依存的精準度仍可能下降。
上下文工程 vs. 提示詞工程：從單次設計到持續管理
- 提示詞工程：主要是設計單次輸入的系統提示詞，偏重「寫出最佳指令」。
- 上下文工程：則是每一次推理前，都要決定「要讓模型看到什麼」，不只是提示詞，還包括工具、上下文協定、外部資料、訊息歷史等，是一個持續策展（curation）的過程。
打造高品質上下文：三個關鍵要素
1) System Prompt：抓住「恰到好處的高度」
- 避免兩個極端：
- 過度硬編 if–else（脆弱、難維護）；
- 指令過於籠統（假設了不存在的共享脈絡）。
- 做法：用清楚、直白的語言，搭配結構化段落（例如
<background_information>、<instructions>、## Tool guidance、## Output description等），追求「最小但完整」的行為定義。
2) 工具設計：少而精、用途明確
- 工具是代理與外部世界的介面規範，需同時促進Token 效率與行為效率。
- 功能應該獨立、不重疊，參數清楚易懂，且能在錯誤時恢復。
- 如果連工程師自己都難以判斷該用哪個工具，就代表設計過度複雜。
3) 示例（Few-shot）：「代表性」比「完整性」重要
- 不要塞滿所有 edge cases 。
- 備少量但多樣化的代表性示例（可包含反例），讓模型能學到一般化的決策模式。
運行時策略：即時上下文（Just-in-Time Context）
- 與其一開始就把所有可能用到的資料放進上下文，不如只保留輕量的識別子（檔案路徑、查詢、連結），需要時再即時載入。
- 案例：Claude Code 使用 Bash、grep 等工具動態讀取檔案，而不是一次性塞進完整資料。
- 優勢：節省 Token、降低干擾；同時，**metadata（檔名、路徑、時間戳）**本身就能作為有用的提示。
長時程任務的三板斧：壓縮、結構化筆記、子代理架構
A. 壓縮（Compaction）
- 概念：對話接近視窗上限就總結重啟，只帶入高保真摘要＋最近關鍵片段（例如最近 5 個存取檔案）。
- 訣竅：先求高召回，再逐步提精確度；優先清理冗長的工具原始輸出（「工具結果清除」在 Claude 開發者平台已有功能支援）。
B. 結構化筆記（Structured Notes / Agent Memory）
- 概念：把進度、決策、未解問題寫到上下文外的持久存儲（如
NOTES.md），需要時再拉回；在非程式領域也能顯著提升長時程一致性。 - 產品上下文：Anthropic 在 Sonnet 4.5 發布時，同步釋出記憶工具公測，提供檔案型記憶介面，便於跨工作階段維持狀態。
C. 子代理架構（Sub-agent / Multi-agent）
- 概念：主代理負責規劃與彙總，專職子代理在乾淨視窗中各自深入探索，最後只回傳1–2k Token 的精煉摘要與關鍵附件。
- 效益：關注點分離，長而雜的搜尋上下文被隔離在子代理，不污染主線；在複雜研究任務上，相較單代理有顯著改善。
工程檢核清單與 KPI
設計與上下文密度
- System Prompt 最小但完整（原則 + 驗收準則）。
- 工具集去重疊、參數自描述、錯誤可恢復。
- 示例集 3–7 個「典型多樣」＋ 1–2 個反例；嚴禁「規則百科」。
檢索與即時載入
- Metadata 導航（路徑/命名/時間）與停損啟發式（避免深搜失控）。
- 關鍵檔預置上下文；其餘即時載入。
長時程穩定度
- 週期性壓縮觸發條件與「保留/丟棄」規則。
NOTES.md / DECISIONS.md模板化、持久化。- 子代理輸入/輸出契約（結構化摘要上限、附件規格）。
建議 KPI
- Context Density：關鍵片段 Token／總 Token（越高越好）。
- Retrieval P/R：針對內部標準集做 needle-in-a-haystack 測試。
- Tool Efficiency：成功輸出平均工具次數、平均回傳 Token。
- Continuity Score：跨壓縮/重啟後，目標延續率與錯誤回歸率。
- Cost × Latency Budget：在 SLA 內達標的比例。
常見失敗模式與修正
- 工具過多且重疊 → 合併功能、明確邊界；下架低使用率工具。
- 示例塞滿邊界 → 改為「典型多樣」。
- 上下文愈塞愈長 → 先做密度盤點；導入即時載入與週期性壓縮。
- 缺少持久筆記 → 導入
NOTES.md / DECISIONS.md；重啟後先讀筆記再行動。 - 子代理回傳原始巨量資料 → 強制結構化摘要（字數上限＋結構化欄位）。
結語
上下文工程代表了我們構建 LLM 應用方式的思維轉變：重點不在追求更長的上下文，而是更聰明的選擇。不論是設計 Token-高效率的工具、採用即時上下文載入，或在長時程任務中使用壓縮／結構化筆記／子代理，透過系統化的上下文管理，工程師能讓代理在成本、延遲與品質間維持最佳平衡。
未來趨勢與建議
- 上下文治理與可觀測性標準化：建立從來源 → 檢索 → 壓縮 → 輸出的可追蹤鏈路（含事件/工具日誌），把上下文變更與輸出品質綁定，支援合規與審計。
- 更智能的即時上下文：隨模型變聰明，人工策展比重下降，但即時載入與子代理並行探索將成主流，並以最小人為規則的設計原則持續演進。
參考資料
主文來源：Anthropic — Effective context engineering for AI agents（發佈：2025-09-29）。
