摘要：Uber 技术长文显示全公司 70% 代码 PR 已由 AI Agent 接管，半年调用量增长近 10 倍，总 AI 账单未涨，单次会话成本下降 52%，规模化与成本优化同时达成。
这组数字里最反直觉的是“调用量涨 10 倍、账单没涨”。它值得单独拆开。
先列清事实：Uber 全公司 70% 的代码 PR 已由 AI Agent 接管；AI 调用量半年增长近 10 倍；总 AI 账单未上涨；单次会话成本下降 52%。
调用量 10 倍、账单不变，意味着单位调用成本降到了原来的十分之一左右。但报告给出的单次会话成本降幅是 52%，两个数字差得很远——说明成本下降不是单一原因造成的，而是多个杠杆叠加。
能想到的杠杆大致有这些：
模型分级路由。简单任务（格式修正、依赖升级、样板代码）用便宜的小模型，复杂任务（架构改动、疑难 bug）才上旗舰模型。这是成本优化里性价比最高的一招，因为在真实工程任务分布里，简单任务占绝对多数。
缓存复用。同一个代码库里，大量上下文是重复的——项目结构、编码规范、常用模块的接口定义。prompt caching 对这类场景的成本削减非常显著。
上下文瘦身。这是最考验工程功力的一块。把整个仓库塞进上下文最简单，也最贵。先用检索定位相关文件、只喂必要片段，token 消耗可以差一个量级。
模型价格本身在降。过去半年主流模型的单价普遍下行，加上开源模型可选项变多，这部分是外部红利。
70% 这个比例怎么理解，也需要一点克制。PR 数量不等于代码价值。依赖升级、lint 修复、测试补充、文档同步、小范围重构——这些任务数量占比高但技术难度低，正是 Agent 最擅长的部分。核心业务逻辑的设计与实现大概仍在人手里。所以准确的说法是：Agent 接管了大部分 PR 数量，但不一定是大部分工程复杂度。
即便如此，这个数据的意义依然很大。它证明了两件事：一是 AI 编码 Agent 在超大规模代码库上是可以工程化落地的，不只是 Demo；二是规模化和成本可控可以同时达成，不必二选一。
对准备推进类似落地的团队，我的建议是从任务分类开始，而不是从工具选型开始。先把你们的 PR 按“重复度高低 × 风险高低”分四象限，高重复低风险的那一格是第一批交给 Agent 的对象。同时把成本监控做在前面——按任务类型、按模型、按团队打标签统计消耗。没有这套观测能力，账单失控几乎是必然的。
再补一个横向对照，能帮你判断自己团队的位置。
本周还有一条相关消息：Warp 团队在 Claude 平台上做了“自我改进智能体”的实践，用基础技能加改进技能两个文件型技能，把人类反馈固化成对智能体的持续优化，已经覆盖数百名贡献者与数千次代码审查。Uber 展示的是规模化的成本控制，Warp 展示的是质量的持续爬升机制——这两件事其实是一个问题的两面。
规模化的难点在于成本会随调用量线性甚至超线性增长；质量提升的难点在于人类反馈是稀缺的、不连续的。两边的共同解法都指向同一个东西：把反馈和经验沉淀成可复用的资产。Uber 那 52% 的单次会话成本下降里，很可能有相当一部分来自“把重复解释的上下文固化成模板或技能”，而不是纯粹的技术优化。
给正在推进的团队一个阶段划分参考。第一阶段先解决“能不能跑通”，选高重复低风险的任务，接受成本偏高。第二阶段解决“值不值”，把成本监控和效果度量建起来，开始做模型分级和上下文优化。第三阶段解决“能不能自己变好”，建立反馈回流机制，让每次人工修正都变成下次的输入。多数团队卡在第一到第二阶段之间，原因通常不是技术，是没人负责看账单和效果数据。
