關於 MCP 的文章已經很多，但大多停留在協定介紹或接了多少 server 這個層面。
Pinterest 工程團隊最近分享了他們真實跑在生產環境裡的 MCP 架構，數據具體、細節夠多，值得仔細看一遍。
架構選擇：多個專用 server，不搞大一統
Pinterest 沒有做一個處理所有事情的巨型 MCP server。他們的方向是：每個核心數據系統對應一個獨立的 MCP server。
目前主要在跑的：
- Presto server：數據查詢
- Spark server：作業除錯和日誌分析
- Airflow server：工作流程管理
- Knowledge server：內部文件和知識庫
為什麼不做一個統一的？
他們的理由是：多個 server 可以獨立做權限控制，不同團隊只能存取自己對應的工具域，避免一個 server 權限過大。同時，每個 server 的工具集保持精簡，不會讓模型在一大堆無關工具裡糾結。
註冊中心：讓 agent 知道能用什麼
Pinterest 建了一個中央註冊中心，作為哪些 server 是經過審批的權威來源。
AI 客戶端在呼叫工具前，先查註冊中心：這個 server 存在嗎？我有權限用它嗎？
這解決了一個實際問題：不是所有數據工具都該對所有員工開放。比如 Presto（大規模數據查詢），只有特定業務組的成員才能透過 AI 工具呼叫。
安全設計細節
兩層認證：
- 使用者 JWT token：驗證是誰在操作（人在迴路的場景）
- 服務網格身份：服務對服務的呼叫用網格身份
他們選擇不採用 MCP 標準的 OAuth 流程，而是基於已有的內部認證體系做整合——理由是減少每個 server 需要單獨授權的摩擦。
還有一個叫 elicitation 的設計：在執行高風險或高成本操作前，agent 必須向人類使用者請求確認，人不批就不執行。這在自動化和安全之間找了一個平衡點。
落地數字
截至 2025 年 1 月的數據：
| 指標 | 數字 |
|---|---|
| 每月呼叫次數 | 66,000 次 |
| 活躍使用者數 | 844 人 |
| 估計每月節省時間 | ~7,000 工程師小時 |
7,000 小時/月——按一個工程師月工作約 160 小時算，相當於節省了約 44 人的工作量。這是基於每個工具呼叫的估計節省時間加總得出的，不是精確數字，但量級有參考價值。
值得注意的是
Pinterest 的文章裡有一句話：這套東西接入了工程師日常用的 IDE、內部聊天平台、以及 AI 工作流程——不是單獨搞了一個 AI 入口讓工程師特意去用。
這才是企業級 AI 落地能不能成功的關鍵：工具得在工人工作的地方出現，不是要求他們換一個地方。
參考來源：Pinterest Deploys Production-Scale Model Context Protocol Ecosystem for AI Agent Workflows（InfoQ）；CocoLoop、Building an MCP Ecosystem at Pinterest（Pinterest Engineering Blog / Medium）