智能体请求暴增9.4倍，token账单却没涨：Uber 公开AI软件工厂省钱方法

AI 工具现已嵌入到 Uber 软件开发的每个阶段。超过 70% 的代码合并请求由本地或云端智能体生成。工程师们已经在软件开发生命周期中构建了超过 3600 个智能体技能，每天执行超过 30000 次智能体技能调用。 在 2026 年 AI 工程师大会上，我们分享了 我们对软件工厂的愿景 "以及我们在软件开发生命周期各阶段构建的模块和托管智能体。随着这一愿景的推进，越来越多的工作会话不再由人工发起，而是由自动化托管智能体完成，包括代码评审、CI 故障自动修复、完成端到端 PR（含视觉验证）、分级处理值班告警、调试新提交的错误，以及各类代码维护任务（需人工审核/升级）。 如图 1 所示，从 2026 年 2 月到 8 月，所有员工（工程师及非工程师）在所有智能体产品中的周活跃用户增长了 7 倍，周智能体请求量增长了 9.4 倍。与此同时，由于全面优化，我们的 AI 总支出自 4 月份以来已相对稳定。 图 1：2026 年 2 月至 8 月中旬的周活跃用户、智能体请求量及成本，用户数据已跨工具去重。 由于工具采用率、工作负载构成和模型版本升级都在发生持续变化，想要单独衡量我们自身优化带来的收益，就需要固定使用同一个模型，因为每次升级和模型系列变更都会带来行为变化。我们从 2 月到 7 月做了对照测试：每 1000 次模型请求的成本较峰值下降了近 34%，每次会话的成本较 6 月峰值下降了 52%。 图 2：模型固定情况下的成本优化效果。单会话成本数据从 5 月底开始。 本文将介绍我们对软件工厂的思考：智能体会话运行的四个层级、用于拆解开销的成本计算公式、各项指标的测算方式，以及我们如何在每一层完成指标优化。 对比的所有定价与供应商指标均基于公开信息，成本效率提升源于我们在标准定价层级内对 Uber 内部业务负载进行更智能的路由调度。虽然我们测算得到的成本降幅取决于我们的环境，实际效果会因代码库、团队规模、智能体工作流的不同而存在差异，但基于真实业务进行的基准测试、围绕准确率与成本进行优化的这套方法论扔具备普适性。 软件工厂及其成本公式 智能体运行的四个层级 我们将 AI 使用划分为四个层级，从高度专用到通用能力依次排布。如图 3 所示，层级越高，我们对成本、质量以及模型选择的掌控力就越强。 图 3：智能体会话运行的四个层级。 成本公式 在上述任一层级中，我们可以将智能体会话的成本分解为以下各项，这些项可以进行独立度量和优化。 图 4：总支出分解为六个相乘的项。 前两项代表采用率和参与度，我们希望在全体用户群体中持续提升这两项指标，无论用户是交互式使用 AI 还是由智能体代劳处理任务。中间三项提供了优化机会：即智能体在工程师实际请求之外自主完成的额外工作。这也是我们投入最多精力的地方，其中包括帮智能体更快规划、减少不必要的轮次或错误、优化输入token等机制。 我们是如何度量的 以下是我们按周、按月跟踪的完整指标集，依靠这些指标，我们能够对短期与长期工作进行预测和规划。 优化手段 在接下来的章节中，我们将详细介绍用于优化成本公式各个组成部分的关键手段。其中一些手段会影响成本公式中的一个或多个项。 优化token价格 供应商设定token价格，我们为各类工作负载匹配模型。在所有托管智能体层级中，我们会为每种工作负载选择帕累托最优的模型。对我们来说，帕累托最优意味着三个东西：每次完成任务的成本、输出质量和模型可靠性。 基于基准测试的模型选择 模型选型分为四个步骤，我们所有托管智能体都采用这套流程。 基于智能体的真实业务任务构建基准测试。在支持任意模型（无论是前沿模型还是开源权重模型）的 Harness 上运行智能体，这些模型均通过统一接口提供服务。迁移到帕累托最优的配置，并持续迭代更新。 我们将借助托管智能体生成的聚合洞察持续优化工作负载性能，测试并落地各类模型路由策略。 例如，我们使用 uReview 处理所有 PR 的 AI 代码评审。我们基于包含已知错误（分为简单、中等、困难三级）的真实 PR 构建基准测试。我们针对这些错误计算精确率、召回率和 F1 分数，同时统计每次评审的成本、延迟、超时和噪音。如图 5 所示，切换模型提高了我们的 F1 分数，同时大幅降低了每个 PR 的成本。图中虚线为帕累托前沿曲线。虚线左下方的配置都存在成本更低或者效果更好的替代方案。 图 5：我们为 uReview 测试过的配置。 基于大型单体代码库中数千个真实 PR，我们内部构建了一个 Uber SWE 基准测试，针对不同任务类型运行前沿模型与开源权重模型。我们用它来为所有 SDLC 托管智能体的模型选择提供依据。 默认模型选择 在交互式界面中，token单位成本保持不变，但我们可以根据策略在不同模型之间分配token。主要由两项默认配置控制token分配：初始会话模型和子智能体模型。 子智能体默认设置被证明是最具影响力的手段，且重要性还在持续提升。随着新一代模型能力实现更有效的多智能体编排，发起子智能体的会话比例稳步上升。由于子智能体执行的是输入明确、任务边界清晰的任务，通常不需要前沿级别的模型推理能力，我们将它们默认设置为能力稍弱但性价比更高的模型，同时也支持人工覆盖修改配置。主模型负责任务分解和评估，而子智能体执行具体的任务。 优化每次请求的token数 每一轮对话都会重新发送完整的对话历史、项目上下文和工具结果。任何能够减少每次请求负载的措施都会在整轮会话中产生复利效应。 默认设置 所有交互式 Harness 都使用统一的封装层，负责安装管理、配置、鉴权以及成本可视化。有两套标准化默认配置可以直接降低单次请求的token消耗量： 自动压缩在达到 40 万token时触发，即使是支持 100 万上下文窗口的模型也是如此：这个阈值在模型性能与缓存突增和重复输入token成本之间取得了平衡。我们的测量显示，这显著降低了整个集群范围的每次请求输入token数。推理强度默认设置为中等：输出token（包括内部推理token）在主模型上的计费倍率高于输入token；这一策略调整直接减少了高成本token的支出。对于绝大多数任务，中等推理强度能够在成本与输出质量之间实现良好平衡。 提示词缓存策略 我们的提示词缓存策略是基于模型服务商提示词缓存的读写成本来制定的。由于每一轮交互都会重新传输完整对话历史，对前文上下文做缓存可以避免重复支付全额成本，将后续读取成本降至标准输入token费率的 0.1 倍。但缓存写入会产生额外溢价，不同有效期的溢价不一样：5 分钟有效期的缓存条目写入溢价为 1.25 倍，1 小时有效期则为 2 倍。因此 TTL 的选择取决于对话轮次之间的间隔时长。Anthropic 提供 5 分钟、1 小时两种 TTL 选项，OpenAI 则提供 30 分钟的选项。 图 6：两种 TTL 时长下 5 轮对话的比较。 由于工程师经常让交互式会话空闲超过 5 分钟，我们从默认的 5 分钟 TTL 过渡到了 1 小时。这些频繁的空闲间隙会导致前缀缓存失效，不得不重新构建完整上下文。与之相反，子智能体仍然保留 5 分钟的缓存 TTL，因为子智能体只负责执行单一、短生命周期的任务。 通过 Shell 执行 MCP 工具