Amazon 工程團隊喺 2026 年 11 月 6 日喺自家 ML Blog 講咗佢哋點樣為北美物流網絡（North America Sort Center，NASC）嘅規劃團隊建咗一個 serverless MCP server，部署喺 Amazon ECS 同 AWS Fargate 上面。呢個嘢嘅核心思路好直接：將 AI agent 同企業數據湖之間加一個集中式閘道，令每個新數據集只需要一份 JSON 元資料檔案，唔使再寫代碼。

MCP（Model Context Protocol，模型上下文協議）係一套開放標準，定義 AI agent 點樣同外部工具同資料源溝通。之前嗰陣，NASC 數據湖入面有幾千個數據集，涵蓋營運指標、商業分析同領域數據。多個團隊想俾 AI 助手用對話方式查呢啲數據，但每個團隊各搞各嘅：每個 agent 自己寫 SQL 生成邏輯、自己識 schema、自己處理連線。表結構一改，就要挨個補每一部 agent。權限管控散落各處，冇一個統一審計點。上線一個新表要寫工具代碼、做查詢驗證、重新部署，通常花幾日。

呢個新架構分四層：client、MCP server、tools、knowledge-base refresh。每層獨立擴展、獨立部署。底層有一個 metadata catalog，儲存 schema 描述、欄位級語義、表關係，agent 喺執行查詢時由呢個 catalog 實時取 schema 知識，唔使 hardcoded 表結構，schema 改咗唔使 redeploy。knowledge-base refresh 層負責跟住新數據集元資料到嚟時自動更新 catalog。

設計目標有四個：

  1. 配置驅動嘅數據存取——加數據集只寫 metadata 檔，唔寫代碼
  2. Agent 無關嘅工具介面——任何 MCP-compatible client 都調用同一套工具
  3. 權限集中喺 MCP server 層執行
  4. 彈性擴展，跟住 AI workload 嘅突發模式

要留意呢個係 AWS 講自己內部系統嘅功能解説，冇獨立測試，冇效能數字，冇用户反饋。

阿調搞兩下：呢個案例有意思嘅地方唔係技術本身，係佢解鎖咗一個好常見嘅痛點——agent 同數據源 N×M 嘅整合爆炸。加中間層閘道，將 N×M 變做 N+M，每個數據集獨立掛載，每個 agent 獨立接入，互唔影響。呢個思路同微服務拆分嘅邏輯一脈相承。

阿調｜深度調教