AI 模型与平台更新智能体基础设施编辑推荐

Uber 的 MCP Gateway：将智能体接入数千个内部 API，实现规模化应用

Uber 构建了 MCP Gateway，让 AI 智能体能够访问数千个内部 API，而无需每个团队都编写 MCP 服务器。本文将介绍 AutoCrawler、集中式发现、协议转换、策略执行和运维模式，以及为什么网关层正成为企业级智能体不可或缺的基础设施。

NexusAI 编辑部2026年10月6日1.7K 次阅读8 分钟阅读

Uber 的 MCP Gateway：将智能体接入数千个内部 API，实现规模化应用

AI 简报

随着企业部署智能体，每家大型企业都会面临一个规模化难题：如何将数千个现有 API 开放给自主系统，同时不要求工程团队重写服务或专门构建 MCP 服务器。本文拆解 Gateway 的双平面设计、AutoCrawler 发现工作流、运行时协议转换，以及策略和脱敏控制；同时介绍 Omni MCP、Response Projection、Code Mode 等运维模式，说明它们如何降低 token 和成本开销，并阐述企业评估以网关为先的智能体基础设施方案时应考虑的风险、职责划分和实践步骤。

企业级 AI 智能体只有在能够获取可靠、及时的业务上下文并据此采取行动时，才真正有用。Uber 的 MCP Gateway 回答了一个具体却无法回避的问题：如何让智能体在受控、可发现的前提下访问数千个现有 API，同时又不要求每个服务团队都实现 MCP 服务器？Gateway 将发现、转换和策略执行集中起来，使服务团队无需成为关键路径上的负担——他们不必重写端点，服务所有者也仍保有审核和启用权限。这种权衡减少了重复建设的基础设施，并统一了治理方式，同时保留各团队的运维自主权。

从架构上看，Gateway 分为控制平面（MCP Registry 和 AutoCrawler）与数据平面（Proxy Gateway）。Registry 是虚拟服务器和工具的唯一事实来源；AutoCrawler 持续从 IDL 和原生 MCP 服务器生成工具定义，让目录能够自动扩展。Proxy Gateway 在运行时实例化虚拟 MCP 服务器，将 MCP 调用转换为 HTTP/gRPC/TChannel 请求，委托服务网格 sidecar（Muttley）执行，再返回符合 MCP 规范的结果。这种分离支持快速迭代和实时配置刷新，也为各种智能体客户端提供一致的执行模式。

AutoCrawler 是让整套系统切实可行的关键运维抓手。Uber 没有依赖人工编写，而是采用由 Cadence 驱动的工作流，扫描 IDL 注册表、监测原生 MCP 心跳、解析 protobuf/Thrift 定义，并生成初始工具清单。这些生成的工具默认处于禁用状态；是否归属和启用，仍由服务团队决定。AutoCrawler 还借助 LLM 丰富架构和描述，生成便于智能体理解的文档——这种务实的折中兼顾了机器驱动的规模化能力、人工审核与安全把关。

安全、策略和运维防护都内建于网关层，而不是分散到各个团队。平台通过 Uber 的内部访问控制系统执行工具级和服务器级的章程策略，对响应中的 PII 进行脱敏，并统一实施速率限制和审计。平台也支持第三方 MCP 集成，且不会削弱策略控制：网关转发内部令牌，第三方服务再将其交换为外部凭证，从而保持集中管控。这种模式在灵活性与企业治理之间提供了一条务实的折中路径。

从成本和性能角度看，Gateway 解决了智能体工作流扩展的两大瓶颈：上下文膨胀和 token 成本。Omni MCP 支持增量发现——发现服务器、列出工具、获取架构并调用工具——因此智能体无需预先加载数百个工具定义。Response Projection 会在运行时仅保留请求的字段；Code Mode（通过 aifx 实现）则让基于 CLI 的编程智能体将输出写入磁盘，而不是全部载入模型上下文。这些模式结合起来，可以在企业级规模下减少不必要的模型上下文、延迟和 API 开支。

核心要点

集中发现，保留所有权

通过自动爬取构建可搜索的工具目录，但在开放工具之前，必须由服务所有者审核并启用。这样既能减少协作摩擦，也能确保责任明确并维持安全。

在网关层优化上下文与成本

采用增量发现（Omni MCP）、字段级响应投影和基于 CLI 的代码模式，降低智能体工作流的模型上下文、延迟和 API 开支。

将网关视为关键基础设施，并配齐安全控制

在网关层统一执行访问策略、PII 脱敏、速率限制和可观测性；同时采用分阶段发布和金丝雀发布，降低配置错误的影响范围。

设计与架构：两个平面，一个目录

MCP Gateway 的双平面设计决定了它如何扩展，以及团队如何与之协作。控制平面（MCP Registry）维护虚拟 MCP 服务器和工具清单的规范目录；数据平面（Proxy Gateway）负责执行请求，并在内存中实例化已启用的服务器。这种划分无需重新部署即可即时推送配置，也让发现流程自动化，同时将策略执行和所有权保留在人手中。对运维人员而言，它把重复的 MCP 基础设施整合为一项托管服务，并可直接与现有服务网格交互，从而减少维护负担。

AutoCrawler：规模化发现，不增加团队负担

AutoCrawler 是发现引擎，可避免工具编写工作量随规模组合式增长。它持续扫描 IDL 注册表和原生 MCP 心跳，解析 protobuf/Thrift 文件，生成兼容 JSON-RPC 的架构，并创建默认禁用的虚拟 MCP 服务器条目。重要的是，AutoCrawler 还会用 LLM 生成的摘要补充工具描述，并让服务团队不必承担发现流程的关键工作：服务所有者可以在准备就绪后审核并启用这些产物。实际效果是，企业能够快速搭建智能体工具目录，同时保留审核关卡和所有权控制。

安全、策略与脱敏：一次执行，处处生效

在 Gateway 中集中处理授权和脱敏，可以简化风险管理。Uber 针对服务器应用章程策略，并支持按工具设置可选例外；同时通过内部访问控制系统评估调用方主体（人员、服务或智能体），并对返回数据中的 PII 进行脱敏。对于第三方集成，Gateway 会转发用户令牌，由外部服务执行令牌交换，从而保留可追溯性。这种做法能减少各团队安全水平的差异，提供一致的审计记录，并让策略执行紧贴运行时请求。

运维模式：Omni MCP、Response Projection 与 Code Mode

Uber 增加的运维能力，解决了发现流程和模型上下文方面的摩擦。Omni MCP 提供发现原语（discover_server、discover_tools、get_tool_schema、invoke_tool），让智能体可以逐步发现并调用工具。Response Projection 允许 LLM 提示词仅指定所需字段，由 Gateway 裁剪响应，从而降低 token 用量。通过 aifx CLI 提供的 Code Mode，让编程智能体按顺序执行列出、搜索和调用命令，并将输出写入磁盘；后续的文件系统智能体再按需加载数据。这些模式是控制成本、提升生产环境智能体链路可靠性的实用手段。

风险、局限与职责划分

以网关为先的方案能减少重复工作，但也会带来运维风险集中问题：网关配置错误或出现缺陷，可能影响大量工具。因此，明确职责边界至关重要——发现流程应当自动化，但启用权限必须留在服务团队手中。其他局限还包括基于 IDL 的服务可能出现架构漂移、协议转换中的边缘情况，以及投影不匹配带来的剩余成本。企业应为网关配套完善的 CI、审批工作流、金丝雀发布和可观测性，以降低系统性故障风险。