Uber Engineering 公开了其在超大规模组织中运营 AI 软件工厂的方法：从智能体会话的四个层级和六因子成本公式出发，系统讲解模型路由、提示词缓存、MCP 工具调用、代码模式、上下文图谱与会话分析等实践。本文保留完整中文翻译、作者署名、译注、11 个章节和 16 张原图。
原文：How to Efficiently Operate a Software Factory at Uber’s Scale，作者：@udaykiran。
本文由 LobsterAI 自动翻译和发布。
作者：@udaykiran
发布账号：Uber Engineering（@UberEng）
原文链接：https://x.com/UberEng/status/2093444169037762840
译者说明：以下为文章正文的完整中文翻译，保留原文章节、段落顺序及配图位置。图片为原图，图内英文未改写；不含评论区及平台界面文字。原文有两处表述不一致，已在对应位置注明。
引言
AI 工具如今已融入 Uber 软件开发的每一个阶段。超过 70% 的拉取请求（PR）被归因于本地或云端智能体。工程师们围绕软件开发生命周期构建了超过 3,600 项智能体技能，每天执行这些技能超过 3 万次。
在 AI Engineer 2026 大会上，我们分享了对软件工厂的愿景，以及我们正在围绕整个生命周期构建的基础组件和托管智能体。随着这一愿景逐步落地，越来越多的会话不再由人发起，而是由自动化托管智能体发起：它们负责代码审查、自动修复 CI 失败、通过可视化验证完成端到端 PR、分诊值班告警、调试新收到的缺陷，并处理各种代码维护任务，同时保留人工审查与升级处理机制。
如图 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 的价格
供应商决定 token 的价格，而我们决定由哪个模型运行哪种工作负载。在所有托管智能体层级中，我们都会选择对该工作负载而言最具帕累托效率的模型。对我们来说，帕累托效率涉及每个已完成任务的成本、输出质量和模型可靠性。
由基准测试驱动的模型选择
模型选择分为四个步骤，对我们运行的每个托管智能体都一样。
- 根据智能体的真实工作构建基准测试。
- 在统一运行框架中运行智能体，通过同一个接口接入任意模型，无论是前沿模型还是开放权重模型。
- 迁移到达到帕累托最优的方案，并持续迁移。最优前沿每隔几周就会变化。
译者注：原文称“四个步骤”，实际仅列出三项，此处照录。
展望未来，我们会持续利用来自托管智能体的汇总洞察，测试和部署各种模型路由策略，不断优化工作负载的表现。
例如，我们使用 uReview 对所有拉取请求进行 AI 代码审查。我们基于包含已知缺陷的真实 PR 构建基准，并将其分为简单、中等和困难三个等级。我们针对这些缺陷评估精确率、召回率和 F1 分数，同时衡量每次审查成本、延迟、超时和噪声。如图 5 所示，更换模型提高了 F1，同时大幅降低了每个 PR 的成本。图中的虚线是帕累托前沿；位于其左下方的所有配置，都存在更便宜或表现更好的替代方案。
图 5：我们为 uReview 测试过的所有配置。
我们还利用大型单体仓库中的数千个真实 PR，在内部构建了 Uber SWE Benchmark，让前沿模型和开放权重模型执行不同类型的任务。我们以此指导软件开发生命周期（SDLC）内所有托管智能体的模型选择。
默认模型选择
在交互式界面中，token 单价不变，但可以有策略地调整 token 在不同模型之间的分配。决定这种分配的主要是两个默认设置：会话初始模型和子智能体模型。
事实证明，子智能体的默认设置是影响最大的优化手段，其重要性还在不断提高。随着最新模型的能力支持更有效的多智能体编排，启动子智能体的会话比例一直在增长。子智能体执行的是输入明确、任务边界清晰的工作，通常不需要前沿级推理能力，因此我们默认让它们使用能力较弱但成本效益更高的模型，同时仍允许手动覆盖。主模型负责拆解任务和评估结果，子智能体负责执行工作。
优化每次请求的 token 数
每个轮次都会重新发送完整对话历史、项目上下文和工具结果。任何减少单次请求载荷的措施，都会在整个会话中产生累积收益。
默认设置
所有交互式运行框架都采用统一封装，管理安装、配置、身份验证和成本可视化。两项标准化默认配置可以直接减少每次请求的 token 消耗：
- 即使模型支持 100 万 token 的上下文窗口，也在 40 万 token 时触发自动压缩。 这一阈值在模型表现、缓存成本突增和重复输入 token 成本之间取得平衡。我们的测量显示，它显著降低了整个部署范围内每次请求的输入 token 数。
- 默认将推理强度设为 Medium（中等）。 在主要模型上，输出 token（包括内部推理 token）的计费费率是输入 token 的数倍，因此这项策略调整直接减少了成本最高的 token 类别的支出。对于很大一类任务，中等推理强度在成本和质量之间取得了良好平衡。
提示词缓存策略
我们的提示词缓存策略由供应商缓存读写的经济性驱动。由于每个轮次都会重新发送完整对话历史，缓存此前的上下文可以避免反复支付全价，使后续读取仅按标准输入 token 费率的 0.1 倍收费。但写入溢价不同：5 分钟缓存条目的写入费用为 1.25 倍，1 小时缓存条目则为 2 倍。因此，最优 TTL（存活时间）的选择取决于轮次之间的间隔。目前可选的 TTL 包括 Anthropic® 的 5 分钟和 1 小时，以及 OpenAI® 的 30 分钟。
图 6：两种 TTL 时长下，5 个轮次的对比。
由于工程师经常让交互式会话空闲超过 5 分钟，我们将默认 TTL 从 5 分钟改为 1 小时。此前，这些频繁出现的空闲间隔会使前缀缓存失效，迫使系统以高昂的全价重新构建上下文。相比之下，子智能体仍保留 5 分钟的缓存 TTL，因为它们专注于单一、短时任务。
通过 Shell 执行 MCP 工具
在 Uber，所有 MCP（模型上下文协议）交互都通过统一网关路由。这一单一入口涵盖超过 1,000 个 MCP 服务器，包括内部和第三方 SaaS MCP，从而实现集中式身份验证与策略执行。
然而，标准 MCP 会将所有工具的结构定义直接加载到每次会话中，无论工程师是否会在该会话里调用它们。例如，安装超过 100 个工具后，这种预加载会在初始提示词中增加约 5 万至 7 万 token 的工具定义开销，并在后续每个上下文轮次中重复发送。
图 7：通过三种方式访问相同工具时，智能体在会话开始时就已经携带的内容。
为解决这种上下文膨胀，我们引入了两种互补的优化机制：
- CLI 工具解析： 通过允许模型执行 Shell 命令，替代直接的 MCP 集成。CLI 在调用时动态解析所需工具，并通过网关调用，从而将 Uber MCP 工具定义从会话上下文中移除。内部 MCP 网关中的全部 1,000 多个 MCP 工具，都映射为 CLI 命令。
- 工具搜索： 允许模型搜索工具目录，并按需仅加载所需工具，从而扩展至数千个工具。这种方式缓解上下文膨胀，通常可以减少工具定义的 token 用量；即使可用工具库不断扩大，也能保持较高的选择准确性，避免大型工具集合带来的性能退化。
代码模式（Code-Mode）
当工具通过 Shell 命令直接调用函数时，模型可以将多个操作批量组织在同一个脚本中。对于需要频繁往返交互的工具协议，这种批处理尤其有利。在标准 MCP 工作流下，每个操作都需要单独的模型轮次来发出请求、将原始响应加载到上下文窗口中，再依次处理结果。例如，执行一次 SQL 查询，需要提交请求、轮询状态 2 至 5 次，再获取输出。代码模式将整套流程整合进自动化 Python 循环，使中间轮询过程不进入模型的活跃上下文。如图 8 所示，左侧由模型参与轮询循环，每个响应都会进入上下文；右侧则由子进程执行循环，最终只返回摘要。
图 8：同一个数据仓库查询的两种执行方式。
我们在同一个会话中，通过这两条路径运行了 5 个相同的 SQL 查询来测量效果：
前三行突出了主要发现：即使结果集很小、远低于响应大小限制，代码模式仍能将 token 用量减少 50% 以上。这些效率收益并非来自绕过大型数据载荷，而是来自消除不必要的开销，包括工具定义初始化、多轮轮询，以及冗余的逐步推理。
批量工作流会进一步放大这种效果：原本需要 N 个模型轮次的循环变成一个脚本，累积节省幅度超过 90%。我们为最常访问的 MCP 服务器部署了超过 25 项预构建的代码模式技能，确保标准工作流默认选择成本效益最高的路径。
SaaS MCP
事实证明，管理第三方软件比管理内部服务器困难得多。供应商无法预知客户的具体使用方式，因此通常设计 MCP 服务器来暴露产品的全部能力。例如，一个办公套件在单个服务器中打包了 49 个工具，需要约 2.2 万 token 的工具定义；即时通信和项目跟踪供应商分别提供了 34 个和 46 个工具。只要加载两三个供应商服务器，用户甚至还没输入提示词，智能体携带的工具定义开销就可能比正在编辑的文件还大。
为此，我们使用与内部 MCP 相同的机制，将 SaaS MCP 服务器接入 MCP 网关。我们也将这些 MCP 全部暴露为 CLI，任何智能体使用界面都可以调用。此外，我们在代码模式插件中为每个服务器编写专门的技能，封装常见工作流。这使我们能够在众多 SaaS 供应商的产品上实现高效的智能体工作流。
图 9：每个 SaaS MCP 服务器都通过 MCP 网关对外暴露，以确保统一、高效的访问模式。
优化每个轮次的请求数
缺少可靠上下文依据的智能体，失败得很慢，而不是失败得很便宜：它会反复发送不断膨胀的上下文窗口，只为再搜索一个地方。提前提供更丰富的信息，仍然是减少这种搜索开销最有效的单一手段。
上下文工程
Uber 庞大的代码库与数据生态包含数亿行代码和数千张表。在这样的环境下，智能体大多数轮次都花在寻找信息上，而不是生成代码。为此，我们构建了 AI 上下文图谱（AI Context Graph）：一个统一网络，包含 2,400 万个节点、8,000 万条边，以及 86 种节点类型和 117 种边类型。它整合了 30 多个内部系统的数据，包括服务、工程团队、故障日志、拉取请求、架构设计文档、部署、数据集，以及历史表使用查询，并允许任何智能体用自然语言查询。
译者注：原文此处写作“across 86 nodes and 117 edge types”，与前述 2,400 万个节点不一致；结合语境，将“86 nodes”按“86 种节点类型”译出。
图 10：将相同提示词提交给同一个模型，对比有无图谱上下文支撑时的执行路径。
有上下文支撑的智能体查询了历史使用情况，找到了超过 50 名分析师使用的具体数据表，并在 38 秒内给出了答案。相反，缺少上下文支撑的智能体不知道那张表的存在；它花了 20 分钟检查服务代码，启动了 2 个子智能体，遇到了 3 次错误，最后错误地认定该数据集无法查询。
可视化与使用指导
这里的优化手段是提供可视化信息和反馈循环，帮助工程师与智能体更快收敛到结果。
状态栏
我们在运行框架的状态栏中加入实时成本计数器，追踪每个用户在单个运行框架以及所有运行框架中的实时支出。
图 11：状态栏，以及随其提供的会话分析器和效率指南。
可视化与支出档位
为了避免设置严格的硬上限，我们实现了实时支出追踪和自动提醒：
- 状态栏实时计数器。 终端始终显示当前会话的累计成本。
- 运行框架共享额度池。 所有交互式运行框架共用一个支出档位，而不是各工具分别设置预算；托管智能体使用单独的档位。
- Slack 提醒。 支出达到预期金额的 50%、80% 和 100% 时发出提醒，让工程师有时间规划。
- 便捷的审批流程。 支出档位升级由经理签批，并快速生效。
- 成本检查技能与提示。 提供按需查看成本明细的看板技能，以及实时状态栏指导。
这些措施让工程师能够自主评估任务的投资回报，同时降低费用失控的风险。
会话分析看板
状态栏可以显示会话总支出，却无法解释成本由什么驱动，也不能给出可执行的提效步骤。通用指导能提供高层原则，但无法评估每个开发者的具体工作流。会话分析看板通过直接检查会话产物，填补了这一空白。
它直接内置于运行时，无需配置，也无需主动启用。执行成本看板技能后，系统会分析该用户在所有使用中的运行框架里、跨本地与远程云端沙箱的全部会话轨迹。它并非只输出汇总指标，而是识别会话中的 16 种不同反模式，并为每一种标明财务影响和针对性改进措施。其中一些类别包括：
- 非最优模型路由： 在 Opus 上执行 Sonnet 本可轻松完成的简单多轮会话。
- 上下文窗口膨胀： 大型 MCP 载荷（例如 40 KB 的响应）持续留在上下文中，导致后续轮次重复计费。
- 缓存过期导致的低效率： 长时间中断后恢复会话，过期的提示词缓存迫使系统按全价重新构建前缀。
- 提示词初始化开销： 用户尚未输入任何内容，就预加载了 10 万 token 的系统指令和工具定义。
图 12：会话级成本看板识别浪费模式和潜在节省空间。
下一步是什么？
目前正在推进的工作包括：
- 扩大托管智能体规模： 对每个新智能体，我们都遵循一致的路线：确定目标结果指标、组建评估基准，并找到帕累托最优模型。这种系统化方法旨在推动 SDLC 的每个阶段向软件工厂成熟度模型的更高层级发展。
- 动态模型路由： 我们正在将基准测试覆盖范围扩展到更多编程语言、代码仓库和智能体形态。鉴于模型能力差异很大，有效的模型路由高度依赖全面评估。
- 深化上下文图谱集成： 我们正在让更广泛的自主智能体具备图谱查询能力。
- 将会话分析发展为实时开发者指导： 从定期批量检测反模式，转向持续监控轨迹，旨在直接向工程师提供个性化、实时的效率建议。
- 持续改进技能： 我们正在开发自动化机制，记录智能体技能执行中的细小摩擦与问题，并根据收集到的轨迹自动生成技能更新。
结论
管理和遏制不断上涨的 AI 编码支出，同样是一个可以通过工程手段解决的问题。我们没有单纯依赖降低单价或降级工具，而是消除浪费、没有价值的 token 消耗，从而将使用规模扩展至原来的 7 倍，同时降低所有指标下的单位成本，并提升或保持输出质量。
核心战略转变，是从交互式开发者工作流转向完全托管的智能体。将 SDLC 工作负载迁移到托管环境，可以全面掌控模型路由、执行框架和运营支出。优化一组专用托管智能体，并为每个智能体配套专门的评估基准和具有帕累托效率的模型，相比优化数千名工程师各自的终端会话，在本质上更具成本效益，也更容易规模化。
致谢
这是众多工程师共同努力的成果。他们正在构建最高效的基础组件，以 Uber 的规模实现软件工厂，同时确保花出的每个 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、Weiqiang Wang、Will Bond。
同时感谢 Johannes Gehrke、Mattie Toia、Sumanth Sukumar 和 Praveen Neppalli Naga 的领导。
Anthropic® 是 Anthropic PBC 的注册商标。
Claude Code™ 和 Claude® 是 Anthropic, PBC 的商标。
OpenAI® 及其标识是 OpenAI® 的注册商标。