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