擴展 Amazon Bedrock AgentCore Gateway 對 MCP 的支持

在企業中部署模型上下文協議（MCP）服務器時，需要跨服務器的細粒度訪問控制、團隊使用工具的可見性、防止數據泄露的安全保障以及集中式憑證管理，所有這些都需要大規模實現。Amazon Bedrock AgentCore Gateway 位於 MCP 服務器和消費它們的客户端之間，將憑證管理、可觀測性和安全連接集中到一個可信入口點。

今天，我們為 AgentCore Gateway 增加了新功能，進一步強化了對企業 MCP 部署的支持。本文涵蓋了擴展的 MCP 工具模式支持、將 MCP 提示和資源作為一等原語、用於運行時發現 MCP 服務器的動態列表、支持有狀態實時交互的流式傳輸和會話管理、執行中請求輸入的獲取，以及用於委託認證的 OAuth 2.0 令牌交換。動手示例請訪問 GitHub 示例倉庫。

通過 AgentCore Gateway 統一企業的 MCP 服務器

如果沒有集中式網關，組織構建的每個 MCP 服務器都必須獨立處理憑證、策略執行、私有連接和日誌記錄。這意味着法律團隊的合同審查 MCP 服務器、財務團隊的數據檢索 MCP 服務器、運營團隊的應急響應 MCP 服務器都承擔着相同的基礎設施負擔。安全團隊逐個審查每台服務器，開發人員等待審批，沒有人能統一瞭解整個組織中 MCP 基礎設施的使用情況。

AgentCore Gateway 通過建立一個 MCP 流量流經的單一入口點來避免這種重複。下圖展示了 AgentCore Gateway 的主要功能，允許集中治理和控制。

每個團隊只需構建其 MCP 服務器的業務邏輯。AgentCore Gateway 處理其他所有事務。它聚合了不同目標類型的能力，包括 MCP 服務器、REST API、AWS Lambda 函數等。基於資源的策略（RBP）控制誰可以調用 AgentCore Gateway，例如限制調用到 Amazon VPC。服務控制策略（SCP）管理如何在 AWS 組織中維護 AgentCore Gateway。

為了網絡隔離，AgentCore Gateway 支持 AWS PrivateLink 用於控制平面和數據平面操作，使流量保持在 VPC 邊界內。您還可以通過託管 VPC 資源模式連接到私有 API 端點或 MCP 服務器。集中式應用程序和身份日誌幫助管理審計和合規要求。

藉助攔截器功能，AWS Lambda 函數可以自定義請求和響應，實現細粒度訪問控制、數據清洗、自定義授權邏輯等。與 AgentCore Policy（預覽版）的集成提供了以工具為中心的智能體護欄，在集中平面上實現確定性策略執行。AgentCore Gateway 還有助於促進 OAuth 2.0 授權碼流程，其中智能體在調用工具之前代表用户進行身份驗證。

現在，我們將介紹 AgentCore Gateway 新增的功能，進一步加強企業 MCP 支持。

通過單一網關展示你的 MCP 服務器原語

AgentCore Gateway 成為一個單一的 MCP 端點，聚合組織中每個 MCP 服務器的能力。客户端看到一個統一的工具目錄、一個提示庫和一個資源命名空間，無需管理 20 個單獨連接。在底層，AgentCore Gateway 支持所有三種 MCP 原語：工具、提示和資源。MCP 中的工具定義包括可選的 outputSchema 用於定義預期輸出結構，以及描述行為屬性（如工具是隻讀還是破壞性）的註釋，此外還有標準名稱、圖標、描述和 inputSchema。該網關還通過其完整的 MCP 方法集支持提示、資源和資源模板：tools/list、tools/call、prompts/list、prompts/get、resources/list、resources/read 和 resources/templates/list。下圖展示了 AgentCore Gateway 如何促進列表和調用操作。

在默認列表模式下，AgentCore Gateway 發現並緩存來自連接的 MCP 服務器目標的工具、提示和資源。此緩存在您調用 CreateGatewayTarget 或 UpdateGatewayTarget 時會隱式刷新，並可以使用 SynchronizeGatewayTargets API 顯式刷新。當客户端進行列表調用（如 tools/list、prompts/list 或 resources/list）時，AgentCore Gateway 直接從該緩存返回響應，而不調用 MCP 服務器目標。與 MCP 服務器目標的實際交互僅發生在調用操作期間：tools/call、prompts/get 和 resources/read。此時，AgentCore Gateway 將請求路由到正確的目標。

AgentCore Gateway 返回的工具和提示會以目標名稱前綴 targetName___ 的形式出現。與工具和提示不同，資源 URI 返回時不帶目標名稱前綴，直接傳遞來自下游 MCP 服務器的原始 URI。在創建公開資源的 MCP 服務器目標時，您可以選擇指定 resourcePriority 值（1–1000），以控制當多個目標公開相同資源 URI 時 AgentCore Gateway 如何解決衝突。如果未定義優先級，則應用默認值 1000。當發生衝突時，AgentCore Gateway 返回 resourcePriority 值最低的目標中的資源。如果兩個衝突資源具有相同優先級，則返回首先同步的目標中的資源。

由於資源 URI 由下游 MCP 服務器目標提供，且 AgentCore Gateway 不進行驗證或清理，因此對不受信任的目標需謹慎。惡意或被攻破的 MCP 服務器可能返回指向內部端點或本地文件系統路徑的 URI。在遵循資源 URI 之前，請驗證並清理它們，不要自動從不受信任的 MCP 服務器目標獲取或渲染 URI。

用於運行時靈活性的動態列表

某些 MCP 服務器會根據用户個性化其能力。權限感知服務器可能只向管理人員公開 approve_expense，或多租户服務器可能僅為醫療保健客户公開符合 HIPAA 的工具。動態列表允許您在仍通過 AgentCore Gateway 路由的同時保留服務器端訪問控制。

創建目標時，您可以在兩種列表模式之間選擇：默認和動態。在默認列表模式下，AgentCore Gateway 在 CreateGatewayTarget 或 UpdateGatewayTarget 操作期間調用 MCP 服務器，以發現並緩存工具、提示和資源。此緩存可以使用 SynchronizeGatewayTargets API 顯式刷新。當客户端進行列表調用時，AgentCore Gateway 直接從該緩存提供響應，而無需聯繫後端服務器。在動態列表模式下，AgentCore Gateway 在 CreateGatewayTarget 或 UpdateGatewayTarget 操作期間不調用 MCP 服務器。相反，列表調用會在請求時使用調用用户的身份實時轉發到 MCP 服務器。在兩種模式下，調用操作（如 tools/call、prompts/get 和 resources/read）都直接路由到 MCP 服務器目標。下圖説明了兩種模式如何協同工作。

MCP 服務器 1 配置為動態列表模式，而 MCP 服務器 2 和 3 使用默認列表模式。AgentCore Gateway 緩存僅包含來自默認模式服務器的能力。在列表調用期間，響應是分頁的；緩存的原始數據和 MCP 服務器 1 的原始數據在不同頁面上返回。由於動態列表目標的原始數據未在 AgentCore Gateway 中建立索引，因此無法使用語義工具搜索功能。

這種雙模式架構還為您提供了多租户和細粒度訪問控制的靈活性。對於兩種列表模式，您可以使用 AgentCore Policy 或 AWS Lambda 響應攔截器集中實施策略，以根據租户身份過濾能力。例如，您可以限制租户僅查看只讀工具。對於動態列表模式，您可以直接在 MCP 服務器本身管理訪問控制，因為列表操作在最終用户身份下執行，並且 MCP 服務器目標僅返回該用户有權訪問的能力。

流式傳輸、會話管理和請求獲取

許多企業 MCP 工作流超越了簡單的請求-響應工具調用。MCP 服務器可能需要在生成報告時流式傳輸進度更新，在執行敏感操作前暫停以請求用户批准，或者在跨越多個工具調用的多步驟對話中維護上下文。AgentCore Gateway 支持 Streamable HTTP 傳輸、MCP 會話管理和請求獲取，從而支持有狀態、實時、人在迴路的交互。

Streamable HTTP

沒有流式傳輸時，耗時 45 秒的工具調用直到完成才返回任何內容，用户只能盯着轉圈圖標。有了流式傳輸，他們可以實時看到進度事件。當客户端發送帶有 Accept: application/json, text/event-stream 的 tools/call 請求時，AgentCore Gateway 打開一個 SSE 流，並實時轉發來自 MCP 服務器目標的事件，包括進度通知、日誌消息和最終工具結果。僅發送 Accept: application/json 的客户端繼續接收單個 JSON 響應，保持完全向後兼容。

當在 AgentCore Gateway 上啓用響應流式傳輸時，響應攔截器行為會發生變化，必須檢查 gatewayResponse 中的 isStreamingResponse 字段，以區分流式和非流式響應。響應攔截器針對包含 JSON-RPC id 字段的事件調用。響應攔截器不會為 notifications/progress、notifications/message 和 pings 調用。要啓用流式傳輸，請在 CreateGateway 或 UpdateGateway API 調用中設置 enableResponseStreaming 塊。

"protocolConfiguration": { "mcp": { "streamingConfiguration": { "enableResponseStreaming": true } } }

在考慮 AgentCore Gateway 的流式傳輸用例時，請記住以下幾點。AgentCore Gateway 根據流中的第一個事件確定 HTTP 狀態碼。如果流中間發生錯誤，它將以 SSE 幀內的 JSON-RPC 錯誤對象形式傳遞，而不是 HTTP 狀態碼，因為狀態碼已經發送。流前的錯誤（如身份驗證失敗、限流或驗證錯誤）將作為標準 JSON-RPC 錯誤響應返回，不帶 SSE 幀。

會話管理

會話管理為 AgentCore Gateway 引入了有狀態的多輪工作流。啓用會話後，AgentCore Gateway 在第一個 initialize 請求時生成 Mcp-Session-Id，並將其作為響應頭返回。客户端在後續請求中包含此頭，使 AgentCore Gateway 能夠跟蹤客户端交互、維護與下游 MCP 服務器會話的映射，並在工具調用之間關聯請求獲取。

要啓用會話，請在 CreateGateway 或 UpdateGateway API 調用中添加 sessionConfiguration 塊。您可以將會話超時配置為最少 15 分鐘到最長 8 小時。默認是 1 小時。

"protocolConfiguration": { "mcp": { "sessionConfiguration": { "sessionTimeoutInSeconds": 3600 } } }

會話範圍限定為經過身份驗證的用户。AgentCore Gateway 從授權上下文、OAuth 入站的 JWT 承載令牌或 AWS_IAM 入站的 IAM 憑證派生用户身份，並驗證會話中的每個請求是否來自同一用户。這有助於防止會話劫持。