文章作者：@udaykiran
引言
AI 工具如今已融入 Uber 软件开发的每个阶段。超过 70% 的拉取请求（PR）由本地或云端智能体参与产出。工程师围绕软件开发生命周期构建了超过 3,600 项智能体技能，每天执行这些技能超过 3 万次。
在 AI Engineer 2026 大会上，我们分享了软件工厂的愿景，以及正在围绕整个开发生命周期构建的基础组件和托管智能体。随着这一愿景逐步落地，越来越多的会话不再由人发起，而是由自动运行的托管智能体发起：它们负责代码审查、自动修复 CI 失败、端到端完成 PR 并进行视觉验证、分诊值班告警、排查新报告的缺陷，以及执行各种代码维护任务，并在需要时交由人工审查或升级处理。
如图 1 所示，从 2026 年 2 月到 8 月，面向全体员工（包括工程师和非工程师）的所有智能体产品，周活跃用户数增至原来的 7 倍，每周智能体请求量增至原来的 9.4 倍。与此同时，由于各方面的优化，我们的 AI 总支出自 4 月起趋于稳定。
使用普及程度、工作负载构成和模型版本都在不断变化，而每次升级或切换模型系列都会改变模型行为。因此，要单独衡量我们自身优化带来的收益，就需要固定一个模型进行观察。我们在 2 月至 7 月间这样做了：每 1,000 次模型请求的成本较峰值下降近 34%，每次会话的成本较 6 月峰值下降 52%。
本文将介绍我们如何看待软件工厂：智能体会话运行的四个层级、用于拆解支出的成本公式、各项指标的衡量方式，以及如何在各个层级优化这些指标。
本文比较所用的价格和供应商指标均来自公开信息。成本效率的提升，来自在标准分层定价下，更智能地为 Uber 内部工作负载选择执行模型。我们测得的具体降本幅度与自身环境有关；你的结果可能因代码库、团队规模和智能体工作流而异。但以真实工作构建基准测试、同时优化准确性与成本的方法具有普遍适用性。
软件工厂及其成本公式
智能体使用的四个层级
我们将 AI 使用方式分为四个层级，从最专用到最通用。如图 3 所示，层级越高，我们对成本、质量和模型选择的掌控就越强。
成本公式
对于上述任意层级，我们都可以将智能体会话的成本拆解为以下各项，分别衡量和优化。
前两项代表使用普及程度和参与度。无论用户直接交互，还是由智能体代为处理任务，我们都希望这两项在整个用户群体中持续增长。中间三项则提供了优化空间：它们对应智能体为完成工程师实际请求而额外进行的工作。这也是我们投入最多精力的地方，包括帮助智能体更快规划、减少不必要的轮次或错误、优化输入 token 等机制。
我们如何衡量
下图列出了我们每周、每月跟踪的完整指标，用于预测并规划短期和长期的工作。
优化手段
接下来，我们将详细介绍优化成本公式各部分的主要手段。其中一些手段会影响公式中的一个或多个条目。
优化每个 token 的价格
供应商决定 token 的价格，我们决定用哪个模型运行哪类工作负载。在所有托管智能体层级，我们都选择对相应工作负载最具帕累托效率的模型。这里的帕累托效率综合考虑每完成一项任务的成本、输出质量和模型可靠性。
基准测试驱动的模型选择
模型选择分为四个步骤，所有托管智能体都遵循同一流程。（译注：原文称“四个步骤”，下文实际列出三项。）
- 根据智能体的真实工作构建基准测试。
- 在通过统一接口支持任意模型的运行框架（harness）中运行智能体，无论是前沿模型还是开放权重模型。
- 切换到帕累托最优的模型，并持续调整。最优前沿每隔几周就会变化。
展望后续，我们会汇总托管智能体的运行洞察，用于测试和部署不同的模型路由策略，持续改善工作负载的表现。
例如，uReview 负责对所有 PR 进行 AI 代码审查。我们用包含已知缺陷的真实 PR 构建基准测试，并将其分为简单、中等、困难三个等级。针对这些缺陷，我们评估精确率、召回率和 F1 分数，同时衡量每次审查的成本、延迟、超时和噪声。如图 5 所示，切换模型既提高了 F1 分数，也大幅降低了每个 PR 的审查成本。图中的虚线是帕累托前沿，位于其左下方的每个方案，都存在更便宜或效果更好的替代方案。
我们还利用大型 monorepo 中数千个真实 PR，构建了内部的 Uber SWE Benchmark，在不同任务类型上测试前沿模型和开放权重模型，为整个软件开发生命周期（SDLC）中的托管智能体选择模型提供依据。
默认模型选择
在交互式界面中，token 单价虽然固定，但可以有策略地调整 token 在不同模型之间的分配。主要影响这一分配的是两个默认设置：会话初始模型和子智能体模型。
实践证明，子智能体的默认模型设置是影响最大的手段，而且越来越重要。新模型的能力让多智能体编排更有效，启动子智能体的会话占比也在持续上升。子智能体执行的通常是输入明确、边界清晰的任务，往往不需要前沿模型级别的推理能力。因此，我们默认让它们使用能力稍弱、成本效益更高的模型，同时允许手动覆盖。主模型负责任务拆解和评估，子智能体负责具体执行。
优化每次请求的 token 数
每一轮都会重新发送完整的对话历史、项目上下文和工具结果。只要减少单次请求的数据量，收益就会在整个会话中不断累积。
默认设置
所有交互式运行框架都使用统一封装层，管理安装、配置、身份认证和成本展示。两项标准化默认配置直接降低了每次请求的 token 消耗：
- 即便模型支持 100 万 token 的上下文窗口，也在达到 40 万 token 时触发自动压缩。这个阈值兼顾模型表现、缓存开销突增和重复输入 token 的成本。我们的测量显示，整个运行环境中每次请求的输入 token 数明显下降。
- 推理强度默认设为 Medium。主力模型的输出 token（包括内部推理 token）单价是输入 token 的数倍；调整这一策略，直接减少了最昂贵 token 类别的支出。对相当多的任务而言，Medium 推理强度能较好地平衡成本与质量。
提示词缓存策略
我们的提示词缓存策略取决于供应商对缓存读写的计费方式。由于每一轮都要重新传输完整对话历史，缓存此前的上下文可以避免反复支付全价，将后续读取成本降至标准输入 token 单价的 0.1 倍。但写入溢价有所不同：有效期为 5 分钟的缓存条目按 1.25 倍计费，有效期为 1 小时的条目则按 2 倍计费。因此，最优 TTL（生存时间）取决于轮次之间的间隔。可选 TTL 包括 Anthropic® 提供的 5 分钟和 1 小时，以及 OpenAI® 提供的 30 分钟。
工程师经常让交互式会话闲置超过 5 分钟，因此我们将默认 TTL 从 5 分钟改为 1 小时。过去，这类频繁的空闲间隔会让前缀缓存失效，迫使系统以高昂的全价重新处理上下文。相比之下，子智能体只专注于单个短时任务，因此保留 5 分钟的缓存 TTL。
通过 Shell 执行 MCP 工具
在 Uber，所有 MCP（Model Context Protocol，模型上下文协议）交互都经过统一网关。这个单一入口覆盖超过 1,000 个内部及第三方 SaaS MCP 服务器，实现集中身份认证和策略执行。
但标准 MCP 接入方式会将所有工具的 schema（结构定义）直接加载到每个会话中，无论工程师是否会在该会话里调用它们。例如，安装超过 100 个工具后，预加载会给初始提示词增加约 5 万至 7 万 token 的 schema 开销，之后每一轮都要重新发送。
为解决这种上下文膨胀，我们引入了两种互补的优化机制：
- CLI 工具解析：让模型执行 shell 命令，替代直接集成 MCP。CLI 在调用时动态解析所需工具，并通过网关调用，使 Uber MCP 的 schema 不再占用会话上下文。内部 MCP 网关中的 1,000 多个 MCP 工具均映射为 CLI 命令。
- 工具搜索：允许模型搜索工具目录，按需加载必要工具，从而支持数千个工具。这种方式能缓解上下文膨胀，通常会减少工具定义的 token 用量；即使工具库扩大，也能保持较高的工具选择准确率，避免大型工具集引起的性能退化。
Code-mode
当工具以 shell 命令的形式直接调用函数时，模型可以在一个脚本中批量执行多个操作。这对需要频繁往返交互的工具协议尤其有用。在标准 MCP 工作流中，每个操作都需要单独一个模型轮次来发出请求、将原始响应载入上下文窗口，并依次处理结果。例如，执行一条 SQL 查询需要提交请求、轮询状态 2 至 5 次，再获取输出。Code-mode 将整个流程收敛为一个自动执行的 Python 循环，让中间轮询过程不进入模型的当前上下文。如图 8 左侧所示，模型参与轮询循环，每次响应都会进入上下文；右侧则由子进程执行循环，只返回摘要。
我们在同一会话中，分别通过这两条路径运行相同的 5 条 SQL 查询来测量效果：
前三行凸显了主要发现：即便结果集很小，远低于响应大小限制，code-mode 仍能将 token 用量降低 50% 以上。这些收益并非来自绕过大体积数据，而是来自消除不必要的开销，包括 schema 初始化、多轮轮询以及重复的逐步推理。
批量工作流会进一步放大效果：原本需要 N 个模型轮次的循环，变成一个脚本，累积节省可超过 90%。我们为最常使用的 MCP 服务器部署了超过 25 项预构建的 code-mode 技能，让标准工作流默认走成本效益最高的路径。
SaaS MCP
管理第三方软件比管理内部服务器困难得多。供应商无法预判客户的具体用法，因此会通过 MCP 服务器暴露完整的产品能力。例如，某办公套件在一个服务器中打包了 49 个工具，schema 需要约 2.2 万 token；即时通信和项目跟踪供应商则分别提供 34 个和 46 个工具。加载两三个供应商的服务器后，用户还没输入提示词，智能体携带的 schema 开销就已超过正在编辑的文件。
为此，我们采用与内部 MCP 相同的机制，将 SaaS MCP 服务器接入 MCP 网关，同时把所有这些 MCP 能力暴露为 CLI，供任意智能体使用入口调用。此外，我们在 code-mode 插件中为各个服务器编写专用技能，封装常用工作流。这让跨多个 SaaS 供应商的智能体工作流也能高效运行。
优化每轮请求数
缺乏可靠上下文的智能体，并不会低成本地失败，而是缓慢地失败：它反复发送不断膨胀的上下文，只为再搜索一个地方。提前提供更丰富的信息，仍然是减少这类搜索开销最有效的单一手段。
上下文工程
Uber 的庞大代码库和数据生态包含数亿行代码和数千张表，智能体的大部分轮次都花在定位信息，而非生成代码上。为此，我们构建了 AI Context Graph（AI 上下文图谱）：一个包含 2,400 万个节点、8,000 万条边的统一网络，涵盖 86 种节点类型和 117 种边类型。（译注：原文此处写作“86 nodes”，结合前述节点总数及后面的边类型，按“86 种节点类型”理解。）它整合了 30 多个内部系统的数据，包括服务、工程团队、事故日志、PR、架构设计文档、部署、数据集，以及历史表使用查询记录，让任意智能体都能通过自然语言查询。
有上下文支撑的智能体查询了历史使用记录，找到 50 多位分析师使用的那张表，并在 38 秒内给出答案。相反，缺少上下文的智能体不知道这张表的存在：它花了 20 分钟检查服务代码，启动了 2 个子智能体，遇到 3 次错误，最后还错误地认定该数据集无法查询。
可见性与使用指导
这里的优化手段是提高可见性、建立反馈闭环，帮助工程师和智能体更快找到有效路径。
状态栏
我们在运行框架的状态栏中加入实时成本计数器，跟踪每位用户在单个框架及所有框架中的实时支出。
可见性与支出档位
为了避免设置硬性上限，我们实施了实时支出跟踪和自动提醒：
- 状态栏实时计数器：终端始终显示当前会话的累计成本。
- 运行框架共享额度池：所有交互式运行框架共用一个支出档位，而不是按工具分别设预算；托管智能体则使用独立档位。
- Slack 提醒：达到预期支出的 50%、80% 和 100% 时发送提醒，让工程师有时间规划。
- 简便的审批流程：升级档位由经理批准，并快速生效。
- 成本查询技能与提示：通过仪表盘技能按需查看成本明细，并在实时状态栏中提供使用指导。
这些机制让工程师能够自主评估任务的投入产出比（ROI），同时降低费用失控的风险。
会话分析仪表盘
状态栏能显示会话总支出，却无法说明成本由什么驱动，也不能给出可执行的提效措施。通用指南只能提供高层原则，无法评估每位开发者的具体工作流。会话分析仪表盘直接检查会话产物，填补了这一空白。
它直接内置于运行时，无需配置或主动启用。执行成本仪表盘技能，即可分析用户在所有运行框架中、本地及远程云沙盒里的全部会话轨迹。它不只是生成汇总指标，而是识别会话中的 16 类反模式，逐一给出费用影响和针对性的改进措施。其中包括：
- 模型路由不佳：本可由 Sonnet 轻松完成的简单多轮会话，却使用 Opus 执行。
- 上下文窗口膨胀：大型 MCP 数据（例如 40KB 的响应）一直保留在上下文中，后续轮次反复计费。
- 缓存过期造成浪费：长时间中断后恢复会话，提示词缓存已过期，只能以全价重建前缀。
- 提示词初始化开销：用户尚未输入任何内容，就已预加载 10 万 token 的系统指令和工具定义。
下一步是什么？
我们目前正在推进以下工作：
- 扩大托管智能体规模：对每个新智能体，我们都遵循一致的路线：确定目标结果指标、构建评估基准、找到帕累托最优模型。通过这套系统化方法，将 SDLC 的每个阶段推向软件工厂成熟度模型的更高层级。
- 动态模型路由：扩大基准测试的覆盖范围，涵盖不同编程语言、代码仓库和智能体形态。由于模型能力差异很大，有效的模型路由高度依赖全面评估。
- 深化上下文图谱集成：让更多自主智能体具备图谱查询能力。
- 将会话分析演进为实时开发指导：从定期批量检测反模式，转向持续监控运行轨迹，直接为工程师提供个性化的实时提效建议。
- 持续改进技能：我们正在开发一种自动化机制，记录智能体技能执行中的细小摩擦，并根据收集的运行轨迹自动生成技能更新。
结语
管理并抑制不断上涨的 AI 编程支出，同样是一个可以通过工程手段解决的问题。我们没有仅仅依赖更低的单价或降低工具能力，而是消除不产生价值的 token 浪费，让使用规模增至原来的 7 倍，同时降低各项指标下的单位成本，并提升或保持输出质量。
核心战略转变，是从开发者交互式工作流转向全托管智能体。将 SDLC 工作负载迁移到托管环境，可以全面掌控模型路由、执行框架和运行支出。为每个专用托管智能体配备专属评估基准和具备帕累托效率的模型，再对整个智能体集群进行优化，天然比逐一优化数千名工程师的终端会话更具成本效益，也更容易扩展。
致谢
这项工作凝聚了许多工程师的共同努力。他们正在构建最高效的基础组件，让软件工厂能在 Uber 的规模下运转，并确保花费的每个 token 都带来回报。我们感谢参与软件工厂各项工作的核心团队成员：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、Weiqiang Wang、Will Bond。
同时感谢 Johannes Gehrke、Mattie Toia、Sumanth Sukumar 和 Praveen Neppalli Naga 的领导。
Anthropic® 是 Anthropic PBC 的注册商标。 Claude Code™ 和 Claude® 是 Anthropic, PBC 的商标。 OpenAI® 及其标志是 OpenAI® 的注册商标。