设计 MCP 网关：Uber 的 MCP 管理平台
Uber 用集中式 MCP Gateway 把碎片化的智能体工具集成，重构为可扩展、可治理的统一平台，承载 800+ 服务器、5000+ 工具。
引言
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 个工具。
在本文中，我们将回顾 MCP Gateway 的设计，涵盖代理层（MCP 与现有协议之间的相互转换）、发现层（MCP Registry 与 API 爬取）及其控制平面（编写）。
网关
MCP 网关采用基于微服务的架构，网关作为 AI 系统与 Uber 后端服务之间的核心集成点。该平台由两个主要组件构成：作为控制平面的 MCP 注册中心，以及构成数据平面的代理网关。
MCP 注册中心维护着一个由内部服务支撑的数百个 MCP 服务器目录，以及数千个 MCP 工具。这些工具涵盖范围广泛，从将现有 API 暴露为 MCP 工具的无代码定义，到完全按照 MCP 规范构建的原生实现。注册中心为整个生态系统中的发现、归属和启用提供了单一可信来源。
代理网关负责在运行时执行 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 注册表和内部服务信号。按照固定计划，一个 cron 任务会触发 Cadence 工作流，扫描新增的服务、API 以及 schema 变更。
对于每一个被发现的对象，AutoCrawler 负责：
- 创建或更新 MCP 服务器表示
- 生成或获取工具定义与 schema
- 将工具注册到 MCP 注册表中，默认处于禁用状态
这一共享基础使得 MCP 发现能力能够扩展到数千个服务，同时让服务团队无需处于关键路径上。
面向 IDL 支撑服务的发现
对于通过 Protobuf 或 Thrift IDL 定义的传统后端服务，AutoCrawler 直接从 IDL 注册表中推导出 MCP 服务器和工具。对于每个服务（API 组），AutoCrawler 执行以下步骤：
- Upsert MCP 服务器： 创建或更新与所发现服务对应的虚拟 MCP 服务器。
- 解析 IDL 定义： 解析相关的 protobuf 或 Thrift 文件，提取方法名、请求与响应 schema 以及文档注释。
- 生成工具描述： 使用 LLM 基于提取出的 schema 和注释，生成丰富的、对 agent 友好的 MCP 工具描述。
- Schema 转换： 将 protobuf 或 Thrift schema 转换为兼容 MCP 的 JSON-RPC 2.0 schema。
- Upsert MCP 工具： 将生成的 MCP 工具注册或更新到 MCP Registry 中，默认处于禁用状态。
原生服务器的发现
除基于 IDL 的服务外，MCP Gateway 还支持原生 MCP 服务器——即直接实现 MCP 协议并暴露面向智能体优化的工具的服务。
MCPFx 是 Uber 用于构建原生 MCP 服务器的框架。每个原生 MCP 服务器都会发出一个心跳指标，以表明其存在与就绪状态。AutoCrawler 持续监控这些心跳信号，以自动发现新的原生 MCP 服务器。当发现一个原生 MCP 服务器时，AutoCrawler 会走一条不同的发现路径：
- 它向该原生 MCP 服务器发起一次 listTools 调用，以获取其显式暴露的工具及其 schema。
- 它在 MCP Registry 中创建一个虚拟代理 MCP 服务器，其中包含所有已发现的工具及其 schema，默认处于禁用状态。
第三方 MCP 服务器
MCP Gateway 是 Uber 内部所有 MCP 交互的集中式编排层，并将无缝支持扩展至 Jira、Google 等第三方集成。
第三方 MCP 服务器的配置依赖于两个关键组件的协同：
- MCP Gateway： 在向下游转发调用方的用户令牌的同时，执行必要的网关能力，包括授权、限流和敏感数据脱敏。
- 第三方 MCP 服务： 将内部用户令牌换取对应的第三方认证令牌，然后再将请求分发至外部 MCP 服务器。
编写与启用
虽然我们可以在不涉及服务团队的情况下创建 MCP 服务器，但 MCP 服务器的所有权和控制权必须归属于服务团队。MCP Gateway 的一个核心设计原则是：被发现并不意味着被暴露。每个 MCP 服务器和工具初始都处于禁用状态，必须由所属团队明确审查并启用。服务所有者可以在启用之前审查和完善生成的工具定义。
对工具描述的任何更改都会触发配置变更差异，该差异必须由服务器所有者批准。所有者可以批准并部署配置变更，并在需要时回滚到之前的已知版本。
数据平面
MCP Gateway 数据平面是负责执行 MCP 请求的核心运行时服务。它持续从控制平面消费服务器和工具配置，并以固定频率刷新其内存状态，使配置变更（如工具更新或启用状态变更）能够实时生效，无需重启服务或重新部署。
基于这些配置，数据平面动态物化虚拟 MCP 服务器。对于每个虚拟服务器，Gateway 暴露一个单一的 /<service-name>/mcp 端点，作为 AI 代理执行的入口点。传入的请求通过内置的代理服务器解析到对应的服务器处理器。
协议转换与执行
MCP Gateway 中的协议转换由 Proxy Gateway 内的服务器处理器处理。每个服务器处理器都具备工具感知和下游感知能力，使其能够在运行时正确地路由和执行 MCP 请求。
安全性
MCP Gateway 为所有服务器提供内置的授权与脱敏功能，粒度精确到工具级别。MCP Gateway 使用 Uber 内部的访问控制系统，针对检测到的调用方主体（人类、服务和代理）应用不同的章程策略。章程策略在服务器级别创建，如有需要可选择性地在工具级别进行覆盖。
MCP Gateway 还会对工具响应中的任何 PII 或敏感数据开箱即用地执行脱敏。
IDL 支持的下游服务
对于由现有后端服务支持的工具，服务器处理器维护一份内存映射，描述下游目标，例如 HTTP 端点配置或 gRPC/TChannel 过程。
当 MCP 请求到达时，处理器会：
- 将传入的 JSON 载荷转换为适当的传输格式。
- 将请求序列化为 Protobuf 或 Thrift 字节。
- 将请求转发至下游服务。
- 将 Protobuf 或 Thrift 字节响应转换回 MCP 兼容的 JSON，并返回给调用方代理。
实际的下游请求通过 Muttley 执行，这是 Uber 的服务网格边车，与所有后端服务一同运行。通过将请求执行委托给 Muttley，MCP Gateway 自动受益于现有的服务间路由能力。
原生 MCP 服务器
原生 MCP 服务器同样在 MCP 注册表中注册为虚拟服务器，该注册表充当原始服务器的代理。在运行时，原生 MCP 请求会被透明地代理到下游服务器，响应则被代理回调用方。
网关的优势
通过构建 MCP-Gateway，Uber 实现了可扩展且统一的智能体系统构建方式，其中最具影响力的优势包括：
- 易于发现和安装
- 对现有 API 的无代码接入方式
- 内置可观测性与安全性
- 集中化的所有权与治理
扩展网关
将 MCP 网关扩展到数百个服务器和数千个工具后，暴露出了一些在小规模下不存在的问题。上下文膨胀与成本过高
运行时发现
MCP 没有跨服务器搜索的原生概念。智能体必须先知道要与哪个服务器通信，然后才能查询有哪些可用工具。配置智能体使用某个 MCP 服务器需要显式地接入服务器 URL、凭证和工具列表。为数百个服务器逐一配置无法扩展，因为所有这些上下文会耗尽模型的上下文限制。我们通过以下方式解决了这个问题
- Omni MCP - 一个单一的代理服务器，允许 MCP 客户端通过渐进式发现模式访问 MCP 网关的任意服务器，同时通过增量发现实现上下文/token 优化。Omni MCP 暴露了以下工具。
- discover_server - 根据查询意图发现 MCP 服务器
- discover_tools - 查找某个服务器的工具
- get_tool_schema - 获取某个工具的 json schema
- invoke_tool - 调用某个工具
这些工具共同实现了对所有 MCP 服务器的增量发现与访问，并内置了访问控制以及网关的其他功能。
- 响应投影（Response Projection）- MCP Gateway 还提供响应投影，这是一种面向 MCP 工具的类 GraphQL 调用模式。其工作方式是在工具请求 schema 中注入一个新字段，指示网关只请求所需字段，而非全部字段。LLM 读取并注入这些字段，以仅包含所需字段的嵌套路径数组的形式。随后，网关在运行时对响应进行裁剪，只保留被投影的字段。这使我们能够在企业级规模上扩展 MCP 的 API schema 兼容性。
- 代码模式（Code Mode）- 编码智能体通常在 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 从根本上改变了 AI 智能体在 Uber 的运作方式。最初，这是一个碎片化问题：数十个团队各自独立地搭建 MCP 集成，工具链不一致，没有共享的安全保障，基础设施重复建设。而如今，它已发展为一个统一、可扩展的平台，任何团队都能在几分钟内接入。
驱动我们设计的核心洞见很简单：现有 API 是为智能体提供工具的最快途径。与其要求各团队为智能体时代重写自己的服务，MCP Gateway 选择顺应它们的现状——通过 Muttley 透明地将 HTTP、gRPC 和 TChannel 调用转换为 MCP 兼容的交互，且无需对下游服务做任何改动。
如果你正在大规模构建智能体系统，最难的部分并不是 AI。真正困难的是构建那些连接性的组织——发现、安全、可靠性——正是这些让智能体足够可信，能够在生产环境中代表真实用户采取行动。MCP Gateway 是我们对这一挑战的回应，我们希望这里记录的设计决策对面临同样问题的人有所帮助。
致谢
封面图片说明：由 OpenAI 的 ChatGPT 生成；未使用任何外部图片、徽标或第三方素材。
gRPC 是 The Linux Foundation 的商标。
随时了解 Uber Engineering 的最新动态——在 LinkedIn 上关注我们，获取最新博客文章与洞见。