原文：Running a Software Factory Efficiently at Uber Scale
作者：Uday Kiran Medisetty｜发布时间：2026 年 8 月 27 日｜以下为完整中文译文；图内文字已中文化。
引言
在 Uber，AI 工具已经嵌入软件开发的每一个阶段。超过 70% 的拉取请求归因于本地或云端智能体。工程师在软件开发生命周期中构建了超过 3,600 个智能体技能，每天执行超过 3 万次技能调用。
在 AI Engineer 2026 大会上，我们分享了软件工厂的愿景，以及贯穿整个生命周期的基础模块和托管智能体。随着这一愿景持续推进，越来越多会话不再由人工发起，而是由自动化托管智能体处理代码审查、CI 失败自愈、带视觉验证的端到端 PR 完成、值班告警分诊、传入缺陷调试，以及各类代码维护任务；这些流程都保留人工审查或升级处理。
如图 1 所示，2026 年 2 月至 8 月，在全部员工（工程师和非工程师）的所有智能体产品中，去重后的周活跃用户增长 7 倍，周智能体请求增长 9.4 倍。与此同时，受各项优化影响，AI 总支出自 4 月以来相对稳定。
采用规模、工作负载组合和模型升级都在持续变化。要隔离自身优化的收益，就需要固定一个模型，因为每次升级和模型家族变更都会改变行为。我们在 2 月至 7 月这样做：每 1,000 次模型请求的成本相较峰值下降近 34%，每会话成本相较 6 月峰值下降 52%。
本文说明我们如何看待软件工厂：智能体会话运行的四层、用于拆解支出的成本公式、各项的度量方法，以及如何跨层优化这些项。
本文涉及的定价和供应商指标均基于公开信息。成本效率收益来自在标准分层定价内更智能地路由 Uber 内部工作负载。我们测得的具体降本幅度属于 Uber 环境，可能因代码库、团队规模和智能体工作流而异；但用真实工作做基准、同时优化准确性与成本的方法具有普适性。
软件工厂及其成本公式
智能体使用的四层
我们将 AI 使用组织为从最专用到最通用的四层。图 3 表明，层级越高，我们对成本、质量和模型选择的控制越强。
成本公式
无论位于上述哪一层，智能体会话成本都可拆解为若干可独立度量和优化的项。
前两项代表采用与参与度。我们希望它们在总体用户群中持续增长，不论用户是交互式使用，还是由智能体代其处理任务。中间三项则提供了优化机会：即智能体在工程师实际请求之外、为完成任务而进行的工作。我们的大部分工作聚焦于此，包括帮助智能体更快规划、减少不必要轮次或错误、优化输入 Token 等机制。
如何度量
| 层级 | 指标 | 回答的问题 |
|---|---|---|
| 组合层 | - 归因总成本 - 去重后的归因用户数 - 按工具或智能体的成本、用户数与支出占比 | 钱花在何处，以及哪一个工具发生了变化。 |
| 单工具单位经济 | - 每用户成本 - 每用户请求数 - 每 1,000 次请求成本 - 每次请求的输入、输出与总 Token - 每 100 万 Token 成本 - 每 1,000 次会话成本 - 每活跃会话小时成本 - 提示词缓存命中率 | 工具是否正在变便宜，还是仅仅发生了使用量迁移。 |
| 模型经济 | 针对每个模型：成本与成本占比、请求与请求占比、每 1,000 次请求成本、每 100 万 Token 成本。 | 模型发布是否在相同或不同的每 Token 价格下真正改变了账单。 |
| 驱动因素分解 | 按顺序将成本变化分解为：采用（用户）、参与度（每用户请求）、输入工作负载（每请求输入 Token）、输出工作负载（每请求输出 Token）。 | 精确说明数值为何变化，不留下无法解释的残差。 |
| 托管智能体结果 | 对每个托管智能体：按结果计价的成本（每个合并 PR、每次审查、每条告警、每次清理）；质量信号（回滚率、F1、MTTR）；产出量（落地差异、发布审查、分诊告警）。 | 每个托管智能体是否以更低成本交付单位价值，以及跨模型迁移时质量能否保持。 |
优化抓手
下文详述用于优化成本公式各部分的关键抓手。有些抓手会影响公式中的一个或多个项。
| 成本项 | 主要抓手 |
|---|---|
| 每 Token 价格 | 基准驱动、帕累托最优的模型选择；模型默认值。 |
| 每请求 Token | 40 万上下文上限和默认中等推理强度；提示词缓存；工具搜索和 CLI 解析的 MCP 调用；代码模式批量调用；经网关路由的 SaaS MCP。 |
| 每轮请求数 | 图谱支撑的上下文；持续的技能优化。 |
| 可见性与教育 | 状态栏实时成本计数器；可见性和支出层级；会话分析仪表盘。 |
优化每 Token 价格
供应商决定 Token 单价；我们决定何种模型运行何种工作负载。对于各层托管智能体，我们选择在该工作负载上最具帕累托效率的模型。这里的帕累托效率指每个完成任务的成本、输出质量和模型可靠性。
基准驱动的模型选择
每个托管智能体的模型选择遵循相同步骤：
- 从智能体的真实工作中构建基准。
- 在一个能通过同一接口提供任意前沿模型或开放权重模型的运行环境中执行智能体。
- 迁移到帕累托最优方案，并持续迁移；前沿每隔几周就会变化。
展望未来，我们持续利用托管智能体的聚合洞见完善工作负载表现，以测试和部署不同模型路由策略。
例如，uReview 为所有拉取请求执行 AI 代码审查。我们用包含已知缺陷的真实 PR 构建基准，并将其分为简单、中等和困难。除针对这些缺陷计算精确率、召回率和 F1 外，我们还衡量每次审查成本、延迟、超时和噪声。图 5 显示，切换模型在显著降低每 PR 成本的同时提升了 F1。图中的虚线是帕累托前沿；位于其左下方的任何配置，都被更便宜或更好的方案支配。
在大型单体仓库的数千个真实 PR 上，我们还内部维护 Uber SWE Benchmark，用于在不同任务类型上运行前沿模型和开放权重模型，并据此指导所有 SDLC 托管智能体的模型选择。
默认模型选择
在交互式界面中，Token 的单位成本保持不变；但可以战略性地管理 Token 在模型间的分布。两个默认设置主要决定这种分布：初始会话模型与子智能体模型。
子智能体默认设置被证明是影响最大的抓手，而且其重要性仍在提升。随着最新模型能力让多智能体编排更加有效，启动子智能体的会话占比持续上升。子智能体执行的是输入明确、边界清晰的任务，通常不需要前沿级推理，因此我们默认使用较弱但更具成本效益的模型，同时仍允许人工覆盖。主模型负责任务拆解与评估，子智能体负责执行。
优化每请求 Token
每一轮都会重新发送完整的对话历史、项目上下文和工具结果。任何减少单次请求载荷的做法都会在整个会话中累积。
默认设置
所有交互式运行环境都采用统一包装器，用于安装管理、配置、认证和成本可见性。两项标准默认配置直接降低每请求的 Token 消耗：
- 即使模型拥有 100 万 Token 上下文窗口，也会在 40 万 Token 时自动压缩。这一阈值在模型表现、缓存突发和重复输入 Token 成本之间取得平衡；测量显示，它显著降低了整个集群每请求的输入 Token。
- 默认推理强度为中等。包括内部推理 Token 在内的输出 Token，在主要模型上的计费倍率高于输入 Token；该策略直接降低了成本最高类别的 Token 支出。对大量任务而言，中等推理在成本与质量之间取得良好平衡。
提示词缓存策略
提示词缓存策略由供应商缓存读写的经济性驱动。每一轮都会重新传输完整对话历史，缓存此前上下文可避免反复支付全价，使后续读取成本降至标准输入 Token 费率的 0.1 倍。但写入溢价不同：5 分钟缓存条目成本为 1.25 倍，1 小时条目为 2 倍。因此，选择最优 TTL（存活时间）取决于轮次之间间隔的时长。
Anthropic 提供 5 分钟和 1 小时 TTL，OpenAI 提供 30 分钟 TTL。
工程师常会让交互式会话空闲超过 5 分钟，因此我们从默认的 5 分钟 TTL 转为 1 小时窗口。过去，这些频繁的空闲间隔会使前缀缓存失效，迫使系统以全价重建上下文。相反，子智能体保留 5 分钟缓存 TTL，因为其执行通常聚焦于单个、短生命周期任务。
通过 Shell 执行 MCP 工具
在 Uber，所有 MCP（模型上下文协议）交互都通过统一网关路由。这个单一入口覆盖超过 1,000 个内部 MCP 服务器和第三方 SaaS MCP，从而实现集中认证和策略执行。
但标准 MCP 会在每个会话中直接加载所有工具模式，不论工程师在该会话中是否会调用。例如，安装 100 多个工具时，初始提示词就增加约 5 万至 7 万 Token 的模式开销，且会在每一轮上下文中重新发送。
为解决这种上下文膨胀，我们引入两项互补机制：
- CLI 工具解析：以让模型执行 shell 命令的方式替代直接 MCP 集成。CLI 在调用时针对网关动态解析并调用所需工具，从会话上下文中移除 Uber MCP 模式。内部 MCP 网关的全部 1,000 多个工具都会投影为 CLI 命令。
- 工具搜索：让模型搜索工具目录，并只按需加载所需工具，从而扩展到数千个工具。它通常降低工具定义的 Token 用量，并在工具库扩张时维持较高选择准确率，避免大规模工具集带来的退化。
代码模式
当工具作为 shell 命令直接调用函数时，模型可以在一段脚本中批量执行多个动作。这对于交互频繁的工具协议尤其有利。标准 MCP 工作流中，每个动作都需要一个独立模型轮次来发出请求、把原始响应载入上下文窗口，并按顺序处理结果。比如一次 SQL 查询，需要提交请求、轮询状态 2 至 5 次，再获取输出。
代码模式将整个流程放进自动化 Python 循环，使中间轮询不进入模型的活跃上下文。如图 8 所示，左侧模型参与轮询循环，每个响应都会进入其上下文；右侧循环在子进程中运行，只有摘要返回。
我们在同一 Claude Code 会话中，让两条路径各执行 5 个相同 SQL 查询：
| 查询 | LLM 工具调用 | 代码模式 | 节省 |
|---|---|---|---|
| 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% |
前 3 行突出了主要发现：即使结果集远小于响应大小限制，代码模式仍能将 Token 用量降低超过 50%。效率并非来自绕过大型数据载荷，而是来自消除不必要开销，包括模式初始化、多轮轮询和冗余的逐步推理。
批量工作流会放大这种效果：原本需要 N 个模型轮次的循环变成一段脚本，节省可超过 90%。我们为访问量最高的 MCP 服务器部署了超过 25 个预构建代码模式技能，使标准工作流默认走成本最有效的路径。
SaaS MCP
管理第三方软件比管理内部服务器更具挑战。供应商会让 MCP 服务器暴露完整产品能力，因为他们无法预知某个客户的具体使用方式。例如，一个工作区套件将 49 个工具打包到单个服务器中，需要约 2.2 万 Token 的模式；消息和项目跟踪供应商分别提供 34 个和 46 个工具。
在用户甚至还未输入提示词之前，加载两个或三个供应商服务器就可能使智能体携带的模式开销超过正在编辑的文件。
为此，我们通过 MCP 网关以与内部 MCP 相同的机制路由 SaaS MCP 服务器，也把它们暴露为任何智能体界面可调用的 CLI，并在代码模式插件中为每个服务器编写封装常见工作流的专用技能。这让跨多个 SaaS 供应商的智能体工作流更加高效。
优化每轮请求数
缺少依据的智能体会缓慢且昂贵地失败：它不断发送不断扩大的上下文窗口，只为再搜索一个位置。预先提供更丰富的信息，仍然是减少这种搜索开销的最强抓手。
上下文工程
Uber 的代码库和数据生态系统包含数亿行代码和数千张表。智能体将大部分轮次花在定位信息上，而不是生成代码。为此，我们构建了 AI Context Graph：一个统一网络，包含 2,400 万个节点和 8,000 万条边，覆盖 86 类节点和 117 类边。
它整合来自 30 多个内部系统的数据，包括服务、工程团队、事故日志、拉取请求、架构设计文档、部署、数据集和历史表使用查询，并允许任意智能体以自然语言查询。
有图谱支撑的智能体查询历史使用情况，识别出被超过 50 位分析师使用的具体表，并在 38 秒内给出答案。没有图谱支撑的智能体看不到该表；它花了 20 分 9 秒检查服务代码、启动 2 个子智能体并遇到 3 个错误，最后还错误地得出"该数据集无法查询"的结论。
可见性与教育
这一部分的抓手是可见性和反馈循环，帮助工程师与智能体更快收敛。
状态栏
我们在运行环境状态栏中放置实时成本计数器，跟踪每个运行环境以及每位用户跨全部运行环境的实时支出。
可见性和支出层级
为避免强制硬上限，我们实现了实时支出跟踪和自动提醒：
- 状态栏实时计数器：终端中始终显示正在运行的会话成本。
- 运行环境池：所有交互式运行环境共用一个层级，而非按工具设置预算；托管智能体则使用独立层级。
- Slack 提醒：在预期支出的 50%、80%、100% 时提醒，让工程师有时间规划。
- 便捷审批流程：经理确认层级升级，并快速传播。
- 成本检查技能和提示：提供按需成本拆解的仪表盘技能，以及状态栏的实时指导。
这让工程师能够独立评估任务 ROI，同时降低失控支出的风险。
会话分析仪表盘
状态栏突出的是会话总支出，却无法看见成本驱动因素或可执行的效率步骤。通用指导只能给出高层原则，不能评估单个开发者工作流。会话分析仪表盘通过直接检查会话产物来填补这一空白。
它直接构建在运行时中，无需任何设置或主动加入。执行成本仪表盘技能会分析用户在其使用的所有运行环境中、本地和远程云沙箱里的全部会话轨迹。它不是生成汇总指标，而是在会话中标记 16 种不同反模式，并为每一种配对说明财务影响和针对性修复措施。其中包括：
- 次优模型路由：在 Sonnet 足以完成的简单多轮会话上使用 Opus。
- 上下文窗口膨胀：大型 MCP 载荷（例如 40KB 响应）留在上下文中，并在后续轮次持续计费。
- 缓存过期低效：长时间间隔后恢复会话，过期的提示词缓存迫使系统以全价重建前缀。
- 提示词初始化开销：用户尚未输入任何内容前，就预加载 10 万 Token 的系统指令和工具定义。
下一步
当前进行中的工作包括：
- 扩展托管智能体集群：对于每个新智能体，我们遵循一致路线图，设定目标结果指标、组装评估基准、识别帕累托最优模型。其目标是将 SDLC 的每一阶段提升到更高的软件工厂成熟度层级。
- 动态模型路由：我们正在扩展对不同编程语言、代码仓库和智能体模态的基准覆盖。有效模型路由高度依赖全面评估，因为模型能力差异很大。
- 深化上下文图谱集成：把图谱查询能力开放给更广泛的自主智能体。
- 把会话分析演进为实时开发者指导：从周期性批量发现反模式，转向持续追踪会话轨迹，并直接向工程师提供个性化、实时的效率建议。
- 持续技能改进：我们在研究自动记录技能执行中的痛点，并根据收集到的轨迹自动生成技能更新的方法。
结论
管理和抑制不断上升的 AI 编程开支，本身也是一个可解决的工程问题。我们通过消除没有价值的 Token 消耗，而非仅依赖更低的单位价格或降级工具，在使用量扩大 7 倍的同时降低所有单位成本指标，并提升或保持了输出质量。
核心战略转变是从交互式开发者工作流转向完全托管的智能体。将 SDLC 工作负载迁移到托管环境后，可以完整控制模型路由、执行运行环境和运营支出。与优化数千名工程师的单独终端会话相比，优化一组专用托管智能体，并为每个智能体配备专门评估基准和帕累托最优模型，在成本上更有效、在规模上也更可扩展。