Uber 软件工厂的 AI 成本控制实践

来源：X @UberEng

Uber 在软件工厂（Software Factory）实践分享中报告了一个反直觉的结果：2026 年 2 月到 8 月，全公司（工程师与非工程师）所有 agent 产品的周活跃用户增长 7 倍，每周 agent 请求量增长 9.4 倍，而总 AI 花费自 4 月起相对稳定 ^[0]。同一口径下，每千次模型请求的成本较峰值下降近 34%（2 月至 7 月、固定单一模型），每次会话成本较 6 月峰值下降 52% ^[0]。这套结果的关键不在压价，而在把一次 agent 会话拆成可逐项优化的成本公式，把力气花在消除“无价值的 token 消耗”上 ^[0]。下文沿着这条拆解逻辑，梳理这套成本控制机制如何运转。

数字背后的口径：超过 70% 的 PR“归功于 agent”指什么

支撑上述增长的是几项采用率数据：99% 的工程师使用 AI 工具 ^[2]，超过 70% 的 pull request 由本地或云端 agent 完成 ^[0,2]，工程师构建了 3600 多个 agent 技能，每天执行超过 3 万次技能调用 ^[0]。所谓“由 agent 完成”，按 Uber 的说法即 agent 完成了从分诊（triage）到写规格、实现、评审、验证的全部工作 ^[1]。相应地，越来越多会话不是由人发起的：自动化的托管 agent 开始处理代码评审、CI 失败自愈、带视觉验证的端到端 PR、on-call 告警分诊、新 bug 调试以及各类代码维护任务，人工只负责评审与升级处理 ^[0]。这些数字都来自 Uber 自己的统计，第三方报道只是在转述同一场分享 ^[2]。

成本公式：把一次会话拆成六个可独立优化的因子

Uber 将一次 agent 会话的成本拆成六个因子的乘积：用户数 × 人均会话数 × 每会话轮数 × 每轮请求数 × 每请求 token 数 × 每 token 单价 ^[0]。前两项反映采用率与参与度，是希望持续增长的部分；中间三项是 agent 在工程师请求之外为自己做的多余工作——包括帮助 agent 更快规划、减少多余轮次或错误、优化输入 token 的各类机制——这是优化的重点；最后一项由供应商定价，Uber 能做的是决定哪个模型跑哪个负载 ^[0]。把成本写成一个乘积的意义在于：单价只是六分之一，且对所有人一视同仁，真正拉开差距的是中间三项的执行效率 ^[0]。

分层与路由：给每个负载挑“帕累托最优”的模型

Uber 将 agent 用法分为四层，从最专用到最通用，层数越高，对成本、质量和模型选择的控制越细 ^[0]。每层内部的模型选择都追求“帕累托最优”：对 Uber 而言，这具体指成本/完成任务数、输出质量和模型可靠性三个维度上的权衡 ^[0]——模型选择本身可定义为在候选集中选择帕累托最优 ^[17]。选择过程对所有托管 agent 统一分四步：先用 agent 的真实工作构建基准；再把 agent 放到一个能接入任何模型（前沿或开源）的统一 harness 上；然后切换到帕累托最优模型并持续迁移，因为前沿每几周就会移动 ^[0]。

uReview 是这套流程的典型案例。它负责所有 PR 的 AI 代码评审，基准取自带已知 bug 的真实 PR，按易、中、难分级，用 precision、recall、F1 对 bug 打分，并计入每次评审成本、延迟、超时和噪声指标 ^[0]，第三方资料也确认它是 Uber 构建的 AI 代码评审平台 ^[9,10,11]。切换模型后，uReview 的 F1 提升、单 PR 成本大幅下降，图表中的虚线即帕累托前沿 ^[0]。此外，Uber 还在大型 monorepo 的数千个真实 PR 基础上建立了内部 Uber SWE Benchmark，在不同任务类型上测试前沿与开源模型，用于指导所有 SDLC 托管 agent 的选型 ^[0]。

在交互界面这一层，token 单价固定，能管理的是 token 在不同模型间的分布，其中“子代理默认模型”被证明是最有力的杠杆：子代理处理的是输入明确、通常不需要前沿推理的细分任务，系统默认给它们配更弱、更便宜的模型，同时允许手动覆盖；主模型负责任务分解与评估，子代理负责执行 ^[0]。

压缩每个请求：压缩阈值、推理档位与缓存 TTL

每一轮对话都会重发完整的会话历史、项目上下文和工具结果，任何减少单次请求载荷的措施都会在会话中复利放大 ^[0]。Uber 的三个默认设置直接作用于这个因子：自动压缩在 40 万 token 处触发（即使模型上下文窗口是 100 万），这一阈值在模型表现与缓存突发、重复输入成本之间取平衡 ^[0]；推理努力程度默认设为 Medium，因为输出 token（含内部推理 token）在主模型上的计费倍率高于输入 token ^[0]；提示词缓存则按“读便宜、写贵”的经济学设计——缓存读只按标准输入价的 0.1 倍计费，5 分钟条目写入加价 1.25 倍、1 小时条目加价 2 倍 ^[0]。

缓存 TTL 的选择因此取决于轮次之间的间隔：工程师经常让交互式会话闲置超过 5 分钟，导致前缀缓存失效、被迫全价重建上下文，于是 Uber 把交互会话的默认 TTL 从 5 分钟改为 1 小时；子代理则保留 5 分钟，因为它们的执行聚焦于单一、短命的任务 ^[0]。这个区分背后是一条更普遍的原则：上下文不是一个单一的概念，“项目用什么框架”和“这次任务要修改哪个文件”是生命周期完全不同的信息 ^[21]——按会话类型管理缓存，正是对不同生命周期的上下文分层处理 ^[0,21]。

MCP 瘦身：从预加载 Schema 到按需调用

Uber 所有 MCP（Model Context Protocol）交互都经过一个统一网关，覆盖内部与第三方 SaaS 的 1000 多个 MCP 服务器，集中做认证与策略执行 ^[0]。但标准 MCP 会把全部工具 schema 预载进每个会话，不取决于工程师是否会用到：装了 100 多个工具时，预载给初始 prompt 增加约 5 万到 7 万 token，且每轮都会重发 ^[0]。SaaS 端的膨胀更严重：一个工作区套件把 49 个工具打包进单个服务器，schema 约需 2.2 万 token，消息与项目管理供应商分别带 34 和 46 个工具，加载两三个供应商服务器，agent 携带的 schema 开销就超过了它正要编辑的文件 ^[0]。

Uber 引入两个互补机制：CLI 工具解析——把 MCP 集成替换为让模型执行 shell 命令，调用时由 CLI 动态解析并调用网关里的工具，内部网关全部 1000 多个 MCP 工具都投影为 CLI 命令，从而把工具 schema 从会话上下文中消除 ^[0]；工具搜索——让模型先搜索工具目录、按需加载，把工具定义的 token 占用降下来，并在工具库扩大时避免选型精度退化 ^[0]。在此基础上，Code-mode 让工具以 shell 命令直连时把多个动作批量进一个脚本：以 SQL 查询为例，标准流程需要提交请求、轮询状态 2 到 5 次、再取回输出，每一步都是一次模型轮次；Code-mode 把整个过程变成子进程里的自动化 Python 循环，只有摘要回到模型上下文 ^[0]。用 5 条相同 SQL 查询在同一个会话里走两条路径实测：即使结果集远小于响应上限，Code-mode 也能把 token 消耗降低超过 50%；批量工作流中，原本 N 次模型轮次变成一段脚本，节省超过 90% ^[0]。为此 Uber 为最常用的 MCP 服务器部署了 25 个以上的预置 Code-mode 技能，让标准工作流默认走最省 token 的路径 ^[0]。

AI 上下文图：把“找信息”变成“查索引”

在数亿行代码、数千张表的规模上，agent 的大部分轮次花在定位信息而不是生成代码上 ^[0]。Uber 为此构建了 AI 上下文图：一个包含 2400 万个节点、8000 万条边、整合 30 多个内部系统数据的统一网络，覆盖服务、工程团队、事故日志、pull request、架构设计文档、部署、数据集与历史表使用查询，任何 agent 都可以用自然语言查询它 ^[0]。对比实验很直观：接地（grounded）的 agent 查询历史使用记录，识别出被 50 多名分析师使用的具体数据表，38 秒内给出答案；未接地的 agent 看不到这张表，花 20 分钟检查服务代码、派生了 2 个子代理、撞上 3 个错误，最后错误地断定数据集不可查询 ^[0]。未接地 agent 的失败方式是“慢而贵”——反复把不断膨胀的上下文窗口发出去再多搜一个地方，因此在 Uber 的经验里，前置提供更丰富的信息是削减搜索开销最有力的单一杠杆 ^[0]。

可见性：让工程师和 agent 都为成本负责

成本控制不只有技术杠杆。Uber 在 harness 的状态栏放了实时花费计数器，按每个 harness 和用户全部 harness 统计实时支出 ^[0]。支出管理上，交互式 harness 共享一个统一的额度池（而非按工具预算），托管 agent 单独设额度；Slack 在预期花费的 50%、80%、100% 三个节点提醒，额度升级需要经理审批，并配套一个按需查询成本明细的 dashboard 技能 ^[0]。会话分析 dashboard 更进一步：它直接检查用户在所有本地与云端沙箱里的会话痕迹，标记 16 种反模式并逐条给出财务影响与整改建议——例如用 Opus 跑 Sonnet 就能胜任的简单多轮会话、40KB 的 MCP 响应滞留上下文并在后续轮次重复计费、长时间中断后缓存过期被迫全价重建前缀、以及用户输入前就预载 10 万 token 的系统指令与工具定义 ^[0]。

软件工厂：从交互式工作流转向托管代理

在 Uber 的表述里，核心战略转移是从交互式开发工作流转向完全托管的 agent：把 SDLC 负载迁入托管环境，才能对模型路由、执行 harness 和运营支出获得完全控制 ^[0]。每个新托管 agent 都遵循同一套路线图——先定结果指标，再组评估基准，然后选帕累托最优模型——并在此之上继续推进动态模型路由（扩大基准的语言、仓库与 agent 形态覆盖）、上下文图的更广接入、会话分析从批量检测走向实时指导，以及从技能执行的“papercut”记录中自动生成技能更新 ^[0]。

这套做法放在行业语境里并不孤立：agent 化软件开发把被动的跟踪界面变成自组织的工作队列，agent 不只是消费任务 ^[22]；AI 原生的软件工厂里“每个 agent 都有一份工作” ^[23]；AI 时代也正在让“驱动 AI 干活”成为普遍技能 ^[20]。Uber 的结论是：把上涨的 AI 编码支出当作一个可处理的工程问题，通过消除零价值的 token 消耗——而不是只依赖更低的单价或降级工具——可以在采用率大幅增长的同时降低单位成本、维持甚至改善输出质量 ^[0]。