上一頁展示了中介軟體如何以橫切關注點包裹代理的執行流程，像是日誌記錄、防護措施、錯誤處理，但不觸及代理核心邏輯。 但中介軟體處理的是代理執行的方式，而不是代理本身的認知。 到目前為止，代理人的知識來自兩個來源：訓練資料和使用者在當前回合說的話。
這可是個問題。 一個有用的經紀人需要的不只是這些。 它需要回想三回合前使用者說過什麼、了解使用者偏好，或從知識庫中提取相關事實——這些都在開始產生回應 之前 。 工具可以擷取資訊，但牠們是被動的：模型必須決定是否呼叫它們。 如果模型不意識到需要上下文，它就不會要求。
情境提供者能解決這個問題。 它們是會在每次代理呼叫前後執行的元件，主動將相關資訊注入上下文視窗，並可選擇從回應中擷取狀態以儲存以備未來使用。 它們賦予你的客服人員記憶力、個人化功能，以及對外部知識的存取——而不必更改客服的指示或程式碼。
何時使用
在以下情況下，為您的代理人新增情境提供者：
- 代理人需要對話 紀錄 ——它應該記得之前回合說過的內容，而不只是當前訊息。
- 你想注入 使用者專屬資料 ——個人資料、偏好設定、帳號細節或會話狀態——讓代理能個人化回應。
- 你需要檢索增強生成模型（RAG），即在每次回應前自動從知識庫取得相關文件或事實。
- 代理程式需要 動態指令 ——根據時間、使用者位置或其他執行時條件，在呼叫間的上下文會改變。
- 你想將 資料來源與代理邏輯解耦 ——代理 不需要知道上下文 來源，只要知道它是否可用即可。
為什麼不直接用工具呢？
工具與情境提供者都讓代理者存取外部資訊，但其運作方式根本不同：
| 層面 | 工具 | 上下文提供者 |
|---|---|---|
| Trigger | 反應式 — 模型決定何時呼叫工具 | 主動式 — 每次呼叫前自動執行 |
| 控制 | 模型驅動：模型選擇工具、時間及參數 | 開發者主導：由你決定哪些上下文永遠可用 |
| 可視性 | 模型必須知道工具的存在，並判斷其相關性 | 上下文是透明注入的——模型將它視為提示的一部分 |
| 應用案例 | 按需操作與查詢：「搜尋網頁」、「查詢資料庫」 | 始終存在的上下文：對話歷史、使用者資料、預先載入的知識 |
| 代幣成本 | 代幣只有在工具被呼叫時才會花費 | 每次召喚所花費的代幣（上下文總是在提示中） |
兩者都沒有絕對優越。 許多客服人員同時使用：情境提供者提供應 始終 存在的資訊（歷史紀錄、使用者資料、核心知識），以及工具來提供客服應 隨時 取得的資訊（即時搜尋結果、資料庫查詢、API 呼叫）。
小提示
一個不錯的經驗法則：如果代理每次執行時都應該有 此資訊，就使用上下文供應者。 如果代理人只在 相關時才取得，請使用工具。
情境提供者的運作方式
上下文提供者參與每個代理呼叫的兩階段生命週期：
┌──────────────────────────────────────────────────────────────┐
│ Caller: agent.run("What's the return policy?") │
└──────────────┬───────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ BEFORE RUN — each context provider injects context │
│ │
│ • History provider loads past conversation messages │
│ • Memory provider retrieves relevant facts/preferences │
│ • RAG provider searches knowledge base and adds results │
│ • Custom provider injects user profile, time, location │
└──────────────┬───────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ Agent core — model sees original input + all injected │
│ context and generates a response │
└──────────────┬───────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ AFTER RUN — each context provider processes the response │
│ │
│ • History provider saves the new messages │
│ • Memory provider extracts facts to remember for later │
│ • Custom provider updates session state │
└──────────────────────────────────────────────────────────────┘
關鍵點：
- 情境供應者會自動執行。 建立代理人時只需註冊一次。 之後，他們會參與每次的調用，而不需要你撰寫額外的程式碼。
- 多家供應商共同編寫。 你可以註冊多個情境提供者——歷史提供者、RAG 提供者和自訂提供者——它們都會貢獻到同一個上下文視窗。 他們的貢獻依註冊順序合併。
- 提供者有兩個鉤子。 Before 掛鉤會為提示注入上下文（訊息、指示、工具）。 之後的鉤子處理回應——儲存訊息、提取記憶或更新狀態。
- 提供者具有會話狀態感知能力。 情境提供者會接收當前會話，以便載入並儲存針對特定對話範圍的資料。 請參閱 Sessions 以 了解 session 管理的運作方式。
小提示
欲詳細了解上下文提供者在完整代理執行流程中的位置——與中介軟體及聊天客戶端並列——請參閱 代理流程架構。
管理上下文視窗
你注入的每一個上下文都會消耗模型上下文視窗的代幣。 歷史隨著每一個轉折而成長。 RAG 結果會添加文件區塊。 使用者設定檔會新增元資料。 若總數超過模型限制，最舊或最不相關的資訊會被截斷——可能會失去重要的上下文。
使用上下文視窗管理是使用上下文提供者時的重要考量： 壓縮 策略會彙整或修剪舊歷史，以保持在標記限制內同時保留關鍵資訊。 參見整合。
小提示
若想親手操作記憶與情境提供者，請參考「入門」教學中的 第四步：記憶 。
這很重要
不建議維持過長的上下文視窗，因為隨著上下文視窗擴大，模型效能可能會下降。 如果代理開始出現效能下降，可以考慮使用壓縮策略來縮小上下文大小。
考慮事項
| 考量事項 | 詳細資料 |
|---|---|
| 代幣預算 | 每個注入的上下文都會消耗代幣。 仔細監控整體情境大小——尤其是在合併多個提供者時。 如果上下文無限膨脹，重要資訊就會被悄悄地截斷。 |
| 檢索延遲 | 查詢外部服務（資料庫、搜尋索引、API）的上下文提供者會增加每次調用的延遲。 使用快取、連線池和非同步處理操作，以保持檢索的快速性。 |
| Relevance | 注入無關上下文不僅浪費代幣，還可能透過稀釋訊號來削弱模型的回應。 確保你的醫療提供者注入有針對性且相關的資訊。 |
| 過時性 | 快取或預載的上下文可能會過時。 設計供應商在適當間隔刷新資料，並考慮稍微陳舊的上下文是否適合你的使用情境。 |
| 可組合性 | 當多個提供者同時貢獻於同一情境視窗時，他們的貢獻可能會以意想不到的方式互動。 應同時測試醫師，而非個別測試，以確保綜合情境合理。 |
下一步
現在你的代理人擁有工具、技能、中介軟體和上下文提供者，下一步就是將 代理人當作工具 ——透過使用一個代理人作為另一個代理人的工具來組合代理人，實現專業化與委派。
深入探討：