MoEngage 用 AgentCore Gateway 將 400 個 API 轉為代理工具

背景

MoEngage 是一個代理式客戶參與平台（agentic customer engagement platform），超過 1,350 個消費品牌使用它透過推送、電子郵件、應用內訊息、簡訊、WhatsApp 和 RCS 提供個人化體驗。該平台背後有約 400 個內部 REST API，由 25 個工程團隊開發，運行在七個 AWS 區域的私有虛擬私有雲（VPC，一種隔離的網路環境）中。這些 API 不公開於互聯網，以滿足資料駐留承諾。當工程團隊開始建置 AI 代理時，面臨的挑戰是讓這些私有 API 能被代理安全存取，而不暴露於公共網路、不讓模型控制身分識別，以及避免數百個工具定義淹沒上下文窗口。 AWS ML Blog

發生什麼事

MoEngage 使用 Amazon Bedrock AgentCore Gateway，將這些私有 API 轉化為具有權限範圍的代理工具。此方法估計為 MoEngage 節省了六個月的平台工程工作，現在接入新 API 只需數小時而非數天。沒有產品團隊撰寫 Model Context Protocol（MCP，一種讓代理發現和呼叫工具的標準協議）伺服器程式碼，沒有為每個整合配置網路，且路徑中不存在任何公共端點。 AWS ML Blog

重點內容

Amazon Bedrock AgentCore Gateway 是一個完全管理的 MCP（Model Context Protocol，一種讓代理發現和呼叫工具的標準協議）伺服器。團隊註冊 OpenAPI 規範作為目標，閘道器從中生成 MCP 工具，然後將呼叫路由到後端服務。每個操作成為一個工具，命名格式為 Target___operationId，例如 CampaignsAPI___searchCampaigns。當規範變更時，工具隨之變更；團隊新增端點時工具出現，移除時工具消失，無需部署或協議專業知識。 AWS ML Blog

AgentCore 策略引擎使用 Cedar 策略在目錄序列化前進行評估。每個代理以其自身的 IAM（Identity and Access Management，身分與存取管理）角色進行驗證，其 Cedar 策略決定它能看見和呼叫哪些工具。這使得 400 個工具變得可管理，因為這是伺服器端範圍限制，而非客戶端事後過濾。例如，一個活動 QA 機器人對活動和分群工具具有讀取權限，但無法呼叫寫入操作，因為這些工具根本不會出現在其 tools/list 回應中。 原文

閘道器透過 AgentCore 管理的出口（egress）到達 MoEngage 的內部服務，而非透過 MoEngage 自建和運維的網路。入站方面，閘道器僅可透過具有私有 DNS 的 VPC 介面端點存取，沒有公共路徑。接入新 API 只需新增一個目標，而非變更網路拓撲。此外，透過 x_amz_bedrock_agentcore_search 功能，代理可以透過描述任務來尋找工具，而非指定工具名稱，這消除了對自訂發現層的需求，並解決了重命名脆弱性問題。 原文

對使用者的意義

對於開發者而言，團隊只需維護 OpenAPI 規範，無需撰寫 MCP 伺服器程式碼或配置網路。AI 平台團隊擁有 MCP 層的所有權，其他團隊的責任止於提供描述良好的 OpenAPI 規範。這使得接入新 API 的時間從數天縮短至數小時，且不需要每個團隊具備 MCP 專業知識。 AWS ML Blog