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：验证是谁在操作（人在回路的场景）
- 服务Mesh身份：服务对服务的调用用网格身份
他们选择不采用MCP标准的OAuth流程，而是基于已有的内部认证体系做整合——理由是减少每个server需要单独授权的摩擦。
还有一个叫elicitation的设计：在执行高风险或高成本操作前，agent必须向人类用户请求确认，人不批就不执行。这在自动化和安全之间找了一个平衡点。
落地数字
截至2025年1月的数据：
| 指标 | 数字 |
|---|---|
| 每月调用次数 | 66,000次 |
| 活跃用户数 | 844人 |
| 估计每月节省时间 | ~7,000工程师小时 |
7000小时/月——按一个工程师月工作约160小时算，相当于节省了约44人的工作量。这是基于每个工具调用的估计节省时间加总得出的，不是精确数字，但量级有参考价值。
值得注意的是
Pinterest的文章里有一句话：这套东西接入进了工程师日常用的IDE、内部聊天平台、以及AI工作流——不是单独搞了一个AI入口让工程师特意去用。
这才是企业级AI落地能不能成功的关键：工具得在工人工作的地方出现，不是要求他们换一个地方。
参考来源：Pinterest Deploys Production-Scale Model Context Protocol Ecosystem for AI Agent Workflows（InfoQ）；Building an MCP Ecosystem at Pinterest（Pinterest Engineering Blog / Medium）