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