AWS AgentCore Gateway 实战：用 MCP 为 AI Agent 扩展能力

为什么 AI Agent 需要 MCP

大语言模型本身只能处理文本输入输出，无法直接访问外部服务。当你让 ChatGPT、Gemini 或 Claude 帮你画一张 draw.io 流程图时，模型并不具备调用绘图服务的能力。这正是 Model Context Protocol（MCP）要解决的问题。

MCP 是由 Anthropic 设计的协议，它让 Agent 能够从代码库中主动调用外部服务。换句话说，MCP 为 LLM 补上了「动手做事」的那只手——无论是生成 draw.io 图表、读取 PDF 文档，还是处理文本文件，都能作为额外工具挂载到 Agent 上。在 AWS 的语境里，承载这套机制的组件就叫 AgentCore Gateway（也即 MCP Gateway）。

MCP（Model Context Protocol）于 2024 年 11 月由 Anthropic 正式开源，采用客户端-服务器架构：LLM 宿主程序作为 MCP Client，外部能力提供方作为 MCP Server，两者之间通过标准化的 JSON-RPC 消息格式通信。这种设计的核心价值在于「一次实现，到处复用」——开发者只需按照 MCP 规范封装一个工具服务，任何支持 MCP 的 Agent 框架（如 Claude Desktop、LangChain、Bedrock 等）都可以直接接入，无需为每个平台单独编写适配层。相比此前各家 Agent 框架各自定义工具调用接口的碎片化状态，MCP 的出现相当于为 AI 工具生态建立了一套「USB 标准」，极大降低了工具开发与 Agent 集成之间的耦合成本。

Gateway 到底是什么

Gateway 本质上是一个「入口点」（entry point），是 Agent 调用外部能力的统一网关。你可以在这里注册各种外部服务，让 Agent 像使用内置工具一样去调用它们。

项目架构与流程示意

在 AWS AgentCore Gateway 中，可以挂载的目标类型（Target Type）包括：

Lambda ARN：当你的代码本身没有现成 API，但想从一个 Lambda 调用另一个 Lambda 时使用
REST API：通过 OpenAPI 风格的 Schema 描述接口
MCP Server 端点：直接接入已有的 MCP 服务
Connectors：平台新增的连接器类型

这种设计的价值在于解耦——Agent 无需关心每个服务的实现细节，只需通过 Gateway 的统一接口发起调用。

请求是如何流转的

从时序上看，一次完整的请求流程大致如下：移动端或网页前端发起请求后，请求首先抵达 Orchestrator（编排器）。整个项目代码部署在 AWS Lambda 中，由编排器承接。

请求进入控制台前的流转逻辑

编排器内部有一个「意图分类 Agent」，负责识别用户请求的意图。根据不同意图，再分发给对应的子 Agent 处理。以一个医疗场景项目为例，内部子 Agent 可能覆盖预约挂号、排班调度，以及医院、医生、诊所、药品等不同业务领域。

对于内部已有的子 Agent，直接在代码库中调用即可；而对于需要调用的外部 Agent 或服务，则通过 Gateway 的四种目标类型（Lambda ARN、Connectors、MCP Server、REST API）接入。本次演示采用的是 REST API 方式。

在控制台创建 Gateway

实际操作时，在 AWS 控制台搜索 Amazon Bedrock AgentCore，进入后找到 Gateways 菜单，点击「Create Gateway」开始创建。

基础配置与角色权限

创建时需要填写 Gateway 名称、权限和描述。关键一步是选择 IAM Role：你需要确认该角色的策略中已经启用了 Bedrock AgentCore 相关服务权限。只有权限正确配置，才能从 Lambda 中成功调用 Gateway。

入站身份认证（Inbound Identity）

下一步是入站认证配置。AgentCore 使用 Signature V4 机制，并会自动为你创建一个 Cognito URL。每次从 Lambda 代码调用 Gateway 时，都需要携带这个 URL 作为认证凭据，系统会据此生成带 Signature V4 的 Token，用于验证请求来源的合法性，防止被攻击者伪造调用。

生产环境部署时需格外注意认证配置

视频作者特别强调：这一入站认证在生产环境部署时同样必须配置，这也是 AWS 官方推荐的做法，务必谨慎处理。

Signature V4（SigV4）是 AWS 用于对 HTTP 请求进行签名的标准认证机制，广泛应用于 S3、DynamoDB、Lambda 等几乎所有 AWS 服务的 API 调用中。其核心思路是：调用方使用 AWS 访问密钥（Access Key + Secret Key）对请求的方法、路径、Header 和 Body 进行 HMAC-SHA256 哈希运算，生成一个随时间戳变化的签名字符串附在请求头中。服务端收到请求后，用同样的密钥重新计算签名并比对，从而确认请求确实来自持有合法凭证的调用方，且内容在传输途中未被篡改。相比简单的静态 API Key，SigV4 签名包含了时间戳（默认有效期 15 分钟），可以有效防御重放攻击（Replay Attack）。在 AgentCore Gateway 的场景中，Lambda 代码需要通过 AWS SDK 或手动构造 SigV4 签名头，才能成功向 Gateway 发起认证请求。

配置目标类型与 OAuth 认证

目标类型（Target Type）是整个 MCP Gateway 最核心的部分，因为每个 Gateway 挂载的外部服务都在这里定义。

REST API 的 Schema 配置

以 REST API 为例，需要选择 OpenAPI 作为接口类型，并提供对应的 Schema。你可以上传一个描述接口的 JSON 文件，也可以直接填写内联 Schema（Inline Schema）——其中包含服务器 URL（Server URL）和各个路径（Paths）。作者提到，如果不确定 Schema 格式，完全可以借助 ChatGPT 或 Copilot 辅助生成。

目标类型与认证配置界面

OpenAPI（前身为 Swagger）是一种用 JSON 或 YAML 描述 RESTful API 接口的规范标准，目前主流版本为 3.x。一份典型的 OpenAPI Schema 包含服务器基础 URL、每个接口路径（Path）、HTTP 方法、请求参数类型与约束、响应结构等信息。AgentCore Gateway 之所以依赖 OpenAPI Schema，是因为它需要将接口的语义（如「这个端点用于查询药品库存」）和参数结构暴露给 LLM，使模型能够在推理时自动判断何时调用该工具、传入哪些参数。Schema 中的字段描述（description）越清晰，模型的工具选择准确率越高。对于尚不熟悉 OpenAPI 格式的开发者，可以将现有 Postman Collection 或 curl 示例交给 ChatGPT，要求其生成符合 OpenAPI 3.0 规范的 JSON Schema，通常只需少量修改即可直接使用。

外部服务的 OAuth 认证

如果被调用的 API 需要 Token 认证，则要在认证环节配置好对应的授权方式。AgentCore 支持多种身份提供商，包括 GitHub、Google、Microsoft SSO 等预置选项。

若要手动配置，需要在 Identity 面板中选择「Manual Config」，并填入以下关键信息：

Client Name（客户端名称）
Issuer（签发方）
Token Endpoint（Token 端点）
Client ID 与 Client Secret

其中 Client ID 和 Secret 这类敏感凭据，务必通过 AWS Secrets Manager 安全存储，而不是硬编码在代码中。配置完成后，将其关联到对应的目标类型即可。

总结：从 Gateway 到代码调用

当 Gateway、认证和目标类型全部配置完毕后，你会得到一个可供调用的资源 URL。接下来只需在 Lambda 代码中按规范发起调用，就能把外部服务作为工具提供给 Agent。

整体来看，AWS AgentCore Gateway 把 MCP 的理念落地为一套可运维的托管能力：统一入口、标准化目标类型、内置的入站/出站认证机制。对于希望在生产环境中为 AI Agent 扩展工具能力的团队而言，这套方案在安全性（Signature V4 + Secrets Manager）和扩展性（多种 Target Type）上都做了较完整的覆盖。