在Uber规模下高效运营软件工厂

作者：@udaykiran

引言

AI工具现已嵌入Uber软件开发的每个阶段。超过70%的代码合并请求由本地或云端智能体完成。工程师们在整个软件开发生命周期中构建了超过3,600项智能体技能，每天执行超过3万次智能体技能调用。

在AI Engineer 2026大会上，我们分享了对软件工厂的愿景，以及我们正在构建的覆盖全生命周期的构建模块和托管智能体。随着这一愿景的推进，越来越多的任务会话不再由人类发起，而是由自动化托管智能体处理，包括代码审查、自我修复CI失败、通过视觉验证完成端到端的代码合并请求、分类运维警报、调试传入的bug，以及在人类审查/升级的情况下处理各种代码维护任务。

如图1所示，从2026年2月到8月，所有员工（工程师和非工程师）在所有智能体产品中的周活跃用户增长了7倍，周智能体请求量增长了9.4倍。与此同时，由于全面的优化，自4月以来我们的总AI支出已相对稳定。

图1：2026年2月至8月中旬的周活跃用户、智能体请求量和成本，用户已在各工具间去重。

由于采用率、工作负载组合和模型升级都在持续变化，要隔离我们自身的优化成果，必须固定一个模型，因为每次升级和模型系列的变化都会导致行为改变。我们在2月至7月期间进行了此项分析：每千次模型请求的成本较峰值下降了近34%，每次会话的成本较6月峰值下降了52%。

图2：固定模型后的成本优化影响。*每次会话成本数据从5月底开始。

本文将阐述我们如何看待我们的软件工厂：智能体会话运行的四个层次、用于分解支出的成本方程、如何衡量每个项，以及如何优化每一层中的这些项。

本对比中的所有定价和供应商指标均基于公开信息，其成本效率提升源于我们在标准层级定价内更智能地路由我们的内部Uber工作负载。虽然我们测量的具体成本降低可能特定于我们的环境，并且根据您的代码库、团队规模和智能体工作流的不同，您的结果可能有所差异，但基准测试实际工作并为准确性和成本进行优化的方法论是普遍适用的。

软件工厂及其成本方程

智能体使用的四个层次

我们将AI使用组织为四个层次，从最专用到最通用。如图3所示，层次越高，我们对成本、质量和模型选择的控制力越强。

图3：智能体会话运行的四个层次。

成本方程

在上述任何层次中，我们都可以将智能体会话的成本分解为以下各项，这些项可以独立衡量和优化。

图4：总支出分解为相乘的六个项。

前两项代表采用和参与度，我们希望在整体用户群中持续增长，无论用户是交互式使用还是智能体代其处理任务。中间的三项提供了优化的机会：智能体在工程师实际请求之上自行执行的工作。这是我们大部分努力所在。这包括帮助智能体更快规划、减少不必要的轮次或错误、优化输入token等机制。

我们如何衡量

以下是我们每周和每月追踪的全套指标，使我们能够短期和长期地预测和规划我们的工作。

优化杠杆

在以下章节中，我们将详细说明我们用来优化成本方程每个部分的几个关键杠杆。其中一些杠杆会影响成本方程中的一行或多行。

优化价格/Token

供应商设定token价格。我们选择哪个模型运行哪种工作负载。在我们所有托管智能体的层次中，我们为该工作负载选择最具帕累托效率的模型。对我们而言，帕累托效率意味着成本/完成任务、输出质量和模型可靠性。

基准测试驱动的模型选择

模型选择分四个步骤进行，对于我们运行的每个托管智能体都是相同的。

• 根据智能体的真实工作构建一个基准。
• 在一个可以为任何模型（前沿模型或开放权重模型）提供服务的工具上运行该智能体。
• 转向任何帕累托最优的模型，并持续跟进。前沿模型每几周就会发生变化。

展望未来，我们通过利用托管智能体的聚合洞察来测试和部署各种模型路由策略，持续优化我们的工作负载性能。

例如，我们使用uReview，它处理所有代码合并请求的AI代码审查。我们根据已知bug的真实代码合并请求构建了其基准，并将它们评级为简单、中等和困难。我们针对这些bug评估精确率、召回率和F1值，以及每次审查的成本、延迟、超时和噪声。如图5所示，切换模型在显著降低每次合并请求成本的同时，提高了我们的F1值。图中虚线是帕累托前沿线。其下方和左侧的任何配置都会被更便宜或更好的配置超越。

图5：我们为uReview测试的每种配置。

利用我们大型单体代码库中的数千个真实世界合并请求，我们内部还有一个Uber SWE基准，它在不同的任务类型上运行前沿模型和开放权重模型。我们使用它来为我们的所有SDLC托管智能体提供模型选择依据。

默认模型选择

在交互式界面中，token单位成本保持不变；但是，您可以战略性地管理跨模型的token分布。两个默认设置主要控制此分布：初始会话模型和子智能体模型。

子智能体默认设置已被证明是影响最大的杠杆，并且其重要性持续增长。随着最新模型能力实现更有效的多智能体协调，发起子智能体的会话比例稳步增加。因为子智能体执行定义明确的任务，其指定输入通常不需要前沿模型的推理能力，所以我们默认使用较弱、更具成本效益的模型，同时仍允许手动覆盖。主模型处理任务分解和评估，而子智能体执行具体工作。

优化令牌/请求

每次轮次都会重新发送完整的对话历史、项目上下文和工具结果。任何减少每请求负载的措施都会在整个会话中复合产生效果。

默认设置

所有交互式工具都使用统一的封装器进行安装管理、配置、身份验证和成本可见性。两个标准化的默认配置直接减少了每次请求的令牌消耗：

• 即使对于100万上下文窗口模型，也将在40万token时触发自动压缩：此阈值平衡了模型性能与缓存突发和重复输入token成本。我们的测量显示，整个集群每次请求的输入token量有显著减少。
• 推理努力程度默认为中等：输出token，包括内部推理token，在主模型上按输入token费率的倍数计费；此策略调整直接减少了最高成本token类别的支出。对于一大类任务，中等推理在成本与质量之间达到了良好的平衡。

提示缓存策略

我们的提示缓存策略由提供商提示缓存读写的经济学驱动。由于每次轮次都会重新传输完整的对话历史，缓存前面的上下文可以避免重复支付全额成本，将后续读取成本降低至标准输入token费率的0.1倍。但是，写入溢价各不相同：5分钟缓存条目成本为1.25倍，而1小时条目成本为2倍。因此，选择最佳的TTL取决于轮次之间的间隔时间。可用的TTL选项包括来自Anthropic®的5分钟和1小时，以及来自OpenAI®的30分钟。

图6：两种TTL持续时间下5轮次的比较。

由于工程师经常将交互式会话闲置超过5分钟，我们从默认的5分钟TTL过渡到了1小时窗口。这些频繁的闲置间隙以前会使前缀缓存失效，迫使进行昂贵的全额上下文重建。相比之下，子智能体保留5分钟的缓存TTL，因为它们的执行焦点仅限于单个短期任务。

通过Shell执行MCP工具

在Uber，所有MCP（模型上下文协议）交互都通过一个统一的网关路由。这一个入口点涵盖了内部和第三方SaaS MCP的1000多个MCP服务器，实现集中的身份验证和策略执行。

然而，标准MCP将所有工具架构直接加载到每个会话中，无论工程师在该会话中是否会调用它们。例如，安装了100多个工具时，此预加载会在初始提示中增加约5万-7万token的架构开销，而这部分会在每次上下文轮次中重新发送。

图7：在访问相同工具的三种方式下，智能体在会话开始时已经携带的内容。

为了解决此上下文膨胀问题，我们引入了两个互补的优化机制：

• CLI工具解析：通过允许模型执行shell命令来取代直接的MCP集成。CLI在调用时动态解析并针对网关调用所需工具，从而从会话上下文中消除Uber MCP架构。我们内部MCP网关的所有1000多个MCP工具都被映射为CLI命令。
• 工具搜索：通过允许模型搜索工具目录并按需仅加载所需工具，扩展到数千个工具。这种方法缓解了上下文膨胀，通常减少了工具定义的token使用量，并在可用工具库扩展时保持高选择准确性，防止与大型工具集相关的性能下降。

代码模式

当工具直接以shell命令调用函数时，模型可以在单个脚本中批量处理多个操作。对于“话多“的工具协议，此批处理特别有利。在标准MCP工作流下，每个操作都需要一个单独的模型轮次来发出请求、将原始响应加载到上下文窗口中，并顺序处理结果。例如，执行单个SQL查询需要提交请求、轮询状态2到5次以及检索输出。代码模式将整个流程简化为一个自动化的Python循环，将中间轮询排除在模型的活跃上下文之外。如图8左侧所示，模型参与轮询循环，每个响应都进入其上下文。右侧，循环在子进程中运行，只有摘要返回。

图8：相同的仓库查询，两种方式。

我们通过在同一会话中通过两种路径运行5个相同的SQL查询来测量这一点：

前三行突出了主要发现：即使对于远低于响应大小限制的最小结果集，代码模式也能将令牌使用量减少50%以上。这些效率并非源于绕过大型数据负载，而是源于消除了不必要的开销，包括架构初始化、多轮轮询和冗余的逐步推理。

批量工作流会复合此效果，因为原本需要N个模型轮次的循环变成了一个脚本，节省量复合超过90%。通过为我们访问量最大的MCP服务器部署超过25个预构建的代码模式技能，我们确保标准工作流默认使用最具成本效益的路径。

SaaS MCPs

管理第三方软件被证明比管理我们的内部服务器更具挑战性。供应商设计MCP服务器以暴露完整的产品功能，因为他们无法预测特定的客户使用情况。例如，一个工作空间套件将49个工具打包到一个服务器中，需要约22K token的架构，而消息和项目跟踪供应商分别提供34和46个工具。加载两到三个供应商服务器，智能体在用户输入提示之前就要携带比被编辑的文件更多的架构开销。

为了解决这个问题，我们使用与内部MCP相同的机制，通过我们的MCP网关路由SaaS MCP服务器。我们还将所有这些MCP暴露为任何智能体表面都可以调用的CLI。此外，我们为每个服务器在我们的代码模式插件中编写了专用技能，以封装常见工作流。这解锁了跨多个SaaS供应商的高效智能体工作流。

图9：每个SaaS MCP服务器都通过我们的MCP网关暴露，以确保统一、高效的访问模式。

可见性与教育

这里的杠杆是可见性和反馈循环，帮助工程师和智能体更快地收敛。

状态行

我们在工具状态行中放置了一个实时成本计数器，跟踪每个工具和每个用户所有工具的实时支出。

图10：状态行，以及附带的会话分析器和效率指南。

图10：状态行，以及附带的会话分析器和效率指南。

可见性与支出层级

为了避免施加严格的限制，我们实施了实时支出跟踪和自动化提示：

• 状态行实时计数器。运行会话始终在终端中可见。
• 工具池。所有交互式工具共享一个层级，而不是每个工具的预算。托管智能体则使用单独的层级。
• Slack提示。在预期支出的50/80/100%时发出警报，以便工程师有时间进行规划。
• 便捷的审批流程。