[译]在 Uber 规模下高效运行软件工厂
原文：Running a Software Factory Efficiently at Uber Scale 作者：Uday Kiran Medisetty, Distinguished Engineer（Uber 杰出工程师） 原文链接：https://www.uber.com/us/en/blog/efficient-software-factory/ 发布日期：2026 年 8 月 27 日
引言
在 Uber，AI 工具现已嵌入软件开发的每一个阶段。超过 70% 的 Pull Request（PR）归因于本地或云端 agent。工程师们在软件开发生命周期（SDLC）中构建了超过 3,600 个 agent 技能，平均每天执行超过 30,000 次 agent 技能。
在 AI Engineer 2026 大会上，我们分享了针对软件工厂的愿景，以及我们正在整个生命周期内构建的基础模块和托管 agent。随着这一愿景的推进，越来越多的会话并非由人类发起，而是由自动化托管 agent 驱动的，它们负责代码审查、自愈 CI 故障、带可视化验证的端到端 PR 完成、on-call 告警分级、调试新出现的 bug，以及处理各种带人工审查/升级机制（human reviews/escalations）的代码维护任务。
如图 1 所示，从 2026 年 2 月到 8 月，我们全体雇员（工程师与非工程师）在所有 agentic 产品上的周活跃用户数增长了 7 倍，每周 agentic 请求数增长了 9.4 倍。与此同时，由于我们在各个环节的优化，我们总的 AI 支出自 4 月以来已相对趋于稳定。
图 1：2026 年 2 月至 8 月中旬的每周活跃用户、agent 请求与成本（用户已在各工具间去重）。
由于采用率、工作负载构成和模型升级都在持续变化，要隔离我们自身的优化收益，就需要保持某个模型固定不变——因为每一次升级和模型换代都会改变行为表现。我们在 2 月到 7 月期间就是这么做的：每 1,000 次模型请求的成本较峰值下降了近 34%，每次会话的成本较 6 月峰值下降了 52%。
图 2：模型保持不变时的成本优化影响。每次会话成本数据从 5 月底开始统计。
这篇博客将介绍我们如何看待自己的软件工厂：agent 会话运行的四个层次、我们用于拆解支出的成本方程、如何度量每个项，以及如何跨每一层对这些项进行优化。
本文中的所有定价和供应商指标都基于公开可获得的信息，成本效率的改善源自于在标准层级定价（tier pricing）框架内更智能地路由我们的内部 Uber 工作负载。虽然我们测得的具体成本削减只适用于自身环境，你的结果可能因代码库、团队规模和 agent 工作流而异，但对真实工作进行基准测试，并同时优化准确性和成本的方法论具有普适性。
软件工厂及其成本方程
Agent 使用的四个层次
我们将 AI 使用组织为四个层次，从最专用到最通用。如图 3 所示，层次越高，我们对成本、质量和模型选择的控制力就越强。
图 3：agent 会话运行的四个层次。
成本方程
在上面任何一个层次中，我们都可以将一个 agentic 会话的成本分解为以下项，这些项可以独立度量与优化。
图 4：总支出被分解为六个相乘的项。
总支出 = 用户数 × 每用户会话数 × 每会话轮数 × 每轮请求数 × 每请求 token 数 × 每 token 价格
前两项代表采用与参与度（adoption & engagement），我们希望在整个用户群体中持续推动其增长，无论用户是交互式地使用，还是 agent 代表他们处理任务。中间三项提供了优化空间：它们代表 agent 在工程师实际发起的请求之外，为完成任务而自行执行的工作。这里是我们投入绝大部分精力的地方，包括帮助 agent 更快规划、减少不必要的轮次或错误、优化输入 token 等机制。
我们如何度量
下面是我们每周和每月追踪的完整指标集，它们让我们能够对长期和短期的投入进行预测与规划。
| 层次 | 指标 | 回答的问题 |
|---|---|---|
| 组合（Portfolio） | · 总归因成本 · 去重后的归因用户数 · 每工具/agent 的成本、用户数与支出占比 |
钱花到哪里去了，哪个工具在变化 |
| 每工具单位经济性（Unit economics, per tool） | · 每用户成本 · 每用户请求数 · 每 1,000 请求成本 · 每请求输入、输出与总 token 数 · 每 1 百万 token 成本 · 每 1,000 会话成本 · 每活跃会话小时成本 · 提示缓存命中率（Prompt Cache hit rate） |
工具是否变得更便宜，还是只是使用在迁移 |
| 模型经济性（Model economics） | 对每个模型： · 成本与成本占比 · 请求数与请求占比 · 每 1,000 请求成本 · 每 1 百万 token 成本 |
哪些模型发布真正改变了账单——在相同或不同的每 token 价格下 |
| 驱动因子分解（Driver decomposition） | 成本变化依序分解为 · 采用（用户数） · 参与度（每用户请求数） · 输入工作负载（每请求输入 token） · 输出工作负载（每请求输出 token） |
数字为何变动，精确陈述，不留下任何无法解释的残余 |
| 托管 agent 结果（Managed agent outcomes） | 对每个托管 agent： · 按结果计量的成本（每合并 PR 成本、每审查成本、每告警成本、每清理成本） · 质量信号（revert 率、F1、MTTR） · 数量（落地的 diff、发布的审查、已分级的告警） |
每个托管 agent 交付的每单位价值是否变得更便宜，以及在模型迁移过程中质量是否保持 |
优化杠杆
在以下章节中，我们将详述用于优化成本方程中各部分的关键杠杆。其中一些杠杆会同时影响成本方程中的一行或多行。
| 成本方程项 | 杠杆 |
|---|---|
| 价格 / Token | · 基准驱动的 Pareto 最优模型选择 · 模型默认设置 |
| Token / 请求 | · 400K 上下文上限与默认中等思考强度 · 提示缓存（Prompt Caching） · 工具搜索与 CLI 解析的 MCP 调用 · 代码模式（Code-mode）的批量工具调用 · 网关路由的 SaaS MCP |
| 请求 / 轮 | · 基于图谱的上下文（Graph-grounded context） · 持续技能优化（Continuous Skill Optimization） |
| 可见性与教育 | · 状态行中的实时成本计数器 · 可见性与支出层级 · 会话分析面板 |
优化价格 / Token
token 价格由供应商设定，我们负责选择让哪个模型运行哪种工作负载。在我们所有托管 agent 的各层次中，我们都为相应工作负载选择最 Pareto 高效的模型。对我们而言，Pareto 高效需要同时考虑每项已完成任务的成本、输出质量和模型可靠性。
基准驱动的模型选择
模型选择分三个步骤进行，对我们运行的每个托管 agent 都一样。
- 基于 agent 的真实工作构建一个基准（benchmark）。
- 在一个能同时服务前沿或开放权重模型、且统一接口的 harness 上运行该 agent。
- 迁移到 Pareto 最优的选项，然后持续迁移。前沿每几周就会移动一次。
展望未来，我们通过汇集托管 agent 的聚合洞察来测试和部署各种模型路由策略，从而持续打磨我们各工作负载的表现。
例如，我们使用 uReview——它为所有 pull request 提供 AI 代码审查服务。我们用带有已知 bug 的真实 PR 构建了其基准，并按其难易度分为简单、中等和困难三档。我们针对这些 bug 评估精确率（precision）、召回率（recall）和 F1，再加上每次审查成本、延迟、超时和噪声。如图 5 所示，切换模型在显著降低每 PR 成本的同时提升了我们的 F1。图中虚线即 Pareto 前沿（Pareto frontier）。位于其下方和左侧的所有点，都被某个更便宜或更好的方案压制了。
图 5：我们为 uReview 测试过的每一种配置。
借助大规模单体仓库（monorepo）中的数千个真实 PR，我们内部还有一个 Uber SWE 基准（Uber SWE Benchmark），它跨不同任务类型运行前沿和开放权重模型。我们用它在所有 SDLC 托管 agent 中为模型选择提供参考。
默认模型选择
在交互式界面中，token 单位成本保持固定；然而，你可以策略性地跨模型管理 token 分配。两个默认设置主要决定这种分配：初始会话模型和子代理（subagent）模型。
子代理的默认设置已被证明是影响力最大的杠杆，而且其重要性还在持续增长。随着最新模型能力带来更有效的多 agent 编排，发起子代理的会话比例在稳步上升。由于子代理执行的都是有明确输入的精确定义任务，往往不需要前沿级的推理能力，因此我们默认将它们设为更弱、更具成本效益的模型，同时仍允许手动覆盖。主模型负责任务分解和评估，而子代理负责执行工作。
优化 Token / 请求
每一轮都会重新发送完整的对话历史、项目上下文和工具结果。任何减少每次请求载荷的措施都会在整个会话中被叠加放大。
默认设置
所有交互式 harness 都使用统一封装层来管理安装、配置、鉴权和成本可见性。两个标准化的默认配置可直接减少每次请求的 token 消耗：
- 即使是对 1M 上下文窗口的模型，也在 400k token 处触发自动压缩（compaction）：该阈值在模型性能与缓存突发、重复输入 token 成本之间取得平衡。我们的测量显示，整个 agent 舰队的每次请求输入 token 都明显减少。
- 推理强度默认为中等（Medium）：输出 token（包括内部推理 token）在主力模型上按输入 token 价格的多倍计费；这一策略调整直接降低了最高成本 token 类别的支出。对于一大类任务而言，中等推理强度在成本与质量之间取得了良好的平衡。
提示缓存策略
我们的提示缓存策略由供应商提示缓存读写（prompt cache reads and writes）的经济性驱动。由于每一轮都会重新传送完整的对话历史，缓存前面的上下文可以避免反复支付全额成本，将后续读取降至标准输入 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 服务的 1,000 多个 MCP 服务器，实现了集中式鉴权和策略执行。
然而，标准 MCP 会将所有工具 schema 直接加载到每个会话中，无论工程师是否会在该会话中真正调用它们。例如，在安装了超过 100 个工具的情况下，这种预加载会给初始提示词增加约 50K–70K 的 schema 开销 token，并且这些 token 会在每一轮上下文中反复重发。
图 7：在 3 种触达相同工具的方式下，agent 在会话开始时已经携带的内容。
为了解决这种上下文膨胀问题，我们引入了两个互补的优化机制：
- CLI 工具解析（CLI tool resolution）：允许模型执行 shell 命令，以代替直接的 MCP 集成。CLI 在调用时动态解析并通过网关调用所需工具，从而把 Uber 的 MCP schema 从会话上下文中剔除。我们内部 MCP 网关的全部 1,000+ 个 MCP 工具都被投影为 CLI 命令。
- 工具搜索（Tool search）：允许模型搜索工具目录、并按需只加载所需工具，从而扩展到数千个工具。这种方式缓解了上下文膨胀，通常会减少工具定义所消耗的 token，并且即使在可用工具库扩张时也能保持较高的选择准确度，避免与大工具集相关的性能退化。
代码模式（Code-Mode）
当工具直接以 shell 命令形式调用函数时，模型可以在单个脚本中批量执行多个操作。这种批处理对繁复的工具协议（chatty tool protocols）尤其有利。在标准 MCP 工作流下，每个操作都需要单独的模型轮次来发出请求、把原始响应载入上下文窗口、并依序处理结果。例如，执行一条 SQL 查询需要提交请求、轮询状态 2 到 5 次、再取回输出。Code-mode 把整个流程整合到一个自动化的 Python 循环中，将中间的轮询保持在模型的活动上下文之外。如图 8 左侧所示，模型参与到轮询循环中，每个响应都落入其上下文；右侧的循环则在子进程中运行，只有摘要被返回。
图 8：同一条数据仓库查询的两种执行方式。
我们在同一个会话中通过两条路径分别运行 5 条相同的 SQL 查询来度量这一点：
| 查询 | LLM 工具调用（token） | Code-mode（token） | 节省 |
|---|---|---|---|
| SELECT 1（1 行） | 903 | 402 | 55% |
| COUNT(*)（1 行） | 954 | 403 | 58% |
| GROUP BY LIMIT 20（20 行） | 1,600 | 457 | 71% |
| SHOW COLUMNS（175 行） | 2,200 | 900 | 59% |
| SELECT * 宽表（50 行） | 1,431,594 | 900 | ~100% |
每查询 token，在同一个 Claude Code 会话中测得。
前三行凸显了主要发现：即使是远远低于响应大小限制的最小结果集，code-mode 也能将 token 用量降低超过 50%。这些效率并非源自绕过大数据载荷，而是源于消除不必要的开销，包括 schema 初始化、多轮轮询、以及冗余的逐步推理。
批量工作流会放大这种效应，因为原本需要 N 个模型轮次的循环变成了单个脚本，节省会叠加到 90% 以上。通过为我们访问最频繁的 MCP 服务器部署超过 25 个预构建的 code-mode 技能，我们确保标准工作流默认走最具成本效益的路径。
SaaS MCP
管理第三方软件被证明比我们的内部服务器更具挑战性。供应商设计 MCP 服务器是为了暴露完整的产品能力，因为它们无法预判具体客户的用法。例如，一个工作区套件（workspace suite）把 49 个工具打包进单个服务器，需要约 22K 个 schema token；消息和项目管理供应商则分别提供 34 个和 46 个工具。加载两到三个供应商服务器，会让 agent 携带的 schema 开销超过用户输入提示词前准备编辑的文件本身的大小。
为解决这个问题，我们使用与内部 MCP 相同的机制，将 SaaS MCP 服务器路由到我们的 MCP 网关。此外，我们把所有这些 MCP 都暴露为任何 agentic 界面都能调用的 CLI。另外，我们在 code-mode 插件中为每个服务器编写了专用技能，以封装常见工作流。这解锁了跨众多 SaaS 供应商的高效 agentic 工作流。
图 9：每个 SaaS MCP 服务器都置于 MCP 网关之后，以确保统一、高效的访问模式。
优化请求 / 轮
缺乏上下文根基（ungrounded）的 agent 会缓慢地失败，而不是低成本地失败：它会反复发送不断膨胀的上下文窗口，只为再搜索一个位置。在前端提供更丰富的信息，仍是减少这种搜索开销的最强大杠杆。
上下文工程（Context Engineering）
Uber 的代码库和数据生态包含数亿行代码及数千张表，agent 把大部分轮次花在定位信息上，而不是生成代码上。为解决这个问题，我们构建了 AI 上下文图谱（AI Context Graph）：这是一个统一网络，包含 2,400 万个节点和 8,000 万条边，覆盖 86 种节点类型和 117 种边类型。它整合了来自 30 多个内部系统的数据，包括服务、工程团队、事故日志、pull request、架构设计文档、部署、数据集以及历史表使用查询，并允许任何 agent 用自然语言查询它。
图 10：向同一模型提交相同提示词时，有无图谱根基（graph grounding）的执行路径对比。
有上下文的 agent（grounded agent）查询了历史使用情况，识别出被 50 多位分析师使用过的具体表，并在 38 秒内给出了答案。相反，缺乏上下文的 agent 对该表没有可见性：它花了 20 分钟检查服务代码、派生了 2 个子代理、遇到 3 个错误，最后错误地得出了"该数据集无法查询"的结论。
可见性与教育
这里的杠杆是可见性和反馈闭环，它们帮助工程师和 agent 更快收敛。
状态行（The Status Line）
我们在 harness 状态行中放置了一个实时成本计数器，追踪每个用户在所有 harness 中的实时支出，以及各个 harness 的实时支出。
图 11：状态行，及其一同发货的会话分析器和效率指南。
可见性与支出层级
为避免强加严格的硬性上限，我们实现了实时支出追踪和自动提醒（nudges）：
- 状态行实时计数器。 运行中会话的成本始终在终端里可见。
- harness 池。 所有交互式 harness 共享同一个层级，而非按工具的预算。托管 agent 则使用独立层级。
- Slack 提醒。 在预期支出的 50/80/100% 处发出告警，让工程师有时间做规划。
- 便捷的审批流程。 管理层签字批准层级升级，升级结果快速生效。
- 成本检查技能与提示。 提供按需成本分解和状态行实时指导的仪表盘技能。
这些机制让工程师能够独立评估任务的 ROI，同时遏制失控的支出。
会话分析面板（Session Analysis Dashboard）
虽然状态行能突出显示会话的总支出，但它无法揭示成本驱动因素或可操作的效率步骤。通用指南提供的是高层次原则，但无法评估单个开发者的工作流。会话分析面板通过直接检查会话工件（session artifacts）来弥合这一差距。
它直接内建于运行时，无需任何配置或选择加入（opt-in）。执行 cost dashboard 技能会分析用户在本地和远程云沙箱、跨其使用的所有 harness 的全部会话追踪。它不是产出聚合指标，而是标记出跨会话的 16 种不同反模式（anti-patterns），并将每种模式与它的财务影响和针对性修复方案配对。其中一些类别包括：
- 次优的模型路由： 在 Opus 上执行 Sonnet 就能轻松完成的简单多轮会话。
- 上下文窗口膨胀： 大量 MCP 载荷（例如 40KB 的响应）滞留于上下文，并在后续轮次反复计费。
- 缓存过期低效： 在长时间中断后恢复会话，此时过期的提示缓存迫使进行全价的前缀重建。
- 提示词初始化开销： 在任何用户输入之前就预加载 10 万 token 的系统指令和工具定义。
图 12：会话级成本面板可识别浪费模式和潜在节省。
接下来是什么？
正在进行中的计划包括：
- 扩展托管 agent 的舰队： 对每一个新 agent，我们都遵循一致的路线图：确立目标结果指标、组装评估基准、找出 Pareto 最优模型。这种系统化方法旨在把 SDLC 的每个阶段提升到更高的工厂成熟度等级。
- 动态模型路由（Dynamic Model Routing）： 我们在跨不同编程语言、代码仓库和 agent 形态扩展基准覆盖。鉴于模型能力差异巨大，有效的模型路由高度依赖全面的评估。
- 深化上下文图谱集成： 我们正在为更广泛的自主 agent 解锁图谱查询能力。
- 将会话分析演进为实时开发者指导： 通过从周期性的反模式批量检测转向持续的追踪监控，我们旨在直接向工程师提供个性化、实时的效率建议。
- 持续技能改进： 我们正在研究一种自动化方式，从 agent 技能执行中记录摩擦点（papercuts），并基于收集的追踪自动生成技能更新。
结论
管理和遏止日益增长的 AI 编码支出，同样是一个可解决的工程挑战。通过消除浪费的、零价值的 token 消耗，而不是仅仅依赖更低的单位价格或降级工具，我们将使用规模扩大了 7 倍，同时降低了各项指标中的单位成本，并提升或保持了输出质量。
核心的战略转变是从交互式开发者工作流转向完全托管的 agent。将 SDLC 工作负载迁移到托管环境中，就能对模型路由、执行 harness 和运营支出获得完全的控制。优化一支由专用评估基准和 Pareto 高效模型配套的托管 agent 舰队，天生就比在数千名工程师间逐个优化终端会话更具成本效益、也更可扩展。
致谢
这是众多工程师的集体成果，他们在 Uber 规模下构建最高效的模块来落地软件工厂，同时确保我们为花费的每一个 token 都赢得 ROI。我们要感谢参与软件工厂各条战线工作的核心成员，名单如下：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® 的注册商标。
