Uber 工程实践：一套网关把数千个内部 API 自动转成 MCP 工具
Uber 把公司几千个 API 全自动变成 MCP 工具给 AI Agent 用，零代码接入、默认禁用加审核，还有三招防上下文爆掉，做 Agent 基建的都该看看。
Uber 用“控制平面 + 数据平面”的网关体系，把全公司数千个存量 API 自动转译成 MCP 工具，目前已托管 800+ MCP 服务器、5000+ 工具，AI Agents 无需改动后端即可调用。AutoCrawler 基于 Cadence 工作流扫描 Protobuf/Thrift 的 IDL 注册表，用 LLM 生成工具描述并转成 JSON-RPC 2.0 schema，服务团队零代码接入。安全上所有工具默认禁用，需服务所属团队审核后启用，授权细到单个工具并自动脱敏 PII。针对上下文膨胀，Uber 用 Omni MCP 的四个元工具做渐进式发现、Response Projection 裁剪响应字段，编码智能体则默认走 Code Mode 把输出写入文件后用 grep 读取。
Uber MCP 网关设计工程实践：面向 AI Agents 的企业级 MCP 管理平台 @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… 🔗 View Quoted Tweet 💬 3 🔄 0 ❤️ 3 👀 343 📊 3 ⚡
