ai-agents-for-beginners
AI 代理的上下文工程
(點擊上方圖片觀看本課程影片)
了解您正在為其建構 AI 代理的應用程式的複雜性對於打造可靠的代理至關重要。我們需要建構能夠有效管理資訊、滿足複雜需求的 AI 代理，而這超越了提示工程的範疇。
在本課中，我們將探討什麼是上下文工程及其在打造 AI 代理中的作用。
介紹
本課程將涵蓋：
• 什麼是上下文工程 以及它為何與提示工程不同。
• 有效上下文工程的策略，包括如何撰寫、選擇、壓縮和隔離資訊。
• 常見的上下文失效問題，這些問題可能使您的 AI 代理失敗，以及如何修復它們。
學習目標
完成本課後，您將了解如何：
• 定義上下文工程，並區分它與提示工程的差異。
• 識別大型語言模型（LLM）應用中上下文的關鍵組成部分。
• 運用撰寫、選擇、壓縮和隔離上下文的策略來提升代理效能。
• 辨識常見的上下文失效，如中毒、干擾、混淆和衝突，並實施緩解技術。
什麼是上下文工程？
對於 AI 代理而言，上下文是推動代理規劃採取特定行動的關鍵。上下文工程是確保 AI 代理擁有正確資訊以完成下一步任務的實踐。由於上下文視窗大小有限，作為代理建構者，我們需要建立系統與流程來管理上下文視窗中的資訊添加、移除與濃縮。
提示工程 vs 上下文工程
提示工程著重於一組靜態指令，以一套規則有效引導 AI 代理。而上下文工程則是管理動態資訊集合（包括最初的提示），確保 AI 代理在時間推移中持續擁有所需資訊。上下文工程的核心理念是讓這個過程可重複且可靠。
上下文類型
重要的是要記住，上下文不只是單一事物。AI 代理所需的資訊可以來自多種不同來源，我們的工作是確保代理能存取這些來源：
AI 代理可能需要管理的上下文類型包括：
• 指令： 這類似代理的「規則」——提示、系統訊息、少量範例（展示 AI 如何執行某事）、以及其可使用工具的描述。這是提示工程與上下文工程交織的重點。
• 知識： 涵蓋事實、從資料庫檢索的資訊，或代理累積的長期記憶。若代理需存取不同知識庫及資料庫，這包括整合檢索擴增生成（RAG）系統。
• 工具： 外部函式、API 及 MCP 伺服器定義，代理可呼叫，並獲得使用後的回饋（結果）。
• 對話歷史： 與用戶的持續對話。隨時間推進，對話越來越長且複雜，佔用上下文視窗空間。
• 用戶偏好： 隨時間學習到的用戶喜好或厭惡資訊。這些可被存儲，並於做重要決策時調用以協助用戶。
有效上下文工程的策略
規劃策略
良好的上下文工程始於良好的規劃。以下方法將幫助您開始思考如何運用上下文工程的概念：
- 定義明確結果 - AI 代理被指派任務的結果應明確定義。回答問題：「AI 代理完成任務後，世界會是什麼模樣？」換句話說，與 AI 代理互動後，使用者應獲得什麼樣的改變、資訊或回答。
- 繪製上下文圖譜 - 當您定義好 AI 代理的結果後，需回答：「AI 代理為完成此任務需要哪些資訊？」如此即可開始繪製該資訊所在的上下文圖譜。
- 建立上下文流程 - 現在您知道資訊位置後，需要回答：「代理如何獲取這些資訊？」這可以透過多種方式完成，包含 RAG、使用 MCP 伺服器及其他工具。
實務策略
規劃固然重要，但當資訊開始流入代理的上下文視窗時，我們需要具備實務上的管理策略：
管理上下文
雖然部分資訊會自動加入上下文視窗，上下文工程更強調對這些資訊採取更主動的管理方式，以下是幾種策略：
-
代理備忘錄（Agent Scratchpad） 允許 AI 代理在單次會話中記錄與任務及用戶互動相關的資訊。此資料應存在上下文視窗外的檔案或運行時物件中，代理若需要可於該會話中後續檢索。
-
記憶體（Memories） 備忘錄適用於管理單次會話上下文外的資訊，記憶體則讓代理得以跨多次會話存取及檢索相關資訊。這可能包括摘要、用戶偏好及未來改進的回饋。
-
壓縮上下文 當上下文視窗增大接近限制時，可用摘要及修剪等技術減少資料量。這包括保留最相關資訊或刪除較舊訊息。
-
多代理系統（Multi-Agent Systems） 發展多代理系統也是一種上下文工程，因為每個代理有其獨立的上下文視窗。如何共享並傳遞上下文給不同代理，是建立此類系統時須規劃的重點之一。
-
沙盒環境（Sandbox Environments） 若代理需執行代碼或處理大量文件資訊，可能耗費大量 token 才能處理結果。代理可利用沙盒環境執行此代碼，並只讀取結果及其他相關資訊，而非將全部存於上下文視窗中。
-
運行時狀態物件（Runtime State Objects） 透過建立資訊容器，管理代理需要存取特定資訊的情況。對於複雜任務，可讓代理逐步存儲每個子任務的結果，讓上下文僅連結該子任務。
檢查上下文
實施上述策略後，值得檢查下一次模型調用實際接收到的內容。可用的除錯問題為：
代理是否載入過多上下文、錯誤上下文或遺漏所需上下文？
您不必記錄原始提示、工具輸出或記憶內容以回答這問題。在生產環境中，建議撰寫小型上下文檢視紀錄，捕捉計數、ID、雜湊及策略標籤：
- 選擇（Selection）： 追蹤考慮了多少候選區塊、工具或記憶，被選中多少，以及哪些規則或分數導致其他被過濾。
- 壓縮（Compression）： 記錄原始範圍或追蹤 ID、摘要 ID、壓縮前後估計的 token 數，以及原始內容是否被排除於下一次調用外。
- 隔離（Isolation）： 註明哪些子任務在獨立代理、會話或沙盒中執行，回傳了哪些有界摘要，以及大規模工具輸出是否保持在父代理上下文外。
- 記憶與 RAG： 存儲檢索文件 ID、記憶 ID、分數、被選 ID 及編輯狀態而非全文文本。
- 安全與隱私： 優先使用雜湊、ID、token 桶和策略標籤，避免敏感提示文本、工具參數、工具結果或用戶記憶詳細內容。
目標不是保留更多上下文，而是留存足夠證據，讓開發者辨識運行了哪種上下文策略，以及它是否按預期影響了下一次模型調用。
上下文工程範例
假設我們想讓 AI 代理「替我預訂一趟巴黎旅行」。
• 只用提示工程的簡單代理可能會直接回應：「好的，您想什麼時候去巴黎？」只處理用戶當下提問的直接問題。
• 採用本文提及的上下文工程策略的代理會做更多事情。甚至在回應之前，其系統可能會：
◦ 檢查您的行事曆 以取得可用日期（檢索實時資料）。
◦ 回憶過往旅行偏好（來自長期記憶），如您偏好的航空公司、預算，或者是否偏好直飛。
◦ 確認可用工具 來訂機票與飯店。
- 然後，一個範例回應可能是：「嗨 [您的名字]！我看到您十月第一週有空。要不要我幫您找您習慣的 [航空公司]、預算約 [預算] 內的直飛巴黎航班？」這種豐富且具上下文感知的回應展現了上下文工程的威力。
常見的上下文失效問題
上下文中毒
定義： 當虛構（LLM 產生的錯誤資訊）或錯誤資訊進入上下文並被反覆引用，導致代理追求不可能的目標或產生荒謬策略。
應對方法： 實施上下文驗證與隔離。在將資訊加入長期記憶前先驗證。若發現潛在中毒，啟動新的上下文線程以防止錯誤資訊擴散。
旅遊訂票範例： 代理虛構了一個由小型地方機場直飛遙遠國際城市的航班，該飛行路線實際上無國際班機。此不存在的航班細節被保存於上下文中。日後當您請求代理訂票時，代理不停嘗試尋找該不可能的航線機票，反覆出錯。
解決方案： 實施步驟，在將航班資訊加入工作上下文前先透過實時 API 驗證該航班及路線存在性。驗證失敗時，錯誤資訊會被「隔離」且不再使用。
上下文干擾
定義： 當上下文過大，模型過度專注於累積歷史，反而忽略訓練所學，造成重複或無益行為。模型甚至在上下文視窗未滿前即開始犯錯。
應對方法： 使用上下文摘要。定期將累積資訊壓縮成短摘要，保留重要細節，去除冗餘歷史，有助重設專注點。
旅遊訂票範例： 您已經討論過許多夢想旅行地，包括兩年前背包旅行的詳細經歷。當您終於請求「幫我找下月便宜機票」時，代理被舊有無關細節拖累，不斷詢問背包裝備或過去行程，忽略了您的當前需求。
解決方案： 超過一定輪數或上下文過大時，代理應摘要最近且相關的對話內容——聚焦於您目前的旅行日期和目的地——並用濃縮摘要進行下一次 LLM 調用，捨棄較不相關的歷史對話。
上下文混淆
定義： 過多不必要的上下文（通常為過多可用工具）導致模型產生錯誤回應或調用無關工具。較小模型尤其易受此影響。
應對方法： 使用 RAG 技術實施工具載入管理。將工具描述存入向量資料庫，僅為每項任務選擇最相關的工具。研究顯示將工具數量限制於30以下。
旅遊訂票範例： 您的代理能存取數十種工具：book_flight、book_hotel、rent_car、find_tours、currency_converter、weather_forecast、restaurant_reservations 等。您問「巴黎最佳交通方式是什麼？」由於工具眾多，代理混淆了，試圖在巴黎境內調用 book_flight，或在您偏好公共交通的情況下呼叫 rent_car，因工具描述重疊或無法判斷最佳選項。
解決方案： 針對工具描述使用RAG 檢索。當您詢問巴黎交通方式時，系統依查詢動態檢索並呈現最相關工具，如 rent_car 或 public_transport_info，為 LLM 提供聚焦的工具「載入組合」。
上下文衝突
定義： 上下文中存在矛盾資訊，導致推理不一致或產出錯誤最終回答。這常發生於資訊分階段到達，早期錯誤假設留存於上下文中。
應對方法： 使用上下文修剪與卸載。修剪即隨新資訊到達時移除過時或矛盾的資訊；卸載則讓模型使用獨立「備忘錄」工作區處理資訊，避免主上下文混亂。
旅遊訂票範例： 你起初告訴你的代理人，「我想搭經濟艙。」 後來在對話中，你改變主意並說，「其實這趟行程，我們改搭商務艙。」 如果這兩個指示都保留在上下文中，代理人可能會收到互相矛盾的搜尋結果，或不確定該優先考慮哪個偏好。
解決方案： 實施上下文修剪。當新指示與舊指示矛盾時，舊的指示會從上下文中移除或被明確覆蓋。或者，代理人可以使用草稿本來調和衝突的偏好後再做決定，確保只有最終且一致的指示來引導其動作。
對上下文工程還有更多問題嗎？
加入 Microsoft Foundry Discord 與其他學習者見面，參加辦公時間並獲得 AI 代理人的問題解答。
上一課
下一課
AI 代理人的記憶 (Memory for AI Agents)
免責聲明： 本文件由 AI 翻譯服務 Co-op Translator 翻譯而成。雖然我們致力於確保準確性，但請注意，機器自動翻譯可能包含錯誤或不準確之處。原始文件的母語版本應被視為權威來源。對於重要資訊，建議進行專業人工翻譯。我們不對因使用本翻譯而產生的任何誤解或誤釋承擔責任。