傳統的檢索增強生成（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 部署，開發者可以專注於業務邏輯，而將基礎設施的複雜性和依賴管理交給框架處理。