大家好，我是孟健。
Uber 8 月 27 日公开了一组数字：70% 以上的 PR 归因于本地或云端 Agent，工程师自建了 3,600+ agent skills，每天 30,000+ 次 skill 执行，周活跃用户增长 7 倍，周 Agent 请求增长 9.4 倍------而总 AI 支出从 4 月起趋于稳定。用量涨了 7 倍，账单却没涨，这个反差背后，是一套完整公开的成本方法论。
这不是新闻转述，这是一篇拆架构的文章。Uber 把"省钱"做成了一个工程学科，把成本方程、优化杠杆、每个开关的具体节省幅度都写进了官方博客。读这篇博客时，我几乎每一步都能对上自己的做站流水线------我的 Kanban 派单 → 多 Agent 接力做站/QA/上线，就是一个微型 software factory。
01 发生了什么
时间线拉回 2026 年 3 月，Pragmatic Engineer 报道的数据是：92% 工程师每月用 Agent，IDE 里 65%-72% 代码由 AI 生成，11% 的 PR 由 Agent 零人工开出。5 个月后的 8 月 27 日，这个数字跳到了 70%+。
增长曲线和成本曲线剪刀差开了，这才是工程问题。Uber 在 AI Engineer 大会分享、port.io 整理的数字显示：12 个月跑 250 次自动迁移、重写 900 万行代码，每工程师代码产出一年翻倍。这种规模下，成本不爆炸是因为有一套方程在管着。
还有一件事：Uber 官方提到越来越多的 Agent 会话已经不由人发起了------托管 Agent 自己在后台跑：代码审查、自愈 CI 失败、带视觉验证的端到端 PR、on-call 告警分类、调试新进来的 bug。它和你自己开个窗口聊天的区别是，托管 Agent 盯着事件流，有触发条件就启动、干完就撤，全程无人值守。这种 agent 占比越高，成本管控的压力就越大------因为你不在场，它跑了多少轮、烧了多少 token，事后才看得到。
02 账单公式
Uber 把总 AI 支出拆成六项相乘：
总支出 = 用户数 × 每用户会话数 × 每会话轮次 × 每轮请求数 × 每请求 token 数 × token 单价
前三项是规模（SCALE），后三项是效率（EFFICIENCY）和单价（UNIT COST）。规模要涨，效率要省，单价要砍。
六个因子各有涨价机理：用户数 是团队扩张自然涨；每用户会话数 是用得爽了就多开几个任务；每会话轮次 是 Agent 找不到信息时会反复多搜几轮；每轮请求数 是子 Agent 一开多个并行跑；每请求 token 数 是上下文没压缩、MCP schema 全加载、代码库越读越多；token 单价取决于你选哪个模型。
固定模型口径（2-7 月），Uber 每 1,000 次请求成本较峰值降近 34%，每会话成本较 6 月峰值降 52%。这不是靠模型降价，是靠后三项的优化杠杆。
补一条缓存的钱感：prompt cache 读取按标准输入价的 0.1 倍计费，所以保住缓存前缀就是直接省 90% 输入成本。缓存失效意味着全价重建前缀，5 分钟 TTL 下工程师喝个咖啡回来，上下文就凉了。
03 六个省钱开关
开关 1：模型 Pareto 路由 + 子 Agent 降档
Uber 按"每个任务的成本/质量/可靠性"选 Pareto 最优模型。uReview（代码审查 Agent）用带已知 bug 的真实 PR 建 benchmark，评 precision/recall/F1 + 每次审查成本，挑出性价比最高的模型。
Pareto 最优的意思是：不存在又便宜又强的单一模型，只有某个任务上最划算的组合。uReview 换模型后，F1 分数上升、单次审查成本大幅下降。
子 Agent 默认用更弱更便宜的模型，主 Agent 只做任务拆解和验收------Uber 原话：这是"影响最大的单一杠杆"。
开关 2：400K 自动压缩 + Medium 推理强度
即使用 1M 上下文模型，默认配置也是 400K token 自动压缩。推理强度默认 Medium------推理 token 按输入数倍计费，大多数任务不需要开到 High。
压缩省在哪 ：每轮对话都要重发全量历史上下文，压缩直接砍每轮体积。Medium 推理省在哪：推理 token 单价是输入 token 的数倍，High 推理强度会让输出成本飙升，Medium 够用就别开 High。
开关 3：缓存 TTL 拉长
交互会话的 prompt 缓存从 5 分钟 TTL 改 1 小时。原因：工程师常离开超过 5 分钟，前缀缓存失效后全价重建上下文。子 Agent 保持 5 分钟就够，因为它跑完就扔。
缓存失效 = 全价重建前缀，这笔钱直接白烧。
开关 4：MCP 减 schema
Uber 部署了 1,000+ 个 MCP server，统一走一个网关。100+ 工具直接加载会带来约 50K-70K token 的 schema 开销，改用 CLI 解析 + 工具搜索按需加载。
schema 开销为什么每轮都重复计费：因为它在系统提示里，每轮对话都要重发一遍。CLI 解析后，只有工具真正被调用时才动态加载 schema，不调用就不进上下文。
开关 5：code-mode 批处理
把多次工具调用打包成一个脚本执行。Uber 实测：在同一 Claude Code 会话里跑 5 条 SQL，每条省 55%-71%，宽表查询省约 100%；批处理场景省 90%+。Uber 为此预置了 25+ 个 code-mode skill。
code-mode 为什么省：轮询循环在子进程里跑，中间结果不进模型上下文，只有摘要回来。批量场景省 90%+ 是因为原本 N 次模型轮次变成一次脚本执行。
开关 6：上下文工程 / Context Graph
Uber 的 AI Context Graph：2,400 万节点、8,000 万边、86 种节点类型、117 种边类型，接入 30+ 内部系统。同一问题对比：接了图的 Agent 38 秒答对（30/30 分）；没接图的跑了 20 分 09 秒、2 个子 Agent、3 次报错、答错（19/30 分）。
Uber 仪表盘可见的 4 个典型反模式，每个都是白烧钱：
- 简单会话用 Opus，其实 Sonnet 就够 --- 模型降一档，账单立刻不一样。
- MCP 大 payload 留在上下文里反复计费 --- 每轮重发几万 token 的 JSON，其实只需要摘要。
- 长时间中断后缓存过期，全价重建 --- 缓存 TTL 太短，喝杯咖啡回来前缀凉了。
- 用户还没说话就预加载 10 万 token 系统指令 --- 加载了一堆 MCP schema，结果一个工具都没调用。
省的是"零价值的浪费 token"，不是靠降价或降配。
04 我的流水线对上了几招
我自己做站流水线用的 Codex（ 200/月）+ClaudeCode（20/月），也在跑类似的优化：
- 模型分级：重活好模型（写 PRD、复杂代码重构），轻活便宜模型（批量改文件、QA 跑测试）。和 Uber 的子 Agent 默认弱模型是同一思路。具体场景：改错别字、批量重命名变量这类活，直接扔给便宜模型；涉及架构判断、性能优化的才上贵模型。
- 多模型网关兜底：Pareto 路由的微型版本，每个 Agent 按成本/质量选模型。具体场景：某个模型限额打满了，任务自动切到另一个模型继续跑，不停工。
- 每晚复盘：我每晚会看 Agent 跑得好不好、哪里浪费 token 了。和 Uber 的 16 种反模式仪表盘是同一思路。具体场景：看哪次 Agent 跑了半小时其实在绕路找不到文件，第二天把路径写进配置或者换个搜索方式。
什么先别抄
Context Graph 是 2,400 万节点级别的重器，小团队没有 Uber 的代码库规模，抄了也是空转。先抄的是可见性三件套：成本计数、花费提醒、浪费标记。
我的判断：大多数团队学 Uber 不用先学 Context Graph，先抄三样------给子 Agent 降模型、给 MCP 减 schema、给会话上成本计数器。这三样一周就能落地。
Uber 的状态栏实时成本计数 + 花费档位 + Slack 在 50%/80%/100% 时提醒，这一套可见性系统比 Context Graph 更容易抄。Context Graph 是 Uber 规模才需要的东西，但成本计数器是每个团队今天就能上的。
05 结尾
Uber 官方博客的结论方向是：从"交互式会话"转向"托管 Agent"，是成本可控的关键。我的理解更直接：与其问 AI 编程烧不烧钱，不如问你的流程浪费了多少零价值 token。
Uber 把省 token 做成了工程问题。你的流程里，昨天有多少 token 是白烧的？
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏