Uber 内部 AI 基础设施：与杰出工程师 Uday Kiran Medisetty 的对谈

流媒体播放最新一期节目

现在就在 YouTube、Apple 和 Spotify 上收听和观看。 本页顶部可查看本期节目文字稿，底部可查看本期节目时间戳。

本期节目由以下赞助商支持

• turbopuffer – turbopuffer 工程团队正在做一件非常酷的事：他们正从第一性原理出发彻底重新设计存储架构，让搜索在大规模下更快、更便宜、更可靠。而且他们正在记录整个过程！在 turbopuffer.com/v3 关注他们的重写进展

• Linear – 对我们开发者来说，一大挑战就是要审查的代码量实在太大。Linear Diffs 是一项新功能，让你可以在 Linear 内部审查 PR，所有上下文都集中在一处。它甚至支持堆叠 PR。来看看吧

• WorkOS – 你如何处理智能体与权限问题？WorkOS 构建了 Airlock，这是面向 AI 智能体的授权层。它会根据智能体的意图和你的规则评估每一个请求，然后允许、拒绝，或将其转交给人工审批。可与 Claude Code、Codex 和 MCP 网关配合使用。试一试

本期内容

如今，Uber 内部的开发者工具是什么样子？它们与你在大多数地方看到的非常不同。例如，你能猜到 DevPods、Code Inbox、Slate 或 Wisdom 这些系统为工程师提供什么服务吗？

DevPods、Code Inbox、Slate 和 Wisdom：Uber 工程师日常使用的 20 多个内部工具中的四个

本期节目深入探讨 Uber 开发者日常使用的工具，我们的向导是 Uber 任职时间最长的工程师之一：Uday Kiran Medisetty。Uday 是公司为数不多的杰出工程师之一，如今负责智能体 AI 方面的大量工作。

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

与 Uday 对话的要点

以下是本期节目中 11 个有趣的收获：

1. Uber 的服务数量变化剧烈：2015 年 Uday 加入时，总共只有两个服务。到 2019 年，已有数千个。到 2026 年，服务数量将与 2019 年大致相同，尽管业务规模比那时大了约 10 倍！

2. Uber 大部分服务都是自研的，因为现成软件无法应对其规模——或者根本不存在！以下是 Uber 不得不自建的服务示例：

uOwn：显示谁拥有某个服务或资产。早在 2015 年，还没有这样的供应商。
M3DB：Uber 每秒产生约 5 亿个指标，没有供应商能承受这种负载，所以他们自己构建了它。可观测性公司 Chronosphere 就建立在开源的 M3DB 之上，我们此前也报道过 Uber 如何构建其可观测性平台。
Cadence：一个持久化工作流引擎，用于司机入职等多日流程。Uber 当时需要它时，这样的系统还不存在。 Temporal 就是基于开源的 Cadence 框架构建的。
Morpheus：一个结合了功能开关和实验（包括切换测试）的系统，支持 Uber 运营的双边和三边市场。同样，Uber 当时需要它时，这样的解决方案还不存在。

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

4. 单一的 AI 模型网关带来了丰厚回报。2023 年，Uber 的平台团队决定，所有用 AI 构建的东西都必须与模型和 harness 无关。他们构建了 Model Gateway，以支持在 Anthropic、OpenAI、其他供应商模型之间切换，现在还支持他们运行的开放模型。有了 Model Gateway，就很容易扩展出这些部分：

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

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

6. Uber 对 AI 支出采取混合方式：工程师会分配到一个支出层级。当他们达到限额时，其经理可以签字批准当月支出更多。基本上，对于合适类型的工作，没有支出限制，但 Uber 不希望工程师粗心大意地消耗 token。

一个名为 CostCheck 的插件跨会话工作，并提供如何改善工程师成本状况的建议。过去几个月，Uber 已将 token 成本降低了约 50%，正如我们之前报道的那样。

7. 所有 PR 仍由工程师审查，但 Uber 构建了工具来帮助开发者决定他们需要在每个代码变更上花多少时间。Uday 承认代码审查已成为公司内部的一大瓶颈，Uber 构建了 Code Review，让开发者更容易、更高效地进行这些审查。

当开发者审查一个变更时，AI 代码审查已经运行，该功能的截图和视频已经添加（如适用），并且变更已被分配风险评分。

8. 今年早些时候，Uber 不得不为其 CI 系统宣布内部“红色警报”。这是因为 CI 任务在 12 个月内翻了一倍多，导致 CI 系统的负载过高。为了控制构建速度，团队将简单的 CI 任务（例如 linting、构建和模板规则）移至“内循环”：这样 agent 在打开 PR 之前，会使用 afx validate 命令运行这些命令。

9. Uber 按每个 PR 所做的工作类型为 PR 打标签。过去，Uber 衡量的是“PR 速度”：一个 PR（或者，用 Uber 的话说：一个“diff”）进入生产需要多长时间。有了 agent 之后，这样做意义不大，因为很容易创建几十甚至几百个 PR，而其中许多 PR 可能对产品没有业务影响。

因此，Uber 现在按类型为所有 PR 打标签：功能、缺陷修复、维护、测试或文档。

他们看到“功能 PR”的百分比在上升，而“维护 PR”的百分比在下降。

我觉得这种分类方法很聪明！

10. 在像 Uber 这样的公司里，软件工程师的工作是构建上下文。正如 Uday 反思这份工作如何变化时所说：

“从某种意义上说，工程的工作是：‘你如何为 agent 构建正确的上下文，以产生可靠的输出？’
你需要真正擅长上下文工程。
此外，[擅长]多任务处理也成了一件重要的事。以前，创建一个 PR 要花很多时间，所以你会全神贯注于它。但现在你要在这么多事情之间不断切换。你需要能够验证自己的工作，并从 agent 那里挑出任何代码异味[以避免]将回归发布到生产环境。
上下文工程、多任务处理能力，以及审查和验证输出的能力：这些技能现在变得重要得多，因为你能比以往并行处理更多事情。”

11. Uber 的 AI 工具看似是在一年内建成的：实际上，它建立在十年开发工具投资的基础之上。Minion——于 2025 年构建——由 DevPods 提供支持，而 DevPods 是 Uber 在 2017 年创建的。得益于现有的 Thrift 和 Protobuf 注册表，Uber 的 MCP Gateway 构建得很快。Jaeger 追踪让 Slate 路由和 Context 图变得更容易，等等。

用 Uday 的话说：