擴充套件 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 憑證派生使用者身份，並驗證會話中的每個請求是否來自同一使用者。這有助於防止會話劫持。