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

在 2026 年 AI 工程师大会上，Uber 分享了对软件工厂的愿景以及在软件开发生命周期各阶段构建的模块和托管智能体。随着这一愿景的推进，越来越多的工作会话不再由人工发起，而是由自动化托管智能体完成，包括代码评审、CI 故障自动修复、完成端到端 PR（含视觉验证）、分级处理值班告警、调试新提交的错误，以及各类代码维护任务（需人工审核/升级）。

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

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

由于工具采用率、工作负载构成和模型版本升级都在持续变化，单独衡量优化带来的收益需要固定使用同一个模型，因为每次升级和模型系列变更都会带来行为变化。从 2 月到 7 月的对照测试显示：每 1000 次模型请求的成本较峰值下降了近 34%，每次会话的成本较 6 月峰值下降了 52%。

图 2：模型固定情况下的成本优化效果。单会话成本数据从 5 月底开始。

本文将介绍对软件工厂的思考：智能体会话运行的四个层级、用于拆解开销的成本计算公式、各项指标的测算方式，以及如何在每一层完成指标优化。

对比的所有定价与供应商指标均基于公开信息，成本效率提升源于在标准定价层级内对内部业务负载进行更智能的路由调度。虽然测算得到的成本降幅取决于环境，实际效果会因代码库、团队规模、智能体工作流的不同而存在差异，但基于真实业务进行的基准测试、围绕准确率与成本进行优化的方法论具备普适性。

软件工厂及其成本公式

智能体运行的四个层级

AI 使用被划分为四个层级，从高度专用到通用能力依次排布。如图 3 所示，层级越高，对成本、质量以及模型选择的掌控力就越强。

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

成本公式

在上述任一层级中，可以将智能体会话的成本分解为以下各项，这些项可以进行独立度量和优化。

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

前两项代表采用率和参与度，希望在全体用户群体中持续提升这两项指标，无论用户是交互式使用 AI 还是由智能体代劳处理任务。中间三项提供了优化机会：即智能体在工程师实际请求之外自主完成的额外工作。这也是投入最多精力的地方，其中包括帮智能体更快规划、减少不必要的轮次或错误、优化输入 token 等机制。

如何度量

以下是按周、按月跟踪的完整指标集，依靠这些指标，能够对短期与长期工作进行预测和规划。

优化手段

在接下来的章节中，将详细介绍用于优化成本公式各个组成部分的关键手段。其中一些手段会影响成本公式中的一个或多个项。

优化 token 价格

供应商设定 token 价格，为各类工作负载匹配模型。在所有托管智能体层级中，会选择帕累托最优的模型。帕累托最优意味着三个因素：每次完成任务的成本、输出质量和模型可靠性。

基于基准测试的模型选择

模型选型分为四个步骤，所有托管智能体都采用这套流程。

• 基于智能体的真实业务任务构建基准测试。




• 在支持任意模型（无论是前沿模型还是开源权重模型）的 Harness 上运行智能体，这些模型均通过统一接口提供服务。




• 迁移到帕累托最优的配置，并持续迭代更新。

借助托管智能体生成的聚合洞察持续优化工作负载性能，测试并落地各类模型路由策略。

例如，使用 uReview 处理所有 PR 的 AI 代码评审。基于包含已知错误（分为简单、中等、困难三级）的真实 PR 构建基准测试。针对这些错误计算精确率、召回率和 F1 分数，同时统计每次评审的成本、延迟、超时和噪音。如图 5 所示，切换模型提高了 F1 分数，同时大幅降低了每个 PR 的成本。图中虚线为帕累托前沿曲线。虚线左下方的配置都存在成本更低或者效果更好的替代方案。

图 5：为 uReview 测试过的配置。

基于大型单体代码库中数千个真实 PR，内部构建了一个 SWE 基准测试，针对不同任务类型运行前沿模型与开源权重模型。用它来为所有 SDLC 托管智能体的模型选择提供依据。

默认模型选择

在交互式界面中，token 单位成本保持不变，但可以根据策略在不同模型之间分配 token。主要由两项默认配置控制 token 分配：初始会话模型和子智能体模型。

子智能体默认设置被证明是最具影响力的手段，且重要性还在持续提升。随着新一代模型能力实现更有效的多智能体编排，发起子智能体的会话比例稳步上升。由于子智能体执行的是输入明确、任务边界清晰的任务，通常不需要前沿级别的模型推理能力，将其默认设置为能力稍弱但性价比更高的模型，同时也支持人工覆盖修改配置。主模型负责任务分解和评估，而子智能体执行具体的任务。

优化每次请求的 token 数

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

默认设置

所有交互式 Harness 都使用统一的封装层，负责安装管理、配置、鉴权以及成本可视化。有两套标准化默认配置可以直接降低单次请求的 token 消耗量：

• 自动压缩在达到 40 万 token 时触发，即使是支持 100 万上下文窗口的模型也是如此：这个阈值在模型性能与缓存突增和重复输入 token 成本之间取得了平衡。测量显示，这显著降低了整个集群范围的每次请求输入 token 数。




• 推理强度默认设置为中等：输出 token（包括内部推理 token）在主模型上的计费倍率高于输入 token；这一策略调整直接减少了高成本 token 的支出。对于绝大多数任务，中等推理强度能够在成本与输出质量之间实现良好平衡。

提示词缓存策略

提示词缓存策略是基于模型服务商提示词缓存的读写成本来制定的。由于每一轮交互都会重新传输完整对话历史，对前文上下文做缓存可以避免重复支付全额成本，将后续读取成本降至标准输入 token 费率的 0.1 倍。但缓存写入会产生额外溢价，不同有效期的溢价不一样：5 分钟有效期的缓存条目写入溢价为 1.25 倍，1 小时有效期则为 2 倍。因此 TTL 的选择取决于对话轮次之间的间隔时长。Anthropic 提供 5 分钟、1 小时两种 TTL 选项，OpenAI 则提供 30 分钟的选项。

图 6：两种 TTL 时长下 5 轮对话的比较。

由于工程师经常让交互式会话空闲超过 5 分钟，从默认的 5 分钟 TTL 过渡到了 1 小时。这些频繁的空闲间隙会导致前缀缓存失效，不得不重新构建完整上下文。与之相反，子智能体仍然保留 5 分钟的缓存 TTL，因为子智能体只负责执行单一、短生命周期的任务。

通过 Shell 执行 MCP 工具

在 Uber，所有 MCP 交互都通过一个统一网关进行路由。这个入口点涵盖了超过 1000 个内部和第三方 SaaS MCP 服务器，实现了集中式认证和策略管控。

但标准 MCP 会把全部工具 Schema 直接加载到每一个会话中，无论工程师在该会话里是否会调用这些工具。例如，当安装超过 100 个工具时，这种预加载会给初始提示词带来大约 5 万至 7 万的 token 开销，并且每一轮上下文交互都会重复发送这部分内容。

图 7：三种调用相同工具的方式，智能体在会话开始时携带的内容对比。

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

• CLI 工具解析：不再直接集成 MCP，改为允许模型执行 Shell 命令。CLI 在调用时动态解析并调用所需工具，将 MCP 工具 Schema 从会话上下文中移除。内部 MCP 网关的全部 1000 多个 MCP 工具均对外映射为 CLI 命令。




• 工具检索：支持数千个工具，模型可检索工具目录，按需加载需要用到的工具。该方案缓解了上下文膨胀问题，通常可以降低工具定义带来的 token 消耗；即便工具库不断扩充，也能保持较高的工具选择准确率，避免工具数量庞大带来的性能下降。

代码模式

当工具将函数直接作为 Shell 命令调用时，模型可以在单个脚本中批量执行多个操作。这种批处理对于交互频繁的工具协议来说尤其有利。在标准 MCP 工作流中，每个操作都需要单独的模型轮次来发出请求、将原始响应加载到上下文窗口中，并顺序处理结果。

例如，执行单个 SQL 查询需要提交请求、轮询状态 2 到 5 次，然后检索输出。在代码模式下，整个流程被简化为自动化的 Python 循环，将中间轮询排除在模型的活动上下文之外。如图 8 左侧所示，模型参与轮询循环，每次响应都会进入上下文。右侧显示的是循环在子进程中运行，只有摘要被返回。

图 8：两种方式执行同一个数据仓库查询。

通过在同一个会话中使用两条路径执行 5 条相同的 SQL 查询来对比测算：

从表格前三项数据可以看出，即便返回结果集很小、远未达到响应大小的上限，代码模式依旧可以将 token 消耗降低 50% 以上。这种效率提升并非来自靠绕过大数据负载，而是源于消除了各类不必要的开销，包括 Schema 初始化、多轮轮询以及冗余的分步推理。

批量工作流会放大这种优化效果，因为原本需要 N 个模型轮次的循环变成了一个脚本，token 节省复利增长至 90% 以上。为最常访问的 MCP 服务器部署超过 25 个预构建的代码模式技能，确保标准工作流默认采用最具成本效益的路径。

SaaS MCP

管理第三方软件远比管理内部服务器困难得多。供应商设计 MCP 服务器是为了暴露完整的产品能力，因为他们无法预测客户的具体使用场景。例如，一个办公套件将 49 个工具打包到单个服务器中，Schema 需要约 22000 个 token，而消息通讯和项目跟踪供应商分别提供 34 个和 46 个工具。加载两三个供应商服务器后，在用户输入提示词之前，智能体上下文开销就已经超过了正在编辑的文件本身。

针对该问题，复用了内部 MCP 的处理机制，将 SaaS MCP 服务器全部通过 MCP 网关来路由。同时把这些 MCP 全部对外封装为 CLI，可供任意智能体调用。除此之外，在代码模式插件中为每一个第三方服务提供专用的技能，封装了常见的工作流。这为许多 SaaS 供应商解锁了高效的智能体工作流。

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

优化每轮请求数

缺少事实依据的智能体不会低成本快速失败，它会不断发送持续膨胀的上下文窗口，只为再多搜索一个位置。提前提供更完备的信息仍是降低这类检索开销最有效的优化手段。

上下文工程

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

图 10：比较同一模型在使用相同提示词下时有图谱锚定和无图谱锚定的执行路径。

有图谱锚定的智能体查询了历史使用记录，定位到被 50 多名分析师使用过的那张数据表，仅用 38 秒就给出答案。与之相对，没有事实锚定的智能体无法获知该数据表的存在；它耗时 20 分钟去检查服务代码，衍生出 2 个子智能体，并遇到 3 次报错，最后错误地判定该数据集无法查询。

可见性与知识沉淀

这里的优化手段是可观测性与反馈闭环，帮助工程师和智能体更快地达成预期结果。

状态行

在 Harness 状态行加入实时成本计数器，跟踪单个任务的实时支出以及每个用户的总支出。

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

可见性与支出层级

为避免设置硬性消耗上限，实现了实时开销追踪和自动提醒机制：

• 状态行实时计数器。运行中的会话成本始终在终端中可见。




• Harness 任务池。所有交互式 Harness 共享一个层级，而非每个工具单独预算。托管智能体则有单独的层级。




• Slack 提醒。在预期支出的 50%/80%/100% 时发出提醒，让工程师有时间规划调整。




• 便捷的审批流程。层级升级只需管理者审批，快速生效。




• 成本检查技能和提示。一个仪表盘技能，用于按需成本分解和实时状态行指导。

这些机制让工程师能够自主评估任务的投入产出比，同时避免开销失控。

会话分析仪表盘

状态行虽然可以展示会话的总开销，但无法看清成本成因，也不能给出可操作的优化方案。通用指引只能提供宏观原则，无法评估个人开发者的工作流。会话分析仪表盘弥补了这一短板，它可以直接解析会话运行产物。

该能力直接内置在运行时中，无需任何配置，也不需要用户手动开启。成本仪表盘技能会分析该用户所有 Harness 任务、本地以及远程云沙箱中的全部会话追踪日志。它不只是输出汇总指标，而是会识别会话中 16 种不同的低效反模式，每一类都会标注对应的资金消耗影响，并给出针对性修复方案。部分分类如下：

• 次优模型路由：在 Opus 上执行简单的多轮会话，而 Sonnet 完全可以胜任这些任务。




• 上下文窗口膨胀：大型 MCP 负载（例如 40KB 的响应）持续保留在上下文中，在后续轮次中产生重复计费。




• 缓存过期效率低下：在长时间中断后恢复会话，提示词缓存已过期，需要重新完整构建前缀，产生全额开销。




• 提示词初始化开销：在用户输入之前，预加载 10 万 token 的系统指令和工具定义。

图 12：会话级成本仪表盘，识别浪费模式，给出可节省成本预估。

未来展望

当前正在进行的举措包括：

• 扩大托管智能体集群规模：对于每一个新智能体，遵循一致的路线图：建立目标结果指标、组装评估基准测试、选出帕累托最优模型。这种系统化的方法旨在将 SDLC 的每个阶段提升到工厂成熟度模型的更高层级。




• 动态模型路由：扩展基准测试覆盖范围，涵盖更多编程语言、代码库和智能体模态。有效的模型路由严重依赖于全面评估，因为模型能力差异很大。




• 深化上下文图谱集成：让更多自主智能体能够调用图谱查询能力。




• 将会话分析演进为实时开发者指引：将反模式检测从周期性批量分析改为持续链路监控，直接向工程师推送个性化、实时的效率优化建议。




• 持续技能改进：开发一种自动化方式，记录智能体技能执行中的小问题，并基于采集到的运行追踪日志自动生成能力更新。

结论

管理和遏制不断增长的 AI 编码开销也是一项可解决的工程挑战。没有单纯依靠压低单价、降级工具能力，而是消除各类无价值的 token 浪费，最终实现使用规模扩大 7 倍，同时各项指标下的单位成本下降，并且保持甚至提升了输出质量。

核心战略从交互式开发者工作流转向完全托管的智能体。将 SDLC 工作负载迁移到托管环境中可以完全控制模型路由、Harness 执行和运营开销。对一批专用托管智能体进行优化，每个智能体都配备专用评估基准和帕累托最优模型，本质上比优化数千名工程师各自的终端会话更具成本效益和可扩展性。