10 个关键问题Q&A

Q1：Uber 为什么要做 MCP Gateway，直接让各团队自建 MCP Server 不行吗？

A：小规模自建 MCP 可以，但数百团队落地时会出现工具碎片化、基础设施重复建设、安全策略不统一、工具难以检索。单独开发的 MCP 工具与服务强耦合，运维复杂，安全风险不可控。MCP Gateway 提供统一网关层，避免重复造轮子，集中管控安全、权限与可观测性。

Q2：MCP Gateway 整体架构由哪两大核心部分组成，各自职责是什么？

A：控制平面（MCP Registry 注册中心）：工具元数据管理、自动发现、配置审批、版本回滚；数据平面（Proxy Gateway 代理网关）：运行时协议翻译、请求转发、鉴权、敏感数据脱敏，处理智能体实际调用请求。

Q3：AutoCrawler 是什么，它的工作原理？

A：AutoCrawler 是 MCP 的自动发现引擎，基于 Cadence 分布式工作流。定时扫描 Uber IDL 注册中心：解析 Protobuf/Thrift IDL 自动生成虚拟 MCP 服务；监听原生 MCPFx 服务心跳；自动注册工具到 MCP Registry。所有工具默认禁用，需要业务团队手动审核启用。

Q4：MCP Gateway 支持哪三类后端接入方式？

A：① IDL 存量后端服务（HTTP/gRPC/TChannel，无代码生成 MCP 工具）；② Uber 原生 MCPFx 开发的 MCP Server；③ Jira、Google 这类第三方 MCP 服务。

Q5：“发现不等于启用” 这条治理原则怎么理解？

A：AutoCrawler 自动扫描并生成 MCP 工具元数据，只是录入注册目录，工具初始状态是禁用。服务归属团队必须人工审核、优化工具描述，审批后才能开放调用；修改工具定义也需要所有者审批，支持配置回滚，保障业务可控。

Q6：数据平面如何实现协议转换，下游业务服务是否需要改造？

A：网关代理处理器接收 MCP JSON-RPC 请求，自动转换成 HTTP/gRPC/TChannel 协议，序列化 Protobuf/Thrift 二进制请求，经由 Muttley 服务网格边车转发给下游；响应再反向转成 MCP JSON 格式。原有后端服务完全不需要改动。

Q7：MCP Gateway 的安全能力体现在哪里？

A：支持工具粒度的 ABAC 基于属性访问控制，可对人、服务、AI 智能体配置不同权限策略；内置 PII 个人隐私与敏感数据自动脱敏；同时支持限流、用户令牌透传，第三方 MCP 场景下做身份令牌转换。

Q8：大规模使用 MCP 遇到最大痛点是什么？Omni MCP 如何解决？

A：原生 MCP 不支持跨服务检索。智能体需要预先配置全部 MCP 服务地址、凭证和工具列表，大量工具会占用巨大上下文窗口，token 成本高。Omni MCP 提供统一代理，支持增量发现：根据意图动态搜索服务、查找工具，按需调用，不用一次性加载全部工具定义。

Q9：Response Projection 和 Code Mode 分别解决什么问题？

A：Response Projection（响应投影）类似 GraphQL，LLM 指定需要的字段，网关在运行时裁剪返回结果，减少返回数据体积、降低 token 消耗。Code Mode 面向代码智能体，通过aifxCLI，将工具输出直接写入文件，只按需读取文件内容，避免大量数据灌入模型上下文，是 Uber 代码智能体默认模式。

Q10：MCP Gateway 带给 Uber 的核心价值是什么？对企业构建 Agent 系统有什么启示？

A：内部价值：存量 API 快速封装成 Agent 工具、统一安全与运维，几分钟就能接入，支撑 800+MCP 服务和 5000 + 工具。启示：大规模智能体系统的难点往往不是大模型本身，而是连接层：工具发现、权限治理、可观测、安全管控；优先复用现有业务 API，而不是重写业务系统适配 Agent。

引言

Uber 大规模落地 AI 智能体，从根本上改变了各团队使用代码、数据与运维系统的方式。早期针对 MCP（模型上下文协议，Model Context Protocol）的零散集成已经展现出显著价值：当智能体能够获取实时业务上下文、查询内部服务，并代表用户执行实际操作时，其能力得到大幅提升。这些早期落地成果验证了：MCP 是在 Uber 内部构建智能体系统的强大抽象层。

但随着接入规模快速增长，一系列突出挑战随之显现。各个团队独立开发集成，造成工具生态碎片化、基础设施重复建设；MCP 工具难以检索发现、稳定运维难度高，并且和特定服务、智能体实现强耦合。小规模场景下这类方案尚能运行，但当数百个团队开始探索智能体工作流时，已无法满足 Uber 的业务需求。如果缺少统一架构，MCP 的规模化落地会带来运维复杂度上升、安全风险增加、开发者使用门槛变高等问题，最终限制 MCP 的价值释放。

为在 Uber 的业务规模下充分释放 MCP 的潜力，我们需要一套集中式、可横向扩展的方案，标准化 AI 智能体对接现有后端系统的方式，同时保留各团队的灵活度。这套平台需要屏蔽不同协议之间的差异（HTTP、gRPC、TChannel），统一落地安全策略与可观测性能力，并简化 MCP 工具的创建、检索与跨团队复用。

为此，我们构建了 MCP Gateway（MCP 网关）。它是支撑 Uber 全部 MCP 交互的基础微服务，作为编排与路由层，连接 AI 智能体、现有后端服务以及原生 MCP 服务端。通过将 MCP 核心逻辑收敛至统一网关，我们为 “智能体调用服务” 提供一致的执行模型，避免各团队重复搭建底层基础设施。现有 API 可以无缝封装为 MCP 工具，在同一平台完成管控与运维，并且能够被多个智能体以统一方式调用。MCP Gateway 为 Uber 内部搭建 AI 智能体提供了一条可扩展、高效、标准化的实现路径；目前平台已托管超过 800 个 MCP 服务端、5000+ 工具。

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

本文将介绍 MCP Gateway 的整体设计，涵盖代理层（MCP 协议与原有协议双向转换）、发现层（MCP 注册中心 + API 自动爬取），以及控制平面（工具编排）。

MCP 网关整体架构

MCP Gateway 基于微服务架构，网关作为 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 注册中心与内部服务信号。定时任务会触发 Cadence 工作流，扫描新增服务、API 以及 schema 变更。

对于每一个扫描到的实体，AutoCrawler 需要完成：

1. 创建或更新对应的 MCP 服务端虚拟描述
2. 生成 / 拉取工具定义与 schema
3. 将工具注册到 MCP 注册中心，默认禁用状态

这套共享底层能力，支持在数千个服务规模下实现 MCP 工具自动发现，而不会阻塞业务团队的迭代流程。

图 2：AutoCrawler 自动爬虫

基于 IDL 的服务发现

对于使用 Protobuf 或 Thrift IDL 定义的传统后端服务，AutoCrawler 直接从 IDL 注册中心提取信息，生成 MCP 服务端与工具。针对每一组服务 / API 分组，执行以下步骤：

1. 增 / 改虚拟 MCP 服务端：为扫描到的业务服务创建或更新虚拟 MCP 服务端
2. 解析 IDL 定义：解析 Protobuf/Thrift 文件，提取方法名、请求 / 响应 schema、文档注释
3. 生成工具描述：基于提取的 schema 和注释，调用大模型生成更适合智能体理解的 MCP 工具描述
4. Schema 转换：将 Protobuf/Thrift schema 转换为兼容 MCP 的 JSON-RPC 2.0 schema
5. 增 / 改 MCP 工具：把生成的 MCP 工具注册、更新到 MCP 注册中心，默认禁用

原生 MCP 服务端发现

除了基于 IDL 的存量服务，MCP Gateway 也支持原生 MCP 服务端—— 即直接实现 MCP 协议、面向智能体优化的服务。

Uber 使用 MCPFx 框架开发原生 MCP 服务端。每个原生 MCP 服务端会上报心跳指标，宣告自身存活与就绪状态。AutoCrawler 持续监听这些心跳信号，自动发现新增原生 MCP 服务。当识别到原生 MCP 服务端后，走另一套发现流程：

1. 调用原生 MCP 服务端的 listTools接口，获取它暴露的全部工具及对应的 schema
2. 在 MCP 注册中心创建一个虚拟代理 MCP 服务端，包含所有发现的工具与 schema，默认禁用

第三方 MCP 服务端

MCP Gateway 作为 Uber 内部全部 MCP 交互的统一编排层，也支持 Jira、Google 等第三方系统的集成。

第三方 MCP 服务的开通依赖两大组件协同：

1. MCP Gateway：向下透传调用方用户令牌，同时执行网关核心能力：鉴权、限流、敏感数据脱敏
2. 第三方 MCP 服务：将内部用户令牌换取对应的第三方身份凭证，再发起请求到外部 MCP 服务

工具编写与启用管控

虽然 MCP 服务端可以自动生成，但其所有权与控制权仍归属业务服务团队。MCP Gateway 的核心设计原则：被发现 ≠ 对外开放。所有 MCP 服务端与工具初始都是禁用状态，必须由归属团队人工审核、手动启用。服务负责人可以在启用前审阅、优化自动生成的工具定义。

工具描述的任何修改都会触发配置变更对比，变更必须由服务所有者审批。负责人审批并发布配置，必要时可以回滚到历史稳定版本。

图 3：MCP 注册中心 UI 图 4：MCP 工具 UI

数据平面

MCP Gateway 的数据平面是执行 MCP 请求的核心运行时服务。它持续从控制平面拉取服务端、工具配置，并按固定周期刷新内存状态；因此工具更新、启用状态变更这类配置修改可以实时生效，不需要重启或重新部署网关服务。

数据平面基于配置动态实例化虚拟 MCP 服务端。每一个虚拟服务端，网关暴露独立入口端点：/<service-name>/mcp，作为 AI 智能体调用入口。收到请求后，内置代理服务器将请求路由至对应的服务处理器。

图 5：MCP Gateway 数据平面

协议转换与请求执行

MCP Gateway 的协议转换由代理网关内的服务处理器完成。每个处理器能够识别工具信息与下游目标，在运行时完成 MCP 请求路由与执行。

安全能力

MCP Gateway 在工具粒度提供内置鉴权与脱敏能力。网关采用 Uber 内部基于属性的访问控制（ABAC），针对调用主体（人、服务、智能体）执行不同授权策略。授权策略在服务端维度配置，必要时可以针对单个工具单独覆盖策略。

MCP Gateway 还可以开箱即用地对工具返回结果中的个人身份信息（PII）和敏感数据做自动脱敏。

后端为 IDL 服务的调用流程

对于依托现有后端服务的工具，服务处理器在内存维护下游路由映射，包含 HTTP 端点配置、gRPC/TChannel 方法信息。

收到 MCP 请求后，处理器执行：

1. 将传入 JSON 载荷转换成对应传输格式
2. 将请求序列化为 Protobuf 或 Thrift 二进制字节
3. 转发请求到下游业务服务
4. 将后端返回的 Protobuf/Thrift 二进制响应，转回 MCP 兼容 JSON，返回给调用智能体

实际下游请求由 Uber 服务网格边车 Muttley 负责执行。将请求转发给 Muttley，MCP Gateway 可以直接复用已有的服务间路由能力。

原生 MCP 服务端调用

原生 MCP 服务端同样作为虚拟服务注册在 MCP 注册中心，网关充当反向代理。运行时，原生 MCP 请求被透明代理转发至下游服务，响应原路返回调用方。

MCP 网关带来的收益

搭建 MCP Gateway 后，Uber 实现了统一、可规模化的智能体系统构建方案，核心收益如下：

• 工具易于检索与接入
• 存量 API 支持无代码转为 MCP 工具
• 内置可观测性与安全能力
• 集中式归属与治理
• 良好的扩展能力

网关能力扩展

当 MCP Gateway 扩展至数百个服务端、数千工具后，出现了小规模场景不会遇到的难题：上下文膨胀、调用成本过高。

运行时发现

MCP 协议本身没有跨服务检索的原生能力。智能体必须预先知道要访问哪个 MCP 服务端，才能查询可用工具。想要让智能体使用某个 MCP 服务，必须手动配置服务地址、凭证、工具清单。当数量达到数百个服务端，这种方式无法扩展 —— 大量信息会挤占大模型上下文窗口。我们通过下面方案解决该问题：

Omni MCP：单一代理服务，允许 MCP 客户端访问网关内所有 MCP 服务端，采用渐进式发现模式；同时借助增量发现，实现上下文与 token 优化。Omni MCP 对外暴露以下工具：

• discover_server
  根据查询意图，检索匹配的 MCP 服务端
• discover_tools
  查询某个服务端下的可用工具
• get_tool_schema
  获取工具的 JSON Schema
• invoke_tool
  调用工具

以上能力支持增量检索访问全部 MCP 服务，并且自带访问控制与网关全部能力。

Response Projection（响应投影）

MCP Gateway 还提供响应投影，是一种类似 GraphQL 的 MCP 工具调用模式。原理是在工具请求 schema 中新增字段，指示网关只返回需要的字段，而非全量数据。LLM 识别并传入一个嵌套路径数组，指定只需要哪些字段。网关在运行时裁剪返回结果，仅保留投影指定字段。该能力让 MCP 在企业级规模下，更好兼容各类 API schema。

Code Mode（代码模式）

代码智能体常在 Shell 环境运行，把工具输出直接写入文件，比将完整响应载入模型上下文更高效。Code Mode 通过 Uber 面向智能体的 CLI 工具 aifx支持该模式：MCP 调用经由网关转发，无需本地安装 MCP 服务端。智能体可以找到适配任务的 MCP 工具，而不需要在上下文里加载 MCP 定义。aifx提供三条命令：

• aifx mcp list
  列出可用 MCP 服务端
• aifx mcp search
  跨全部 MCP 服务检索工具
• aifx mcp call
  经由 MCP Gateway 调用 MCP 工具

智能体可以在一条命令里串联这些操作，把输出写入文件；文件系统智能体再通过 grep 按需读取，仅把必要内容加载进上下文。Code Mode 目前已经是 Uber 内部代码智能体使用 MCP 工具的默认方案。

结语

MCP Gateway 从根本上改变了 AI 智能体在 Uber 内部的运行方式。过去，数十个团队独立搭建 MCP 集成，工具不统一、安全策略缺失、基础设施重复建设；如今它变成统一、可规模化的平台，任意团队几分钟内即可接入。

这套设计背后的核心思路很简单：存量 API 是给智能体提供工具的最快路径。我们不要求业务团队为智能体时代重写服务；MCP Gateway 在现有基础上做适配，借助 Muttley 透明地把 HTTP/gRPC/TChannel 调用转换成 MCP 交互，下游业务服务零改造。

如果你正在构建大规模智能体系统，最难的部分往往不是 AI 模型本身，而是搭建连接层：检索发现、安全、可靠性，让智能体在生产环境中可信地代表真实用户执行操作。MCP Gateway 就是我们给出的解决方案，希望本文的设计决策能给面临同类挑战的同行带来参考。

致谢

封面图由 OpenAI ChatGPT 生成；未使用外部图片、Logo 或第三方素材。 gRPC 是 Linux 基金会的商标。

关注 Uber 工程团队 LinkedIn 账号，获取最新技术博客与见解。

开源代表：官方 MCP SDK、mcp-proxy、MCP Inspector、各类单 Server MCP 实现（如 Python/TS MCP Server 模板）