ai-agents-for-beginners
為 AI 代理進行情境工程
(點選上方圖片以觀看本課程的影片)
理解你正在為之建構 AI 代理的應用程式之複雜性，對打造可靠的代理非常重要。我們需要建立能有效管理資訊以應對超越提示工程的複雜需求的 AI 代理。
在本課程中，我們將探討什麼是情境工程以及它在構建 AI 代理中的角色。
介紹
本課程將涵蓋：
• 什麼是情境工程 以及為何它不同於提示工程。
• 有效情境工程的策略，包括如何撰寫、選擇、壓縮與隔離資訊。
• 常見的情境失敗，可能破壞你的 AI 代理，以及如何修復它們。
學習目標
完成本課程後，你將會了解如何：
• 定義情境工程 並區分其與提示工程的差異。
• 識別大型語言模型（LLM）應用中的情境關鍵組成要素。
• 應用撰寫、選擇、壓縮與隔離情境的策略 以改善代理效能。
• 辨識常見的情境失敗，例如中毒（poisoning）、分心（distraction）、混淆（confusion）與衝突（clash），並實施緩解技術。
什麼是情境工程？
對於 AI 代理而言，情境驅動代理規劃採取特定行動。情境工程是確保 AI 代理擁有完成下一步任務所需正確資訊的實務。情境視窗大小有限，因此作為代理構建者，我們需要建立系統與流程來管理在情境視窗中新增、移除與凝縮資訊。
提示工程 vs 情境工程
提示工程專注於一組靜態指令，以一組規則有效引導 AI 代理。情境工程則是管理一組動態資訊（包含初始提示），以確保 AI 代理能隨時間擁有所需資料。情境工程的主要理念是讓此流程可重複且可靠。
情境類型
重要的是要記得，情境不只是一件事情。代理所需的資訊可以來自各種不同來源，而確保代理能存取這些來源是我們的工作：
AI 代理可能需要管理的情境類型包括：
• 指示（Instructions）： 這些就像代理的「規則」——提示、系統訊息、少量範例（示範 AI 如何執行某事），以及它可以使用的工具描述。這是提示工程與情境工程交會的重點。
• 知識（Knowledge）： 這涵蓋事實、從資料庫檢索的資訊，或代理累積的長期記憶。如果代理需要存取不同的知識庫與資料庫，這也包括整合檢索增強生成（RAG）系統。
• 工具（Tools）： 這些是代理可以呼叫的外部函式、API 與 MCP Servers 的定義，以及其使用這些工具所獲得的回饋（結果）。
• 對話歷史（Conversation History）： 與使用者的持續對話。隨著時間推移，這些對話會變得更長且更複雜，意味著它們會佔用情境視窗的空間。
• 使用者偏好（User Preferences）： 隨時間學到的使用者喜好或不喜好。這些可以被儲存並在作出重要決策時被調用，以協助使用者。
有效情境工程的策略
規劃策略
良好的情境工程始於良好的規劃。以下是一個能幫助你開始思考如何應用情境工程概念的方法：
- 定義明確結果 - 應指派給 AI 代理的任務結果應明確定義。回答問題——「當 AI 代理完成任務時，世界會是什麼樣子？」換句話說，使用者在與 AI 代理互動後，應該得到什麼變化、資訊或回覆。
- 映射情境 - 一旦你定義了 AI 代理的結果，你需要回答「AI 代理為了完成此任務需要哪些資訊？」藉此你可以開始映射出這些資訊可能位於何處的情境。
- 建立情境管線 - 現在你知道資訊在哪裡，你需要回答「代理將如何取得這些資訊？」這可以透過多種方式完成，包括 RAG、使用 MCP 伺服器與其他工具。
實務策略
規劃很重要，但一旦資訊開始流入我們代理的情境視窗，我們需要實務策略來管理它：
管理情境
雖然有些資訊會自動新增到情境視窗，但情境工程在於更積極地處理這些資訊，這可以透過幾種策略完成：
-
代理草稿區（Agent Scratchpad） 這允許 AI 代理在單一會話期間記錄與當前任務和使用者互動相關的筆記。這應該存在於情境視窗之外，例如檔案或執行時物件，代理若需要可以在此會話中稍後檢索。
-
記憶（Memories） 草稿區適合管理單一會話情境視窗之外的資訊。記憶使代理能跨多個會話儲存與檢索相關資訊。這可能包括摘要、使用者偏好與改進回饋。
-
壓縮情境（Compressing Context） 一旦情境視窗成長並接近上限，可使用如摘要與修剪等技術。這包括僅保留最相關的資訊或刪除較舊的訊息。
-
多代理系統（Multi-Agent Systems） 開發多代理系統是一種情境工程，因為每個代理有其自己的情境視窗。當建構這些系統時，如何共享與傳遞該情境到不同代理是另一個需要規劃的面向。
-
沙盒環境（Sandbox Environments） 若代理需要執行程式碼或處理大量文件資訊，這可能會消耗大量 token 來處理結果。與其將所有結果儲存在情境視窗中，代理可以使用能執行該程式碼的沙盒環境，並僅讀取結果與其他相關資訊。
-
執行時狀態物件（Runtime State Objects） 這是透過建立資訊容器來管理代理需要存取特定資訊的情況。對於複雜任務，這將允許代理一步一步儲存每個子任務的結果，使情境僅與特定子任務保持連結。
情境工程範例
假設我們想讓 AI 代理 「幫我預訂一趟巴黎行程。」
• 一個僅使用提示工程的簡單代理可能只會回覆：“好，您想何時去巴黎？“。它只處理使用者當下提出的直接問題。
• 使用我們所討論的情境工程策略的代理會做更多事情。在回覆之前，它的系統可能會：
◦ 檢查你的行事曆 以找出可用日期（檢索即時資料）。
◦ 回想過去的旅遊偏好（來自長期記憶），例如你偏好的航空公司、預算或是否偏好直飛。
◦ 識別可用工具 用於訂機票與訂旅館。
- 然後，一個範例回覆可能是： “嗨 [您的名字]！我看到你在十月的第一週有空。要我在你偏好的航空公司內、以你平常的預算幫你找直飛巴黎的航班嗎？”。這種更豐富、具有情境感知的回覆展示了情境工程的威力。
常見的情境失敗
情境中毒（Context Poisoning）
定義： 當一個幻覺（LLM 生成的錯誤資訊）或錯誤進入情境並被反覆引用時，會導致代理追求不可能的目標或發展出荒謬策略。
處理方式： 實作 情境驗證（context validation） 與 隔離（quarantine）。在將資訊加入長期記憶前先驗證。如果偵測到潛在中毒，啟動新的情境線程以防止錯誤資訊擴散。
旅遊預訂範例： 你的代理幻覺出現一條 從某個小型地方機場到遙遠國際城市的直飛班機，但該小型機場實際上並不提供國際航班。這個不存在的航班細節被儲存在情境中。稍後，當你要求代理訂票時，它持續嘗試找到這條不可能的航線，導致反覆錯誤。
解決方案： 在將航班詳情加入代理的工作情境前，實作一步 使用即時 API 驗證航班與航線是否存在。若驗證失敗，將錯誤資訊「隔離」，不再使用。
情境分心（Context Distraction）
定義： 當情境變得非常龐大時，模型會過度關注累積的歷史，而非使用訓練時學到的知識，導致重複或無用的行為。模型可能在情境視窗尚未滿之前就開始犯錯。
處理方式： 使用 情境摘要（context summarization）。定期將累積資訊壓縮成較短的摘要，保留重要細節並移除冗贅的歷史。這有助於「重設」焦點。
旅遊預訂範例： 你已經討論過很多夢想旅遊地點，包括兩年前背包旅行的詳細敘述。當你終於要求 “替我找下個月的便宜機票” 時，代理被舊的無關細節拖累，不斷詢問你的背包裝備或過去行程，而忽略你當前的需求。
解決方案： 在達到一定回合數或情境過大時，代理應 將最近且相關的對話部分進行摘要——聚焦於你當前的旅行日期與目的地——並在下一次 LLM 呼叫時使用該濃縮摘要，棄用較不相關的歷史對話。
情境混淆（Context Confusion）
定義： 不必要的情境，通常以太多可用工具的形式出現，導致模型產生錯誤回應或呼叫不相關的工具。較小的模型尤其容易出現這種情況。
處理方式： 使用 RAG 技術實作 工具載入管理（tool loadout management）。將工具描述儲存在向量資料庫中，並為每個特定任務僅選擇最相關的工具。研究顯示，將工具選擇限制在少於 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 提供一個聚焦的工具「配置」。
情境衝突（Context Clash）
定義： 當情境中存在相互衝突的資訊時，會導致推理不一致或糟糕的最終回覆。這常發生於資訊分階段到達，而早期的錯誤假設仍保留在情境中。
處理方式： 使用 情境修剪（context pruning） 與 卸載（offloading）。修剪即在新細節到達時移除過時或衝突的資訊。卸載則給模型一個獨立的「草稿區」工作空間，以便在不汙染主情境的情況下處理資訊。
旅遊預訂範例： 你最初告訴代理，“我想搭經濟艙。” 在對話稍後，你改變心意說，“其實這次我們改訂商務艙。” 如果兩者指示都保留在情境中，代理可能會收到衝突的搜尋結果或無法判定優先使用哪個偏好。
解決方案： 實作 情境修剪。當新指示與舊指示相矛盾時，舊指示會被移除或在情境中被明確覆寫。或者，代理可以使用 草稿區 來協調衝突的偏好，再決定最終優先順序，確保僅以最終一致的指示來引導後續行動。
還有更多關於情境工程的問題嗎？
加入 Microsoft Foundry Discord 與其他學習者交流、參加辦公時間並讓你的 AI 代理相關問題獲得解答。
免責聲明： 本文件係使用 AI 翻譯服務 Co‑op Translator（https://github.com/Azure/co-op-translator）進行翻譯。雖然我們力求準確，但請注意，自動翻譯可能包含錯誤或不準確之處。原始語言的文件應視為具權威性的版本。對於重要資訊，建議採用專業人工翻譯。我們不對因使用此翻譯而產生的任何誤解或誤譯承擔任何責任。