设计 MCP 网关：Uber 的 MCP 管理平台

简介

Uber 对 AI 代理的快速采用从根本上改变了团队与代码、数据和运营系统交互的方式。早期与 MCP（模型上下文协议）的临时集成展现了明确的价值：当代理能够访问实时业务上下文、查询内部服务并代表用户执行有意义的操作时，其能力得到了显著提升。这些早期的成功验证了 MCP 作为在 Uber 内部构建代理系统的强大抽象层的价值。

然而，随着采用速度加快，重大挑战也随之出现。各个团队独立构建集成，导致工具碎片化和基础设施重复。MCP 工具难以被发现、难以可靠地运行，并且与特定服务或代理实现紧密耦合。虽然这些方法在小规模下可行，但当数百个团队开始探索代理工作流时，它们无法满足 Uber 的需求。如果没有统一的架构，扩展 MCP 将增加运营复杂性、安全风险和开发者阻力，最终限制其影响力。

为了在 Uber 的规模下释放 MCP 的全部潜力，我们需要一个集中式、可扩展的解决方案，以标准化 AI 代理与现有后端系统交互的方式，同时为团队保留灵活性。该解决方案需要抽象协议差异（HTTP、gRPC™、TChannel），强制执行一致的安全性和可观测性保证，并使 MCP 工具易于在全公司范围内创建、发现和重用。

我们构建了 MCP Gateway 来满足这一需求。它是一个基础微服务，为 Uber 上所有的 MCP 交互提供支持，充当 AI 代理与现有后端服务及原生 MCP 服务器之间的编排和路由层。通过将 MCP 逻辑集中到单个网关中，我们为代理到服务的交互提供了一致的执行模型，同时消除了团队重新构建核心基础设施的需要。现有的 API 可以无缝地暴露为 MCP 工具，在一处进行治理和运维，并以统一的方式被多个代理使用。MCP Gateway 为在 Uber 内部构建 AI 代理开辟了一条可扩展、快速且一致的路径，目前托管着超过 800 个 MCP 服务器和超过 5000 个工具。

Flowchart showing MCP Gateway routing requests from four callers to four downstream services using various protocols.

图 1：MCP Gateway（API 作为工具）。

在这篇博文中，我们将回顾 MCP Gateway 的设计，涵盖代理层（MCP 与现有协议之间的双向转换）、发现层（MCP 注册表和 API 爬取）及其控制平面（编写）。

网关

MCP Gateway 遵循基于微服务的架构，网关作为 AI 系统与 Uber 后端服务之间的中心集成点。该平台由两个主要组件组成：作为控制平面的 MCP Registry，以及构成数据平面的 Proxy Gateway。

MCP Registry 维护着由内部服务支撑的数百个 MCP 服务器的目录，以及数千个 MCP 工具。这些工具范围从将现有 API 暴露为 MCP 工具的无代码定义，到明确针对 MCP 规范构建的完全原生实现。注册表为整个生态系统中的发现、所有权和启用提供了单一事实来源。

代理网关（Proxy Gateway）负责在运行时执行 MCP 请求。它将 MCP 协议调用转换为 HTTP、gRPC 或 TChannel 请求，将其转发到相应的后端服务，并将响应转换回兼容 MCP 的结果。这一转换层使 AI 代理能够通过一致的 MCP 接口与现有系统交互，而无需对底层服务进行任何更改。

控制平面

Uber 采用微服务架构，拥有数千个内部服务，这些服务通过 HTTP、gRPC 和 TChannel 暴露 API。这些 API 为 AI 系统提供了宝贵的上下文，但要求团队手动编写 MCP 服务器既缓慢又痛苦。为了解决这个问题，我们构建了 AutoCrawler，它持续扫描 Uber 的 IDL 注册表中的 API，进行转换，并在注册表中更新它们。它还会查询原生 MCP 服务器并将其添加到注册表中。

AutoCrawler：发现引擎

Autocrawler 是一个由 Cadence 驱动的分布式工作流系统，订阅了 Uber 的 IDL 注册表和内部服务信号。按照固定的时间表，一个定时任务会触发一个 Cadence 工作流，扫描新添加的服务、API 和模式（schema）变更。

对于每个发现的实体，AutoCrawler 负责：

创建或更新 MCP 服务器表示
生成或获取工具定义和模式（schema）
在 MCP 注册表中以默认禁用状态注册工具

这一共享基础使 MCP 发现能够跨数千个服务扩展，同时让服务团队远离关键路径。

图 2：Auto Crawler。
基于 IDL 的服务发现

对于通过 Protobuf 或 Thrift IDL 定义的传统后端服务，AutoCrawler 直接从 IDL 注册表派生 MCP 服务器和工具。对于每个 service:API 组，AutoCrawler 执行以下步骤：

更新 MCP 服务器（Upsert MCP server）：创建或更新与所发现服务对应的虚拟 MCP 服务器。
解析 IDL 定义：解析关联的 protobuf 或 Thrift 文件，以提取方法名称、请求和响应模式（schema）以及文档注释。
生成工具描述：使用 LLM 根据提取的模式和注释生成丰富的、对代理友好的 MCP 工具描述。
模式转换：将 protobuf 或 Thrift 模式转换为兼容 MCP 的 JSON-RPC 2.0 模式。
更新 MCP 工具（Upsert MCP tools）：在 MCP 注册表中以默认禁用状态注册或更新生成的 MCP 工具。

原生服务器的发现

除了基于 IDL 的服务外，MCP 网关还支持原生 MCP 服务器——即直接实现 MCP 协议并暴露针对代理优化的工具的服务。

MCPFx 是 Uber 用于构建原生 MCP 服务器的框架。每个原生 MCP 服务器都会发出一个心跳指标，以表明其存在和就绪状态。AutoCrawler 持续监控这些心跳信号，以自动发现新的原生 MCP 服务器。当发现原生 MCP 服务器时，AutoCrawler 会遵循不同的发现路径：

它会向原生 MCP 服务器发起 listTools 调用，以检索该服务器显式暴露的工具及其模式。
它会在 MCP Registry 中创建一个虚拟代理 MCP 服务器，其中包含所有已发现的工具及其模式，默认处于禁用状态。

第三方 MCP 服务器

MCP Gateway 作为 Uber 所有 MCP 交互的集中式编排层，为 Jira 和 Google 等第三方集成提供无缝支持。

配置第三方 MCP 服务器依赖于两个关键组件的协作：

MCP Gateway：将调用方的用户令牌向下游转发，同时执行必要的网关功能，包括授权、速率限制和敏感数据脱敏。
第三方 MCP 服务：在将请求发送到外部 MCP 服务器之前，将内部用户令牌交换为相应的第三方认证令牌。

虽然我们可以在不涉及服务团队的情况下创建 MCP 服务器，但 MCP 服务器的所有权和控制权必须归属于服务团队。MCP Gateway 的一个核心设计原则是：发现不等于暴露。每个 MCP 服务器和工具初始都处于禁用状态，必须由所属团队明确审核并启用。服务所有者可以在启用之前审核并完善生成的工具定义。

对工具描述的每次更改都会触发配置变更差异，必须由服务器所有者批准。所有者可以批准并部署配置变更，如有需要，还可以回滚到之前的已知版本。

MCP Registry dashboard displaying a list of verified MCP servers with details like tools, agents, and service tiers.

图 3：MCP Registry UI。

图 4：MCP 工具 UI。
数据平面

MCP Gateway 数据平面是负责执行 MCP 请求的核心运行时服务。它持续从控制平面消费服务器和工具配置，并以固定节奏刷新其内存状态，使得配置变更（如工具更新或启用状态变更）能够实时生效，无需重启服务或重新部署。

基于此配置，数据平面动态实例化虚拟 MCP 服务器。对于每个虚拟服务器，Gateway 会暴露一个 /<service-name>/mcp 端点，作为 AI 代理执行的入口点。传入的请求通过内置代理服务器解析到相应的服务器处理器。

图 5：MCP Gateway 数据平面。
协议转换与执行

MCP Gateway 中的协议转换由 Proxy Gateway 内的服务器处理器负责。每个服务器处理器都具备工具感知和下游感知能力，使其能够在运行时正确路由和执行 MCP 请求。

安全性

MCP Gateway 为所有服务器提供工具级粒度的内置授权和脱敏功能。MCP Gateway 使用 Uber 内部的访问控制系统，根据检测到的调用方角色（人类、服务和代理）应用不同的 Charter 策略。Charter 策略在服务器级别创建，如有需要，可在工具级别进行覆盖。

MCP Gateway 还开箱即用地对工具响应中的任何 PII 或敏感数据进行脱敏。

基于 IDL 的下游服务

对于由现有后端服务支撑的工具，服务器处理器维护一个内存映射，用于描述下游目标，例如 HTTP 端点配置或 gRPC/TChannel 过程。

当 MCP 请求到达时，处理器：

将传入的 JSON 负载转换为适当的线格式。
将请求序列化为 Protobuf 或 Thrift 字节。
将请求转发到下游服务。
将 Protobuf 或 Thrift 字节响应转换回兼容 MCP 的 JSON，并返回给调用代理。

实际的下游请求通过 Muttley 执行，Muttley 是 Uber 的服务网格 sidecar，与所有后端服务并行运行。通过将请求执行委托给 Muttley，MCP Gateway 自动受益于现有的服务间路由能力。

原生 MCP 服务器

原生 MCP 服务器也作为虚拟服务器注册在 MCP 注册表中，该注册表充当到原始服务器的代理。在运行时，原生 MCP 请求被透明地代理到下游服务器，响应则被代理回给调用方。

网关的优势

通过构建 MCP-Gateway，Uber 实现了一种可扩展且统一的构建 agentic 系统的方法，其中最具影响力的优势来自：

易于发现和安装
面向现有 API 的无代码方法
内置可观测性和安全性
集中化的所有权和治理

扩展网关

将 MCP Gateway 扩展到数百个服务器和数千个工具，暴露出在小规模下不存在的问题。上下文膨胀与过高成本

运行时发现

MCP 没有跨服务器搜索的原生概念。代理必须先知道要与哪个服务器通信，才能询问有哪些可用工具。配置代理使用 MCP 服务器需要显式连接服务器 URL、凭据和工具列表。对数百个服务器执行此操作无法扩展，因为所有这些上下文都会耗尽模型上下文限制。我们通过以下方式解决了这个问题

Omni MCP - 一个单一的代理服务器，允许 MCP 客户端以渐进式发现模式访问 MCP Gateway 的任何服务器，这也通过增量发现解锁了上下文/令牌优化。Omni MCP 暴露这些工具。
- discover_server - 根据查询意图发现 MCP 服务器
- discover_tools - 查找某个服务器的工具
- get_tool_schema - 获取某个工具的 json schema
- invoke_tool - 调用某个工具

这些工具共同实现了对所有 MCP 服务器的增量发现和访问，并内置了访问控制和网关的其余功能。

响应投影 - MCP Gateway 还提供响应投影（Response Projection），这是一种类似 GraphQL 的 MCP 工具调用模式。其工作原理是在工具请求模式中注入一个新字段，指示网关仅请求所需的字段，而非全部字段。LLM 会读取并注入一个由仅需字段组成的嵌套路径数组。随后，网关在运行时对响应进行裁剪，仅保留被投影的字段。这使我们能够在企业级层面扩展 MCP 的 API 模式兼容性。
代码模式 - 编码代理通常在 shell 环境中运行，将工具输出直接写入文件比将完整响应加载到模型上下文中更高效。代码模式通过 aifx（Uber 用于智能体操作的 CLI）来支持这一模式，将 MCP 调用通过网关路由，而无需安装任何 MCP 服务器。它帮助代理在 MCP 定义不在上下文中的情况下，发现适合任务的正确 MCP 工具。aifx 提供三个命令：
- aifx mcp list - 列出可用的 MCP 服务器
- aifx mcp search - 跨所有 MCP 服务器搜索工具
- aifx mcp call - 通过 MCP Gateway 调用 MCP 工具

代理可以在单个命令中将这些命令链接起来，并将输出写入文件，文件系统代理随后会进行选择性 grep，仅将所需内容加载到上下文中。代码模式现已成为编码代理中使用 MCP 工具的公司默认方式。

结论

构建 MCP Gateway 从根本上改变了 Uber 的 AI 代理的运作方式。最初这是一个碎片化问题——数十个团队各自独立地接入 MCP 集成，工具不一致、缺乏共享的安全保障、基础设施重复——如今已变成一个统一、可扩展的平台，任何团队都可以在几分钟内接入。

驱动我们设计的核心洞察很简单：现有 API 是为代理提供工具的最快方式。MCP Gateway 并不要求团队为智能体世界重写他们的服务，而是就地满足他们——通过 Muttley 将 HTTP、gRPC 和 TChannel 调用透明地转换为兼容 MCP 的交互，且对下游服务零改动。

如果你正在大规模构建智能体系统，最难的部分不是 AI，而是构建连接组织——发现机制、安全性、可靠性——这些使代理足够可信，能够在生产环境中代表真实用户行事。MCP Gateway 是我们对这一挑战的回答，我们希望这里记录的设计决策对面临同样问题的其他人有所帮助。

致谢

封面图片来源：由 OpenAI 使用 ChatGPT 生成；未使用任何外部图片、标志或第三方资产。

gRPC 是 The Linux Foundation 的商标。

及时获取 Uber Engineering 的最新动态——在 LinkedIn 上关注我们，获取我们最新的博客文章和见解。

简介

网关