ai-agents-for-beginners
AI 代理的情境工程
(點擊上方圖像觀看本課程的影片)
了解您為之構建 AI 代理的應用程式之複雜性，對於打造可靠的代理十分重要。我們需要構建能有效管理資訊以應對超出提示工程範疇之複雜需求的 AI 代理。
在本課程中，我們會探討什麼是情境工程及其在建立 AI 代理中的角色。
介紹
本課程將涵蓋：
• 什麼是情境工程 以及它為何不同於提示工程。
• 有效情境工程的策略，包括如何撰寫、選擇、壓縮與隔離資訊。
• 常見的情境失敗，可能會使您的 AI 代理失效，以及如何修復它們。
學習目標
完成本課程後，您將了解如何：
• 定義情境工程 並將其與提示工程區分。
• 識別 LLM 應用中情境的關鍵組成部分。
• 套用撰寫、選取、壓縮與隔離情境的策略 以改善代理效能。
• 辨識常見的情境失敗，例如中毒、分散注意力、混淆與衝突，並實施緩解技術。
甚麼是情境工程？
對於 AI 代理而言，情境是驅動代理規劃採取特定行動的依據。情境工程是確保 AI 代理擁有完成下一步任務所需正確資訊的實務。情境視窗（context window）大小有限，因此作為代理的建立者，我們需要建立系統與流程來管理情境視窗中資訊的加入、移除與濃縮。
提示工程 vs 情境工程
提示工程專注於一組靜態的指令，以一組規則有效引導 AI 代理。情境工程則是管理一組動態資訊（包括初始提示）的方式，確保 AI 代理隨時間擁有所需的資訊。情境工程的主要概念是使這個流程可重複且可靠。
情境的類型
重要的是要記住，情境不是單一的東西。AI 代理所需的資訊可以來自各種不同來源，而確保代理能存取這些來源是我們的責任：
AI 代理可能需要管理的情境類型包括：
• 指示： 這些像是代理的「規則」——提示、系統訊息、few-shot 範例（示範 AI 如何做某事），以及它可以使用的工具描述。這裡是提示工程與情境工程結合的重點所在。
• 知識： 包含事實、從資料庫擷取的資訊，或代理累積的長期記憶。若代理需要存取不同的知識庫與資料庫，這也包括整合檢索增強生成 (RAG) 系統。
• 工具： 這些是代理可以呼叫的外部函數、API 與 MCP 伺服器的定義，以及使用它們時所得的回饋（結果）。
• 對話歷史： 與使用者的持續對話。隨著時間流逝，這些對話會變得更長、更複雜，意味著它們佔據情境視窗的空間。
• 使用者偏好： 關於使用者喜好或不喜好的資訊，隨時間習得。這些可以儲存並在做出關鍵決策時調用，以幫助使用者。
有效情境工程的策略
規劃策略
良好的情境工程始於良好規劃。以下方法將幫助您開始思考如何應用情境工程的概念：
-
定義明確結果 - AI 代理將被指派的任務結果應明確定義。回答問題 —「當 AI 代理完成其任務時，世界會是什麼樣子？」換句話說，使用者在與 AI 代理互動後，應該得到什麼變化、資訊或回應。
-
繪製情境地圖 - 一旦您定義了 AI 代理的結果，您需要回答「AI 代理為完成此任務需要哪些資訊？」這樣您就可以開始繪製該資訊可能位於何處的情境地圖。
-
建立情境管線 - 既然您知道資訊在哪裡，您需要回答「代理將如何獲取這些資訊？」這可以透過各種方式完成，包括 RAG、使用 MCP 伺服器與其他工具。
實務策略
規劃很重要，但一旦資訊開始流入我們代理的情境視窗，我們需要實際的策略來管理它：
管理情境
雖然有些資訊會自動加入情境視窗，情境工程是指對這些資訊採取更主動的管理，這可以透過幾種策略完成：
-
Agent Scratchpad 這允許 AI 代理在單一會話期間記錄與當前任務和使用者互動相關的筆記。這應存在於情境視窗之外的檔案或執行時物件中，代理之後在此會話需要時可檢索。
-
Memories Scratchpad 適合管理單一會話之外的資訊。記憶使代理能在多個會話間儲存與擷取相關資訊。這可能包含摘要、使用者偏好與改進回饋。
-
Compressing Context 一旦情境視窗成長並接近其限制，可以使用如摘要與修剪等技術。這包括只保留最相關的資訊或移除較舊的訊息。
-
Multi-Agent Systems 開發多代理系統也是一種情境工程，因為每個代理都有自己的情境視窗。如何分享與傳遞該情境給不同的代理，是建立這些系統時需要規劃的另一件事。
-
Sandbox Environments 如果代理需要執行一些程式碼或在文件中處理大量資訊，處理結果可能需要大量 token。與其將這些全部儲存在情境視窗中，代理可以使用能執行程式碼的沙箱環境，僅讀取結果和其他相關資訊。
-
Runtime State Objects 透過建立資訊容器來管理代理需要存取特定資訊的情況。對於複雜任務，這可使代理逐步儲存每個子任務的結果，讓情境僅與該特定子任務保持關聯。
情境工程範例
讓我們假設要 AI 代理幫我 “幫我訂一趟巴黎之旅。”
• 一個僅使用提示工程的簡單代理可能只會回應： “好的，你想何時去巴黎？“。它只處理使用者提出的直接問題。
• 使用本課所述情境工程策略的代理會做更多事。在回應之前，其系統可能會：
◦ 檢查你的行事曆 以確認可用日期（擷取即時資料）。
◦ 回想過去的旅行偏好（來自長期記憶），例如你偏好的航空公司、預算或是否偏好直飛。
◦ 識別可用的工具 用於機票和飯店預訂。
- 然後，一個範例回應可能是： “Hey [Your Name]! I see you’re free the first week of October. Shall I look for direct flights to Paris on [Preferred Airline] within your usual budget of [Budget]?”. 這種更豐富、具情境感知的回應展示了情境工程的威力。
常見的情境失敗
情境污染
它是甚麼： 當模型產生的幻覺（由 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 代理的問題解答。
免責聲明： 本文件乃使用人工智慧翻譯服務 Co-op Translator（https://github.com/Azure/co-op-translator）進行翻譯。儘管我們力求準確，但請注意自動翻譯可能包含錯誤或不準確之處。原始語言版本應視為具權威性的版本。對於重要資訊，建議採用專業人工翻譯。我們不對因使用本翻譯而產生的任何誤解或誤釋承擔責任。