Uber 把七成代码 PR 交给 AI，AI 账单却零增长是怎么做到的

8 月 27 日，Uber 官方博客发了一篇长文，讲他们怎么控制 AI 编程成本。据报道，Uber 目前超过 70% 的代码 PR 已经由本地或云端 AI Agent 产生，工程师团队攒了 3600 多个 Agent 技能，每天执行超 3 万次。更夸张的是数据曲线：2026 年 2 月到 8 月，公司里 AI Agent 的周活跃用户涨了 7 倍，周请求量涨了 9.4 倍，但总 AI 支出从 4 月开始就基本稳住了。换算到固定模型口径，每 1000 次请求的成本比峰值降了约 34%，单次会话成本比 6 月峰值降了 52%。

用量涨近 10 倍、账单不动，这才是这篇文章真正值得看的地方。

技术本质：AI 编程的账本被拆开了

大多数人用 AI 编程，只看"写没写出来"。Uber 的思路是把成本拆成一个乘式：总成本 ≈ 采用人数 × 人均请求数 × 每请求 token 数 × 每 token 单价 × 轮次数。前两项是增长项，他们不想压；真正动手的是后三项——让每个请求更省、每个 token 更便宜、每次对话少绕弯。

几个具体的工程手段，都是能直接抄作业的：

• 模型路由：不为所有任务都用最强模型。给每个 Agent 建一个基于真实工作的 benchmark，跑分之后选性价比最优（他们叫 Pareto 最优）的模型，子任务默认丢给便宜模型，主模型只做拆解和把关。
• • 控制上下文：即使是 1M 上下文窗口的模型，Uber 也默认 400K token 触发自动压缩；推理强度默认 Medium。理由很实在：上下文越长，缓存越容易失效，重复计费越多。
• • Prompt 缓存调优：他们发现工程师经常把会话晾着超过 5 分钟，导致默认 5 分钟的缓存 TTL 频繁失效、每次都要全价重建前缀，于是把交互会话的缓存 TTL 改成 1 小时，子 Agent 保持 5 分钟。
• • 给上下文减负：MCP 工具一次性把上百个工具 schema 塞进上下文，一个会话开场就背 5 万到 7 万 token 的包袱。Uber 的做法是把 MCP 工具全部 CLI 化、按需加载，要哪个工具再现场解析。
• • Code-mode 批量执行：让模型用脚本批量做事，而不是一轮轮"提问—等待—回复"。他们实测同一批 SQL 查询，走脚本路径比走工具调用路径省 55%~71% 的 token，宽表查询省得更多。
• • 上下文图谱：用 2400 万个节点、8000 万条边的知识图谱给 Agent 指路，让它在回答前先定位到正确的表、正确的服务，而不是瞎翻代码。文中举例：有图谱的 Agent 38 秒答完问题，没图谱的翻代码翻了 20 分钟还答错了。
    说白了，Uber 做的不是"用 Agent 写代码"，而是把代码生产重新设计了一遍：写代码只是其中一环，模型选型、上下文管理、缓存策略、工具接入方式全部变成可优化的工程对象。

对普通开发者的意义

这事对打工人来说，信号挺直接。

第一，AI 编程的下一个话题不是"能不能写"，而是"烧不烧得起"。Uber 这种体量都要专门发文讲怎么省 token，说明 AI 账单已经成了正经的工程预算。公司迟早会在 Agent 使用上加预算、加监控，这不是科幻，是已经在发生的事。

第二，会省 token 正在变成一种新技能。同样的活，有人一把梭把整个项目塞进对话、让最贵的模型跑最简单的需求，有人拆任务、选模型、控制上下文——后者的账单可能是前者的零头。别小看这个差距，绩效季看的就是这个。

第三，Agent 写代码不代表人没事干。Uber 的数据里，70% 的 PR 来自 Agent，但 review、返工、CI 修复、兜底还是人来做。未来普通开发者的工作重心大概率会从"写"往"审、拆、管"移动。

怎么用在自己的项目里

个人用 AI 编程，不用搞那么大的工程体系，但几个原则可以直接套：

• 简单任务用便宜模型。改个文案、写个正则，别让最强模型出场；只有复杂重构、跨文件排查才上旗舰。
• • 控制喂进去的上下文。别把整个仓库、整段日志无脑贴进对话，先检索再贴，或者明确告诉模型"只关注这几段"。
• • 利用缓存和批处理。长会话别频繁中断重启；能用脚本循环批量改的，别一轮轮让模型来。
• • 自己建一个成本敏感的习惯。给常用场景记一下大概 token 消耗，做到心里有数。
    一个朴素但真实的成本估算脚本，可以帮你感受"每轮重发上下文"有多烧钱：

defestimate_cost(context_tokens,new_tokens,turns,price_in,price_out):"""简化估算：每轮都重发全部历史上下文时的总成本（元）。"""total_in=context_tokens+new_tokens# 第一轮for_inrange(turns-1):total_in+=context_tokens+new_tokens# 之后每轮重发全部历史cost=total_in*price_in/1_000_000+new_tokens*turns*price_out/1_000_000returncost# 单价示意：输入 10 元/百万 token，输出 30 元/百万 tokenprint(estimate_cost(50_000,2_000,10,10,30))# 10 轮对话print(estimate_cost(50_000,2_000,30,10,30))# 30 轮对话，账单接近 3 倍

跑一下就能看出来：上下文越长、轮次越多，输入 token 的复利越吓人——Uber 那些"省 token"的招，本质都是在砍这个复利。

顺便说一句，Uber 这篇文章的完整方法论里还提到：他们不靠降级工具、不靠限制用量，而是把没价值的 token 消耗抹掉。这个思路放到个人身上同样成立：AI 工具不是越贵越好，是花出去的每个 token 都要有产出。你觉得公司层面管 AI 账单，是会放开用还是卡预算？评论区聊聊。