Pinterest 如何构建生产级 MCP 生态系统

标题：Pinterest 如何构建生产级 MCP 生态系统

来源 URL：https://blog.bytebytego.com/p/how-pinterest-built-a-production

发布时间：2026-05-11T15:31:17+00:00

Markdown 内容：

真正重要的上下文并不在你的数据库中。它存在于用户每天使用的工具里。多阶段代理在遇到无法识别的步骤时会停滞不前。而每一次缺失的集成都意味着不同的 OAuth 流程、不同的令牌生命周期，以及在代理读取第一条记录之前需要花费数周的时间来处理管道。

WorkOS Pipes 将您的代理连接到用户日常使用的工具中。预构建的连接器支持 GitHub、Slack、Salesforce、Google Drive 等更多工具。Pipes 处理 OAuth、令牌刷新和凭据存储。每次您都会用一个新鲜的令牌调用真实的提供者 API。您的代理会在每个步骤中提取上下文，直到任务完成。

赋予代理上下文 →

Pinterest 的工程师每天都在跨多个内部系统工作。他们通过 Presto 查询数据，使用 Spark 调试批量作业，在 Airflow 中管理工作流，搜索内部文档，并在工单平台上跟踪错误。

当 Pinterest 开始构建 AI 代理时，他们希望这些代理不仅仅能回答问题。他们希望代理能够直接进入这些系统，拉取日志、调查错误工单、查询数据库并提出修复建议，所有操作都在工程师已经使用的界面上完成。

这一挑战源于标准数学计算。如果您有五个由 AI 驱动的界面（内部聊天应用、IDE 插件、聊天机器人、CLI 代理和其他自主代理）和十个内部工具，那么没有共享协议的情况下，您需要构建五十个定制集成。换句话说，每增加一个新的界面或工具都会成倍增加工作量。

模型上下文协议（MCP）承诺将这种乘法简化为加法。为每个界面构建一个 MCP 客户端，为每个工具构建一个 MCP 服务器，它们都将使用相同的语言进行通信。

Pinterest 采用了 MCP 作为实现这一愿景的基础。然而，实施协议本身其实是最简单的部分。真正的工程努力集中在协议之外的一切，例如中央注册表、两层认证系统、统一的部署流水线，以及从第一天起就内置的可观测性。

在这篇文章中，我们将探讨 Pinterest 是如何设计这个生态系统的，并且除了协议本身之外，他们还需要做哪些正确的事情。

免责声明：本文基于 Pinterest 工程团队公开分享的细节撰写。如果您发现任何不准确之处，请在评论区指出。

模型上下文协议（MCP）是一个开源标准，它为大型语言模型提供了一种与外部工具和数据源统一通信的方式。

与其为每个 AI 应用程序和它需要访问的每个工具编写自定义粘合代码，MCP 定义了一个共享的客户端-服务器协议。AI 界面充当客户端，MCP 服务器包装工具或数据源，并使用标准化格式进行工具发现、调用和返回结构化结果的通信。

在 MCP 出现之前，将 AI 界面连接到内部工具是一个 N x M 的问题。五个界面乘以十个工具等于需要构建和维护五十个定制集成。MCP 将其转化为一个 N+M 的问题。您只需构建五个客户端和十个服务器，任何客户端都可以与任何服务器通信。这只需要十五项工作，而不是五十项，随着界面或工具数量的增加，差距会进一步扩大。

但 MCP 只定义了通信协议。它不处理身份验证、授权、部署、服务发现或治理。

这些都是 Pinterest 自己必须解决的问题。换句话说，MCP 规范提供了语法，而 Pinterest 必须围绕它构建整个“教育体系”。

当 Pinterest 决定采用 MCP 时，三个早期决策塑造了整个生态系统。每个决策都涉及真正的权衡，理解这些权衡有助于我们明白为什么架构看起来是这样的。

查看下面的架构图：

MCP 支持运行在开发人员笔记本电脑上的本地服务器，并通过标准输入/输出进行通信。许多独立开发者使用 MCP 与工具如 Claude 或 Cursor 配合工作。

而 Pinterest 则选择了相反的方向。

他们明确优化了内部云托管的 MCP 服务器，这样他们的路由和安全基础设施可以一致地应用。尽管仍然允许本地服务器用于实验，但 Pinterest 的所谓“标准化路径”是编写一个服务器，将其部署到他们的云计算环境中，并在中央目录中注册它。每次工具调用都会变成网络请求，这与本地服务器相比会增加延迟。

然而，将服务器集中到云端意味着 Pinterest 可以在整个服务器上一致地应用认证、授权、日志记录和监控，而无需依赖个别开发人员在其个人机器上正确配置这些功能。

Pinterest 曾讨论过构建一个包含所有工具的单体 MCP 服务器，还是构建多个领域特定的服务器。他们选择了后者。

例如，Presto MCP 服务器处理数据查询。Spark MCP 服务器处理作业调试。Knowledge MCP 服务器处理文档和机构问答。每个服务器负责一组小而连贯的工具。

这一决策受到两个因素的推动。

• 首先，不同的服务器需要不同的访问控制。Presto 服务器涉及敏感业务数据，需要严格的基于组的限制。文档服务器风险较低，可以更广泛地访问。将它们捆绑到一个服务器中会迫使所有工具采用单一的访问策略，而这些工具的敏感性水平差异很大。

• 其次，每个工具描述都会消耗 AI 模型上下文窗口中的令牌，这是模型在单次交互中能够处理的文本量的限制。一个包含五十个工具的单体服务器会在提示中填充大量不需要的工具描述，从而挤占实际对话的空间。

领域特定的服务器保持工具列表的小而相关。这种上下文窗口约束是 AI 特有的，因为在传统的微服务设置中，你不会担心服务目录消耗令牌。

这里的权衡是每个服务器的运营开销更大，因为每个服务器都需要部署、监控和所有权。这个成本直接导致了第三个赌注。

团队的早期反馈很明确。启动一个新的 MCP 服务器需要太多样板代码，包括部署管道、服务配置和操作设置，所有这些都必须完成才能有人编写一行业务逻辑。

Pinterest 工程团队通过构建统一的部署管道来回应这一点。团队定义其工具，平台则负责部署、扩展和基础设施。这将原本需要多天的设置过程转变为领域专家可以完全专注于业务逻辑的过程。如果没有这项投资，围绕许多小型服务器的赌注将因自身的运营负担而崩溃。

这一切的基础是 MCP 注册表，这是一个中央目录，作为哪些服务器存在、谁拥有它们以及如何连接到它们的真相来源。它有两个方面。

• 网页界面允许人类浏览可用的服务器，查看其实时状态，找到所属团队和支持渠道，并检查可见的工具。

• API 允许 AI 客户端以编程方式发现服务器、验证它们，并检查给定用户是否被授权访问某个服务器。

只有在这里注册的服务器才被视为批准用于生产环境。换句话说，注册表不仅仅是电话簿，而是整个生态系统治理的核心支柱。

赋予 AI 代理访问接触真实生产系统和敏感数据的工具会立即引发安全问题。

Pinterest 从一开始就将 MCP 视为与安全团队的联合项目，结果是一种两层授权模型，值得仔细关注。

参见下图：

考虑一下当工程师打开 Pinterest 内部的 AI 聊天并要求代理从数据仓库查询收入数据时会发生什么。该单一请求会跨越多个系统，如下所述：

• 聊天前端与 MCP 注册表通信以查找可用的服务器。

• 请求被路由到 Presto MCP 服务器，该服务器对包含业务敏感信息的真实数据库执行查询。

• 在每个步骤中，系统都需要回答两个问题。这个人是谁？他是否被允许做这个特定的事情？

第一层在网络边缘处理粗粒度检查。

当工程师打开 Pinterest 上的任何 AI 表面时，他们会经历 OAuth 流程，这是使用公司账户登录的标准流程，并授予应用程序代表用户行事的权限。这会产生一个 JWT（JSON Web Token），这是一个小的签名令牌，编码了用户的标识和组成员资格。该 JWT 会伴随每个后续请求一起传递。

在请求到达任何 MCP 服务器之前，它会通过 Envoy 进行处理，Envoy 是 Pinterest 基础设施中每个服务前面的一个网络代理。Envoy 通过检查签名和过期时间来验证 JWT，然后将其转换为标准的头部信息，例如 X-Forwarded-User 和 X-Forwarded-Groups。

Envoy 还执行粗粒度的访问策略。这些规则是像“生产 AI 聊天应用可以与 Presto MCP 服务器通信，但运行在开发命名空间中的实验性服务器是禁止访问的”这样的广泛规则。如果请求违反了这些规则，它会在 MCP 服务器收到请求之前就被拒绝。可以将 Envoy 想象成大楼的安保台，它检查你的证件并确保你有权进入大楼。

第二层负责在每个服务器内部执行细粒度的检查。

即使 Envoy 允许请求通过，MCP 服务器仍然会对特定工具级别应用第二层授权。Pinterest 在工具函数上使用装饰器模式（@authorize_tool(policy='...')），以检查特定用户是否允许调用该特定工具。

例如，Presto MCP 服务器可能对多个团队开放，但只有广告工程组可以调用像 get_revenue_metrics 这样的工具。这就像进入大楼和进入特定房间的区别。

对于处理特别敏感数据的服务器，Pinterest 添加了业务组限制。服务器从用户的 JWT 中提取其业务组成员资格，并在建立会话之前将其与批准的列表进行比较。这个批准的组列表是在服务器首次注册时初始安全审查期间设置的。

例如，尽管 Presto MCP 服务器在技术上可以从 Pinterest 的广泛使用的 AI 聊天界面访问，但只有像广告、财务或某些基础设施团队这样的特定组才能实际连接并运行查询。这意味着在热门界面上启用一个功能强大的、数据密集型的服务器不会无声地扩大谁可以看到敏感数据的范围。

为什么需要两层而不是一层？

Envoy 的策略是快速的网络级检查，在任何应用程序代码收到请求之前阻止明显未经授权的流量。工具级别的装饰器处理复杂的、特定于业务逻辑的权限，而网络代理无法对此进行推理。两者共同提供了深度防御。即使其中一层配置错误，另一层仍能捕获未授权访问。

官方 MCP 规范定义了一个 OAuth 2.0 授权流程，用户需要单独向每个 MCP 服务器进行身份验证，通常涉及同意屏幕和每服务器令牌管理。Pinterest 完全跳过了这一过程。由于他们控制整个内部环境，因此他们利用用户在打开 AI 界面时已经拥有的认证会话。当用户调用 MCP 工具时，没有额外的登录提示或同意对话框。

这对终端用户来说更简单，但这只适用于 Pinterest 拥有堆栈的每一部分的情况。依赖第三方 MCP 服务器的公司很可能需要按照规范中描述的每服务器 OAuth 方法。

最后，对于没有人在循环中的自动化服务到服务调用，Pinterest 使用基于 SPIFFE 的认证。在这种模式下，调用服务通过服务网格颁发的加密证书证明其身份，而不是呈现人类的 JWT。Pinterest 将此保留用于低风险、只读场景，其中影响范围受到严格限制。

Pinterest 对一件事非常明确。MCP 不可能成为一个孤立于自己独立界面的科学项目。它必须出现在工程师每天使用的工具中。

下面的图表展示了 Pinterest 各种界面中 MCP 集成是如何完成的。

Pinterest 内部的 AI 聊天界面是大多数员工每天都会使用的。前端自动处理 OAuth 流程并返回当前用户权限范围内的可用 MCP 工具列表。一旦连接成功，AI 代理会直接将 MCP 工具集成到其工具集中，因此调用 MCP 工具的感觉与调用任何其他内置功能完全相同。从用户的角度来看，他们只是要求 AI 做某事，而 MCP 的管道是不可见的。

Pinterest 还在其内部通信平台中嵌入了 AI 机器人，这些机器人也暴露了 MCP 工具。认证是通过注册 API 处理的，就像网页界面一样。这些机器人支持上下文感知的工具范围限制，这意味着某些 MCP 工具仅限于某些频道。例如，Spark MCP 工具仅出现在 Airflow 支持频道中。这使得工具列表与对话相关，并防止用户意外调用在给定上下文中无意义的工具。

AI 支持的 IDE 可以按需通过 Presto MCP 服务器拉取数据，因此代理可以直接将数据带入编码工作流，而不是要求工程师切换到单独的仪表板。CLI 代理为基于终端的工作流提供类似的功能。

使用最频繁的服务器反映了最常见的工程痛点。

• Presto MCP 服务器始终是最繁忙的服务器，因为跨团队的数据访问是一个普遍需求。

• Spark MCP 服务器支撑着 Pinterest 的 AI 辅助调试体验，其中代理诊断作业失败、总结日志并帮助记录结构化的根本原因分析，将嘈杂的操作线程转化为可重用的知识。

• 知识 MCP 服务器作为机构知识的通用端点，使代理能够跨内部资源搜索文档并回答问题。

由于 MCP 服务器支持自动化操作，错误的影响范围比人类手动执行相同步骤时更大。

Pinterest 的代理指导方针要求在执行任何敏感或高成本操作之前必须获得人工干预的批准。代理提出操作建议，人类审批或拒绝（可选批量处理），然后执行。Pinterest 还对危险操作使用确认机制，在这种情况下，AI 会在执行类似覆盖表中数据的操作之前明确要求用户确认。这是一个治理决策。

Pinterest 从一开始就将可观测性构建到 MCP 生态系统中，而不是将其视为事后考虑的问题。所有 MCP 服务器都使用一组共享的库函数，这些函数提供开箱即用的日志记录功能，包括输入和输出日志、调用计数、异常跟踪以及其他遥测数据。这是服务器框架的一部分，因此团队在使用统一部署管道时可以免费获得可观测性。

在生态系统层面，Pinterest 跟踪注册服务器和工具的数量、所有服务器的调用次数以及一个汇总所有指标的北极星指标。这个数字就是节省的时间。对于每个工具，服务器所有者根据轻量级用户反馈和与先前手动工作流的比较，提供每次调用“节省的分钟数”估计值。通过乘以调用次数，这提供了影响的大致视图。

截至 2025 年 1 月，Pinterest 的 MCP 服务器每月为 844 名活跃用户提供 66,000 次调用。根据所有者提供的估计值，MCP 工具每月大约节省了 7,000 小时。

Pinterest 的 MCP 生态系统为需要在内部系统上运行 AI 代理的组织提供了清晰的蓝图。他们建立的模式——标准协议、中央注册表、分层认证、统一部署管道和内置可观测性——在超出 Pinterest 特定上下文的情况下具有广泛的适用性。

最重要的经验在于努力的方向。MCP 协议为 Pinterest 提供了 AI 表面和工具之间的共同语言。这是必要的，但远远不够。注册表、认证层、部署管道和度量框架将一个有前景的协议转化为每月处理数万次调用的生产系统。

总之，Pinterest 的方法表明了一个实用的起点：先培育少量高杠杆的 MCP 服务器来解决实际痛点，然后投资于平台工作，特别是部署管道，以便其他团队可以轻松在其基础上构建。Pinterest 的统一管道是将平台团队项目转变为全公司生态系统的突破点。

参考文献：

• 在 Pinterest 构建 MCP 生态系统

• 介绍模型上下文协议