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

引言

AI 工具现已嵌入 Uber 软件开发的每个阶段。超过 70% 的拉取请求（pull request）归因于本地或云端智能体。工程师们已在软件开发生命周期中构建了超过 3,600 个智能体技能，每天执行超过 3 万次智能体技能调用。

在 AI Engineer 2026 大会上，我们分享了 我们的愿景，即软件工厂（Software Factory）以及我们在整个生命周期中构建的构建模块和托管智能体。随着我们推进这一愿景，越来越多的会话并非由人类发起，而是由自动化托管智能体发起，它们负责代码审查、自愈 CI 故障、完成带有视觉验证的端到端（E2E）拉取请求、分类处理值班告警、调试新出现的缺陷，并在人类审查/升级的配合下处理各种代码维护任务。

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

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

由于采用率、工作负载组合和模型升级都在不断变化，要分离出我们自身的优化收益，就需要固定一个模型，因为每次升级和模型系列的变化都会导致行为发生改变。我们从 2 月到 7 月进行了这项工作：每 1,000 次模型请求的成本较峰值下降了近 34%，每次会话的成本较 6 月峰值下降了 52%。

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

本篇博文将详细介绍我们如何思考软件工厂：智能体会话运行的四个层、我们用于分解支出的成本等式、我们如何衡量每个项，以及我们如何在每一层优化这些项。

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

软件工厂及其成本等式

智能体使用的四个层

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

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

成本等式

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

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

前两项代表采用与参与度，我们希望在整个用户群中持续提升，无论用户是交互式使用，还是由代理代为处理任务。中间三项提供了优化机会：代理在工程师实际提出的请求之外，自行完成的工作。这是我们投入精力最多的地方。这包括帮助代理更快规划、减少不必要的轮次或错误、优化输入词元等机制。

我们如何衡量

以下是我们每周和每月跟踪的完整指标集，使我们能够短期和长期预测并规划我们的工作。

优化杠杆

在以下章节中，我们详细介绍了用于优化成本公式各部分的关键杠杆。其中一些杠杆会影响成本公式中的一行或多行。

优化价格 / Token

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

基于基准测试的模型选择

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

• 基于智能体的真实工作构建基准测试。
• 在测试框架上运行该智能体，该框架通过统一接口支持任何模型，无论是前沿模型还是开放权重模型。
• 转向帕累托最优的模型，并持续转移。前沿模型每隔几周就会变化。

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

例如，我们使用 uReview，它为所有拉取请求处理 AI 代码审查。我们基于包含已知缺陷的真实拉取请求构建其基准测试，并将其分为简单、中等和困难。我们针对这些缺陷计算精确率、召回率和 F1，外加每次审查的成本、延迟、超时和噪音。如图 5 所示，切换模型提高了我们的 F1，同时大幅降低了每个 PR 的成本。在图中，虚线是帕累托前沿。位于其下方和左侧的所有配置都被更便宜或更好的配置所超越。

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

利用大型单体代码库中的数千个真实 PR，我们内部还有一个 Uber SWE Benchmark，它在不同任务类型上运行前沿模型和开放权重模型。我们用它来为所有 SDLC 托管智能体的模型选择提供信息。

默认模型选择

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

子代理默认设置已被证明是影响最大的杠杆，其重要性还在持续增长。随着最新模型能力使多代理编排更加高效，启动子代理的会话比例稳步上升。由于子代理执行的是定义明确、输入指定的任务，通常不需要前沿级别的推理能力，我们将其默认设置为更弱但更具成本效益的模型，同时仍允许手动覆盖。主模型负责任务分解和评估，而子代理负责执行工作。

优化每次请求的 Token 数

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

默认设置

所有交互式工具链都使用统一的封装层来管理安装、配置、身份验证和成本可见性。两项标准化的默认配置直接降低了每次请求的 token 消耗：

• 即使对于 100 万上下文窗口的模型，自动压缩也会在 400k 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 的 1,000 多个 MCP 服务器，实现集中式身份验证和策略执行。

然而，标准 MCP 会将所有工具 schema 直接加载到每个会话中，无论工程师是否会在该会话中调用它们。例如，安装了 100 多个工具时，这种预加载会为初始提示增加约 50K-70K token 的 schema 开销，而这些开销随后会在每个上下文轮次中被重新发送。

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

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

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

Code-Mode

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

图 8：同一个数仓查询，两种方式。

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

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

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

SaaS MCP

管理第三方软件被证明比管理我们内部的服务器要困难得多。供应商设计 MCP 服务器是为了暴露完整的产品能力，因为他们无法预知具体的客户使用场景。例如，一个工作区套件将 49 个工具捆绑在一个服务器中，需要约 22K 个 token 的 schema，而消息传递和项目跟踪供应商分别提供 34 和 46 个工具。加载两三个供应商服务器，会让智能体在用户输入提示词之前就背负比正在编辑的文件更多的 schema 开销。

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

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

优化每轮请求数

缺乏上下文依据的智能体失败得慢而不是便宜，它会反复发送不断扩大的上下文窗口去搜索更多位置。在一开始就提供更丰富的信息，仍然是降低这种搜索开销最强大的杠杆。

上下文工程

在 Uber 庞大的代码库和数据生态系统中，包含数亿行代码和数千张表，智能体大部分轮次都花在定位信息而非生成代码上。为了解决这个问题，我们设计了 AI 上下文图谱：一个统一的网络，包含 2400 万个节点和 8000 万条边，涵盖 86 种节点类型和 117 种边类型。它整合了来自 30 多个内部系统的数据，包括服务、工程团队、事故日志、拉取请求、架构设计文档、部署、数据集和历史表使用查询，并允许任何智能体用自然语言查询它。

图 10：对比提交给同一模型的相同提示词在有图谱依据和无图谱依据情况下的执行路径。

有依据的智能体查询了历史使用情况，识别出超过 50 位分析师使用的特定表，并在 38 秒内给出了答案。相反，无依据的智能体无法看到那张表；它花了 20 分钟检查服务代码，派生了 2 个子智能体，遇到 3 次错误，最终错误地得出该数据集无法查询的结论。

可见性与教育

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

状态栏

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

图 11：状态栏，以及随其一起提供的会话分析器和效率指南。

可见性与支出层级

为了避免设置严格的上限，我们实施了实时支出跟踪和自动提醒：

• 状态栏实时计数器。 运行中会话的成本始终在终端中可见。 
• 工具池。 所有交互式工具共享一个统一额度，而非按工具单独分配预算。托管智能体则有独立的额度。
• Slack 提醒。 在预期支出达到 50/80/100% 时发出警报，让工程师有时间进行规划。
• 便捷的审批流程。 额度升级需经理签批，并可快速生效。
• 成本检查技能与提示。 一个仪表板技能，用于按需查看成本明细并提供实时状态栏指导。

这些功能使工程师能够独立评估任务的投资回报率，同时防止费用失控。

会话分析仪表板

状态栏虽然突出显示了会话的总支出，但缺乏对成本驱动因素或可操作的效率改进步骤的可见性。通用指导提供了高层原则，但无法评估单个开发者的具体工作流。会话分析仪表板通过直接检查会话产物来弥补这一差距。

它直接内置于运行时中，无需任何设置或选择加入。执行 cost dashboard 技能会分析用户在本地和远程云沙箱中、跨其使用的所有工具的全部会话轨迹。它不会生成汇总指标，而是标记出跨会话的 16 种不同反模式，并将每种模式与其财务影响和针对性的修复措施配对。部分类别包括：

• 次优模型路由：在 Opus 上执行简单的多轮会话，而 Sonnet 完全可以胜任。
• 上下文窗口膨胀：大型 MCP 载荷（例如 40KB 的响应）滞留在上下文中，在后续轮次中导致重复计费。
• 缓存过期低效：长时间中断后恢复会话，过期的提示缓存迫使按全价重建前缀。
• 提示初始化开销：在接收任何用户输入之前，预先加载 100,000 个 token 的系统指令和工具定义。

图 12：会话级成本仪表板识别浪费模式和潜在节省空间。

下一步计划？

当前正在进行的计划包括：

• 扩大托管智能体规模：对于每个新智能体，我们都遵循一致的路线图：确定目标成果指标、组建评估基准，并找出帕累托最优模型。这种系统化方法旨在将软件开发生命周期（SDLC）的每个阶段提升到更高的工厂成熟度模型层级。
• 动态模型路由：我们正在扩展跨多种编程语言、代码仓库和智能体模式的基准测试覆盖范围。鉴于模型能力差异很大，有效的模型路由在很大程度上依赖于全面的评估。
• 深化上下文图集成：我们正在为更广泛的自主智能体解锁图查询能力。
• 将会话分析演进为实时开发者指导：通过从周期性的反模式批量检测转向持续的轨迹监控，我们旨在将个性化、实时的效率建议直接推送给工程师。
• 持续的技能改进：我们正在研究一种自动化方法，用于记录智能体技能执行过程中的小问题（papercuts），并根据收集到的跟踪记录自动生成技能更新。

结论

管理和遏制不断上涨的 AI 编码费用也是一个可解决的工程挑战。通过消除浪费的、零价值的 token 消耗，而不是仅仅依赖更低的单价或降级工具，我们将使用量扩大了 7 倍，同时降低了所有指标的单位成本，并提高/保持了输出质量。

核心战略转变是从交互式开发者工作流转向完全托管的智能体。将 SDLC 工作负载迁移到托管环境中，可以完全控制模型路由、执行框架和运营支出。优化一组专业的托管智能体（每个智能体都配有专门的评估基准和帕累托最优模型），本质上比优化数千名工程师的单个终端会话更具成本效益和可扩展性。

致谢

这是众多工程师的集体努力，他们正在构建最高效的模块，以在 Uber 规模上实施软件工厂（Software Factory），同时确保我们花费的每一个 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、Viv Keswani、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® 的注册商标。