Uber MCP 网关：面向 AI Agents 的企业级 MCP 管理平台

Uber MCP 网关设计工程实践：面向 AI Agents 的企业级 MCP 管理平台 [@UberEng](https://x.com/UberEng) Uber 把全公司数千个存量 API 用一套 “控制平面 + 数据平面” 的网关体系自动转译成 MCP 工具，让 AI Agents 不改动任何后端服务就能调用整个公司的能力。目前已托管 800+ MCP 服务器、5000+ 工具。 要解决的问题 AI Agents 在 Uber 内部快速铺开，数百个团队各自搭建与后端服务的 MCP 集成，导致工具碎片化和基础设施重复建设。Uber 的判断是：缺的不是更聪明的模型，是一套统一的“连接组织”，发现、安全、可靠性这些让 Agents 值得信任的基建。 架构：经典的两平面分离 · MCP Registry（控制平面）：全公司工具的目录和唯一事实来源，管理发现、所有权、启停。支持从“零代码包装现有 API”到“原生 MCP 服务”的多种形态。 · Proxy Gateway（数据平面）：运行时真正执行 MCP 请求，在 MCP 协议与 HTTP / gRPC / TChannel（Uber 自研 RPC 协议）之间双向转换，经 Muttley（服务网格 sidecar）转发到下游，再把响应转回 MCP JSON。配置热更新，无需重启。 最有工程价值的三个设计 1. AutoCrawler：存量 API 的自动化“MCP 化” 基于 Cadence 工作流引擎，持续扫描内部 IDL 注册表（Protobuf/Thrift 定义），对每个新服务执行五步流水线：建虚拟服务器 → 解析 schema 和文档注释 → 用 LLM 生成对智能体友好的工具描述 → 把 Protobuf/Thrift 转成 MCP 兼容的 JSON-RPC 2.0 schema → 注册。整个流程不需要服务团队写一行代码。 2. “发现 ≠ 暴露” 的安全模型 所有工具默认禁用，必须由拥有该服务的团队显式审核后启用；工具描述的变更要走配置 diff 审批、可回滚。授权细到单个工具，按调用主体（人/服务/Agents）应用不同策略，PII 数据开箱即用自动脱敏。这是把平台工程的传统治理纪律完整搬进了智能体时代。 3. 对抗上下文膨胀的三板斧 给智能体配几百个服务器会直接撑爆模型上下文窗口，Uber 的解法层层递进： · Omni MCP：单一入口 + 四个元工具（discover\_server → discover\_tools → get\_tool\_schema → invoke\_tool），让智能体按需渐进式发现，而不是一次性加载全部定义； · Response Projection：类 GraphQL 思路，让模型在请求里声明只需要哪些字段，网关在运行时裁剪响应； · Code Mode：编码智能体通过 aifx CLI 调用工具并把输出写入文件，再用 grep 选择性读取；彻底绕开上下文限制，目前已是 Uber 内部编码智能体的默认方式。   Uber Engineering@UberEng [x.com/i/article/2106…](https://x.com/i/article/2106059544376066048) [🔗 View Quoted Tweet](https://x.com/UberEng/status/2106071967619322330)