Uber 软件工厂：规模化成本优化

以下来自 @udaykiran（经 @UberEng 转发）的 Uber 工程博客。当 AI 编码从"尝鲜"变成"主力"，先爆炸的不是质量，是账单——Uber 的真实规模是这样的：

• 70%+ 的 PR 归因于本地 / 云端 agent；
• 3600+ 个 agent skills 覆盖整个 SDLC（软件开发生命周期）；
• 每天 30K+ 次 skill 执行；
• 2026 年 2 月 → 8 月：周活用户 7 倍，agent 请求 9.4 倍；
• 模型固定不变的情况下：每千请求成本降 34%，每 session 成本降 52%。

Uber 把一次 agentic session 的成本拆成六个相乘的项，每一项都可以独立测量、独立优化：

• 前两项 = 采用与参与度（adoption & engagement）：希望它继续涨，不管用户是交互式使用还是让 agent 代劳；
• 中间三项 = agent 替你多做的工作：在工程师真实请求之上，agent 自己规划、试错、走的冤枉路——这是优化的主战场，Uber 大部分精力都花在这里（帮 agent 规划更快、减少无效轮次和错误、优化输入 token）；
• 六项以图示完整呈现（Figure 4）。

Uber 把 AI 的使用组织成四层，从最专用到最通用。关键规律：层越高，对成本、质量和模型选择的控制力越强（Figure 3）。

这直接导向 Uber 的战略转向：

Uber 不靠"感觉"选模型，靠 benchmark-driven 的四步：

1. 用真实工作建 benchmark；
2. 在 harness 上跑 frontier 模型和开源模型；
3. 选 Pareto 最优的；
4. 持续跟进新模型。

Uber 对 Pareto efficient 的定义：cost / completed task（每完成一个任务的成本）+ 输出质量 + 模型可靠性，三者权衡。

实战案例 uReview（AI code review）：用 precision / recall / F1 + cost per review 评估，把真实 PR 按 easy / medium / hard 分级，每种配置都测一遍再选（Figure 5）。

1. 自动 compaction：上下文到 40 万 token 自动压缩——即使模型支持 1M 上下文也一样压；
2. reasoning effort 默认 Medium：不需要每次都开最高档思考；
3. prompt cache 玩 TTL：读缓存 0.1x 价格，写缓存按存活时间 5 分钟 1.25x / 1 小时 2x。interactive session 切 1 小时 TTL（工程师经常一闲置就超 5 分钟，避免缓存过期重建），subagent 短平快，保持 5 分钟。

Figure 7：session 开始时 agent 背上已经背了什么▼

用三种不同方式接到同样的工具，session 一开始的上下文开销天差地别。

先看一个扎心的数字：100+ 个工具预载 schema，约 50K–70K token 的开销——活还没干，上下文先没了一大截。Uber 的两招：

• 解法一 · CLI tool resolution：模型执行 shell 命令，网关动态解析——1K+ 个 MCP 工具映射成 CLI，不用全量预载；
• 解法二 · tool search：按需加载，用到哪个拿哪个。

code-mode：把轮询踢出模型上下文

标准 MCP 流程里，查一次 SQL 要经历"发请求 → 轮询 2–5 次查状态 → 取结果"，每一步都进模型上下文。code-mode 把整个流程收进一个自动化 Python 循环，在子进程里跑，只把摘要还给模型（Figure 8 左 vs 右）。

• 5 条相同 SQL 实测：省 token 50%+——省的不是大数据 payload，而是 schema 初始化、多轮轮询、冗余的逐步推理这些 overhead；
• 批量工作流：循环从 N 个模型轮次变成 1 个脚本，省 90%+；
• 给最常用的 MCP 服务器预置了 25+ 个 code-mode skills，让标准工作流默认走最省的路。

AI Context Graph：2400 万节点、8000 万边、86 种节点类型、117 种边类型，整合了 30+ 个内部系统——Uber 给 agent 配的"内部世界地图"。

效果对比（Figure 10，同一个 prompt 同一个模型）：

• 有图 grounding：38 秒找到答案；
• 无 grounding：20 分钟 + 2 个 subagent + 犯 3 次错，最后还答错了。

harness 的状态行上有一个实时 cost counter（Figure 11）；花到 50% / 80% / 100% 时发 Slack 告警——让花钱这件事"看得见"。

更狠的是 session 分析 dashboard：零配置，直接分析所有 session trace，标出 16 种反模式，每种都配财务影响和修复建议，包括：

• 用 Opus 跑 Sonnet 就能搞定的简单多轮会话（模型路由不当）；
• 40KB 的 MCP 响应常驻上下文，每轮重复计费；
• 长休息后恢复会话，缓存过期被迫全价重建；
• 用户还没说话，先预载 10 万 token 的系统指令和工具定义。