Uber 用 MCP 网关把 800 多个内部服务转为 5000 余个智能体工具

10 月 1 日，Uber 在工程博客公开发布了内部 MCP Gateway 的设计实践，首次把这家出行巨头在智能体基础设施上的生产级架构摆到台面。根据官方披露，这套网关目前托管着超过 800 个 MCP 服务器和 5000 余个工具，充当公司所有 AI 智能体与后端微服务之间的编排与路由层。它的核心目标很朴素：让既有的数千个内部 API，无需改造下游服务，就能被 AI 智能体直接调用。

在架构上，MCP Gateway 采用经典的双平面设计。控制平面是 MCP Registry，作为整个生态的单一事实来源，维护着服务器目录、工具定义、所有权与启用状态；数据平面是 Proxy Gateway，在运行时把 MCP 协议调用翻译成 HTTP、gRPC 或 TChannel 请求，再经 Uber 的服务网格 Muttley 转发到对应的后端服务，并把响应转回 MCP 兼容结果。这种翻译层让智能体用统一的 MCP 接口对接存量系统，下游服务一行代码都不用改。

真正体现工程含量的，是自动发现与默认安全的设计。Uber 用名为 AutoCrawler 的 Cadence 分布式工作流，定时扫描公司的 IDL 注册表，从 Protobuf 或 Thrift 定义里提取方法名与字段，再用大语言模型生成对智能体友好的工具描述，随后把成千上万个工具以默认禁用状态注册进去。任何工具要被智能体调用，都必须由服务所有者审核并显式启用，描述变更还要走配置 diff 审批——发现在这里只是起点，绝不等于暴露。

针对工具规模带来的上下文膨胀问题，Uber 还引入了 Omni MCP 渐进式发现（discover_server、discover_tools、get_tool_schema、invoke_tool 四个工具按需拉取）和 Response Projection 字段裁剪，避免把每个服务器的完整 schema 都塞进模型上下文。对编码智能体，Uber 已将内部 CLI 工具 aifx 的 Code Mode 设为默认用法，智能体无需本地安装任何 MCP 服务器即可调用工具。

在权限与合规层面，网关在工具级别套用 Uber 的访问控制与租户章程策略，并默认对响应做 PII 脱敏。对第三方 MCP 的把关比内部更严格，护栏会拦截对关键服务的写操作并记录所有调用。Uber 的这份实践，实际上回应了所有大型企业都要面对的同一道题：如何让智能体在生产系统上规模化运行，同时不失去对它究竟能做什么的控制。把存量 API 变成受治理的 AI 工具，正成为企业智能体落地的基础设施主线。