MoEngage 如何用 AgentCore Gateway 将 400 多个 API 转为智能体工具

MoEngage 是一家服务超过 1350 个消费品牌的客户互动平台，其产品背后有 25 个工程团队构建的约 400 个内部 REST API，运行在 7 个 AWS Region 的私有 VPC 中，出于数据驻留承诺不暴露于公网。工程团队要让 AI 智能体调用这些能力，难点不在新建功能，而在于让数百个私有 API 安全可达，同时不让模型掌控身份信息，也不让数百条工具定义挤占上下文窗口。 MoEngage 首先否决了每个团队各自暴露一个 MCP server 的做法：20 多个 MCP server 意味着 20 多个需要监控、打补丁并跟随 MCP 演进的部署，跨域智能体还要连接多个 server 并做结果协调。由此确立原则：各工程团队只构建 REST API 并声明哪些操作应成为工具，MCP 层由 AI 平台团队端到端负责，团队职责止于一份描述良好的 OpenAPI 规范。 架构受四条必须同时满足的约束驱动：内部 API 不得获得公网端点；租户、用户、角色和数据库上下文不能作为模型可见的工具参数，而应由调用方服务注入；约 400 个工具按每个约 50 token 的 JSON schema 计算，全量 tools/list 超过 20000 token，不能塞进上下文窗口；客户端过滤不构成授权边界，不应看到的写操作根本不该下发。 AgentCore Gateway 作为全托管 MCP server，将注册的 OpenAPI 规范直接生成 MCP 工具并路由到后端服务，每个操作成为名为 Target___operationId 的工具，规范变更即工具变更，无需部署。Cedar 策略在目录序列化之前做部分求值，按主体过滤 tools/list，例如 campaign QA 机器人只能看到活动与分群的只读工具，写操作工具不会出现在其响应中。网关通过 AgentCore 托管出口经 Amazon VPC Lattice 访问内部服务，入站仅能通过带私有 DNS 的 VPC 接口端点到达，新增 API 只需添加 target 而非改动网络拓扑。语义搜索能力让智能体按任务描述查找工具，也降低了工具改名的脆弱性。 实际请求链路中，运行在 Amazon EC2 或容器中的智能体服务用已有 IAM 角色做 SigV4 签名，经 HTTPS 发往 VPC 接口端点，网关评估 Cedar 策略后经托管出口调用内部 API。MoEngage 选择 SigV4 而非 JWT，因为智能体本身就是持有 IAM 角色的服务；面向 Claude 等人类认证会话的独立公共 MCP server 则使用 OIDC JWT。身份以 X-MOE-* 请求头传递而非工具参数，模型不可见也不可设置。客户端库只向模型暴露一个 search_tools 元工具，搜索结果中的候选工具才在当轮可调用，上下文里不再装入数百条用不到的定义。团队接入新 API 只需在现有 OpenAPI 规范中增加 x-moe-mcp 块，显式声明是否对外暴露并覆写参数描述，未加该块的端点不会成为工具。