引言
如今，AI 工具已嵌入 Uber 软件开发的每个阶段。超过 70% 的拉取请求归因于本地或云端智能体。工程师已在整个软件开发生命周期中构建了 3,600 多项智能体技能，每天执行逾 3 万次智能体技能。
在 AI Engineer 2026 大会上，我们分享了对软件工厂的愿景，以及正围绕整个生命周期构建的基础模块与托管智能体。随着这一愿景逐步落地，越来越多的会话不再由人工发起，而由自动化托管智能体处理：代码审查、CI 失败自愈、结合视觉验证完成端到端 PR、值班告警分诊、排查新报缺陷，以及各类需人工复核或升级处理的代码维护任务。
如图 1 所示，2026 年 2 月至 8 月，所有员工（工程师与非工程师）在全部智能体产品中的周活跃用户数增长了 7 倍，智能体周请求数增长了 9.4 倍。同时，得益于各方面的优化，我们的 AI 总支出自 4 月以来已相对趋稳。
图 1：2026 年 2 月至 8 月中旬的周活跃用户数、智能体请求数与成本；用户已跨工具去重。
采用率、工作负载组合和模型升级都在持续变化。要分离出我们自身的优化收益，就必须固定一个模型，因为每次升级和模型家族的变更都会改变行为。我们在 2 月至 7 月期间这样做了：每 1,000 次模型请求的成本已从峰值下降近 34%，单次会话成本则较 6 月峰值下降 52%。
图 2：固定模型时的成本优化效果。*每会话成本数据自 5 月末开始统计。
本文将介绍我们如何看待软件工厂：智能体会话运行所在的四层、用于拆解支出的成本方程、如何衡量其中每一项，以及如何在每一层优化这些项。
本文比较中的所有价格和供应商指标均基于公开信息。成本效率的提升来自于在标准分级定价内，更智能地路由 Uber 内部工作负载。我们测得的具体降本幅度只适用于本环境，且会因代码库、团队规模和智能体工作流而异；但以真实工作为基准，并针对准确性与成本优化的方法论具有普适性。
软件工厂及其成本方程
智能体使用的四个层级
我们将 AI 使用划分为四个层级，从最专用到最通用。如图 3 所示，层级越高，我们对成本、质量和模型选择的控制力越强。
图 3：智能体会话运行的四个层级。
成本方程
无论处于上述哪一层，我们都可以将一次智能体会话的成本拆解为以下各项，并分别衡量和优化。
图 4：总支出，由六个相乘项拆解而成。
前两项代表采用与参与度。无论用户以交互方式使用，还是由智能体代为处理任务，我们都希望它们在整体用户群中持续增长。中间三项提供了优化机会：即在工程师实际请求之外，智能体为完成任务自行做的工作。我们的主要精力正放在这里，包括帮助智能体更快规划、减少不必要的轮次或错误、优化输入 token 等机制。
如何衡量
以下是我们每周和每月跟踪的完整指标集合，用于支持短期和长期的预测与规划。
层级
指标
它回答的问题
产品组合
- 总归因成本
- 不重复归因用户数
- 各工具/智能体的成本、用户数和支出占比
资金流向何处，以及是哪个工具发生了变化
单位经济性：按工具
- 每用户成本
- 每用户请求数
- 每 1,000 次请求成本
- 每次请求的输入、输出和总 token 数
- 每 100 万 token 成本
- 每 1,000 次会话成本
- 每活跃会话小时成本
- 提示缓存命中率
工具是否确实变得更便宜，还是仅仅是使用量发生了迁移
模型经济性
针对每个模型
- 成本及成本占比
- 请求数及请求占比
- 每 1,000 次请求成本
- 每 100 万 token 成本
在每 token 价格相同或不同的情况下，哪些模型发布实际改变了账单
驱动因素拆解
按顺序将成本变化拆解为
- 采用（用户数）
- 参与度（每用户请求数）
- 输入工作负载（每请求输入 token 数）
- 输出工作负载（每请求输出 token 数）
精确说明数值变化的原因，不留下任何无法解释的残差
托管智能体成果
针对每个托管智能体：
- 以成果计价的成本（每合并 PR 成本、每次审查成本、每条告警成本、每次清理成本）；
- 质量信号（回滚率、F1、MTTR）；
- 产出量（已落地的差异、已发布的审查、已分诊的告警）
每个托管智能体是否在每单位交付价值上更便宜，以及模型迁移期间质量能否保持
优化杠杆
下文将详细介绍我们用于优化成本方程各部分的关键杠杆。其中一些杠杆会影响成本方程中的一项或多项。
每 token 价格
以基准测试驱动、帕累托最优的模型选择
模型默认值
每请求 token 数
默认采用 400K 上下文上限与 Medium 推理强度
提示缓存
工具搜索与经 CLI 解析的 MCP 调用
以代码模式批量执行工具调用
经网关路由的 SaaS MCP
每轮请求数
基于图谱的上下文
持续优化技能
可见性与教育
状态行中的实时成本计数器
可见性与支出层级
会话分析仪表盘
优化每 token 价格
供应商设定 token 单价，我们决定由哪个模型运行哪类工作负载。在所有托管智能体层级中，我们都会为特定工作负载选择帕累托效率最高的模型。对我们而言，帕累托效率意味着每完成任务成本、输出质量和模型可靠性之间的最佳组合。
基准测试驱动的模型选择
模型选择分四步进行，对我们运行的每个托管智能体都一样。
- 用智能体的真实工作构建基准测试。
- 在一个统一接口后接入所有模型（前沿模型或开放权重模型）的运行框架上运行智能体。
- 迁移到帕累托最优的选择，并持续迁移。前沿每隔数周就会变化。
展望未来，我们正持续利用托管智能体汇聚得到的洞察来优化工作负载表现，并测试和部署不同的模型路由策略。
例如，我们使用 uReview 为所有拉取请求进行 AI 代码审查。我们用存在已知缺陷的真实拉取请求构建了基准，并将缺陷划分为简单、中等和困难。除了每次审查成本、延迟、超时和噪声外，我们还针对这些缺陷评估精确率、召回率和 F1。如图 5 所示，切换模型在显著降低每 PR 成本的同时提高了 F1。图中的虚线是帕累托前沿；位于它下方和左侧的所有方案，都会被某个更便宜或更好的方案支配。
图 5：我们为 uReview 测试的每种配置。
借助我们大型单体仓库中的数千个真实 PR，我们内部还建立了 Uber SWE Benchmark，在不同任务类型上运行前沿模型和开放权重模型。我们用它为全部 SDLC 托管智能体的模型选择提供依据。
默认模型选择
在交互式界面中，token 的单位成本保持不变；但可以策略性地管理不同模型之间的 token 分布。有两项默认设置主要控制这一分布：会话初始模型与子智能体模型。
子智能体的默认设置被证明是最有影响力的杠杆，其重要性还在持续上升。随着最新模型能力使多智能体编排更为有效，发起子智能体的会话比例稳步增加。子智能体承担的是输入明确、定义良好的任务，往往不需要前沿级推理，因此我们默认使用能力较弱但更具成本效益的模型，同时仍允许手动覆盖。主模型负责任务拆解与评估，子智能体负责执行工作。
优化每请求 token 数
每一轮都会重新发送完整对话历史、项目上下文和工具结果。任何能减少每次请求负载的手段，都会在整个会话中产生累积效应。
默认值
所有交互式运行框架都使用统一包装器来管理安装、配置、认证和成本可见性。两项标准化默认配置可直接减少每次请求的 token 消耗：
- 即使对于拥有 1M 上下文窗口的模型，也会在 400K token 时自动压缩： 该阈值在模型性能、缓存突发和重复输入 token 成本之间取得平衡。我们的测量显示，它能显著降低全体请求中每次请求的输入 token 数。
- 默认使用 Medium 推理强度： 输出 token（包括内部推理 token）在主模型上的计费倍数高于输入 token；该策略调整直接降低了成本最高类别的 token 支出。对大量任务而言，Medium 推理在成本与质量间取得了良好平衡。
提示缓存策略
我们的提示缓存策略由供应商提示缓存读写的经济性驱动。由于每一轮都会重传完整对话历史，缓存此前上下文可避免重复支付完整成本，将后续读取降低至标准输入 token 费率的 0.1 倍。不过，写入溢价不同：5 分钟缓存条目为 1.25 倍，1 小时条目为 2 倍。因此，选择最佳 TTL（存活时间）取决于轮次之间的间隔时长。Anthropic® 提供 5 分钟和 1 小时选项，OpenAI® 提供 30 分钟选项。
图 6：两种 TTL 时长下 5 轮对话的对比。
由于工程师经常让交互式会话闲置超过 5 分钟，我们将默认的 5 分钟 TTL 改为 1 小时窗口。这些频繁的闲置间隔此前会使前缀缓存失效，迫使系统以全价重建上下文。相比之下，子智能体保留 5 分钟缓存 TTL，因为它们的执行通常聚焦于短生命周期的单一任务。
通过 Shell 执行 MCP 工具
在 Uber，所有 MCP（模型上下文协议）交互都会经由统一网关路由。该单一入口涵盖内部和第三方 SaaS MCP 在内的 1,000 多台 MCP 服务器，可实现集中的认证与策略执行。
但标准 MCP 会将所有工具 schema 直接加载进每个会话，无论工程师是否会在该会话中调用它们。例如，安装超过 100 个工具时，初始提示中会增加约 50K–70K token 的 schema 开销，随后又会在每一轮上下文中重新发送。
图 7：在同样需要访问工具的三种方式下，智能体会话开始时已携带的上下文。
为应对这一上下文膨胀，我们引入了两项互补的优化机制：
- CLI 工具解析： 允许模型执行 Shell 命令，取代直接集成 MCP。CLI 会在调用时动态针对网关解析并调用所需工具，从会话上下文中消除 Uber MCP schema。内部 MCP 网关的全部 1K+ MCP 工具均被映射为 CLI 命令。
- 工具搜索： 通过允许模型搜索工具目录、仅在需要时加载所需工具，扩展至数千种工具。这种方法缓解了上下文膨胀，通常能减少工具定义的 token 占用；即使可用工具库不断扩大，也能保持较高的选择准确率，避免大型工具集合带来的能力退化。
代码模式
当工具以 Shell 命令形式直接调用函数时，模型可以在一个脚本中批量执行多个动作。这种批量处理对交互频繁的工具协议尤其有利。在标准 MCP 工作流中，每个动作都需要单独一个模型轮次来发出请求、将原始响应加载到上下文窗口，再顺序处理结果。例如，执行一个 SQL 查询需要提交请求、轮询状态 2 至 5 次并获取输出。代码模式将整个流程精简为自动化 Python 循环，使中间轮询不进入模型活跃上下文。如图 8 所示，左侧模型参与轮询循环，且每次响应都进入其上下文；右侧循环在子进程中运行，只返回摘要。
图 8：同一个数据仓库查询的两种方式。
我们在同一个会话中，分别经两条路径运行 5 个相同的 SQL 查询来测量这一效果：
查询
LLM 工具调用
代码模式
节省
SELECT 1 (1 row)
903
402
55%
COUNT(*) (1 row)
954
403
58%
GROUP BY LIMIT 20 (20 rows)
1,600
457
71%
SHOW COLUMNS (175 rows)
2,200
900
59%
SELECT * wide table (50 rows)
1,431,594
900
~100%
每个查询的 token 数，在同一个 Claude Code 会话中测得。
前三行凸显了主要发现：即使结果集很小、远低于响应大小限制，代码模式也能将 token 用量降低 50% 以上。这些效率并非来自绕过大数据载荷，而是来自消除不必要的开销，包括 schema 初始化、多轮轮询和冗余的逐步推理。
批量工作流会进一步放大效果，因为原本需要 N 个模型轮次的循环会变成一个脚本，节省幅度累积超过 90%。我们已为访问量最高的 MCP 服务器部署了 25 多项预构建代码模式技能，确保标准工作流默认走成本效益最高的路径。
SaaS MCP
管理第三方软件被证明远比管理内部服务器困难。供应商设计 MCP 服务器时会暴露完整产品能力，因为他们无法预判客户的具体使用方式。例如，一套工作空间产品将 49 个工具打包进一台服务器，需要约 22K token 的 schema；消息和项目追踪供应商则分别提供 34 个和 46 个工具。用户甚至还未输入提示，加载两三台供应商服务器就可能让智能体携带的 schema 开销超过正在编辑的文件。
为解决这一问题，我们像处理内部 MCP 一样，通过 MCP 网关路由 SaaS MCP 服务器。我们还将所有这些 MCP 暴露为可由任何智能体界面调用的 CLI。此外，我们为每台服务器在代码模式插件中编写专用技能，以封装常见工作流。这使众多 SaaS 供应商场景下的智能体工作流变得高效。
图 9：每台 SaaS MCP 服务器都在 MCP 网关之后暴露，确保统一且高效的访问模式。
优化每轮请求数
缺乏事实依据的智能体不会廉价地失败，而是缓慢地失败：它会反复发送不断扩大的上下文窗口，只为再搜索一个位置。预先提供更丰富的信息，仍是降低这类搜索开销最有力的杠杆。
上下文工程
在 Uber 庞大的代码库和数据生态中，包含数亿行代码和数千张表，智能体大多数轮次都花在定位信息上，而不是生成代码。为此，我们构建了 AI 上下文图谱：它是一个统一网络，包含 2,400 万个节点、8,000 万条边、86 类节点和 117 类边。它整合了 30 多个内部系统的数据，包括服务、工程团队、事故日志、拉取请求、架构设计文档、部署、数据集和历史表使用查询，并允许任何智能体用自然语言查询。
图 10：将相同提示提交给同一模型时，使用图谱支撑与不使用图谱支撑的执行路径对比。
有图谱支撑的智能体查询了历史使用情况，找出了 50 多名分析师使用的特定表，并在 38 秒内给出答案。没有图谱支撑的智能体则无法发现该表；它花了 20 分钟检查服务代码、启动 2 个子智能体、遇到 3 次错误，最后还错误地判定该数据集不可查询。
可见性与教育
这里的杠杆是可见性和反馈循环，它们帮助工程师与智能体更快收敛。
状态行
我们在运行框架状态行中加入实时成本计数器，跟踪每个用户在单个运行框架及所有运行框架中的实时支出。
图 11：状态行，以及随附的会话分析器和效率指南。
可见性与支出层级
为避免设置严格上限，我们实现了实时支出跟踪和自动提醒：
- 状态行实时计数器。 终端中始终可见正在运行的会话成本。
- 运行框架池。 所有交互式运行框架共用一个层级，而不是按工具划分预算；托管智能体则使用单独层级。
- Slack 提醒。 在预期支出的 50/80/100% 时发出告警，让工程师有时间规划。
- 便捷审批流程。 管理者批准层级升级后可快速生效。
- 成本检查技能和建议。 仪表盘技能可按需拆解成本，并在实时状态行中提供指导。
这些措施让工程师能独立评估任务 ROI，同时缓解失控支出。
会话分析仪表盘
虽然状态行突出了会话的总支出，但看不到成本驱动因素或可执行的效率改进步骤。通用指导只能提供高层原则，无法评估个体开发者工作流。会话分析仪表盘通过直接检查会话产物弥补了这一缺口。
它直接构建在运行时中，无需设置或选择加入。执行 成本仪表盘 技能后，系统会分析用户在其使用的所有运行框架、所有本地和远程云沙箱中的全部会话轨迹。它不会只给出汇总指标，而是识别会话中的 16 种不同反模式，并为每种反模式配上财务影响和针对性的修复建议。其中包括：
- 次优模型路由： 用 Opus 执行本可由 Sonnet 轻松完成的简单多轮会话。
- 上下文窗口膨胀： 大型 MCP 载荷（例如 40KB 响应）留在上下文中，并在后续轮次中反复产生计费。
- 缓存过期低效： 长时间停顿后恢复会话，过期的提示缓存迫使系统以全价重建前缀。
- 提示初始化开销： 在用户提供任何输入前，预加载 100,000 token 的系统指令和工具定义。
图 12：会话级成本仪表盘识别出浪费模式和潜在节省。
下一步？
当前正在推进的工作包括：
- 扩大托管智能体队伍： 对每个新智能体，我们都遵循一致路线图：建立目标成果指标、组装评估基准、识别帕累托最优模型。这一系统化方法旨在让 SDLC 的每个阶段在工厂成熟度模型中进一步上移。
- 动态模型路由： 我们正在扩大基准覆盖范围，纳入更多编程语言、代码仓库和智能体形态。鉴于模型能力差异很大，有效的模型路由高度依赖全面评估。
- 深化上下文图谱集成： 我们正为更广泛的自主智能体开放图谱查询能力。
- 将会话分析演化为面向开发者的实时指导： 我们希望从周期性批处理发现反模式，转向持续监测轨迹，并直接向工程师提供个性化、实时的效率建议。
- 持续改进技能： 我们正在研究自动记录智能体技能执行中的痛点，并依据采集的轨迹自动生成技能更新的方法。
结语
管理并抑制不断上涨的 AI 编程支出，同样是一个可工程化解决的问题。我们没有只依赖更低的单位价格或降级工具，而是消除没有价值的 token 浪费，从而在将使用量扩大 7 倍的同时，降低各项指标的单位成本，并提升或保持输出质量。
核心战略转变，是从交互式开发者工作流迈向完全托管的智能体。将 SDLC 工作负载转入托管环境，可完全控制模型路由、执行运行框架和运营支出。相比优化数千名工程师的单个终端会话，优化由专用评估基准和帕累托高效模型配对的专业托管智能体集群，天然更具成本效益和可扩展性。
致谢
这是许多工程师的共同努力：他们构建最高效的模块，在 Uber 规模下实现软件工厂，同时确保我们为每一个花费的 token 获得 ROI。感谢参与软件工厂各项工作的核心团队成员：Abhishek Bhatia、Adam Huda、Aditya Patel、Alok Srivastava、Ameya Ketkar、Anil Purohit、Atakan Kandemir、Ben Chou、Brandon Barker、Danielle Yim、Deepanshu Mehndiratta、Gaurav Gill、Israel Marban、Jason Varbedian、Karen Xu、Lei Shi、Mager Mager、Meghana Somasundara、Peng Liu、Preet Inder、Qiushen Wang、Rush Tehrani、Shesh Patel、Shiven Tripathi、Shubham Gupta、Stas Khalup、Ting Chen、Tse-Shi Wang、Ty Smith、Vikram Hullukunte、Viv Keswani、Weiqiang Wang、Will Bond。
还要感谢 Johannes Gehrke、Mattie Toia、Sumanth Sukumar 和 Praveen Neppalli Naga 的领导。
封面照片署名：Himer Romana
Anthropic® 是 Anthropic PBC 的注册商标。
Claude Code™ 和 Claude® 是 Anthropic, PBC 的商标。
OpenAI® 及其标志是 OpenAI® 的注册商标。