MoEngage 的工程实践：用 Cedar 策略和语义搜索把 400 个私有 API 变成 Agent 可发现的工具

工程团队开始构建 AI Agent 时，所需能力通常已经以内部 API 的形式存在。MoEngage 的情况正是如此：这家服务超过 1350 个消费品牌的客户互动平台，背后有约 400 个内部 REST API，由 25 个工程团队维护，运行在横跨七个 AWS 区域的私有 VPC 中。真正的挑战不是构建新功能，而是让这些 API 在不暴露公网、不让模型控制身份、不把数百个工具定义塞满上下文窗口的条件下，被 Agent 安全调用。

最初的直觉方案是每个团队暴露自己的 MCP 服务器。MoEngage 做了成本估算后否决了它：超过 20 个 MCP 服务器意味着超过 20 套部署要监控、打补丁、保持协议兼容；跨域 Agent 需要连接多个服务器并协调它们；每个团队都得掌握与自身产品无关的 MCP 专业知识。由此确立的原则贯穿了后续所有设计：工程团队不实现 MCP，只构建 REST API 并声明哪些操作应作为工具；AI 平台团队端到端拥有 MCP 层；一个团队的责任止于写好 OpenAPI 规范。

这一原则立即产生三个需求：Agent 只连接一次的中心工具表面、服务器端按 Agent 强制的授权、以及不需要为每个新 API 重建的私有连接。从零搭建一个中心 MCP 服务器可以解决二十个服务器的问题，但仍需自行构建工具生成管线、策略文件格式、重命名别名注册表和熔断器——全部是平台团队的无差别工作，不会让 MoEngage 的 Agent 更聪明或客户的活动效果更好。

AgentCore Gateway 的四个属性恰好对应这些约束。第一，OpenAPI 进、MCP 工具出：注册规范后网关自动生成工具，规范变更即工具变更，无需部署或协议专业知识。第二，Cedar 策略在目录序列化之前完成评估：网关使用部分求值按主体过滤 tools/list 响应，每个 Agent 以自身 IAM 角色认证，其策略决定能看到和调用哪些工具。这是让 400 个工具变得可管理的关键——不是客户端事后过滤，而是服务器端在构建响应之前就已限定范围。一个活动 QA 机器人只能看到读取类工具，写操作根本不会出现在它的 tools/list 响应中。

第三，托管出站通过 Amazon VPC Lattice：网关通过 AgentCore 托管出站到达内部服务，入站仅通过 VPC 接口端点（私有 DNS）可达，不存在公网路径。接入新 API 只是添加一个 target，不是网络拓扑变更——这打破了乘以七个区域的运维爆炸。第四，语义搜索作为网关能力：Agent 通过描述任务来发现工具，而非记忆工具名称。MoEngage 的客户端库向模型只暴露一个元工具 search_tools，模型描述需求，网关返回候选，仅这些候选在本轮剩余时间内可调用。完整目录不进入上下文。

身份处理是另一个关键设计决策。每个内部 API 调用携带租户、用户、角色和数据库上下文。如果这些信息作为 LLM 可见的工具参数，模型可能搞错或被诱导修改。MoEngage 将身份作为请求头传递而非工具参数：客户端库把 Identity 对象转换为 X-MOE-* 前缀的头部，模型看不到也无法设置它们。发现和执行有不同的身份要求——列出和搜索工具不携带租户身份，只有 tools/call 才需要——这使发现保持轻量，审计轨迹无歧义。

接入流程已完全自动化：团队在现有 OpenAPI 规范中添加 x-moe-mcp 块声明工具描述和参数覆盖，推送后 CI 管线验证声明、向网关注册 target、应用 Cedar 策略，无需手动步骤或向平台团队提工单。MoEngage 发现，直接复用 API 描述会导致工具选择质量差——模型按实现细节（返回分页列表）而非意图（按状态或渠道查找活动）挑选工具。tool_description 和 param_overrides 字段专门用于编写面向模型的文本而不改变面向开发者的文档。

需要指出的是，这篇文章由 AWS 与 MoEngage 联合撰写，节省约六个月工程量和接入时间从数天缩短到数小时均为当事方自估，没有独立测量。方案深度绑定 AWS 基础设施（AgentCore、VPC Lattice、SigV4），跨云可移植性未讨论。语义搜索带来的重命名容错（按描述匹配而非标识符）是一个实际收益，但它也意味着工具描述的质量直接决定 Agent 能否找到正确工具，这本身是一个需要持续维护的负担。搜索优先模式改变了 MoEngage 对 Agent 设计的思考方式：新 Agent 从零硬编码工具引用开始，描述意图、接收候选、调用找到的工具；当团队重命名操作或发布新操作时，现有 Agent 无需代码变更即可获取。