跳到主要内容

设计 MCP Gateway：Uber 的 MCP 管理平台

Uber Engineering

原文出处：由 Uber Engineering 发布于 X。

MCP Gateway 概览

引言

Uber 对 AI 智能体的快速采用，从根本上改变了团队与代码、数据以及运维系统交互的方式。早期与 MCP（Model Context Protocol，模型上下文协议）的临时性集成展现出了明确的价值：当智能体能够访问实时业务上下文、查询内部服务，并代表用户采取有意义的行动时，它们的能力得到了显著提升。这些早期的成功验证了 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 个工具。

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

在本篇博客中，我们将回顾 MCP Gateway 的设计，涵盖代理层（把 MCP 翻译为现有协议并再翻译回来）、发现层（MCP Registry 与 API 爬取）以及它的控制平面（编写与授权）。

Gateway

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 注册中心与内部服务信号。一个 cron 任务按固定计划触发 Cadence 工作流，扫描新增的服务、API 以及 Schema 变更。

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

  • 创建或更新 MCP 服务器表示
  • 生成或获取工具定义与 Schema
  • 以默认禁用的状态把工具注册进 MCP Registry

这一共享基础让 MCP 发现能力可以跨数千个服务扩展，同时让服务团队不必处于关键路径上。

图 2：Auto Crawler

面向 IDL 支撑服务的发现

对于通过 Protobuf 或 Thrift IDL 定义的传统后端服务，AutoCrawler 直接从 IDL 注册中心推导出 MCP 服务器与工具。对于每个服务：API 组，AutoCrawler 会执行以下步骤：

  • Upsert MCP 服务器： 创建或更新与所发现服务相对应的虚拟 MCP 服务器。
  • 解析 IDL 定义： 解析关联的 protobuf 或 Thrift 文件，提取方法名、请求与响应 Schema 以及文档注释。
  • 生成工具描述： 使用 LLM 基于提取出的 Schema 与注释，生成更丰富、对智能体更友好的 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 会走一条不同的发现路径：

  1. 它向该原生 MCP 服务器发起 listTools 调用，以获取其显式暴露的工具及对应 Schema。
  2. 它在 MCP Registry 中创建一个虚拟代理 MCP 服务器，其中包含所有已发现的工具及其 Schema，并以默认禁用的状态存在。

第三方（3P）MCP 服务器

MCP Gateway 是 Uber 全公司所有 MCP 交互的集中编排层，并把这套无缝支持延伸到 Jira、Google 等第三方集成。

第三方 MCP 服务器的开通依赖两个关键组件的协作：

  1. MCP Gateway： 将调用方的用户令牌中继到下游，同时执行必要的网关能力，包括授权、限流以及敏感数据脱敏。
  2. 第三方 MCP 服务： 将内部用户令牌换取对应的第三方认证令牌，然后把请求发送到外部 MCP 服务器。

编写与启用

虽然我们可以在不涉及服务团队的情况下创建 MCP 服务器，但对 MCP 服务器的归属与控制权必须留在服务团队手中。MCP Gateway 的一条核心设计原则是：发现并不意味着暴露。每个 MCP 服务器和工具都以禁用状态起步，必须由所属团队显式审查并启用。服务负责人在启用之前可以审查并改进生成的工具定义。

对工具描述的任何改动都会触发配置变更 diff，必须经服务器所有者批准。所有者可以批准并部署该配置变更，必要时还可以回滚到之前的已知版本。

图 3：MCP Registry 界面

图 4：MCP 工具界面

数据平面

MCP Gateway 数据平面是负责执行 MCP 请求的核心运行时服务。它持续消费来自控制平面的服务器与工具配置，并按固定节奏刷新内存中的状态，使工具更新或启用状态变更等配置改动能够实时生效，无需重启服务或重新部署。

基于这些配置，数据平面会动态实例化虚拟 MCP 服务器。对于每个虚拟服务器，网关暴露单一的 //mcp 端点，作为 AI 智能体执行的入口。进来的请求会通过内置的代理服务器，被解析到相应的服务器处理器。

图 5：MCP Gateway 数据平面

协议翻译与执行

MCP Gateway 中的协议翻译由 Proxy Gateway 内部的服务器处理器负责。每个服务器处理器都具备工具感知与下游感知能力，从而能在运行时正确地路由并执行 MCP 请求。

安全

MCP Gateway 为所有服务器提供内置的授权与脱敏能力，粒度细到工具级。MCP Gateway 使用 Uber 内部的访问控制系统（Access Control System），针对识别出的调用方主体（人类、服务与智能体）应用不同的 charter 策略。charter 策略在服务器级别创建，如有需要可提供工具级的覆盖设置。

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

IDL 支撑的下游服务

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

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

  1. 把传入的 JSON 载荷翻译为相应的线上格式。
  2. 将请求序列化为 Protobuf 或 Thrift 字节。
  3. 把请求转发给下游服务。
  4. 把 Protobuf 或 Thrift 字节响应翻译回 MCP 兼容的 JSON，并返回给发起调用的智能体。

实际的下游请求通过 Muttley 执行，它是 Uber 的服务网格 sidecar，与所有后端服务一同运行。通过把请求执行委托给 Muttley，MCP Gateway 自动继承了现有的服务间路由能力。

原生 MCP 服务器

原生 MCP 服务器同样以虚拟服务器的形式注册在 MCP registry 中，该虚拟服务器作为原始服务器的代理。在运行时，原生 MCP 请求会被透明地代理到下游服务器，响应也会被代理回调用方。

Gateway 的收益

通过构建 MCP-Gateway，Uber 在构建智能体系统方面实现了可扩展且统一的方式，其中影响最大的收益来自：

  • 易于发现与安装
  • 面向现有 API 的无代码方式
  • 内置可观测性与安全性
  • 集中化的归属与治理

扩展 Gateway

把 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 服务器的增量发现与访问，并内置了访问控制以及网关的其他能力。

  • 响应投影（Response Projection）- MCP Gateway 还为 MCP 工具提供了响应投影，这是一种类似 GraphQL 的调用模式。它的工作方式是在工具请求 Schema 中注入一个新字段，指示网关只请求所需字段而非全部字段。LLM 读取并注入这些字段，值是一组仅包含必需字段的嵌套路径数组。随后网关在运行时裁剪响应，只保留被投影的字段。这让我们能够在企业级规模上扩展 MCP 的 API Schema 兼容性。
  • Code Mode - 编程智能体常常在 shell 环境中工作，在这些环境里把工具输出直接写入文件，比把完整响应加载进模型上下文更高效。Code Mode 通过 aifx 来服务这种模式——aifx 是 Uber 用于智能体操作的 CLI，它把 MCP 调用经由网关路由，而无需安装任何 MCP 服务器。它帮助智能体发现适合任务的正确 MCP 工具，而无需把 MCP 定义放进上下文。aifx 暴露三个命令：
  • aifx mcp list - 列出可用的 MCP 服务器
  • aifx mcp search - 在所有 MCP 服务器中搜索工具
  • aifx mcp call - 通过 MCP Gateway 调用 MCP 工具

智能体可以在单条命令中串联这些操作并把输出写入文件，文件系统型智能体随后有选择地用 grep 检索，只把需要的内容加载进上下文。Code Mode 目前已是公司内编程智能体使用 MCP 工具的默认方式。

图 6：Code Mode（aifx）

结论

构建 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 上获取我们的最新博客文章与洞察。

评论