将托管在 AgentCore Runtime 上的 MCP 服务接入 Amazon Quick：架构、能力与上手要点

一、这是什么：MCP、AgentCore Runtime 与 Amazon Quick 三者的关系

Model Context Protocol（MCP，模型上下文协议）是一套面向基础模型的标准化协议，用于让 AI 智能体访问外部数据、工具和服务，覆盖文件、数据库、API 等多种资源形态。它通过统一的接口让模型获得真实世界应用的操作能力，并支持有状态的多轮交互，从而减少模型在没有准确上下文时产生的“幻觉”。

Amazon Bedrock AgentCore 是一套面向生成式 AI 应用的全托管服务套件，其中与本文直接相关的两个组件是：

AgentCore Runtime：全托管的无服务器运行时，适合托管 MCP 服务，具备会话隔离、较长执行时间、持久化文件系统、内置身份认证、可观测性、增强载荷、双向流式传输以及评估等能力。
AgentCore Gateway：在 MCP 服务与上层客户端之间扮演安全网关与连接器角色，统一处理鉴权、协议转换与目标注册。

Amazon Quick 是面向业务用户的 AI 助手形态，提供聊天代理和工作流两类界面，已经支持 MCP 集成，可用于自主执行、实时数据访问以及专用 AI 子智能体能力的调用。

三者串联后的整体形态是：用户通过 Amazon Quick 触发对话或自动化操作 → 请求经由 Amazon Quick 的连接器进入 AgentCore Gateway → Gateway 完成鉴权与协议适配 → 调用托管在 AgentCore Runtime 上的 MCP 服务，再把工具调用结果回传给上层应用。

二、关键能力与技术原理

1. MCP 服务的能力边界

MCP 服务本身负责承载具体工具与子智能体能力，例如订单查询、订单更新、数据库检索、文件读写等。每个工具通过装饰器或等效的注册方式被声明为可供模型调用的函数。这种设计让工具的复用不再依赖“为每个客户端重写一份”，从而显著降低 AI 工具的重复建设。

2. AgentCore Runtime 对 MCP 的承载方式

AgentCore Runtime 在协议层面对 MCP 有两个明确约定：

容器需要把 MCP 服务监听在 0.0.0.0:8000/mcp 这一默认路径上，这与主流 MCP 服务 SDK 的默认行为一致。
服务需以 stateless_http=True 的无状态 HTTP 模式运行，以保证与 AgentCore Runtime 的兼容。

满足这两个条件后，MCP 服务即可被打包成容器镜像，在 Runtime 上以无服务器形态运行，无需自行管理底层服务器或扩缩容。

3. 双层鉴权：Inbound Auth 与 Outbound Auth

整套方案在安全上区分两条独立的鉴权链路：

Inbound Auth（入站鉴权）：从 Amazon Quick 到 AgentCore Gateway 这一段，负责对发起请求的用户进行身份认证。常见做法是使用 Amazon Cognito 用户池作为身份提供方，并通过 JWT 完成鉴权。
Outbound Auth（出站鉴权）：从 AgentCore Gateway 到 AgentCore Runtime 上的 MCP 服务这一段，属于机器对机器（M2M）的鉴权。由于 MCP 协议当前要求使用 OAuth 2.0，因此这一链路依赖 AgentCore Identity 创建 OAuth 客户端，并结合第二个 Amazon Cognito 用户池颁发的凭据完成认证。

两条链路都使用受保护的自定义 scope（如 invoke），并且端到端默认启用 TLS，在不写额外安全代码的前提下就能满足多数企业级部署对传输与认证的基本要求。

4. 工具注册与同步

当 Amazon Quick 端完成 MCP 集成后，连接器会先调用 listTools 拉取可用工具列表，并将每个工具同步为可被聊天代理或工作流调用的 Action。只有 Action 进入 Available 或 Ready 状态后，才可以在对话或自动化流中被实际触发。

三、相对“上一代”方案的差异

在 AgentCore Runtime 出现之前，把外部能力接入到类似 Amazon Quick 的产品中通常有两条老路径：

直接对接自有 REST API：如果你已经拥有 REST 接口或托管在 Amazon API Gateway 上的服务，可以让 Amazon Quick 通过 AgentCore Gateway 直接对接该 API。
使用 AWS Lambda：如果偏好无服务器架构，且 AI 智能体只需要最基础的执行能力，可以编写 Lambda 函数并通过 AgentCore Gateway 接入。

相对这两条路径，把 MCP 服务托管在 AgentCore Runtime 上的差异主要体现在：

协议原生：MCP 是行业正在快速形成的标准化协议，AgentCore Runtime 提供的是“原生 MCP 托管”，而不是把 MCP 强行塞进通用 API 或函数运行时。
更强的运行时能力：相比 Lambda 的极简执行模型，AgentCore Runtime 提供更长的执行时间、持久化文件系统、会话隔离、双向流式传输等，这些能力是托管复杂多轮工具调用所需要的。
统一身份与可观测性：AgentCore Identity 专门面向 AI 智能体场景，配合 AgentCore Runtime 的内置可观测性，让鉴权和运行监控形成闭环。
复用而非重复建设：已有 MCP 服务的团队可以直接把服务整体迁入，避免在每个上层客户端内重新实现一遍相同工具。

四、适用场景

这套架构特别适合以下几类需求：

已有 MCP 服务、希望让更多上层应用消费：只需把服务部署到 AgentCore Runtime 并注册到 Gateway，就能在 Amazon Quick 等多个客户端被调用，避免重复接入工作。
面向客户的产品化集成：希望让最终用户在 Amazon Quick 的聊天代理或工作流中直接使用自己产品里的能力，而不必为每个使用场景编写自定义连接器。
多租户、安全合规要求高的企业级 AI 应用：依赖双层 OAuth 2.0 鉴权、会话隔离、端到端 TLS 以及托管可观测性来满足合规与运维需要。
需要长执行与流式交互的工具型智能体：例如持续数秒到数分钟的复杂检索、文件处理或外部系统协同，Lambda 的执行时长限制在这里会成为瓶颈。

如果只是把单一简单接口暴露给 Amazon Quick 使用，且对执行时长和无状态没有特别要求，直接对接 API 或使用 Lambda 通常更轻量、更经济。

五、如何用起来：完整上手步骤

1. 环境与权限准备

在动手之前，需要先确认以下前提：

拥有一个 AWS 账号，并已开通 Amazon Quick，且订阅等级在 Author 及以上。
具备创建 IAM 角色与策略、AgentCore、Amazon Cognito、Amazon CloudWatch 相关资源的权限。
具备基本的 AWS 服务使用经验。
本地具备命令行环境，安装了 AWS SDK 与 Python，并配置好 AWS 凭证。
Amazon Bedrock 已启用 Anthropic 系列模型的访问。
准备 Python 3.10+、Amazon Bedrock AgentCore SDK、MCP 协议库以及运行中的 Docker 守护进程。

2. 在 AgentCore Runtime 上部署 MCP 服务

先准备一个最小可运行的 MCP 服务。典型工程结构包含三个文件：MCP 服务主文件、requirements.txt 和 __init__.py。依赖中需要至少包含 mcp>=1.10.0、boto3、bedrock-agentcore、bedrock-agentcore-starter-toolkit>=0.1.21 以及 strands-agents。

服务代码使用 FastMCP 初始化，并通过 @mcp.tool() 装饰器把普通 Python 函数声明为 MCP 工具，例如 getOrder、updateOrder 等。初始化时需要设置 host="0.0.0.0"、stateless_http=True，运行入口使用 mcp.run(transport="streamable-http")。完成本地运行验证后，使用 AgentCore Starter 工具包执行 agentcore configure 指定入口文件，再执行 agentcore launch 将其打包并部署到 AgentCore Runtime。

3. 配置 AgentCore Gateway 与双向鉴权

Gateway 是连接 Amazon Quick 与 MCP 服务的桥梁。配置过程中通常会依次完成：

为 Gateway 创建一个可被 Amazon Bedrock AgentCore 服务代入的 IAM 角色，授权其调用已部署 MCP 服务的 Runtime 资源，并允许读取 Secrets Manager 中的密钥。
创建一个 Amazon Cognito 用户池作为入站鉴权来源，并在其中定义带 invoke scope 的资源服务器，记录下 Client ID、Client Secret 与 OpenID 配置发现地址。
再创建第二个 Amazon Cognito 用户池作为出站鉴权来源，并在 AgentCore Identity 中基于该用户池创建 OAuth 客户端，作为 Gateway 调用 MCP 服务时的凭据来源。
在 AgentCore 中创建 Gateway，命名为类似 ac-gateway-mcp-server，入站鉴权选择 JWT 并指向入站用户池的发现地址与 Client ID，出站鉴权选择 OAuth 客户端类型，并按模板拼接 MCP 端点 URL：https://bedrock-agentcore.<region>.amazonaws.com/runtimes/{encoded_agentcore_runtime_mcp_server_arn}/invocations?qualifier=DEFAULT。

4. 在 Amazon Quick 中完成连接与调用

在 Amazon Quick 的 Connectors 中选择 MCP 类型，填入 Gateway 的 Resource URL 作为 MCP Server Endpoint，可按需选择是否启用私有 VPC 连接以收紧网络可见性。
在认证环节选择“用户认证”或“服务认证”，填入入站鉴权相关的 Client ID、Client Secret、Token URL（https://{user_pool_id_without_underscore}.auth.<region>.amazoncognito.com/oauth2/token，注意去掉用户池 ID 中的下划线）以及 Authorize URL。
创建完成后等待工具同步到 Available 或 Ready 状态，可使用“Test Action APIs”验证 MCP 工具是否可正常访问。
在聊天代理或工作流的 Actions 中链接该集成，即可在对话或自动化流中调用 MCP 工具。

5. 资源清理

为避免产生不必要的费用，建议在实验或演练结束后按与创建相反的顺序删除：MCP 服务容器、AgentCore Gateway 及其 Target、两个 Amazon Cognito 用户池、IAM 角色与相关密钥等。

六、局限与边界

虽然 AgentCore Runtime 托管的 MCP 服务提供了较为完整的“全托管”能力，但在落地时仍需关注以下几点边界：

协议约束：MCP 协议目前要求使用 OAuth 2.0 作为鉴权协议，因此出站鉴权链路没有其他可选协议，这一点会影响与已有非 OAuth 系统的对接方式。
运行形态约束：AgentCore Runtime 对 MCP 容器有路径与无状态 HTTP 模式的明确要求（0.0.0.0:8000/mcp、stateless_http=True），如果既有 MCP 服务不是按这套约定实现的，需要做适配改造。
客户端形态约束：Amazon Quick 目前可通过 Web 浏览器或桌面应用访问聊天代理和工作流，其他形态（如移动端、嵌入式 SDK 等）并未在本文涵盖范围内。
最小能力门槛：如果仅需要把单一接口暴露出去、且对执行时长、文件持久化和流式交互没有要求，直接使用 API Gateway 或 Lambda 方案在成本和复杂度上往往更友好。
数据隐私与可见性：虽然本文示例使用了 Amazon Cognito 作为身份提供方并启用了端到端 TLS，但在生产环境中仍需结合具体合规要求对 IAM 权限、Secrets Manager 中的凭据以及 VPC 网络可见性做进一步加固。

综合来看，这套方案适合已经把 MCP 作为工具调用协议、并希望以受管方式提供给上层业务用户使用的场景；对于“已有 MCP、想直接复用”和“希望面向客户提供产品化能力”这两类需求尤为契合，而对于轻量级的一次性集成，则需要权衡无服务器运行时的功能优势与资源开销之间的关系。