Uber 的 Agent 化软件开发生命周期——Uday Kiran Medisetty、Adam Huda(Uber)

Uday Medisetty · AI Engineer

Agent 工程

视频 18:24 原文约 1.8 万字预计阅读 15 分钟来源视频 ↗ 中英对照全文

原平台热度 YouTube ↗

1万观看

225赞

2.2%点赞率

7评论

62.7万频道订阅

数据截至 8 月 27 日

TL;DR · 三句话

一Uber 几千名工程师、12 个站点，一年内做到 70% 的 PR 由 agent 生成、人均代码量翻倍、250 项自动迁移改了 900 万行——靠的是六个平台级构建模块（模型网关、MCP 网关、agent 化 Devpod、skill 生命周期、上下文图谱、Cortana 助手），而且站在六年 monorepo / Bazel 基建之上。 → 详细
二贯穿全场的方法论是「一切都要可归因、可追踪、可回流」：每个模型请求按人按项目归因、trace 接进 eval、2,500 个 skill 过 lint + 自动审查并收集使用反馈回传作者、MCP 从直连演进到 CLI 投射和 code mode 省下 40% 以上 token、agent 在 trace 里暴露出"找上下文烧 token"于是建了 4,000 万条记录的上下文图谱。 → 详细
三Adam 用一个世界杯功能走完工厂线：Slack 里的点子 → Cortana 做商业调研和需求 → Figma 两个变体 → Minion 写代码停在草稿 PR → 验证前移进内循环（模拟器截图比 Figma、两层模型评审、PR 附检查表给人信心）→ 受管的维护循环把合入/不合入当标注数据；最后的瓶颈不再是能不能做，而是 CI 容量、实验数，以及「该不该做」。 → 详细

开场成绩单：70% 的 PR 由 agent 生成、人均代码量翻倍、250 项自动迁移

Uday Kiran Medisetty（Uber）开场定调：这场演讲讲的是 Uber 走向「受管软件工厂」（managed software factory，把软件开发当成一条有管理、可度量的流水线）的历程。前半段他讲六个「构建模块」（building blocks），后半段同事 Adam Huda 讲怎么把这些模块拼成端到端的体验。背景：几千名工程师分布在全球 12 个技术站点。 → 详细
过去一年在 agentic AI 上的投入带来的硬数字：超过 70% 的 PR（pull request，代码合并请求）由本地或云端 agent 生成；每位工程师的代码行数同比翻了一倍。他强调这「远不止写代码，今天在工程生命周期的每个环节都能看到这种变化」。 → 详细
削减重复劳作（toil）的速度同样惊人：已为工程师自动完成 250 多项自动化迁移，涉及 900 万行代码。他特别补了一句前提——过去六年在 monorepo（单一大仓库）和 Bazel（统一构建系统）上的投入，才为今天的加速打下了基础。换句话说：agent 的爆发不是凭空来的，是站在六年工程基建之上。 → 详细
他也坦白：这六个模块在 Uber 内部「处于不同的成熟度和推广阶段」，演讲是「先睹为快」而非全部已落地。 → 详细

模块一 · 模型网关：所有 AI 调用走一个口，PII 不出边界、护栏延迟 <100ms、按人按项目归因

模型网关（model gateway，所有模型请求的统一出入口）是 Uber 最早的投入之一，设计时锁定三件事：默认任何 PII（个人身份信息）绝不流向供应商；加的任何护栏延迟有严格上限；每个请求都能按用户 / 项目 / 团队归因。所有内部用例、编码 harness（harness：包住模型、给它工具和流程的外壳程序）、外部用例，全走一个兼容 OpenAI / Anthropic 协议的端点。 → 详细
中间件链：SPIRE 身份认证 → 脱敏 20 多种 PII 类型的数据匿名化器 → 含五个专用模型的 AI guard（安全与策略审查），全部跑完不到 100 毫秒；这一层还做缓存与 token 优化。 → 详细
归因的用处：既能实时也能进数据湖，用来在整个组合层面设支出额度和护栏；同时采集审计日志与会话追踪（session trace），接进基准测试与自我改进循环——这意味着每一次 agent 调用都成为后续评估的数据。工程师侧的体验是「拿原生客户端、设个 project ID，剩下全交给我们」。规模：800 多个项目、每天超过 1 亿次模型请求，前沿模型和开源模型（自托管或供应商托管）都有。 → 详细

模块二 · MCP 网关与 token 税：从直连 MCP → Omni MCP → CLI 投射 → code mode，全公司省 40%+

起点的困境（去年）：Uber 有数千个内部 API，没有一个是 agent 开箱可用的；一堆 SaaS 工具各有各的认证和配置方式；而且 Uday 点出一个很多团队现在才撞上的问题——「一旦 MCP 装得够多，它们加起来就会产生巨大的 token 税」（每个 MCP 的工具描述都占上下文，装得多就把模型的注意力和预算吃掉了）。 → 详细
解法一：做一个 MCP 网关（和模型网关同构），一个自动爬虫扫描内部 API，只改一处配置就把它们全部投射成 MCP；Google / Slack / Jira 等 SaaS MCP 也由网关统一托管、统一做 token 交换，工程师只有「一个入口、一种安装方式」。 → 详细
解法二是一条清晰的演进线，值得整段记住：① 最初「直连 MCP」；② 今年早些时候做 Omni MCP——只装这一个 MCP，它能发现并调用网关内任何 MCP；③ 几个月前把所有 MCP 投射成 CLI 模式，「这样连返回结果都不会占用你的上下文」；④ 最近又加了会自动安装的 code mode skill，即时生成 Python 脚本，对最吃 token 的 MCP 用例做「极致优化」。 → 详细
结果：一千多个 MCP 工具在线，仅靠这些优化就「在全公司范围内节省了 40% 以上」（token 消耗）。这条线的方向很明确——工具越来越多，但暴露给模型的上下文越来越少。 → 详细

模块三 · Devpod agent 化：预热好的 Kubernetes balloon pod，让 agent 几秒内开工

Uber 多年来用 Devpod（云端远程开发环境）应对几百万行代码的 monorepo，现在把它「agent 化」：agent 需要的环境要快、要隔离、要能无限开、要在所有站点全球可用。 → 详细
具体做法：预先配置好一批 Kubernetes balloon pod（像气球一样提前吹好的闲置容器），仓库已快照、搜索索引已建好，agent 要环境时直接取一个，「几秒钟内就能开始干活」。 → 详细

工程师角色边界在模糊：按语言分的 Devpod 变成「Mega Devpod」，非工程岗也能秒开 agent

以前 Devpod 按语言分（Go / Java / Android 各一种），现在 agent 和工程师都要跨仓库干活，于是做了 Mega Devpod——所有仓库放在一个地方，这是自主编码 agent 现在的工作环境。 → 详细
顺带一句但信息量大：非工程岗员工也能在几秒钟内用上任意一种 agent harness——开发环境不再是工程师专属。 → 详细

模块四 · Skill 的完整生命周期：2,500 个 skill、受管市场、lint + 自动审查、按角色自动装、trace 回流给作者

Uber「今年早些时候跟上 skill 这波潮流」，很快撞上三个问题，Uday 原话列得很清楚：「一是大量重复，同一个 skill 被不同工程师在不同地方各建一遍；二是发现和配置非常麻烦；三是很多 skill 质量不过关。」（skill：给 agent 的可复用操作说明包，相当于一份"怎么做某件事"的 SOP。）这三个问题，任何超过一个人用 skill 的团队都会遇到。 → 详细
解法是「围绕 skill 建一整套生命周期」：分核心 skill 和领域专属 skill，全部进入一个受管的 skill 市场（现在 2,500 个）；每个 skill 都要过「一整套 lint 检查（静态格式校验）和自动化审查」以保证基线质量；安装与发现简化为一条命令。 → 详细
更进一步：按工程师的角色画像（persona）自动安装默认 skill，「agent 自动能选到合适的 skill，你甚至都不用自己去装」。 → 详细
最值得记的是闭环那一步——他说这是「我们当下重点投入的一个领域」：收集 trace（agent 运行轨迹）和评论、采集持续 eval（对输出质量的自动打分），把反馈回传给 skill 作者来改进 skill。规模：每天全公司 2 万多次 skill 执行。也就是说，skill 不是写完就完，而是有使用数据、有质量评分、有回流改进的"产品"。 → 详细

模块五 · 上下文图谱：从 trace 里看到 agent 在「找基本上下文」上烧 token，于是把整个 Uber 装进一张 4,000 万条的图

问题是从 trace 里看出来的：「我们在执行 trace 里注意到，agent 花了大量时间在寻找最基本的上下文上」——服务在哪、依赖是什么、归谁负责、该遵循什么模式。这些信息散落在 Uber 二三十个不同系统里，每个都要自己的 skill / MCP 去采集，结果是「烧 token、增加大量延迟，还会让结果更不可预测」。 → 详细
解法：一个统一的上下文图谱（context graph，把公司里的服务、代码、文档、工单、事故等实体和它们之间的关系画成一张可查询的网），150 种节点和边类型、4,000 万条记录，覆盖从移动 App 构建方式到后端到数据湖，设计文档、Jira、故障和 bug 全部连起来。现在所有 skill 和用例（on-call 的 RCA 根因分析、规划、数据分析、安全扫描）都在接进图谱，「所有这些 skill 都有很大提升」。 → 详细
他给的例子很接地气：问「印度有多少出行订单是现金支付的」，agent 得理解每个概念、知道用哪些表、按什么城市维度写 SQL。有图谱 vs 没图谱，在 token、轮次和延迟上都是「巨大的改善」，而且「我们在基础设施内部做过的所有早期 eval 都是这个结果」。 → 详细

模块六 · Cortana：把 skill + MCP + 图谱打包成全员 AI 助手，一个月 300 个 persona、每天 2 万次会话

Cortana 是 Uber 的内部 AI 助手，前面所有东西（skill、MCP、上下文图谱）全接进它，并覆盖 Slack / CLI / 网页所有界面——公司里任何人问一个问题，它能查图谱、调任何 skill、查任何代码库，在任何界面回答。 → 详细 → 详细
个性化是新开放的能力：员工可挂自定义 skill 和 prompt，接进团队 Slack 频道，「它就了解这个团队的一切，像一个队友一样工作」；多人可在同一频道里协作。 → 详细
数据：仅过去一个月就创建了 300 个不同的 persona，每天 2 万多次会话。 → 详细

Adam 的端到端演示（上）：从 Slack 里一个世界杯点子，到商业调研、需求、Figma 两个变体、原型——「原来要几周对齐，现在压缩到很短」

Adam Huda 接棒，用一个功能走完整条工厂线。起点是一个产品想法：世界杯期间，乘客离开拥挤体育场时，能不能给一个避开人群的更好上车点。团队在 Slack 里讨论，@ 进 Cortana 帮忙推进。 → 详细
第一步不是写代码而是判断值不值得做：Cortana 借上下文图谱做商业调研——以前有过哪些大型场馆活动、哪些体育场适合。从 Slack 跳到网页界面看调研结果。然后才是产品需求（判断只在北美上线，因为体育场都在那里），再让 Cortana 一起出 Figma 初步 mock-up。 → 详细
设计阶段直接做两个变体跑 A/B 实验（按钮文案不同）；接着 Cortana 帮忙想「需要哪些代码改动、App 里现有哪些页面和后端能复用」。Adam 的对比句：「以前这个过程可能要很长时间，让所有人对齐可能得花好几周。现在我们能把它压缩到非常短的时间，很快就能拿到一个原型。」——注意这里被压缩的是"对齐"时间，不只是"写代码"时间。 → 详细

端到端演示（中）：交棒给云端编码 agent Minion，故意停在「草稿 PR」不推 CI

从 Cortana 交棒给 Minion——Uber 自研的云端编码 agent，可交互式也可全自主，由 Devpod 驱动，有完整构建环境、能跨仓库，演示里同时改后端和前端。 → 详细
关键设计决策：Minion 停在只创建草稿 PR、暂不推到 CI（持续集成，自动跑构建和测试的流水线）。原因有两层：这种跑法「干琐碎的苦力活很好使，但要构建更复杂的端到端功能，我们真的需要先把功能验证一遍」；同时「避免给 CI 增加大量额外负载」——能在推 CI 之前更早验证，「收益会非常大」。 → 详细

端到端演示（下）：把验证「前移」进内循环——模拟器截图比 Figma、连 staging 验前后端、内外两层代码评审、PR 附检查清单给人信心

SDLC 里有内循环（inner loop，工程师/agent 本地写改跑的小圈）和外循环（outer loop，推到 CI、评审、合入的大圈）。Uber 的思路是把内循环做得更「密」——把更多检查前移到内循环。以前最早只有静态分析这种检查，现在检测到就直接修；更进一步把视觉验证也挪进来：用一个 skill 拉起模拟器、截图、和 Figma 设计稿做比对；还能把服务拉起来连后端 staging 环境，把前后端集成放在一起验。 → 详细
进入外循环后 CI 仍可能出错，于是有自愈式 CI（self-healing CI）自动修掉大部分 CI 上的问题。代码评审也做了分层前移：外循环用强模型 + 推理 + 专门 skill 做深度评审；内循环用更小更快的中等模型先过一遍——两档模型各司其职，而不是所有地方都用最贵的。 → 详细
给人类评审者信心的机制：如果这是 Minion 自主生成的 diff，「我们希望给人类评审者一些信心——这个 diff 已经经过了大量的自我改进，不只是最初生成那一下」。所以 PR 上会附一张表，列出它经过的所有检查，包括截图。这是"agent 产出可验证"的一个具体落地形态：不是让人相信 agent，而是把 agent 自检的证据随 diff 一起交上去。 → 详细

维护比以前更重要：服务「注册」进维护 skill、受管的定时循环（周日跑、控制周一 diff 量）、合不合入都是标注数据

Adam 的转折句：「现在我们的软件工厂里流过的代码多了很多……维护反而更重要了。」机制是把功能或服务注册（enroll）进各种维护 skill，例子如 feature flag 清理——演示里世界杯弹窗有 A/B 两个变体，B 不需要了，就把清理排进一个定时循环。 → 详细
关键词是「受管的循环」（managed loop）：「我们不希望全公司冒出成千上万个毫无边界的循环」，所以有一个统一界面去建循环。两条调度纪律很实在——在周日跑，因为那时 CI 容量更充裕；并控制工程师周一早上看到的 diff 数量，不让人被一堆自动 diff 淹没。 → 详细
数据飞轮：skill 跑出来的 diff 会收到评论、要么合入要么不合入——「这些都是非常好的标注数据，可以反过来用来改进这个 skill 本身」。再加一个月度节奏：从事故复盘里看能学到哪些新 skill，变成新的维护 skill 推到所有服务。也就是说，每一次人类的 accept / reject 都在给 skill 打分。 → 详细 → 详细

新瓶颈：CI 容量、能跑的实验数，以及「不再是能不能做，而是该不该做」

Adam 收尾点了三个正在认真思考的瓶颈：① 基础设施压力变大，要预判 CI 容量并提前做基础投入；② 实际能跑的实验数量是有限的（代码产出翻倍，但业务上能同时做的 A/B 实验没有翻倍）；③ 决策。 → 详细
全场金句：「问题已经不再是『我们能不能做』——我们知道现在大概率能做出来——而更多是『我们该不该做』。」顺带预告下一场同样来自 Uber、讲 agent 化代码评审（AA 和 Will 主讲）。 → 详细

闪电问答 / 收尾

本期为大会演讲，无闪电问答环节；收尾内容已并入「十三」。

联系方式

本期未提供讲者联系方式。

接着读

NO.194 · Agent 工程搭 Agent 已经不难了,上下文才是下一个前沿——Jeff Ng(Unblocked) Jeff Ng · 11 分钟 NO.193 · Agent 工程复利工程:实现只会越来越便宜,判断力不会——Kieran Klaassen(Every/Cora) Kieran Klaassen · 14 分钟