ai-agents-for-beginners

AI 代理的上下文工程

上下文工程

(點擊上方圖片觀看本課程影片)

理解您正在為之構建 AI 代理的應用複雜性，對打造一個可靠的代理至關重要。我們需要建立能有效管理資訊的 AI 代理，以應對超越提示工程的複雜需求。

在本課中，我們將探討什麼是上下文工程以及它在構建 AI 代理中的作用。

簡介

本課程將涵蓋：

• 什麼是上下文工程以及它與提示工程的區別。

• 有效上下文工程的策略，包括如何撰寫、選擇、壓縮和隔離資訊。

• 常見的上下文失敗，會如何破壞您的 AI 代理，及如何修復。

學習目標

完成本課後，您將了解如何：

• 定義上下文工程並能區分它與提示工程的不同。

• 識別大型語言模型（LLM）應用中的上下文主要組成部分。

• 應用撰寫、選擇、壓縮和隔離上下文的策略，以提升代理效能。

• 辨認常見上下文失敗，如中毒、分心、混淆和衝突，並實施緩解技術。

什麼是上下文工程？

對 AI 代理而言，上下文驅動著代理規劃採取某些行動。上下文工程是確保 AI 代理擁有執行下一步任務所需正確資訊的實務。上下文視窗容量有限，因此作為代理建構者，我們需建立系統與流程來管理新增、移除和精簡上下文視窗中的資訊。

提示工程 vs 上下文工程

提示工程專注於一組靜態指令，以一組規則有效引導 AI 代理。而上下文工程則是管理包含初始提示在內的動態資訊集合，確保 AI 代理隨時間持續擁有所需資訊。上下文工程的核心是使此流程可重複且可靠。

上下文的類型

上下文類型

記住上下文不只是單一事物很重要。AI 代理所需的資訊可能來自多種不同來源，而我們要確保代理能接觸這些來源：

AI 代理可能需管理的上下文類型包括：

• 指令： 這類似於代理的「規則」——提示、系統消息、少量範例（示範 AI 如何做事）以及可使用工具的描述。這是提示工程與上下文工程交匯的焦點所在。

• 知識： 包括事實、從資料庫檢索的資訊，或代理累積的長期記憶。如果代理需訪問不同知識庫與資料庫，則包括整合檢索增強生成（RAG）系統。

• 工具： 代理可以調用的外部功能定義、API 與 MCP 伺服器，以及使用後得到的回饋（結果）。

• 對話紀錄： 與用戶的持續對話。隨著時間累積，這些對話更加冗長複雜，佔用上下文視窗的空間。

• 用戶偏好： 隨時間學習的用戶喜好或不喜好資訊。可儲存並在做關鍵決策時調用以協助用戶。

有效上下文工程的策略

規劃策略

上下文工程最佳實踐

良好的上下文工程始於良好的規劃。以下方法將幫助您開始思考如何應用上下文工程的概念：

  1. 定義明確結果 - AI 代理將被指派的任務結果應明確定義。回答「當 AI 代理完成任務後，世界會是什麼樣子？」換句話說，使用者與 AI 代理互動後，應有什麼改變、資訊或回應。
  2. 繪製上下文地圖 - 定義結果後，需回答「AI 代理為完成此任務需要哪些資訊？」如此即可開始繪製該資訊可能所在的上下文地圖。
  3. 建立上下文管線 - 知道資訊所在後，需回答「代理將如何取得這些資訊？」此可透過多種方式完成，包括 RAG、使用 MCP 伺服器及其他工具。

實務策略

規劃很重要，但當資訊開始流入代理的上下文視窗時，我們需有實務策略來管理它：

管理上下文

雖然部分資訊會自動加入上下文視窗，但上下文工程是更積極參與這些資訊的管理，以下為幾種策略：

  1. 代理草稿板 允許 AI 代理在單次會話中記錄與當前任務和用戶互動相關的資訊。此應存在上下文視窗之外，例如一個檔案或運行時物件，代理可於會話中稍後取回所需資料。

  2. 記憶體 草稿板適合管理單次會話上下文視窗之外的資訊。記憶體則使代理能跨多次會話存取相關資訊，包括摘要、用戶偏好與未來改進的回饋。

  3. 壓縮上下文 當上下文視窗逐漸擴大逼近上限時，可採用摘要與裁剪等技術。這包括保留最相關資訊或移除較舊訊息。

  4. 多代理系統 發展多代理系統是一種上下文工程，因為每個代理有自己的上下文視窗。如何分享並傳遞這些上下文給不同代理，是系統構建時需規劃的。

  5. 沙盒環境 若代理需執行程式碼或處理大量文件資訊，處理結果會佔用大量 tokens。代理可使用沙盒環境執行該程式碼，只讀取結果與其他相關資訊，無需全存在上下文視窗。

  6. 運行時狀態物件 透過創建資訊容器管理代理在任務執行時需要存取特定資訊的情況。對複雜任務而言，這使代理逐步存儲子任務結果，並能保持上下文只連結該特定子任務。

檢查上下文

採用上述策略後，值得檢查下一次模型調用實際接收了什麼。實用的除錯問題是：

代理是否載入太多上下文、載入錯誤的上下文，或遺漏了所需上下文？

您不需記錄原始提示、工具輸出或記憶內容即可回答此問題。在生產環境中，優先使用較小的上下文檢查紀錄，捕捉計數、ID、雜湊和策略標籤：

目標不是保留更多上下文，而是留下足夠證據讓開發者辨識採用了哪種上下文策略，且是否如預期改變了下一次模型調用。

上下文工程範例

假設我們想讓 AI 代理 「幫我訂一趟巴黎之旅。」

• 只用提示工程的簡單代理可能回應：「好的，您想什麼時候去巴黎？」 它只對使用者當時的直接問題做處理。

• 採用本課介紹的上下文工程策略的代理則會做更多。在回應之前，系統可能：

  ◦ 檢查您的行程表以確認可用日期（檢索即時數據）。

 ◦ 回憶過去旅行偏好（來自長期記憶），如偏好的航空公司、預算或是否偏好直飛。

 ◦ 辨識可用工具以便訂機票與飯店。

常見的上下文失敗

上下文中毒

定義： 當幻覺（由 LLM 生成的錯誤資訊）或錯誤資訊進入上下文且被反覆引用，導致代理追求不可能的目標或制定毫無意義的策略。

解決： 實施 上下文驗證與 隔離。在加入長期記憶前驗證資訊。如果偵測到可能的中毒，啟動新的上下文線程以防止錯誤資訊擴散。

旅遊訂票範例： 代理幻覺一條「從小型當地機場到遠方國際城市的直飛航班」，而該機場實則不提供國際航班。此不存在的航班細節被保存在上下文中。當您要求代理訂票時，它持續嘗試找到這條不可能的航線，導致反覆出錯。

解決方案： 在將航班細節加入代理工作上下文之前，利用即時 API 驗證航班是否存在與航線是否合理。若驗證失敗，錯誤資訊將被「隔離」且不再使用。

上下文分心

定義： 當上下文過大，模型過度集中於累積歷史資料，而非利用訓練時學習，導致重複或無益行為。甚至在上下文視窗未滿前，模型可能開始出錯。

解決： 採用 上下文摘要。定期將累積資訊壓縮成更短摘要，保留重要細節並刪除冗餘歷史，有助於「重置」焦點。

旅遊訂票範例： 您已長時間討論多個夢想旅遊目的地，並細數兩年前的背包旅行。當您終於請求「幫我找下個月的廉價機票」時，代理陷入舊有且無關細節，並不斷詢問您的背包裝備或過去行程，忽略當前需求。

解決方案： 在達到一定回合數或上下文過大時，代理應摘要最近且相關的對話內容——聚焦您當前的旅遊日期與目的地——並用濃縮摘要進行下一次 LLM 調用，同時丟棄較不相關的歷史對話。

上下文混淆

定義： 不必要的上下文，往往來自過多可用工具，導致模型生成不良回答或調用不相關的工具。較小模型尤為容易發生。

解決： 實施 工具負載管理，使用 RAG 技術。將工具描述存入向量資料庫，針對每項具體任務僅選擇最相關工具。研究顯示限於 30 個工具以下最佳。

旅遊訂票範例： 您的代理可用工具多達數十個：book_flight、book_hotel、rent_car、find_tours、currency_converter、weather_forecast、restaurant_reservations 等。當您詢問 「巴黎市內最好的交通方式是什麼？」時，因工具數量眾多，代理混淆地嘗試在巴黎市內調用 book_flight 或租車工具，即使您偏好公共交通，工具描述可能重疊或代理難以辨識最適合的工具。

解決方案： 利用 RAG 技術對工具描述進行檢索。當詢問如何在巴黎市內移動時，系統會根據您的查詢動態檢索僅最相關的工具，例如 rent_car 或 public_transport_info，並以此呈現聚焦的工具組給 LLM。

上下文衝突

定義： 當上下文中存在相矛盾資訊，導致推理不一致或最終回應有誤。常見於資訊分批抵達，而早期錯誤假設仍留存上下文。

解決： 採用 上下文修剪與卸載。修剪指移除過時或矛盾資訊，隨新細節到來而更新。卸載則給模型一個獨立的「草稿板」工作空間，於此處理資訊而不使主上下文混亂。

旅遊預訂範例： 您最初告訴您的代理人，「我想搭乘經濟艙。」 後來在對話中，您改變主意說，「其實這次旅行，我們改搭商務艙。」 如果兩個指示都留在上下文中，代理人可能會收到衝突的搜尋結果，或無法判斷優先考慮哪個偏好。

解決方案： 實施上下文修剪。當新指示與舊指示互相矛盾時，較舊的指示將從上下文中移除或明確被覆蓋。或者，代理人可以使用草稿本來調和衝突的偏好，然後再決定，確保只有最終且一致的指示指引其行動。

對上下文工程還有其他疑問嗎？

加入Microsoft Foundry Discord認識其他學習者，參加辦公時間並獲得您對 AI 代理人的問題解答。

上一課

Agentic Protocols

下一課

Memory for AI Agents

免責聲明： 本文件使用 AI 翻譯服務 Co-op Translator 進行翻譯。雖然我們力求準確，但請注意，自動翻譯可能包含錯誤或不準確之處。原始文件的母語版本應被視為權威來源。對於重要資訊，建議尋求專業人工翻譯。我們不對因使用本翻譯而引起的任何誤解或曲解承擔責任。

This site is open source. Improve this page.