Uber 的 Agent 周请求量从 2026 年 2 月到 8 月中增长了 9.4 倍，周活跃用户增长 7 倍，但总体 AI 支出从 4 月起相对稳定。重点在于 Uber 对模型选择、上下文、MCP 工具调用、执行路径和成本反馈的逐项改造，而非某次模型降价。它更像一套可以持续运行的成本工程体系。
2026 年 8 月 27 日，Uber Engineering 发布了 Running a Software Factory Efficiently at Uber Scale，集中介绍这套成本控制方法。
这篇复盘有一个不太轻松的背景。Axios 回顾称，Uber CTO 曾在 4 月透露，公司已经提前耗尽原定的 2026 年 AI 预算。到了 8 月，Uber 公布的数据变成了：
- Agent 产品的周活跃用户较 2 月增长 7 倍；
- 每周 Agent 请求量增长 9.4 倍；
- 总体 AI 支出自 4 月起相对稳定；
- 固定同一个模型比较时，每 1,000 次请求的成本较峰值下降近 34%；
- 单次会话成本较 6 月峰值下降 52%。
同一时期，Uber 内部已经积累 3,600 多个 Agent Skill，每天执行超过 30,000 次 Skill，超过 70% 的 Pull Request 被归因于本地或云端 Agent。
这里的“归因于 Agent”不等于 70% 的代码在无人参与的情况下直接进入生产。Uber 对 Managed Agent 的描述里仍然保留人工 Review 和异常升级。这个口径更接近“Agent 参与了这些变更”，而不是“Agent 独立拥有这些变更”。
先把 Agent 成本拆开
Uber 用六个相乘的变量描述 Agent 总支出：
总支出
= 用户数
× 每个用户的会话数
× 每次会话的轮次
× 每轮模型请求数
× 每次请求的 Token 数
× 每 Token 价格
这个公式比单看 Token 单价更接近 Agent 的真实成本。
普通对话通常是一轮输入对应一次模型调用。Agent 还会规划任务、搜索代码、启动子 Agent、调用工具、轮询任务、处理失败，并在后续请求中继续携带已有上下文。用户只发出一个任务，后台可能已经执行了许多轮。
Uber 希望前两个变量继续增长，因为它们代表采用率和使用深度。优化集中在 Agent 为完成任务额外产生的轮次、请求和上下文，以及每类任务使用的模型价格。
| 成本变量 | 常见放大因素 | Uber 使用的控制手段 |
|---|---|---|
| 每次会话的轮次 | 搜索路径错误、失败重试 | Context Graph、Skill、Managed Agent |
| 每轮模型请求数 | 轮询、聊天式工具调用 | Code Mode、脚本批处理 |
| 每次请求的 Token 数 | 完整历史、工具 Schema、原始结果 | 压缩、缓存、Tool Search、CLI |
| 每 Token 价格 | 所有任务使用同一档模型 | Benchmark 驱动的模型选择 |
这些变量彼此相乘，执行链路上的几项小改动叠加以后，也可能明显改变总成本。
从 Cost per Token 转向 Cost per Outcome
Uber 的指标分成四层。
| 层级 | 主要指标 |
|---|---|
| 整体组合 | 总成本、用户数、每个工具或 Agent 的成本占比 |
| 单个工具 | 每用户成本、每 1,000 次请求成本、每会话成本、每活跃小时成本、缓存命中率 |
| 模型 | 请求占比、费用占比、每 1,000 次请求成本、每百万 Token 成本 |
| Managed Agent | 每个合并 PR、Review、告警或清理任务的成本，以及 Revert Rate、F1、MTTR |
Uber 还会把成本变化拆成用户增长、使用频率、输入 Token 和输出 Token，避免用一句“最近大家用得更多”解释所有变化。
判断模型性价比时，成功结果比 Token 更适合作为分母。一个便宜模型如果频繁失败并触发重试，每个成功任务的总成本未必更低；价格更高的模型如果能稳定完成高风险工作，也可能更划算。
因此，Uber 在选择模型时同时看完成任务的成本、输出质量和可靠性，而不是只比公开价目表。
用真实任务 Benchmark 选择模型
Uber 为 Managed Agent 使用同一套模型选择流程：
- 从 Agent 的真实工作中构建 Benchmark；
- 通过统一 Harness 在不同模型上运行同一批任务；
- 比较质量、可靠性和每个完成任务的成本；
- 选择位于 Pareto Frontier 上的配置，并持续复测。
代码 Review Agent uReview 的评测集来自带有已知缺陷的真实 PR，并按难度分级。指标包含 Precision、Recall、F1、每次 Review 的成本、延迟、超时率和噪声。Uber 表示，切换模型后 F1 得到提升，同时每个 PR 的 Review 成本显著下降。
交互式 Agent 里，子 Agent 的默认模型又是影响费用最大的配置之一。主 Agent 负责理解目标、拆解任务和检查结果，子 Agent 通常执行输入明确、范围较小的工作。Uber 因此默认让子 Agent 使用能力较弱但成本更低的模型，同时保留人工覆盖选项。
需要区分的是，Uber 当前已经在做按工作负载选择模型，但更细粒度的动态模型路由仍被列在后续计划中。它不是文章所描述的既成系统。
大上下文不等于应该把窗口填满
每次 Agent 请求都会重新携带对话历史、项目上下文和工具结果。上下文越大，后续每一轮的重复成本越高。
Uber 给交互式 Harness 设置了两个默认值：
- 即使模型支持 100 万 Token，也在 40 万 Token 时触发自动压缩；
- 默认使用 Medium Reasoning Effort，需要时再提高。
这两个默认值给会话留出了缓冲区。100 万 Token 代表可用上限，不等于正常工作区间。
对于自己的 Agent Runtime，我会至少监控会话轮次、上下文大小、工具调用、子 Agent 数量、重试、执行时间和单任务费用。触发阈值以后，还要决定是压缩、降级、暂停还是转人工；直接终止只会把 Token 浪费变成失败任务。
Prompt Cache 的 TTL 要跟着会话节奏走
Agent 会重复发送系统提示、项目说明、历史对话和工具定义。Prompt Cache 可以降低重复前缀的读取费用，但缓存写入存在溢价，TTL 不能只照搬默认值。
Uber 观察到，工程师经常离开终端超过 5 分钟，回来继续工作时缓存已经失效，需要重新构建完整前缀。于是交互式会话从 5 分钟 TTL 调整到 1 小时；生命周期较短的子 Agent 仍保留 5 分钟。
Uber 原文还列出了当时供应商的缓存价格差异：缓存命中读取约为标准输入价格的 0.1 倍，5 分钟写入约为 1.25 倍，1 小时写入约为 2 倍。这些数字会随供应商变化，可复用的是决策方法：先看相邻轮次的间隔分布，再决定 TTL。
长时间的人机交互通常适合更长缓存，短任务和批处理则未必值得支付更高的长期写入成本。
MCP 的成本不只发生在工具执行时
Uber 的统一 MCP Gateway 接入了 1,000 多个内部和第三方 MCP Server，用于集中处理认证和策略。
它们最初遇到的问题，是直接集成路径会把大量工具 Schema 预加载到会话。Uber 测得，安装 100 多个工具会让初始 Prompt 增加约 50K 到 70K Token；这些定义还会随着上下文在后续轮次中重复发送，即使其中大多数工具从未被调用。
Uber 后来采用了两条路径：
- CLI 动态解析：模型调用统一 CLI，CLI 在执行时通过 Gateway 找到并调用工具，MCP Schema 不常驻模型上下文；
- Tool Search：先搜索工具目录，只加载当前任务需要的定义。
这里需要把“能力可用”和“Schema 常驻”分开。MCP 继续负责连接和调用，Harness、CLI 或 Gateway 决定模型此刻需要看到哪些工具。
这也和 Skills Over MCP 里的渐进式加载思路相呼应：模型先看到少量元数据，任务匹配后再加载完整说明和资源。
把确定性循环移出模型上下文
提交查询、获取任务 ID、轮询状态、下载结果和过滤数据，这类步骤不需要模型每次重新思考。如果每一步都占用一个模型回合，轮询响应会持续进入上下文，后面的请求还会反复携带它们。
Uber 使用 Code Mode，让模型生成脚本，并由子进程完成轮询、批处理和结果裁剪，最后只把摘要返回模型。
Uber 对五条相同 SQL 查询分别测试了传统工具调用和 Code Mode：
| 查询 | 普通工具调用 | Code Mode | 节省 |
|---|---|---|---|
SELECT 1，1 行 | 903 Token | 402 Token | 55% |
COUNT(*)，1 行 | 954 Token | 403 Token | 58% |
GROUP BY LIMIT 20 | 1,600 Token | 457 Token | 71% |
SHOW COLUMNS，175 行 | 2,200 Token | 900 Token | 59% |
| 宽表查询，50 行 | 1,431,594 Token | 900 Token | 接近 100% |
前几条查询的结果很小，节省仍然超过 50%。这说明收益不只是少传大结果，还来自移除 Schema 初始化、多轮轮询和重复的步骤推理。批量工作流里，Uber 测得节省可以超过 90%。
边界并不复杂：分页、轮询、重试、格式转换和聚合适合普通代码；理解目标、判断异常和评价结果仍交给模型。
好的上下文也会降低成本
在大型代码库里，Agent 的大量时间花在寻找信息，而不是生成代码。服务由谁负责、数据表在哪里使用、故障以前怎样处理，这些问题如果没有可靠入口，Agent 就会搜索更多文件、启动更多子 Agent，并反复发送越来越大的上下文。
Uber 的 AI Context Graph 包含约 2,400 万个节点和 8,000 万条边，整合了 30 多个内部系统的数据，包括服务、团队、事故、PR、架构文档、部署和数据集。
Uber 用同一个模型测试同一个问题：
- 有 Context Graph 时，38 秒得到正确答案；
- 没有 Graph 时，运行 20 分钟，启动两个子 Agent、遇到三次错误，最后给出错误结论。
普通团队没有必要从数千万节点的知识图谱起步。先把仓库索引、服务依赖、代码所有者、数据表调用方、Runbook、架构决策和验证命令整理成 Agent 可查询的入口，就可能减少大量无效搜索。
让费用出现在工程师眼前
Uber 把实时成本计数器放进终端状态栏，显示当前 Harness 和用户全部 Harness 的累计费用，并在达到预期费用的 50%、80% 和 100% 时提醒。交互式 Harness 共用一个费用层级，Managed Agent 使用单独层级；提高额度需要经理批准，但审批和配置传播保持轻量。
月末账单只能告诉团队花了多少钱，无法解释费用发生在哪一步。Uber 的 Session Analysis Dashboard 会直接分析本地和远程会话 Trace，识别 16 类成本反模式，并给出费用影响和对应修复建议，例如：
- 简单任务使用了过强模型；
- MCP 返回的大块数据长期留在上下文；
- 会话恢复时 Prompt Cache 已经过期；
- 用户输入前已经预加载大量系统指令和工具定义。
这样，成本治理就进入了日常开发流程，不再只出现在财务报表里。
Managed Agent 更容易计算单位成本
文章结尾，Uber 把更多软件开发任务迁移到 Managed Agent 作为后续方向。
开放式终端会话很灵活，但平台很难控制任务输入、上下文规模、模型选择、执行轮次和验证方式。Managed Agent 可以提前定义目标、工具、模型、完成条件、质量指标和人工升级路径，因此也更容易计算每个成功结果的成本。
Uber 维护的是一组拥有独立 Benchmark 和模型策略的专用 Agent，而不是一个包办所有任务的 Agent。对平台团队来说，优化这些稳定工作流，比逐个纠正数千名工程师的终端使用习惯更可控。
如果把这套方法缩小到普通团队，我会按下面的顺序实施：
- 先记录 Trace：任务类型、模型、输入输出 Token、缓存、工具调用、重试、延迟、费用和结果；
- 再加预算护栏：限制轮次、上下文、并发、重试、时间和单任务费用；
- 然后治理执行路径：上下文压缩、工具按需加载、结果摘要和脚本批处理；
- 最后用真实任务 Benchmark 做模型选择，并统计每个成功任务的成本和质量。
顺序很重要。没有 Trace，很难知道该优化什么；没有结果指标，模型路由也容易退化成单纯比价。
这套方法的价值
Uber 的数据来自自己的代码库、团队规模和供应商组合，不能直接当成其他公司的节省承诺。它更有价值的地方，是把 Agent 成本从一张 API 账单拆成可以测量的运行时问题。
用户和任务可以继续增长，需要减少的是错误搜索、重复上下文、闲置工具 Schema、模型参与的轮询、无效重试，以及与任务难度不匹配的模型调用。
当每笔费用能够回到具体会话，每个会话能够回到具体结果，成本治理才有了可执行的抓手。模型能力只是 Agent 规模化的一个条件，Runtime 还要能解释一次任务为什么花了这些钱。