MoEngage 如何用 AgentCore Gateway 把 400 多个 API 变成智能体工具

发生了什么

MoEngage 是一家面向 1350 多个消费品牌的客户互动平台，其产品背后约有 400 个内部 REST API，由 25 个工程团队开发，运行在七个 AWS 区域的私有 VPC 中，出于数据驻留承诺不暴露到公网。据原文，MoEngage 使用 Amazon Bedrock AgentCore Gateway 将这些私有 API 转为按权限划分的智能体工具，目前部署在七个 AWS 区域，向 10 个内部智能体提供约 400 个已注册 API 操作，已在生产运行三个月。

为什么不用多个 MCP 服务器

原文给出的直接方案是每个团队各自暴露一个 MCP 服务器，MoEngage 评估后否决：20 多个服务器意味着 20 多个部署要监控、打补丁并跟随 MCP 协议演进；跨域智能体需要连接多个服务器再做协调；每个团队还得具备与自身产品无关的 MCP 专业知识。由此确立的原则是，产品团队只构建 REST API 并声明哪些操作应成为工具，MCP 层由 AI 平台团队端到端负责。

四项约束与对应能力

原文列出四条必须同时满足的约束：内部 API 不得有公网端点；身份信息不能作为模型可见的工具参数；400 个工具的完整目录约需两万多 token，无法塞进上下文窗口；客户端过滤不构成授权边界。

对应地，AgentCore Gateway 提供四项能力：注册 OpenAPI 规范即生成 MCP 工具，每个操作命名为 Target___operationId；Cedar 策略在工具列表序列化之前按主体过滤，智能体以各自 IAM 角色认证；通过 Amazon VPC Lattice 的托管出口访问内部服务，入站仅经 VPC 接口端点；借助 x_amz_bedrock_agentcore_search 能力按任务描述做语义检索，降低工具改名带来的脆弱性。

接入流程与身份处理

团队在既有 OpenAPI 规范中加入 x-moe-mcp 块，显式声明暴露范围、面向模型的工具描述和参数覆盖。CI 流水线校验该块、向网关注册目标并应用 Cedar 策略。原文强调工具描述不同于 API 描述，直接复用后者会导致模型按实现细节而非意图选工具。身份方面，MoEngage 内部网关选用 SigV4 而非 JWT，租户、用户、角色和数据库上下文由客户端库转为 X-MOE-* 请求头，模型不可见也不可设置；工具发现不携带租户身份，只有 tools/call 携带。

编辑部观察

这份材料属于厂商与云服务方共同撰写的实践说明，节省约六个月工程投入、接入从数天缩短到数小时均为 MoEngage 自报估算，原文未给出对照基线或独立测量。可迁移的部分是职责切分方式：把协议层、策略层和连接层收归平台团队，产品团队只交付规范注解。打算照此实施的团队需要先确认所在区域是否支持 AgentCore 相关能力，原文明确提示功能可用性因区域而异；同时应评估自身 API 规模是否真的触及上下文预算问题，规模较小时多服务器方案的成本可能更低。