傳統的檢索增強生成（RAG）通常採用單次檢索加單次生成的模式：將問題嵌入，從一個索引中獲取最近鄰的文本塊，交給模型生成答案。這種設計對於許多簡單問題是有效的，但當答案需要跨多個語料庫，或者需要根據問題選擇不同資料來源，又或者需要在看到初步結果後再次檢索時，單次檢索就會失效——模型可能返回流暢但不完整的答案，甚至無法找到正確的資訊。
企業級代理式檢索透過引入一個推理代理來解決這些問題。代理決定是否需要檢索、應該查詢哪個知識庫、以及在生成答案前是否需要再次檢索。亞馬遜雲科技近期推出的託管知識庫（Managed Knowledge Base）將這一能力變為服務的一等公民：AgenticRetrieveStream API 能夠執行多輪規劃、工具驅動的檢索，並返回帶有引用的可靠答案。與傳統的客戶管理（DIY）知識庫相比，託管知識庫自動處理資料攝取、儲存、索引和檢索，包括嵌入和重排序，無需使用者預置或管理向量資料庫。此外，代理式檢索和 AgentCore Gateway 整合僅在託管知識庫上可用，使其成為構建企業級代理式檢索的理想基礎。
然而，代理式系統也帶來了更復雜的運維挑戰。由於代理對每個問題的處理路徑可能不同，預設情況下很難觀察其行為或評估答案質量。因此，可觀測性和評估不再是可選項，而是確保系統可靠執行的必要組成部分。本文介紹的解決方案透過 AWS CDK 部署，包含兩個 CloudWatch 儀表板，覆蓋七層遙測資料，並提供按需和持續兩種評估方式，所有基礎設施即程式碼定義，一鍵部署。
架構上，整個系統由四個 CDK 堆疊組成。知識庫堆疊建立兩個託管知識庫（分別對應金融和天氣語料庫），並從 S3 自動攝取資料。閘道器堆疊建立 AgentCore Gateway，將每個知識庫暴露為 MCP 工具。代理堆疊在 AgentCore Runtime 上部署推理代理，該代理根據問題路由到相應的知識庫工具。最後，可觀測性堆疊配置儀表板和評估機制。堆疊間的依賴關係透過 CDK 的構造引用自動推導，無需手動管理部署順序。
當使用者提出問題時，代理首先在執行時中接收請求，其推理模型規劃並選擇合適知識庫工具。工具呼叫透過 AgentCore Gateway 使用 MCP 協議代理，並由 IAM 角色授權和 SigV4 簽名，最終呼叫託管知識庫的 AgenticRetrieveStream API。該 API 在知識庫內部進行問題分解、迭代檢索和答案合成，返回帶有引用的答案。代理檢查返回的上下文是否充分，若不足則迴圈再次檢索，直到生成最終答案。整個過程產生的跟蹤資料、令牌計數和指標傳送到 CloudWatch 和 X-Ray，支撐七層可觀測性和評估評分。
與 2024 年釋出的單次檢索方案相比，本方案消除了對 OpenSearch Serverless 集合和 OCU 容量的需求，檢索變為代理式，且近一半的資源用於監控代理行為。對於需要複用現有向量儲存或滿足特定資料駐留、調優及合規要求的情況，客戶管理知識庫仍是合適選擇；但對於企業級代理式檢索，託管知識庫是實現該能力的關鍵。透過 CDK 部署，開發者可以專注於業務邏輯，而將基礎設施的複雜性和依賴管理交給框架處理。