引言
Uber 对 AI Agent 的快速采用，从根本上改变了团队与代码、数据以及运营系统的交互方式。早期与 MCP（Model Context Protocol，模型上下文协议）的临时集成就展现出了明显价值：当 Agent 能够访问实时业务上下文、查询内部服务并代表用户执行有意义的操作时，它们的能力得到了大幅提升。这些早期的成功验证了 MCP 是在 Uber 内部构建 Agentic 系统的强大抽象层。
然而，随着采用速度加快，重大挑战也随之浮现。各个团队独立构建集成方案，导致工具碎片化和基础设施重复建设。MCP 工具难以被发现、难以稳定运行，并且与特定服务或 Agent 实现紧密耦合。虽然这些方法在小规模下行之有效，但当数百个团队开始探索 Agentic 工作流时，它们已无法满足 Uber 的需求。如果没有统一的架构，扩展 MCP 将增加运维复杂度、安全风险和开发者摩擦，最终限制其影响力。
为了在 Uber 的规模下释放 MCP 的全部潜力，我们需要一个集中式、可扩展的解决方案，来标准化 AI Agent 与现有后端系统的交互方式，同时为各团队保留灵活性。这个解决方案需要抽象协议差异（HTTP、gRPC™、TChannel），强制执行一致的安全性和可观测性保障，并让 MCP 工具在全公司范围内易于创建、发现和复用。
为此，我们构建了 MCP Gateway。它是一个基础微服务，支撑着 Uber 所有的 MCP 交互，充当 AI Agent 与现有后端服务及原生 MCP 服务器之间的编排和路由层。通过将 MCP 逻辑集中到单一网关中，我们为 Agent 与服务的交互提供了统一的执行模型，同时免去了各团队重复造轮子搭建核心基础设施的麻烦。现有 API 可以无缝暴露为 MCP 工具，在一处统一治理和运维，并以一致的方式被多个 Agent 调用。MCP Gateway 为在 Uber 内部构建 AI Agent 开辟了一条可扩展、快速且一致的路径，目前托管着超过 800 个 MCP 服务器和 5000 多个工具。
图 1：MCP Gateway（API 即工具）。
在这篇博客中，我们将回顾 MCP Gateway 的设计，涵盖代理层（Proxy Layer，负责 MCP 与现有协议之间的双向转换）、发现层（Discovery Layer，包括 MCP Registry 和 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 Agent 能够通过一致的 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 Registry 派生出 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 协议并暴露针对 Agent 优化工具的服务。
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：向下游传递调用者的用户 token，同时强制执行必要的网关能力，包括授权、限流和敏感数据脱敏。
- 第三方 MCP 服务：在将请求分发到外部 MCP 服务器之前，将内部用户 token 交换为对应的第三方认证 token。
创作与启用
虽然我们可以在不牵涉服务团队的情况下创建 MCP 服务器，但 MCP 服务器的所有权和控制权必须归属于服务团队。MCP Gateway 的一个核心设计原则是：发现不等于暴露。每个 MCP 服务器和工具都以禁用状态启动，必须由所属团队显式审查并启用。服务负责人可以在启用前审查并优化生成的工具定义。
工具描述的任何变更都会触发配置变更 diff，必须由服务器负责人审批。负责人可以批准并部署配置变更，并在必要时回滚到之前的已知版本。
图 3：MCP Registry UI。
图 4：MCP 工具 UI。
数据面
MCP Gateway 数据面是负责执行 MCP 请求的核心运行时服务。它持续从控制面消费服务器和工具配置，并按固定频率刷新内存状态，使配置变更（如工具更新或启用状态变化）能够实时生效，无需重启或重新部署服务。
基于这些配置，数据面动态实例化虚拟 MCP 服务器。对于每个虚拟服务器，网关暴露一个 /<service-name>/mcp 端点，作为 AI Agent 执行的入口。传入的请求通过内置的代理服务器解析到相应的服务器处理程序。
图 5：MCP Gateway 数据面。
协议转换与执行
MCP Gateway 中的协议转换由 Proxy Gateway 内的服务器处理程序完成。每个服务器处理程序都感知工具和下游信息，从而能够在运行时正确路由和执行 MCP 请求。
安全性
MCP Gateway 为所有服务器提供内置的授权和脱敏功能，粒度精细到工具级别。MCP Gateway 使用 Uber 内部的访问控制系统，对检测到的调用者角色（人类、服务和 Agent）应用不同的 charter 策略。Charter 策略在服务器级别创建，如有需要也可在工具级别进行可选覆盖。
MCP Gateway 还会开箱即用地对工具响应中的任何 PII 或敏感数据进行脱敏。
IDL 支撑的下游服务
对于由现有后端服务支撑的工具，服务器处理程序会在内存中维护一份映射，描述下游目标，例如 HTTP 端点配置或 gRPC/TChannel 过程。
当 MCP 请求到达时，处理程序会：
- 将传入的 JSON payload 转换为适当的传输格式。
- 将请求序列化为 Protobuf 或 Thrift 字节。
- 将请求转发到下游服务。
- 将 Protobuf 或 Thrift 字节响应转换回兼容 MCP 的 JSON，并返回给调用的 Agent。
实际的下游请求通过 Muttley 执行，这是 Uber 的服务网格 sidecar，与所有后端服务一同运行。通过将请求执行委托给 Muttley，MCP Gateway 自动受益于现有的服务间路由能力。
原生 MCP 服务器
原生 MCP 服务器也会作为虚拟服务器注册到 MCP Registry 中，后者充当前往原始服务器的代理。在运行时，原生 MCP 请求会被透明地代理到下游服务器，响应也会被代理回调用方。
网关的优势
通过构建 MCP Gateway，Uber 实现了一种可扩展且统一的方式来构建 Agentic 系统，其中最具影响力的优势来自：
- 易于发现和安装
- 针对现有 API 的无代码方式
- 内置的可观测性和安全性
- 集中的所有权和治理
扩展网关
将 MCP Gateway 扩展到数百个服务器和数千个工具后，暴露出了一些在小规模下不存在的问题。上下文膨胀与成本过高
运行时发现
MCP 本身没有跨服务器搜索的原生概念。Agent 必须先知道要与哪个服务器通信，才能询问有哪些可用工具。配置 Agent 使用某个 MCP 服务器，需要显式接入服务器 URL、凭证和工具列表。对数百个服务器这样做无法扩展，因为所有这些上下文都会耗尽模型的上下文限制。我们通过以下方式解决了这个问题：
- Omni MCP —— 一个单一的代理服务器，允许 MCP 客户端以渐进式发现模式访问 MCP Gateway 的任何服务器，这也通过增量发现解锁了上下文/token 优化。Omni MCP 暴露了以下工具：
- discover_server - 根据查询意图发现 MCP 服务器
- discover_tools - 查找某个服务器的工具
- get_tool_schema - 获取某个工具的 json schema
- invoke_tool - 调用某个工具
这些工具共同实现了对所有 MCP 服务器的增量发现和访问，并内置了访问控制和网关的其他功能。
- Response Projection（响应投影） —— MCP Gateway 还提供 Response Projection，一种类似 GraphQL 的 MCP 工具调用模式。它的原理是在工具请求 schema 中注入一个新字段，指示网关只请求需要的字段，而不是全部。LLM 读取并注入仅包含所需字段的嵌套路径数组。随后，网关在运行时通过仅保留投影字段来裁剪响应。这使我们能够在企业级规模上扩展 MCP 的 API schema 兼容性。
- Code Mode（代码模式） —— 编程 Agent 通常在 shell 环境中运行，将工具输出直接写入文件比将完整响应加载到模型上下文中更高效。Code Mode 通过 aifx（Uber 用于 Agentic 操作的 CLI）支持这种模式，将 MCP 调用路由经过网关，而无需安装任何 MCP 服务器。它帮助 Agent 在上下文中没有 MCP 定义的情况下发现适合任务的 MCP 工具。aifx 暴露了三个命令：
- aifx mcp list - 列出可用的 MCP 服务器
- aifx mcp search - 在所有 MCP 服务器中搜索工具
- aifx mcp call - 通过 MCP Gateway 调用 MCP 工具
Agent 可以在单条命令中串联这些操作并将输出写入文件，文件系统 Agent 可以选择性地 grep 这些文件，只将需要的内容加载到上下文中。Code Mode 现在已成为全公司编程 Agent 使用 MCP 工具的默认方式。
结语
构建 MCP Gateway 从根本上改变了 AI Agent 在 Uber 的运行方式。最初，这是一个碎片化问题：数十个团队各自独立接入 MCP 集成，工具不一致、没有共享的安全保障、基础设施重复建设；如今，它已成为一个统一、可扩展的平台，任何团队都能在几分钟内接入。
驱动我们设计的核心洞察很简单：现有 API 是为 Agent 提供工具的最快途径。与其要求团队为 Agentic 世界重写服务，MCP Gateway 选择顺应现状——通过 Muttley 将 HTTP、gRPC 和 TChannel 调用透明地转换为兼容 MCP 的交互，下游服务零改动。
如果你正在大规模构建 Agentic 系统，最难的部分并不是 AI。而是构建连接组织——发现机制、安全性和可靠性——正是这些让 Agent 足够可信，能够在生产环境中代表真实用户采取行动。MCP Gateway 是我们应对这一挑战的答案，希望这里记录的设计决策能对面临同样问题的其他人有所帮助。
致谢
封面图片说明：由 OpenAI 的 ChatGPT 生成；未使用任何外部图片、logo 或第三方素材。
gRPC 是 The Linux Foundation 的商标。
想及时了解 Uber Engineering 的最新动态？请在 LinkedIn 上关注我们，获取最新的博客文章和技术洞察。
