深入 Uber 内部：Uber 的 AI 基础设施

今天，Uber 内部的开发者工具长什么样？它们和大多数公司看到的很不一样。比如，你能猜到 DevPods、Code Inbox、Slate 或 Wisdom 这些系统分别为工程师提供什么服务吗？

本期节目深入 Uber 开发者的日常工具。我们的向导是 Uber 任职时间最长的工程师之一：Uday Kiran Medisetty。Uday 是公司里为数不多的杰出工程师之一，目前负责 Agentic AI 的大量工作。

我们和 Uday 聊了 Uber 的开发者基础设施如何为 AI Agent 做好准备。我们回看了 Uber 在生成式 AI 之前构建的系统，以及那些把 Agent 连接到代码、内部服务和工程知识的新工具。Uday 解释了工程师如何使用后台 Agent，为什么 Slate 这类工具能让开发（以及修 bug）更高效，以及代码审查正在如何变化。我们还谈到了 Uber 对 token 成本的处理方式，以及随着工程师角色变化，Uber 如何衡量生产力。

与 Uday 对话的 11 个要点

1. Uber 的服务数量变化很不规律。
2015 年 Uday 加入时，公司总共只有两个服务；到 2019 年，服务数量已达数千个；到 2026 年，服务数量将与 2019 年大致持平，而业务规模已是当时的约 10 倍。

2. Uber 的大部分服务都是自研的，因为现成软件无法支撑其规模——或者根本不存在。
例如：

• uOwn：显示某个服务或资产归谁所有。2015 年市面上没有这样的产品。
• M3DB：Uber 当时每秒产生约 5 亿个指标，没有厂商能承受这种负载，于是他们自研。可观测性公司 Chronosphere 就是基于开源的 M3DB 建立的；我们此前也介绍过 Uber 如何构建其可观测性平台。
• Cadence：用于司机入职等多日流程的持久化工作流引擎。Uber 需要时，市面上没有这样的系统。Temporal 就是基于开源的 Cadence 框架建立的。
• Morpheus：一个结合功能开关与实验（包括 switchback 折返实验）的系统，支持 Uber 运营的双边和三边市场。同样，Uber 需要时没有现成方案。

3. 在 Uber，“城市”是一等公民概念，一直深入到物理基础设施层。
Uber 之所以要自研大量工具，另一个原因是“城市”是一个需要在可观测性、功能开关、部署甚至服务分片等系统中统一处理的“基本原语”。例如，早期一些服务的数据库按城市分片。即使在今天，每个城市仍被固定到某个云区域，并且可以随时故障转移到另一个区域。我们此前介绍过 Uber 如何从裸金属迁移到云端。

4. 统一的 AI 模型网关带来了巨大回报。
2023 年，Uber 平台团队决定：所有用 AI 构建的东西都必须与模型和 harness 无关。他们构建了 Model Gateway，支持在 Anthropic、OpenAI 及其他厂商模型之间切换，现在也支持 Uber 自己运行的开源模型。有了 Model Gateway，扩展以下能力就很容易：

• AI Guard：由安全团队运行的中间件。它检查所有请求和响应，测量延迟（并标记过慢的模型或查询）。
• 支出追踪：按用户追踪支出。
• 可见性：审计日志和会话追踪。

5. AIFX 让工程师在切换 harness 时不丢失设置。
Uber 目前支持 Claude Code、Codex 和 OpenCode 作为 harness。AIFX（AI Foundations 的缩写）是架在这些 harness 之上的封装层，因此当工程师更换 harness 时，所有设置、技能和插件都会随之迁移。

6. Uber 对 AI 支出采取混合策略。
工程师会被分配一个支出层级。达到限额后，其经理可以签字批准当月追加支出。基本上，对于合适类型的工作，没有支出上限，但 Uber 不希望工程师粗心浪费 token。

一个名为 CostCheck 的插件可以跨会话工作，并就如何改善工程师的成本结构给出建议。过去几个月，Uber 将 token 成本降低了约 50%，我们此前也报道过。

7. 所有 PR 仍由工程师审查，但 Uber 构建了工具，帮助开发者判断每个代码变更需要花多少时间审查。
Uday 承认，代码审查已成为公司内部的一大瓶颈，Uber 构建了 Code Review，让开发者更轻松、更高效地完成审查。

当开发者审查一个变更时，AI 代码审查已经运行完毕，功能截图和视频（如适用）已经添加，变更也被打上了风险分数。

8. 今年早些时候，Uber 不得不为其 CI 系统宣布内部“红色警报”。
原因是 12 个月内 CI 任务数量增加了一倍以上，给 CI 系统带来了过高负载。为了控制构建速度，团队将简单的 CI 任务（如 lint、构建和模板规则）移到“内循环”：让 Agent 在打开 PR 之前用 afx validate 命令运行这些检查。

9. Uber 按每个 PR 所做的工作类型给 PR 打标签。
过去，Uber 衡量“PR 速度”：一个 PR（Uber 称之为 “diff”）进入生产需要多长时间。有了 Agent，这种衡量方式就没那么有意义了，因为很容易创建几十甚至几百个 PR，其中很多可能对产品没有业务影响。

因此，Uber 现在按类型给所有 PR 打标签：功能、缺陷修复、维护、测试或文档。他们看到“功能 PR”占比上升，“维护 PR”占比下降。我认为这种分类方法很聪明！

10. 在 Uber 这样的公司，软件工程师的工作是构建上下文。
Uday 这样反思工作的变化：

“从某种意义上说，工程的工作是：你如何为 Agent 构建正确的上下文，让它们产出可靠的结果？

你必须真正擅长上下文工程。

此外，多任务处理也成了必备能力。以前，创建一个 PR 要花很多时间，所以你会全神贯注于它。但现在你要不断在大量事情之间切换。你需要能够验证自己的工作，并从 Agent 的输出中挑出代码异味，避免把回归带到生产环境。

上下文工程、多任务处理，以及审查和验证输出的能力——这些技能现在重要得多，因为你能并行处理的事情比以前多得多。”

11. Uber 的 AI 工具看起来像是一年建成的，但实际上，它建立在十年开发工具投资之上。
Minion 于 2025 年构建，由 Uber 2017 年创建的 DevPods 驱动。Uber 的 MCP Gateway 之所以能快速构建，是因为已有 Thrift 和 Protobuf 注册表。Jaeger 追踪让 Slate 路由和 Context graph 更容易实现，等等。

用 Uday 的话说：

“我们为让工程师生活更轻松而构建的所有东西，也让我们的 Agent 生活更轻松！”

写在最后：Uber 的 Model Gateway，给所有 AI 团队提了个醒

Uday 在访谈里反复回到一个判断：Uber 在 2023 年就决定，所有 AI 能力都必须与模型和 harness 无关。真正带来回报的，不是某个单一模型，而是那层统一的 Model Gateway——它让团队可以在 Anthropic、OpenAI、自研开源模型之间切换，并在同一层上叠加安全校验、按用户计费、审计日志和会话追踪。模型会变，harness 会变，但网关让这些变化不再牵动每一个业务团队。

这也是 接口AI（jiekou.ai） 想帮多数团队补上的那一层。

接口AI 是一个多模型 API 聚合中转平台：一个账号、一个 API Key、一套 OpenAI 兼容接口，即可调用 GPT、Claude、Gemini、Grok、Qwen、DeepSeek 等 200+ 主流模型。已有 OpenAI 集成的项目，通常只需替换 base_url 和模型名，就能把“换模型”从一次架构改造变成一次配置变更。

对正在把 Agent 引入研发流程的团队，接口AI 和 Uber 那套网关思路最接近的地方有三点：

• 统一入口，模型可切换：同一套接口下按任务选择不同模型，避免业务代码绑死在某一家厂商；同时提供 Anthropic / Gemini 原生协议，Claude Code、Codex CLI 等编程工具可以直接接入。
• 成本可管理：官方资源与低价专区并行，特惠资源包约 8 折，企业订阅包约 75 折；企业包包含 200 个团队席位、共享密钥池与统一账单，并支持企业开票。对编程 Agent 场景，还支持 Prompt Caching，缓存读写单独计价。
• 调用可治理：企业包提供 API Key 管理（额度限制、IP 白名单）、调用日志、数据看板和智能模型网关，可按任务难度、成本和质量做动态路由。

Uber 花了十年建 DevPods、MCP Gateway、Model Gateway，才让 Agent 真正跑进研发流程。对多数团队来说，不必从零复刻这套基础设施——先把“统一网关”这一层搭起来，往往就是性价比最高的一步。