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