起底Uber AI软件工厂：智能体用量暴涨9.4倍，账单却纹丝不动

本文永久链接 – https://tonybai.com/2026/09/03/uber-ai-software-factory-cost-optimization

大家好，我是Tony Bai。

【导读】

Uber 最新公开的工程实践显示：从 2026 年 2 月到 8 月，公司内部所有职能员工使用 AI 智能体的周活跃人数增长了 7 倍，周智能体请求量增长了 9.4 倍，超过 70% 的 Pull Request 已经由本地或云端智能体主导完成。但与用量暴涨形成鲜明对比的是——Uber 的 AI 总花费自 4 月以来基本持平，单次请求成本从峰值下降约 34%，单次会话成本从 6 月峰值下降 52%。这不是靠“少用”换来的省钱，而是一套可以拆解、可以度量、可以逐项优化的成本方程式。这篇文章带你完整拆解 Uber 如何把 AI 编程成本关进笼子里。

【文章要点】

• 核心方法论：把“总花费”拆成六个可独立测量、独立优化的变量：用户数 × 人均会话数 × 每会话轮次 × 每轮请求数 × 每请求Token数 × 单Token价格。
• 四层架构：Uber 把智能体的运行场景分为四个层级，层级越高，对成本、质量、模型选型的控制力越强，也是重点投入方向。
• 模型选型不是拍脑袋：用真实工作构建 benchmark，跑在“模型无关”的评测框架上，持续寻找 Pareto 最优解（例如代码评审智能体 uReview 换模型后，F1 提升的同时单次评审成本大幅下降）。
• Token 消耗的隐形杀手是 MCP：1000+ 个 MCP Server 全部预加载工具 schema，会在会话一开始就吃掉 5 万到 7 万 Token；Uber 用“CLI 化调用 + 按需 Tool Search”几乎清零了这部分开销。
• Code-Mode：把原本需要模型逐轮参与的轮询、翻页操作，打包成一段脚本在子进程里跑完，只把最终摘要交还给模型，单次查询省 50%～100% 的 Token。
• Prompt Cache 的 TTL 选择是门经济学：5 分钟 TTL vs 1 小时 TTL，取决于工程师实际的“停顿间隔”分布，选错了反而更贵。
• 上下文图谱（AI Context Graph）：2400 万节点、8000 万边，把原本 20 分钟、还答错的探索式任务，压缩到 38 秒且答对。
• 文化与可见性同样是杠杆：终端状态栏实时成本计数器、分级预算 + Slack 阈值提醒、自动识别 16 类“浪费模式”的会话分析仪表盘。

一场悄悄发生的“效率革命”

如果说过去一年 AI 编程工具的普及速度让人惊讶，那么 Uber 交出的这份成绩单，可能会让更多工程管理者感到意外。

据 Uber 杰出工程师 Uday Kiran Medisetty 在官方工程博客上的最新披露，Uber 目前已经有超过 3600 个针对软件开发生命周期（SDLC）不同环节构建的智能体技能（Agent Skills），每天执行超过 3 万次。超过 70% 的 Pull Request，如今由本地或云端智能体主导完成。

更值得关注的是，越来越多的会话已经不是由人类工程师发起，而是由自动化的“托管智能体”（Managed Agents）在后台自主处理代码评审、CI 失败自愈、端到端 PR 的可视化验证、on-call 告警分诊、故障调试等一系列代码维护任务，只在必要时才交由人工审核或升级处理。

数据显示，从 2026 年 2 月到 8 月，Uber 全体员工（工程师与非工程师）在所有智能体产品上的周活跃用户数增长了 7 倍，周智能体请求量增长了 9.4 倍。而与此同时，Uber 的 AI 总支出自 4 月以来基本保持稳定。

如果只看用量增长，大多数团队的第一反应是“账单一定爆了”。但 Uber 用数据证明：用量和成本，并不是必然的线性关系。

为了把“我们自己的优化到底起了多大作用”这件事说清楚，Uber 特意做了一个控制变量：在模型版本不变的前提下，单独观察 2 月到 7 月这段时间的成本变化——因为每一次模型升级都会带来行为上的变化，如果不固定模型，根本无法判断成本下降到底是模型换代带来的，还是工程优化带来的。

结果是：每千次模型请求的成本，从峰值下降了约 34%；每次会话的成本，从 6 月峰值下降了 52%。

这篇文章要讲的，就是 Uber 如何做到这一点。

“软件工厂”的四层架构

Uber 把公司内部的 AI 使用场景，划分成了四个层级——从最“专用”到最“通用”。层级越高，Uber 对成本、质量和模型选型的控制力就越强，这也正是团队重点投入的方向。

根据原文描述，这四层大致可以理解为：

Uber 的核心策略是：层级越高，越能拿捏成本和质量的平衡——因为托管智能体和自治智能体的任务边界是明确的、可评测的，团队可以为它们量身定制评测基准，选择性价比最高的模型，而不是让一个“万能模型”去应对所有交互式场景里五花八门的临时需求。

一套能把成本“拆开算”的方程式

Uber 团队做的第一件事，不是先去优化某个具体环节，而是先把“总花费”这个模糊的数字，拆解成六个可以独立测量、独立优化的变量：

这六个变量并不是同等地位。Uber 把它们分成了两组：

• 前两项（用户数、人均会话数）代表“采用度与参与度”——这是 Uber 希望持续做大的分子，无论是工程师主动交互使用，还是智能体代表工程师自主完成任务，都属于良性增长，不应该被压缩。
• 中间三项（每会话轮次、每轮请求数、每请求Token数）代表“智能体在完成一个人类请求的过程中，自己额外做的工作量”——这才是浪费最容易藏身的地方，也是 Uber 团队投入精力最多的战场。这里包括让智能体规划更快、减少不必要的轮次和报错、压缩输入 Token 等一系列机制。

围绕这套方程式，Uber 建立了一整套周度/月度监控指标体系，覆盖组合层（Portfolio）、单工具单位经济（Unit Economics）、模型经济性（Model Economics）、成本变化归因（Driver Decomposition）、托管智能体产出（Managed Agent Outcomes）五个维度，确保成本变化的每一分钱波动都“有账可查”，而不是留在一个说不清道不明的“误差项”里。

优化杠杆一：Price / Token——用基准测试逼近帕累托最优

Token 的单价是模型厂商定的，Uber 唯一能控制的变量，是该用哪个模型跑哪类工作负载。

Uber 给出的模型选型流程是标准化的四步走，套用在每一个托管智能体身上：

一个典型例子是 Uber 内部用于全量 PR 代码评审的智能体 uReview。团队用一批“已知包含真实 Bug”的历史 PR 构建了专属评测集，按简单、中等、困难分级，同时评估精确率（Precision）、召回率（Recall）、F1 分数，以及每次评审的成本、延迟、超时率和噪声水平。

结果显示：换模型之后，F1 分数不降反升，而每次 PR 的评审成本大幅下降——图中虚线是帕累托前沿，凡是落在这条线右下方的配置，都存在“要么更便宜、要么效果更好”的替代方案。除此之外，Uber 内部还维护了一个覆盖数千条真实 PR、跨多个超大单体仓库（monorepo）的 Uber SWE Benchmark，用来给所有 SDLC 相关的托管智能体做模型选型参考。

除了托管智能体的模型选型，Uber 在交互式场景里也设置了两个关键默认值：初始会话模型和子智能体（Subagent）模型。其中子智能体默认模型是影响力最大、且还在持续增长的杠杆——因为子智能体执行的通常是边界清晰、输入明确的子任务，往往不需要旗舰模型级别的推理能力，Uber 默认把子智能体路由到更便宜的模型上（同时保留人工覆盖的选项），由主模型负责任务拆解和结果评估，子智能体专注执行。

优化杠杆二：Tokens / Request——给每一次请求“减重”

每一轮对话都要把完整的对话历史、项目上下文、工具返回结果重新发送一遍。任何能压缩单次请求“体重”的手段，都会在整个会话过程中不断复利。

默认配置：400K上下文上限 + 中等推理强度

Uber 所有交互式 Harness 统一走一套封装层，负责安装管理、配置、鉴权和成本可见性，其中两个默认设置直接降低了单请求的 Token 消耗：

• 即使是支持 100 万 Token 上下文窗口的模型，也在 40 万 Token 处触发自动压缩（Compaction）。这个阈值是在模型表现、缓存命中率和重复输入成本之间找到的平衡点。
• 推理强度（Reasoning Effort）默认设为“中等”。输出 Token（包括内部推理 Token）的计费通常是输入 Token 的数倍，这个策略调整直接削减了成本最高的那一类 Token 支出。对大多数任务而言，中等推理强度已经能在成本和质量之间取得不错的平衡。

Prompt Cache 策略：TTL选择是一门经济学

由于每一轮对话都要重新发送完整历史，缓存“前缀上下文”能避免反复支付全价，让后续的缓存读取只需付标准输入 Token 价格的 0.1 倍。但缓存写入本身也有溢价：5 分钟 TTL 的写入成本是 1.25 倍，1 小时 TTL 是 2 倍。

选哪个 TTL，取决于工程师两轮对话之间实际的“停顿间隔”分布。Uber 发现，交互式会话中工程师经常会中途停顿超过 5 分钟——这种情况下，默认的 5 分钟 TTL 会频繁失效，导致上下文缓存反复以全价重建。于是团队把主会话的默认 TTL 从 5 分钟切换到了 1 小时；而子智能体由于执行的是单一、短生命周期的任务，依然保留 5 分钟 TTL。

MCP工具的执行方式：从“预加载”到“按需CLI调用”

这是本文技术含量最高、也最值得国内团队借鉴的一段。

Uber 内部所有 MCP（Model Context Protocol）交互都通过统一网关路由，覆盖超过 1000 个内部与第三方 SaaS MCP Server，集中管理鉴权和策略。

但标准的 MCP 协议有一个隐藏成本：无论工程师这次会话会不会用到某个工具，它的完整 Schema 都会被预加载进上下文。以 100+ 工具为例，这部分 Schema 开销大约是 5 万到 7 万 Token，而且会在每一轮对话中被重新发送一遍。

Uber 的解法是两个互补机制：

• CLI 化调用：不再让模型直接对接 MCP 协议，而是让模型执行一条 Shell 命令，由 CLI 在调用发生的那一刻动态解析并转发到网关，会话上下文里完全不出现 Uber 的 MCP Schema。目前网关上超过 1000 个 MCP 工具，全部被映射成了 CLI 命令。
• Tool Search：面对数以千计的工具，让模型先"搜索"工具目录，只加载当次真正需要的工具定义。这种方式既压低了工具定义占用的 Token，又能在工具库不断扩容的情况下，维持较高的工具选择准确率。

Code-Mode：把多轮对话压缩成一次脚本执行

当工具调用变成 Shell 命令后，模型就可以在一个脚本里批量执行多个操作——这对“话痨型”工具协议（比如需要反复轮询状态的接口）尤其有效。

在标准 MCP 流程下，每一个动作都需要单独一轮模型交互：发起请求、把原始返回结果塞进上下文、再处理结果。举例来说，执行一次 SQL 查询往往需要提交请求、轮询状态 2 到 5 次、再取回结果——每一次轮询都会把中间状态原样写进模型的上下文窗口。

Code-Mode 把整个流程压缩成一个自动化的 Python 循环，中间的轮询过程完全不进入模型的“视野”，只有最终摘要才会返回。

Uber 用 5 组相同的 SQL 查询，在同一个会话里分别跑了两种路径，结果如下：

前三行是最值得注意的发现：即便结果集小到远低于返回大小限制，Code-Mode 依然能节省超过 50% 的 Token——省下来的不是“避免了大数据量返回”，而是消除了 Schema 初始化、多轮轮询、逐步推理这些看不见的固定开销。批量任务的效果更夸张：原本需要 N 轮模型交互的循环，现在变成一段脚本，节省比例可以超过 90%。目前 Uber 已经为访问量最高的 MCP Server 部署了 25 个以上预置的 Code-Mode 技能，让常见工作流默认走这条最省钱的路径。

SaaS MCP：第三方工具带来的额外挑战

相比内部系统，管理第三方 SaaS 的 MCP Server 要棘手得多。厂商设计 MCP Server 时通常会把产品的全部能力都暴露出来（因为他们没法预判每个客户具体会用哪部分功能）。举例来说，某协同办公套件把 49 个工具打包进一个 Server，Schema 开销约 2.2 万 Token；某即时通讯和某项目管理工具分别提供了 34 个和 46 个工具。只要同时接入两三个这样的第三方 Server，智能体背负的 Schema 开销就可能超过它正在编辑的那个文件本身——而这一切发生在用户输入第一个字之前。

Uber 的应对方式是把 SaaS MCP Server 也纳入同一套网关机制，同样映射成 CLI 命令，并在 Code-Mode 插件里为每个第三方 Server 编写专属技能，封装常见工作流，从而在众多 SaaS 厂商上都跑出了高效的智能体工作流。

优化杠杆三：Requests / Turn——给智能体一张"地图"

一个缺乏上下文的智能体，不会“快速失败”，而是会“缓慢地、一遍遍地失败”——反复用越来越长的上下文去多搜索一个地方。提前给它更丰富的信息，是压低这类搜索开销最有效的手段。

Uber 的代码库和数据生态规模是数亿行代码、数千张数据表，智能体的大部分轮次实际上花在“找信息”而不是“写代码”上。为此，团队构建了 AI Context Graph——一张统一的知识图谱，包含 2400 万个节点、8000 万条边，覆盖 86 种节点类型、117 种边类型，整合了超过 30 个内部系统的数据：服务、工程团队、故障记录、PR、架构设计文档、部署记录、数据集，以及历史表使用查询记录，任何智能体都可以用自然语言对它发起查询。

有图谱支撑的智能体，直接查询到该表的历史使用记录，确认这是超过 50 名分析师常用的目标表，38 秒内给出正确答案；而没有图谱的智能体完全不知道这张表的存在，花了 20 分钟翻查服务代码、派生出 2 个子智能体、遭遇 3 次报错，最后还错误地得出"这个数据集无法查询"的结论。

优化杠杆四：可见性与文化——让工程师和智能体一起学会省钱

除了纯技术手段，Uber 还投入了大量精力，构建工程师能“实时看到自己在花多少钱”的反馈闭环。

状态栏里的实时成本计数器

Uber 在交互式 Harness 的状态栏里放了一个实时成本计数器，同时追踪当前会话的实时花费，以及该用户在所有 Harness 上的累计花费。

分级预算，而不是硬性上限

为了避免“一刀切”式的用量封顶带来的挫败感，Uber 采取的是实时追踪 + 自动提醒的方式：

• 状态栏实时计数器：会话花费全程可见。
• 共享的Harness资源池：所有交互式 Harness 共用一档预算，而不是给每个工具单独设限；托管智能体则单独有自己的分级预算。
• Slack 阈值提醒：花费达到预期的 50%、80%、100% 时自动提醒，给工程师留出规划空间。
• 快速审批流程：需要升档时，主管审批后能快速生效。
• 成本自查技能：一个可以随时调出成本明细的仪表盘技能，配合状态栏的实时提示。

这套机制让工程师能够自主判断“这个任务值不值得花这么多钱”，同时又不会因为担心撞上硬性配额而束手束脚。

会话分析仪表盘：自动识别16类“浪费模式”

状态栏能告诉你“这次会话花了多少钱”，却说不清楚“钱到底花在哪儿了”，更给不出具体的改进建议。会话分析仪表盘（Session Analysis Dashboard）正是为了补上这一环——它直接读取会话产生的原始 trace 数据，无需任何额外配置或主动开启。

工程师执行一个“cost dashboard”技能，系统就会分析该用户在所有 Harness、所有本地和云端沙箱环境下产生的会话记录，自动识别出 16 类不同的反模式，并为每一类都标注对应的经济损失和具体的优化建议。部分典型反模式包括：

• 模型路由不合理：一个简单的多轮会话本可以用更便宜的模型完成，却跑在了旗舰模型上。
• 上下文窗口臃肿：大体积的 MCP 返回结果（例如 40KB 的响应）长期滞留在上下文里，导致后续每一轮都要为它重复付费。
• 缓存过期损耗：会话中途停顿太久，导致 Prompt Cache 失效，被迫以全价重建前缀。
• 提示词初始化开销过大：在用户还没输入任何内容之前，系统就已经预加载了 10 万 Token 的系统指令和工具定义。

成绩单：7倍增长，成本反而下降

把这些杠杆叠加在一起，Uber 得到的结果是：用量增长 7 倍的同时，各项单位成本指标全面下降，输出质量不降反升甚至维持稳定。

Uber 在原文中给出的核心结论是：AI 编程开销的失控，本质上是一个可以被工程化解决的问题——关键不在于死磕更低的单价、或者干脆砍掉某些工具，而在于系统性地消灭那些"零价值"的 Token 消耗。

更深一层的战略判断是：把交互式的人类驱动流程，逐步迁移到全托管的智能体流程。因为托管环境意味着团队能完全掌控模型路由、执行 Harness 和运营开销；相比于在成千上万名工程师的终端会话里逐个优化，运营一支"专属评测基准 + 帕累托最优模型"武装到位的托管智能体舰队，天然更省钱，也更容易规模化。

Uber接下来还要做什么

原文也披露了几个正在推进中的方向：

• 持续扩充托管智能体舰队：每上线一个新智能体，都遵循同一套流程——先定目标产出指标，再搭建评测基准，再确定帕累托最优模型，逐层提升整条 SDLC 在“工厂成熟度模型”上的层级。
• 动态模型路由：扩大评测基准在编程语言、代码仓库、智能体形态上的覆盖面——模型能力差异很大，路由效果高度依赖评测的全面性。
• 上下文图谱的进一步渗透：把图谱查询能力开放给更多自治智能体。
• 会话分析从“事后批处理”走向“实时引导”：从周期性的批量反模式检测，升级为持续的 trace 监控，向工程师实时推送个性化的效率建议。
• 技能的持续自我优化：正在开发一套自动化机制，从智能体技能的执行轨迹中收集“小毛病”（papercuts），自动生成技能更新。

小结：对国内团队的几点启示

Uber 这篇文章最有价值的地方，或许不是某一个具体的技术点，而是它背后的方法论：把一个模糊的"AI 太贵了"问题，转化成一个可以拆解、可以量化、可以逐项优化的工程问题。

对于正在推进 AI 编程工具落地的国内团队，至少有几点可以直接借鉴：

1. 先建立度量体系，再谈优化。没有“每千次请求成本”、“每会话成本”、“每个托管智能体的单位产出成本”等这些细粒度指标，任何优化都只能是拍脑袋。
2. MCP 工具的接入方式本身就是一个巨大的成本变量。如果团队已经接入了大量 MCP Server，预加载 Schema 带来的隐性开销值得认真核算——CLI 化 + 按需检索，可能是性价比最高的一次改造。
3. Prompt Cache 的 TTL 不是“默认就好”，而要结合真实的团队使用节奏来调。
4. 知识图谱式的上下文工程，投入回报可能远超预期——尤其是在代码库和数据资产规模庞大、智能体经常“迷路”的场景里。
5. 成本可见性本身就是一种治理手段。与其用生硬的配额限制工程师，不如让他们清楚地看到自己在花多少钱、花在了哪里。

Uber 强调，具体的降本幅度会因团队的代码库规模、团队构成和工作流不同而存在差异，但“用真实工作构建基准、持续追求成本与效果的帕累托最优”这套方法论，具有普遍的参考价值。

参考资料：

1. Uber Engineering Blog. Running a Software Factory Efficiently at Uber Scale. 2026-08-27. https://www.uber.com/br/en/blog/efficient-software-factory/
2. Uber. AI Engineer 2026 大会分享：Uber 软件工厂愿景。 https://youtu.be/17-YSUHo6Lk

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。