Uber 公开 AI 软件工厂降本细节:省下的 52%,到底省在哪里?

TL;DR

引言

原文首图：AI 成本的六个组成因子。来源：Uber Engineering；原文封面署名 Himer Romana。

AI 工具如今已经融入 Uber 软件开发的各个阶段。超过 70% 的代码合并请求（Pull Request，简称 PR）归因于本地或云端 Agent。工程师围绕软件开发全生命周期构建了 3,600 多个 Agent 技能（Skills），每天的技能执行次数超过 30,000 次。

在 AI Engineer 2026 大会上，我们分享了软件工厂（Software Factory）的愿景，以及正在围绕整个软件生命周期建设的基础组件和托管 Agent。随着这一愿景逐步落地，越来越多会话不再由人发起，而由自动化的托管 Agent 发起。这些 Agent 负责代码评审、CI（持续集成）失败的自动修复、带视觉验证的端到端 PR 实现、值班告警分诊、新报 Bug 的调试，以及各类代码维护工作，并保留人工评审和升级处理机制。

如图 1 所示，2026 年 2 月至 8 月，面向全体员工——包括工程师和非工程师——的各类 Agent 产品，其周活跃用户数增长至原来的 7 倍，每周 Agent 请求量增长至 9.4 倍。与此同时，由于各方面的优化，我们的 AI 总支出从 4 月起已经相对稳定。

图 1｜2026 年 2 月至 8 月中旬的周活跃用户、Agent 请求量与成本；用户已跨工具去重。来源：Uber Engineering。

采用率、工作负载构成和模型版本都在持续变化。要单独识别我们自身优化带来的收益，就必须固定一个模型，因为每次模型升级、每个模型家族都会带来不同的行为。我们对 2 月至 7 月的数据做了这样的对照：每 1,000 次模型请求的成本较峰值下降近 34%，每次会话的成本较 6 月峰值下降 52%。

图 2｜固定模型后观察到的成本优化效果。单次会话成本的数据从 5 月底开始统计。来源：Uber Engineering。

本文将介绍我们如何理解这座软件工厂：Agent 会话运行的四个层级、拆解支出的成本方程、各项指标的衡量方式，以及如何在每个层级优化这些成本因子。

文中比较所涉及的价格和供应商指标均来自公开信息。成本效率的提升，来自在标准分层定价下，为 Uber 内部工作负载选择更合理的路由方式。我们测得的具体降本幅度取决于自身环境；其他团队的结果会因代码库、团队规模和 Agent 工作流而不同。不过，以真实工作构建基准测试，并同时优化准确性与成本的方法，具有普遍适用性。

软件工厂及其成本方程

Agent 使用的四个层级

我们把 AI 的使用方式分成四个层级，从最专用到最通用。如图 3 所示，层级越高，我们对成本、质量和模型选择的控制能力就越强。

图 3｜Agent 会话运行的四个层级，覆盖代码生成、验证、部署、观测与维护。层级越高，对成本、质量和模型选择的控制越强。来源：Uber Engineering。

成本方程

无论会话运行在上述哪一个层级，我们都可以把 Agent 会话的成本拆成若干因子，分别衡量、分别优化。

图 4｜总支出 = 用户数 × 每用户会话数 × 每会话轮次 × 每轮请求数 × 每请求 Token 数 × 每 Token 单价。来源：Uber Engineering。

前两个因子代表采用规模和使用深度。无论用户是以交互方式使用 AI，还是由 Agent 代表他们处理任务，我们都希望这两个因子在整体用户群体中持续增长。

中间三个因子则提供了优化空间：除了工程师真正提出的任务，Agent 为推进自身执行过程还会做额外工作。我们的主要精力就放在这里，包括让 Agent 更快地规划、减少不必要的轮次与错误、优化输入 Token 等。

我们如何衡量

下面是我们每周、每月持续跟踪的完整指标体系。借助这些指标，我们能够预测未来情况，并安排短期与长期的优化工作。

可以优化哪些环节

下面会逐项介绍我们用于优化成本方程的关键手段。其中一些手段会同时影响成本方程里的多个因子。

优化每 Token 单价

Token 的价格由供应商决定；由我们决定的是，哪个模型运行哪类工作负载。在所有托管 Agent 层级中，我们都会为每类工作负载选择帕累托效率最优的模型。对我们而言，帕累托效率需要同时考虑每完成一项任务的成本、输出质量和模型可靠性。

用真实任务的基准测试选择模型

原文将模型选择称为“四个步骤”；正文列出了以下三项，并在随后补充了持续测试模型路由策略的方向。我们运行的每个托管 Agent 都遵循同一套方法：

1. 从 Agent 的真实工作中构建基准测试。
2. 让 Agent 在一个通过统一接口接入不同模型的 Harness（执行框架）上运行，既支持前沿模型，也支持开放权重模型。
3. 转向当前帕累托最优的选择，并持续调整，因为这条最优边界每隔几周就会变化。

面向未来，我们会汇总托管 Agent 的运行经验，持续测试和部署不同的模型路由策略，进一步提升各类工作负载的表现。

例如，uReview 为所有 PR 提供 AI 代码评审。我们选取包含已知 Bug 的真实 PR 构建基准测试，并按简单、中等、困难分级。针对这些 Bug，我们评估精确率、召回率和 F1，同时记录每次评审的成本、延迟、超时情况和噪声。

如图 5 所示，切换模型后，F1 提升的同时，每个 PR 的评审成本显著降低。图中的虚线是帕累托前沿；原文所指虚线左下方的配置，都存在更便宜或表现更好的替代选择。

图 5｜uReview 测试过的各组模型配置：比较评审成本与 F1，虚线表示帕累托前沿。来源：Uber Engineering。

我们还从大型单体代码仓库中选取了数千个真实 PR，建立内部 Uber SWE Benchmark，让前沿模型与开放权重模型在不同类型的任务上接受评测。它为软件开发生命周期（SDLC）中的所有托管 Agent 提供模型选择依据。

默认模型的选择

在交互式界面中，Token 单价本身不变，但我们可以有策略地安排 Token 在不同模型之间的分配。主要影响这一分配的默认配置有两个：会话初始模型和子 Agent 模型。

实践证明，子 Agent 的默认模型是影响最大的优化手段，而且重要性还在上升。随着最新模型更善于编排多 Agent，启动子 Agent 的会话占比持续增加。子 Agent 通常执行边界清楚、输入明确的任务，往往不需要最前沿的推理能力。因此，我们默认让它们使用能力较弱、成本也更低的模型，同时保留人工覆盖默认配置的选项。

主模型负责任务拆解和结果评估，子 Agent 负责执行。

优化每次请求的 Token 数

每一轮都会重新发送完整的对话历史、项目上下文和工具结果。只要能够减小单次请求的数据量，收益就会在整个会话中不断累积。

默认配置

所有交互式 Harness 都通过一个统一封装层管理安装、配置、认证和成本展示。两项标准化默认配置，能够直接减少每次请求的 Token 消耗：

上下文达到 400K Token 时自动压缩。即使模型支持 1M 的上下文窗口，也按这一阈值触发。这个设置在模型表现、缓存写入带来的突发开销以及重复输入 Token 的成本之间取得平衡。我们的测量显示，它显著减少了整个运行体系中每次请求的输入 Token 数。

推理强度默认设为 Medium。在主要模型上，输出 Token——包括内部推理 Token——的单价是输入 Token 的数倍。这一配置调整直接减少了单价最高的那类 Token 支出。对大量任务而言，Medium 能够较好地平衡成本与质量。

提示词缓存策略

我们的提示词缓存策略，取决于供应商缓存读写的成本结构。每一轮都要重新传入全部对话历史，因此缓存此前的上下文，可以避免反复按完整价格付费，使后续读取成本降至标准输入 Token 价格的 0.1 倍。

但缓存写入的溢价并不相同：5 分钟缓存的写入价格为 1.25 倍，1 小时缓存则为 2 倍。因此，最合适的 TTL（Time-to-Live，缓存有效期）取决于相邻两轮之间的时间间隔。原文列出的可用选项包括 Anthropic 的 5 分钟和 1 小时，以及 OpenAI 的 30 分钟。

图 6｜在 5 轮交互中比较 5 分钟与 1 小时两种缓存有效期的成本，区分主线程与子 Agent 场景。来源：Uber Engineering。

工程师常常让交互式会话闲置超过 5 分钟，因此我们把默认缓存有效期从 5 分钟改为 1 小时。过去，这些频繁的空闲间隔会使前缀缓存失效，迫使系统以完整价格重新构建上下文。相比之下，子 Agent 只执行单一、短时任务，因此仍保留 5 分钟的缓存有效期。

通过 Shell 执行 MCP 工具

在 Uber，所有 MCP（Model Context Protocol，模型上下文协议）交互都经过统一网关。这个单一入口覆盖内部与第三方 SaaS 的 1,000 多个 MCP 服务器，实现集中认证和策略执行。

然而，标准 MCP 用法会直接把所有工具的 Schema（结构定义）加载到每个会话中，不论工程师是否会在该会话里调用这些工具。例如，安装超过 100 个工具后，预加载会给初始提示词增加约 50K—70K Token 的工具定义，而且这些内容会在后续每一轮上下文中重新发送。

图 7｜通过三种方式访问同一组工具时，Agent 在会话开始前就已携带的上下文负担。来源：Uber Engineering。

为解决上下文膨胀，我们引入了两种互补的优化机制。

通过 CLI 解析工具。用 Shell 命令取代直接集成 MCP。CLI（命令行接口）在实际调用时，动态解析所需工具，并通过网关执行，从而无需在会话上下文中放入 Uber MCP 的 Schema。内部 MCP 网关中的 1,000 多个工具，全部被映射成 CLI 命令。

工具搜索。让模型搜索工具目录，仅在需要时加载相关工具，从而支持上千个工具。这种方式能够缓解上下文膨胀，通常可以减少工具定义占用的 Token；即使工具库继续扩大，也能维持较高的选择准确率，避免工具集过大造成表现退化。

Code-mode：用代码批量编排工具调用

当工具功能可以直接通过 Shell 命令调用时，模型就能在一个脚本里批量执行多个动作。这对需要频繁往返交互的工具协议尤其有效。

在标准 MCP 工作流中，每个动作都需要模型单独完成一轮：发出请求、把原始响应加载进上下文窗口，再依次处理结果。例如，执行一条 SQL 查询，需要提交请求、轮询状态 2—5 次，再获取输出。

Code-mode 把整个流程整合为自动运行的 Python 循环，让中间轮询过程留在模型的活动上下文之外。图 8 左侧的模型参与了轮询循环，每次响应都会进入上下文；右侧的循环则在子进程中运行，只把汇总结果返回给模型。

图 8｜同一次数据仓库查询的两条执行路径：由模型逐步调用工具，或由 Code-mode 在子进程中执行并返回汇总。来源：Uber Engineering。

我们在同一个会话中，用两条路径分别执行了 5 条完全相同的 SQL 查询，测量结果如下：

表中为每条查询消耗的 Token 数，在同一个 Claude Code 会话中测得。

前三行最能说明主要发现：即使结果集很小，远低于响应大小限制，Code-mode 仍能让 Token 使用量减少 50% 以上。这些收益并非来自绕过大规模数据，而是来自消除不必要的开销，包括 Schema 初始化、多轮轮询和重复的逐步推理。

原本需要模型交互 N 轮的循环，可以交给一个脚本完成。在批量工作流中，这种效果还会累积，节省幅度可超过 90%。我们已经为最常访问的 MCP 服务器部署了 25 个以上预构建的 Code-mode 技能，让常规工作流默认走成本最低的执行路径。

SaaS MCP

与内部服务器相比，管理第三方软件明显更难。供应商无法预知每个客户的具体用法，因此其 MCP 服务器往往会暴露产品的全部能力。例如，一套办公协作软件在单个服务器中打包了 49 个工具，其 Schema 约占 22K Token；消息通信和项目管理供应商则分别提供了 34 个和 46 个工具。

仅加载两三个供应商的服务器，Agent 在用户尚未输入提示词前，就可能已经携带了比待编辑文件本身还多的 Schema 开销。

为此，我们让 SaaS MCP 服务器也经过 MCP 网关，采用与内部 MCP 相同的机制。同时，把这些 MCP 都暴露为 CLI，供任何 Agent 使用界面调用。此外，我们在 Code-mode 插件中为每个服务器编写专用技能，封装常见工作流。这样，多家 SaaS 供应商的工具就都能进入高效的 Agent 工作流。

图 9｜所有 SaaS MCP 服务器都接入统一 MCP 网关，形成一致、高效的访问方式。来源：Uber Engineering。

优化每轮请求数

缺少可靠上下文的 Agent，往往会慢慢失败，而且并不便宜：为了再搜一个位置，它会一次又一次发送不断膨胀的上下文。提前提供更充分的信息，仍然是减少搜索开销最有效的手段。

上下文工程

Uber 拥有庞大的代码库和数据生态，包含数亿行代码和数千张数据表。Agent 的大部分交互轮次花在查找信息上，而非生成代码。为此，我们构建了 AI Context Graph（AI 上下文图谱）：一个包含 2,400 万个节点和 8,000 万条边的统一网络，覆盖 86 种节点类型和 117 种边类型。

这个图谱整合了 30 多个内部系统的数据，包括服务、工程团队、事故日志、PR、架构设计文档、部署、数据集，以及历史数据表使用查询记录，任何 Agent 都可以用自然语言查询。

图 10｜将同一提示词交给同一模型，比较有无上下文图谱时的执行路径：有图谱时 38 秒得到正确答案；无图谱时耗时 20 分 09 秒，结果仍然错误。来源：Uber Engineering。

获得图谱支持的 Agent 查询历史使用记录，找到了 50 多名分析师使用的具体数据表，并在 38 秒内给出答案。相比之下，没有图谱的 Agent 无法看到这张表；它花了 20 分钟检查服务代码、启动 2 个子 Agent、遇到 3 次错误，最后却错误地得出“这个数据集无法查询”的结论。

成本可见性与使用指导

这一部分的优化手段，是让成本变得可见，并建立反馈循环，帮助工程师和 Agent 更快找到有效的工作方式。

状态栏

我们在 Harness 的状态栏中加入了实时成本计数器，跟踪每位用户在单个 Harness 中的实时支出，以及跨所有 Harness 的总支出。

图 11｜工程师随时可见的状态栏，配套提供会话分析器和效率指南。来源：Uber Engineering。

费用可见性与支出档位

为避免设置严格的费用上限，我们采用了实时支出跟踪和自动提醒：

• 状态栏实时计数。
  当前会话的成本始终显示在终端里。
• Harness 共享额度池。
  所有交互式 Harness 共用一个支出档位，不为每个工具单独设预算；托管 Agent 则使用独立档位。
• Slack 提醒。
  当支出达到预期费用的 50%、80% 和 100% 时发出提醒，让工程师有时间规划后续使用。
• 简化审批。
  提高档位需要经理批准，批准后可以快速生效。
• 成本检查技能与建议。
  通过看板技能按需拆解成本，并在实时状态栏中提供使用指导。

这些机制让工程师可以自主评估任务的投入产出比，同时降低费用失控的风险。

会话分析看板

状态栏能显示会话总支出，却不能解释成本由什么驱动，也无法直接提供可执行的改进措施。通用指南能说明原则，但不能评估每个开发者的具体工作流。会话分析看板通过直接检查会话产生的记录和产物，补上了这部分能力。

看板直接内置于运行时，无需额外配置或主动启用。执行成本看板技能后，它会分析用户在所有 Harness 中的会话轨迹，覆盖本地环境和远程云端沙箱。它提供的并非只有一个汇总数字，而是识别跨会话的 16 类低效模式，为每一类标明财务影响和针对性的修复建议。以下是其中几类：

• 模型路由不合理。
  Sonnet 就能轻松完成的简单多轮会话，却交给 Opus 执行。
• 上下文窗口膨胀。
  较大的 MCP 返回数据——例如 40KB 的响应——持续留在上下文里，在后续轮次中被重复计费。
• 缓存过期导致额外开销。
  长时间中断后恢复会话，提示词缓存已经失效，只能按完整价格重建前缀。
• 提示词初始化开销过高。
  用户尚未提供输入，就预加载了 100,000 Token 的系统指令和工具定义。

图 12｜会话级成本看板，用于识别浪费模式和潜在节省空间。来源：Uber Engineering。

接下来做什么

目前，我们正在推进以下工作：

扩大托管 Agent 的规模。每增加一个 Agent，我们都会遵循一致的路线：先确定目标成果指标，再构建评测基准，最后找到帕累托最优的模型。这种系统化方法，旨在让软件开发生命周期中的各个阶段，逐步提升到软件工厂成熟度模型的更高层级。

动态模型路由。我们正在把基准测试扩展到更多编程语言、代码仓库和 Agent 形态。不同模型的能力差异很大，因此有效路由高度依赖全面评估。

深化上下文图谱集成。让更多类型的自主 Agent 能够查询图谱。

让会话分析发展为实时开发指导。从定期批量识别低效模式，转向持续监测执行轨迹，直接向工程师提供个性化、实时的效率建议。

持续改进技能。我们正在探索自动记录技能执行过程中各种细小问题的方式，并根据收集到的轨迹自动生成技能更新。

结语

管理并控制不断上涨的 AI 编程费用，同样是一个可以通过工程手段解决的问题。我们通过消除浪费、减少不产生价值的 Token 消耗，而非仅仅依赖更低单价或降低工具配置，把使用规模扩大到原来的 7 倍，同时让各项单位成本指标下降，并提升或维持输出质量。

核心的战略转变，是从开发者交互式工作流走向全托管 Agent。将软件开发生命周期中的工作负载迁移到托管环境后，我们便能全面控制模型路由、执行 Harness 和运营支出。为一组专用托管 Agent 分别配备专门的评测基准和帕累托高效模型，再对它们进行整体优化，比逐一优化数千名工程师的终端会话，更具成本效率，也更容易扩展。

关于原作者与译文

Uday Kiran Medisetty 是 Uber 杰出工程师，负责工程生产力相关工作，包括 Agent 编程、AI 调试、代码评审和大规模重构。他还共同领导公司级工程师社区，参与塑造 Uber 的架构、工程文化与标准。

本文依据用户提供的英文全文翻译，保留正文、数据表、致谢和作者介绍，省去网站导航、推荐文章与页脚。TL;DR 为新增中文导读。原文图表保留英文，配中文图注；所有图片来源均为 Uber Engineering。

译注：原文模型选型一节写“四个步骤”，但仅列出三个项目，随后补充模型路由的后续方向；本文保留这一信息。上下文图谱一节的“86 nodes and 117 edge types”结合“2,400 万节点”的前文，按“86 种节点类型、117 种边类型”理解并翻译。缓存价格、TTL 选项和模型配置均为原文发布时的表述。文中数据来自 Uber 自述，不代表独立复测结果。

英文原文：Running a Software Factory Efficiently at Uber Scale｜Uber Engineering，2026 年 8 月 27 日。