Uber 用 Agent 接管 70% 代码 PR，AI 账单为什么零增长

很多团队还在为 AI 编程账单肉疼。Uber 在 2026 年 8 月 30 日发布的技术长文给出了一组反直觉数字：全公司 70% 的代码合并请求（PR）由智能体接管，调用量半年涨了近 10 倍，总 AI 账单一分没涨，单次会话成本反而降了 52%。

先把账摆出来

Uber 工程师每天在跑 3 万多次流水线任务：审代码、修挂掉的 CI、分诊报警，全部由托管智能体自动完成，人退到“抽查质检”的位置。真正值得注意的不是自动化程度，而是账本：用量翻了约十倍，成本没有同步上涨。这直接推翻了一个常见假设——AI 用得越多越烧钱。Uber 的结论是：用量涨不可怕，浪费涨才可怕。关于“用量与账单”的关系，我们此前在 AIcoding 商业化悖论 里分析过 92% 工程师用 AI 后，Uber 为何反而开始限额。

Uber 压住 AI 账单的 5 个动作

1. 贵的模型做规划，便宜的模型搬砖：任务拆解交给旗舰模型，具体子任务默认切到轻量模型。这是整个体系里杠杆最高的开关。
2. 上下文缓存从 5 分钟拉长到 1 小时：工程师离开工位开个会回来，缓存还在，按原价一折续用；超过 40 万 token 的历史强制做摘要压缩，绝不整本无限复印。
3. 工具说明不预装：一千多个内部 MCP 工具统一走网关，模型要用时先搜索再按需挂载，而不是开局就灌入 7 万 token 的工具定义。
4. Code-mode 砍掉话痨轮询：跑 SQL 和批处理时让模型自己写脚本去执行，只交回最终结果，避免一问一答的无效往返，单项开销直接省 90%。
5. 用知识图谱导航代替盲搜：给它一张覆盖全公司服务和事故的活地图，以前翻代码盲搜 20 分钟还报错，现在 38 秒定位。

这笔账，中小团队能抄什么、不能抄什么

Uber 的做法有很强的规模前提：每天 3 万次流水线、2400 万节点知识图谱，中小团队直接照抄，会先被自己的基建拖垮。但成本逻辑完全可迁移：

• 贵模型规划、便宜模型执行，第一天就能落地；
• 缓存时长是配置项，调一调就有收益；
• 工具网关可以先从 10 个工具做起；
• 知识图谱最重，可以先从服务清单加事故文档起步。

模型持续降价让“便宜执行层”变得更可行，我们在 388 个 PR 背后的成本拐点 里拆过这笔账。反面教训也来自我们自己：蓝曜炬辉在客户项目里见过最典型的浪费，是把整个代码库一次性塞给模型、同一段历史反复重新计费。上文提到的摘要压缩和一小时缓存，本质都是在给上下文生命周期设红线。不设红线的团队，账单涨得比代码产出快。

常见问题

智能体接管 70% 的代码 PR，质量怎么保证？

Uber 的做法是人退到抽查位，智能体负责流水线执行，人在关键节点做质检。这个比例不是拍脑袋定的，而是跟着成本和质量数据调出来的——这也是他们敢把比例推到 70% 的前提。要让智能体真正接住 PR，工程护栏比模型本身更重要，我们之前写过 用 AGENTS.md 管住智能体生成的 PR，也复盘过 AI 提交 1721 行 diff 后审查者直接关掉 PR 的案例。

普通团队怎么控制 AI 账单？

先从三个配置入手：缓存时长调长、任务按贵贱分流、工具按需挂载。Uber 的 5 个动作里大部分不需要改架构，先动配置就能看到差距。

开源模型能当轻量执行层吗？

可以。8 月 29 日智谱开源的 GLM-5.3 权重在综合智能指数拿到 60 分，与闭源旗舰同级，并列开源模型第一；权重可本地部署，能进一步压低推理成本。

参考来源

本文事实来自 Uber Engineering 8 月 30 日技术长文、AIHOT 导读，开源模型数据来自模型发布页：

• Uber Engineering 技术长文（X 原文）
• AIHOT：Uber 用 Agent 接管 70% 代码 PR，AI 账单零增长
• GLM-5.3 权重（Hugging Face）

如果你也在评估企业 AI 编程的落地成本和工程护栏，欢迎把需求清单发给我们。蓝曜炬辉（www.lanyaoai.com）按项目做一次成本拆解，先把无效 token 的账算清楚。