How Uber Built A Gateway For AI Agents To Access Tools

Uber如何构建AI代理访问工具的网关

ByteByteGo

2026年10月28日

Kalshi：为影响市场的关键时刻而生的工程实践（赞助内容）

市场不会等待。在预测市场中，价格在毫秒之间变动，每个交易必须在发生时立即完成。在12月9日的Agentic数据峰会上，Kalshi技术团队成员Batu Balimtas将带您深入了解《为影响市场的关键时刻而生的工程实践：Kalshi与Redpanda》。了解Kalshi的数据基础设施如何在关键时刻保持同步，以及如何在生产环境中运行这些系统。12:00 PM PT（太平洋时间）观看Kalshi现场演示。峰会免费且为线上举办，时间8:30 AM–2:00 PM PT（太平洋时间），您可选择参与最关注的环节。

立即预留席位

现成的大型语言模型可以解释代码中的错误原因，可以提出可能的成因，或者执行编写数据库查询等任务。然而，所有这些都基于模型训练的通用层面，无法期望它根据您系统内部机制生成答案。

这需要通过工具来实现。每个工具都针对特定任务构建。但在企业环境中，您可能会面临大量工具的困扰。Uber工程团队就面临这样的情况。

为解决这一问题，他们构建了MCP网关。可以将其视为一个共享平台，使不同AI代理能够发现可用工具并使用它们完成任务。本文将详细探讨Uber如何构建这个网关。我们将涵盖以下内容：

• 工具是什么，为什么AI代理需要它们
• MCP在Uber中的作用
• Uber MCP网关的设计方式
• 网关如何发现可用工具
• MCP网关的工作原理
• MCP网关如何处理权限和访问控制

免责声明：本文基于来自多个来源的公开信息。文末有参考文献。如发现任何不准确之处，请在评论区指出。

为什么AI代理需要工具

如果您希望通用型大语言模型（LLM）能针对当前系统生成特定答案，就需要让模型访问系统信息。例如，假设开发人员询问基于LLM的AI助手为什么XYZ服务突然开始失败。答案隐藏在系统的日志、部署、指标和事件中。LLM需要访问这些信息才能回答这个问题。

这时我们可以创建工具。可以将工具视为AI应用可以执行的操作。例如，可以创建搜索日志的工具、检索事件详情的工具，或检查部署状态的工具。模型选择工具并提供必要输入，应用执行操作后将结果返回模型。

许多这些工具已经以API的形式存在。您可能已经知道，API是程序之间请求服务的接口。例如，我们可以有一个日志服务，它暴露了API接口。它接受服务名称和时间范围作为输入，并返回该范围内的所有日志条目。

然而，为了让代理使用此类服务，我们需要描述其功能及所需输入。这种结构化定义表现为LLM应用可使用的工具。在后台，API实际执行搜索操作。

MCP 代表 Model Context Protocol。通过 MCP，AI 应用程序可以以标准化方式发现可用的外部功能并与其交互。Uber 使用 MCP 来构建其工具生态系统。

要更好地理解 MCP 的作用，我们需要了解三个重要概念。

首先，您有 MCP 客户端。这是位于 AI 应用程序内部的组件。它通过 MCP 进行通信，并处理各种交互，例如请求可用工具或调用选定工具。

其次，是 MCP 服务器。它通过 MCP 暴露功能（或工具）。在 Uber 的案例中，服务器展示可用工具并接受对这些工具的请求。

第三，您有 MCP 工具。这是服务器暴露的单个操作。您也可以将其视为能力。一个服务器可以提供多个工具。

MCP 要求您正确定义工具。该定义由名称、描述和输入模式等信息组成。模式提供了数据的结构。例如，哪些字段存在、哪些是必填项以及它们可以接受的值类型。例如，您可以有一个模式，其中 service_name 必须是字符串，limit 是整数。

MCP 使用结构化方式来格式化请求或其参数。同时，也格式化相应的结果或错误。格式通常为 JSON-RPC 2.0。这种标准化使集成变得容易。您可以使用相同的 MCP 客户端与不同的 MCP 服务器通信。

然而，这种标准化并非没有代价。必须有人决定哪些工具存在以及它们在何处运行。您还需要跟踪工具的所有权及其工作方式。最初，Uber 内部的工程团队构建了自己的 MCP 集成。在小规模时，这种自主性很好。但随着采用率的提高，很明显每个团队都在解决类似的问题。例如，暴露工具、管理连接、处理权限等。更困难的是，发现哪些工具可用变得困难。所有内容都分散在各处。

除此之外，Uber 现有的服务环境带来了另一个挑战。Uber 的所有服务之间没有统一的通信方式。一些使用 HTTP，一些使用 gRPC，还有一些使用 TChannel。例如，您可能会有一个使用 JSON 的 HTTP API 和一个使用 Protobuf 消息的 gRPC API。在不修改请求格式的情况下，无法直接将 MCP 请求转发到这些服务。

因此，Uber 需要一个通用层，可以将 MCP 客户端连接到工具。他们还希望这一层能够处理共享的发现、安全性和运维支持。这一层被称为 MCP 网关。

Uber MCP 网关的设计方式

Uber MCP 网关平台分为两个主要组件：MCP 注册中心和代理网关。这种分离有助于 Uber 工程团队独立管理工具定义和权限。

让我们详细看一下这两个组件。

MCP 注册中心

您可以将 MCP 注册中心视为控制平面。它保存 MCP 服务器和工具的目录。您可以在注册中心记录发现工具所需的信息并了解工具的更多细节。

来源：Uber 工程博客

他们称之为控制平面的原因是，注册中心还管理配置。例如，您可以在注册中心启用或禁用工具。它也是共享的事实来源。

代理网关

这是数据平面。它在代理执行任务时处理实际的MCP请求。

网关会识别请求的工具。它应用必要的控制并发送请求到对应的服务。同时，它返回兼容MCP的结果。

工具的发现方式

你无法手动为成千上万的服务创建MCP集成。这需要大量工作，且容易出错。Uber通过使用AutoCrawler自动化了大部分工作。

AutoCrawler可以发现现有的API和MCP服务器。它生成或检索这些工具的定义，并在MCP注册表中进行注册。

从技术层面来看，AutoCrawler是一个分布式工作流系统。它基于Cadence构建。在此架构中，你有一个定时任务启动的工作流，用于查找任何新服务、API或模式变更。

但AutoCrawler是如何发现新内容的？它主要有两个发现路径：

从现有API定义中发现

许多API使用内部定义语言（IDL）来描述它们的接口。

IDL是服务接口的机器可读描述。你可以用它来指定操作名称、请求字段和文档注释。例如，你可能有一个API定义描述了一个名为GetDeploymentStatus的操作。它可能以部署ID作为输入，并返回状态和时间戳。

AutoCrawler可以读取这些定义，然后执行多个步骤。

首先，它为服务创建一个MCP服务器表示。它也可能更新现有的表示。接下来，它提取方法名称、请求和响应结构。然后，它将发现的内容转换为MCP可以理解的工具模式。

AutoCrawler还使用LLM从服务中提取的细节生成更准确的工具描述。最后，它将这些工具定义存储在注册表中。

正如你所看到的，AutoCrawler是Uber无代码方法的一个良好示例。现有服务合同已包含足够信息，使平台能够构建MCP接口。

发现原生MCP服务器

一些服务直接实现MCP。在Uber，这些被称为原生MCP服务器。这些服务器已经具有工具定义。因此，AutoCrawler获取这些定义的工作量更少。

每个原生服务器会发出心跳指标。它表明服务器的存在和就绪状态。AutoCrawler会跟踪这些信号。当它发现服务器时，它会调用服务器的listTools操作。一旦发现工具，它会在注册表中为所有工具及其模式创建代理表示。

正如你所看到的，两种发现路径最终都会进入同一个目录。

工具发现与使用权限

Uber在设计时选择新发现的服务器和工具初始状态为禁用。

这意味着自动发现仅使平台可见这些能力。在此之后，服务所属团队应审核并启用服务，使其对代理可用。启用的决定是所有权决策。最好让服务团队有机会检查工具描述是否正确。

所属团队可以审核工具定义，并通过注册表的接口更新它们。每次修改都会生成一个新的差异，需要批准。只有经过批准的更改才会部署。如果需要，还可以让所有者回滚到之前的版本。

Uber的MCP网关工作原理

一旦将工具配置保存到注册表并标记为可用，数据平面会使用这些工具信息来更新其内存中的状态。这一过程会按照固定的周期性时间间隔执行。

网关在处理请求时使用当时的映射关系。周期性刷新机制确保任何新变更都可以在不重启或重新部署服务的情况下生效。

网关会使用这些配置信息创建虚拟MCP服务器。可以将虚拟服务器理解为网关内部存在的一个逻辑MCP接口，它由一组工具和客户端访问这些工具的端点组成。例如，可以在端点"logging/mcp"上暴露一个名为"logging"的服务。

使用工具时，客户端会将此端点作为MCP服务器进行通信。网关中有一个处理器，知道该服务器包含哪些工具以及如何访问支撑这些工具的服务。

为了更好地理解，建议跟踪请求在网关中的完整路径。

假设有一个AI代理调用了一个由gRPC服务支持的工具：

• 首先，MCP请求到达网关。网关会找到对应的虚拟服务器和被请求的工具。

• 接着，服务器处理器使用内存中的映射关系确定下游目标和操作。在这种情况下，下游服务就是网关将发送请求的目标服务。

• 处理器将工具的JSON参数转换为服务期望的格式。例如，在gRPC操作的情况下，需要将请求序列化为Protobuf字节。

• 接下来，服务执行操作并返回响应。

• 最后，网关将响应转换为MCP兼容的结果并返回给调用者。

可以猜到，这种方法同样适用于其他类型的服务。例如，HTTP后端接收HTTP请求。或者TChannel服务使用TChannel或Thrift路径。

网关如何处理访问控制

可以将网关视为一个共享的访问规则执行场所，适用于所有工具。

Uber工程团队使用其内部的访问控制系统来应用访问规则和策略。这些策略基于调用者。调用者可以是人类用户、服务或AI代理。可以在服务器级别配置策略。如果需要，还可以为特定工具设置特定策略。因此，系统提供了大量灵活性。

这意味着平台支持在工具级别进行授权。例如，可以有一个事件管理服务器暴露用于读取事件和更改事件状态的工具。可以为这些操作设置不同的访问权限，即使它们属于同一个服务器。

网关还可以对响应中的个人身份信息（PII）进行脱敏处理。或者对工具响应中可能存在的其他敏感数据进行脱敏。

对于Jira和Google等第三方服务，需要进行额外的身份验证。这是因为内部Uber凭证与第三方系统可能接受的凭证不同。网关在其处理流程中会将调用者的内部用户令牌发送给该服务。第三方服务会将该令牌兑换为外部认证令牌，然后使用该认证令牌将请求发送到外部MCP服务器。

正如你所看到的，职责被合理划分。网关负责处理通用的访问和执行细节，第三方服务则专注于处理外部事务。

Uber MCP 网关如何处理庞大的工具目录

在 Uber 运行的大量工具所构成的庞大目录，可能会给 MCP 网关带来上下文限制问题。

虽然网关可以提供数千种工具，但 AI 代理需要一种高效的方式来选择有用的工具。这是因为每个工具定义都会占用模型上下文窗口的空间。你可以将这个上下文窗口理解为模型输入中可用的空间。这个窗口有容量限制，你还需要为系统指令、对话历史和工具返回结果等其他内容预留空间。

如果你的应用程序提前加载了数千种工具的描述和模式，它们可能会占用大量上下文空间。同时，模型需要处理的输入量也会大幅增加。工具响应也是如此。一个 API 可能会返回一个详细对象，即使任务只需要两个字段即可完成。

为了解决这些问题，Uber 对网关进行了三项改进：

• Omni MCP 帮助代理逐步发现能力。这是一个单一的代理服务器，允许 MCP 客户端通过逐步发现访问网关的任何服务器。它提供了“discover_server”、“discover_tools”、“get_tool_schema”等工具。

• 响应投影减少了工具结果中返回的字段数量。这是一种类似 GraphQL 的 MCP 工具模式。你可以在工具请求中注入一个新字段，告诉网关哪些字段应该包含在响应中。网关会移除其他字段。

• 代码模式让编码代理可以通过 shell 命令和文件处理结果。

结论

构建 MCP 网关大幅改变了 Uber 上 AI 代理的运作方式。

最初这是一个碎片化问题。你有数十个团队独立地连接 MCP 集成。工具不一致，没有共享的安全保障，基础设施重复。现在，一切都变成了一个可以扩展的统一平台。任何团队都可以在几分钟内接入这个平台。

驱动 Uber 团队的核心理念是：现有 API 是让 AI 代理访问工具的最快方式。他们不希望团队为了适配网关而重写服务。MCP 网关承担了繁重的工作。

对开发者的启示是：构建代理系统最困难的部分不是 AI 本身。你应该更关注构建正确的连接组件。在生产环境中，发现、安全性和可靠性非常重要。

参考资料：

• Designing MCP Gateway Uber’s MCP Management Platform

• Model Context Protocol