Context Engineering：為 AI Agent 管理正確的資訊
原文：Microsoft AI Agents for Beginners · MIT 授權
導論
要打造可靠的 AI Agent，理解應用程式的複雜度至關重要。我們需要建立能有效管理資訊的 Agent，以應對超越 Prompt Engineering 的複雜需求。本課將深入探討 Context Engineering 的核心概念，以及它在打造 AI Agent 中扮演的角色。
學習目標
- 定義 Context Engineering，並區分它與 Prompt Engineering 的不同
- 辨識 LLM 應用中上下文的關鍵組成
- 應用寫入、選擇、壓縮與隔離上下文的策略，提升 Agent 效能
- 辨識常見的上下文失敗模式：污染、分心、混淆與衝突，並實作緩解技術
什麼是 Context Engineering？
對 AI Agent 而言，上下文（Context）是驅動 Agent 規劃並採取行動的核心。Context Engineering 就是確保 AI Agent 在完成任務的每一步都擁有正確資訊的工程實踐。因為上下文視窗大小有限，身為 Agent 開發者，我們需要建立系統和流程來管理上下文的新增、移除與濃縮。
Prompt Engineering vs Context Engineering
| 面向 | Prompt Engineering | Context Engineering |
|---|---|---|
| 焦點 | 單一靜態指令集 | 動態資訊管理 |
| 範圍 | 撰寫規則與提示 | 包含初始提示在內的所有資訊流 |
| 目標 | 有效引導 Agent 行為 | 確保 Agent 在任何時刻都有正確資訊 |
| 時間性 | 一次性設計 | 持續管理，隨任務進展動態調整 |
| 核心理念 | 「說什麼」 | 「知道什麼、何時知道」 |
Context Engineering 的關鍵理念是：讓這個過程可重複且可靠。
上下文的五種類型
上下文不是單一事物。AI Agent 需要的資訊可能來自多種來源，以下是 Agent 需要管理的上下文類型：
| 類型 | 說明 | 範例 |
|---|---|---|
| 1. 指令 (Instructions) | Agent 的「規則」——提示詞、系統訊息、Few-shot 範例、工具描述 | 系統提示：「你是專業的旅遊顧問」、如何使用訂票工具的範例 |
| 2. 知識 (Knowledge) | 事實、從資料庫檢索的資訊、長期記憶 | RAG 系統從知識庫擷取航班政策、使用者過去偏好 |
| 3. 工具 (Tools) | 外部函式、API 與 MCP Server 的定義，以及使用它們得到的回饋（結果） | search_flights 的 API 描述、查詢城市天氣的回傳 JSON |
| 4. 對話歷史 (Conversation History) | 與使用者持續進行的對話記錄 | 使用者說「先去東京再去大阪」的完整多輪對話 |
| 5. 使用者偏好 (User Preferences) | 長期累積的使用者喜好與習慣 | 偏好靠走道的座位、預算範圍、常用航空公司 |
⚠️ 對話歷史隨時間增長會佔據大量上下文視窗空間，是 Agent 效能退化最常見的原因之一。
有效的 Context Engineering 策略
規劃策略（Planning Strategies）
好的 Context Engineering 始於好的規劃。以下是幫助你思考如何應用 Context Engineering 的方法：
| 步驟 | 核心問題 | 說明 |
|---|---|---|
| 1. 定義明確結果 | 「Agent 完成任務後，世界是什麼樣子？」 | 清楚定義使用者應該獲得的變化、資訊或回應 |
| 2. 映射上下文 | 「Agent 需要哪些資訊才能完成這個任務？」 | 畫出資訊的位置藍圖：從哪個資料庫、哪個 API、哪段對話 |
| 3. 建立上下文管線 | 「Agent 如何取得這些資訊？」 | 透過 RAG、MCP Server 或其他工具建立資訊流入機制 |
實務策略（Practical Strategies）
當資訊開始流入 Agent 的上下文視窗，我們需要具體策略來管理它們：
一、管理上下文的方式
| 策略 | 說明 | 使用時機 |
|---|---|---|
| Agent 便條紙 (Agent Scratchpad) | 讓 Agent 將當前任務和使用者互動的相關資訊記錄在上下文視窗之外的檔案或執行期物件中，需要時再取回 | 單一 session 內的臨時資訊 |
| 記憶 (Memories) | 讓 Agent 跨多個 session 儲存和檢索相關資訊，包含摘要、使用者偏好和改進回饋 | 跨 session 的長期資訊 |
| 上下文壓縮 (Compressing Context) | 當上下文接近極限時，使用摘要化（Summarization）和修剪（Trimming）技術——保留最相關資訊或移除舊訊息 | 上下文視窗接近滿載時 |
| 多 Agent 系統 (Multi-Agent Systems) | 每個 Agent 有自己獨立的上下文視窗，需規劃上下文如何在 Agent 之間共享與傳遞 | 任務複雜、可拆分時 |
| 沙箱環境 (Sandbox Environments) | 讓 Agent 在隔離環境中執行程式碼或處理大量文件，只將結果摘要讀回上下文 | 需要大量 token 處理的運算 |
| 執行期狀態物件 (Runtime State Objects) | 建立資訊容器，讓 Agent 逐步儲存每個子任務的結果，使上下文只與當前子任務連結 | 複雜、多步驟任務 |
二、檢查上下文（Inspecting Context）
套用任何策略後，都值得檢查模型呼叫實際收到了什麼。一個有用的除錯問題：
Agent 是否載入了太多上下文？錯誤的上下文？還是遺漏了需要的上下文？
你不需要記錄完整的原始提示或工具輸出來回答這個問題。在正式環境中，偏好使用輕量的上下文檢查記錄——只記錄計數、ID、雜湊和政策標籤：
| 檢查面向 | 記錄什麼（而非原始內容） |
|---|---|
| 選擇 (Selection) | 考慮了多少候選區塊/工具/記憶、選中了多少、用哪條規則或分數過濾掉其他 |
| 壓縮 (Compression) | 來源範圍或追蹤 ID、摘要 ID、壓縮前後的估計 token 數、原始內容是否被排除 |
| 隔離 (Isolation) | 哪個子任務在獨立 Agent/session/沙箱中執行、回傳了什麼有界摘要、大型工具輸出是否留在母 Agent 上下文之外 |
| 記憶與 RAG | 儲存檢索文件 ID、記憶 ID、分數、選中 ID 和遮罩狀態，而非完整檢索文字 |
| 安全與隱私 | 優先使用雜湊、ID、token 桶和政策標籤，而非敏感的提示文字、工具參數、工具結果或使用者記憶內容 |
目標不是保留更多上下文，而是留下足夠證據讓開發者能判斷哪個上下文策略被執行、以及它是否以預期方式改變了下一次模型呼叫。
實際範例：訂一趟巴黎之旅
假設我們要 AI Agent 「幫我訂一趟巴黎之旅」：
| 方式 | Agent 的行為 |
|---|---|
| 僅用 Prompt Engineering | Agent 只回應：「好的，你什麼時候想去巴黎？」——僅處理了當下的直接提問 |
| 使用 Context Engineering | 在回應之前，系統先做了： ① 檢查你的行事曆找出空檔日期（即時資料擷取） ② 回想過往旅行偏好（長期記憶）：偏好航空、預算、是否喜歡直飛 ③ 識別可用工具：航班搜尋、飯店預訂 → 回應：「嗨 [你的名字]！我看到你十月第一週有空。要幫你用 [偏好航空] 搜直飛巴黎的航班嗎？預算照慣例抓 [預算金額]？」 |
常見的上下文失敗模式
1. 上下文污染 (Context Poisoning)
是什麼：當幻覺（LLM 生成的虛假資訊）或錯誤進入上下文並被反覆引用，導致 Agent 追求不可能的目標或建立荒謬的策略。
解法：實作上下文驗證與隔離。在資訊加入長期記憶前先驗證。若偵測到潛在污染，啟動全新的上下文線程，防止錯誤資訊擴散。
旅遊訂票範例：Agent 憑空捏造了「從小機場直飛國際城市」的不存在航班，這個錯誤資訊被存入上下文。之後你再問訂票時，Agent 一直嘗試找出這條不可能路線的機票。解法：在將航班資訊加入工作上下文之前，先用即時 API 驗證航班是否存在——驗證失敗就隔離，不再使用。
2. 上下文分心 (Context Distraction)
是什麼：當上下文變得過於龐大，模型過度專注累積的歷史記錄，而非使用訓練時學到的知識，導致重複或無用的行動。模型可能在上下文視窗還沒滿之前就開始犯錯。
解法：使用上下文摘要化。定期將累積的資訊壓縮成簡短摘要，保留重要細節，移除冗餘歷史，幫助「重置」注意力。
旅遊訂票範例：你長時間討論各種夢想旅行目的地，包括兩年前背包旅行的詳細回憶。當你終於說「幫我找下個月便宜機票」，Agent 被舊的無關細節絆住，一直追問你的背包裝備或舊行程。解法：超過一定回合或上下文過大時，Agent 應摘要最新最相關的對話部分——聚焦於當前旅行日期和目的地，丟棄不相關的歷史對話。
3. 上下文混淆 (Context Confusion)
是什麼：當不必要的上下文（通常是太多可用工具）導致模型產生糟糕的回應或呼叫不相關的工具。較小的模型特別容易發生。
解法：實作工具載入管理（Tool Loadout Management），使用 RAG 技術。將工具描述儲存在向量資料庫中，針對每個具體任務只選取最相關的工具。研究建議限制工具選擇少於 30 個。
旅遊訂票範例：你的 Agent 有數十個工具：book_flight, book_hotel, rent_car, find_tours, currency_converter, weather_forecast, restaurant_reservations...你問「在巴黎市內最好的交通方式是什麼？」由於工具太多，Agent 混淆了，試圖在巴黎市內呼叫 book_flight，或推薦 rent_car 即使你偏好公共交通。解法：對工具描述使用 RAG，動態只擷取最相關的工具（如 public_transport_info），呈現精簡的「工具選單」給 LLM。
4. 上下文衝突 (Context Clash)
是什麼：當上下文內存在衝突的資訊，導致不一致的推理或糟糕的最終回應。常發生在資訊分階段到達時，早期的錯誤假設仍保留在上下文中。
解法：使用上下文修剪（Context Pruning）與卸載（Offloading）。修剪：當新細節到達時移除過時或衝突的資訊。卸載：給模型一個獨立的「便條紙」工作空間來處理資訊，不污染主上下文。
旅遊訂票範例：你最初告訴 Agent「我想搭經濟艙」。之後改變心意說「這次升級商務艙」。如果兩個指令都留在上下文中，Agent 可能收到衝突的搜尋結果，或困惑哪個偏好優先。解法：實作上下文修剪——當新指令與舊指令矛盾時，移除或明確覆蓋舊指令。或者 Agent 使用便條紙來調和衝突偏好再做決定。
本課重點回顧
- Context Engineering ≠ Prompt Engineering：前者管理動態資訊流，後者設計靜態指令——兩者相輔相成
- 五種上下文類型：指令、知識、工具、對話歷史、使用者偏好——每種都需要不同的管理策略
- 六大管理策略：便條紙、記憶、壓縮、多 Agent、沙箱、狀態物件——根據場景選用
- 檢查勝於囤積：記錄 ID/計數/雜湊而非原始內容，確保可觀測性與隱私兼顧
- 四大失敗模式：污染（驗證隔離）、分心（摘要壓縮）、混淆（精簡工具）、衝突（修剪卸載）——各有明確解法