今年 4 月 14 日，Uber 首席技术官 Praveen Neppalli Naga 接受 The Information 采访，说了这么一句：
我又得回去重画图纸了，因为我原以为要用的那笔预算，已经被烧穿了。
同一篇报道里写着，Uber 一整年的 AI 预算，进入 2026 年才几个月就已经用满，主要推手是 Anthropic 的 Claude Code。他没有透露具体金额。
8 月 27 日，Uber 工程团队发布了一篇长文，标题是《在 Uber 的规模上高效运转软件工厂》，讲的是这笔钱都花在哪儿、又是怎么一项一项压下去的。
先把时间摆清楚
4 月 CTO 那句话，是目前唯一的原始来源。福布斯 5 月 17 日的报道链回了 The Information，属于转述。5 月，Uber 首席运营官 Andrew Macdonald 在一档播客里被问到投入产出，他的回答是：那条线现在还画不出来。
预算是怎么烧穿的，The Information 当时也给了线索：Uber 鼓励员工「尽可能多用」AI，还把各人的用量排进了内部排行榜。
6 月 2 日，彭博独家报道 Uber 开始设限：每个 AI 编码工具，每人每月 1500 美元。
8 月这篇长文里，前面这几件事一件都没提。 而且它自己给出的曲线显示，成本优化至少从 3 月就已经在做了，比 4 月那次采访还早。所以这里只有时间先后，没有材料能证明后面这篇是在回应前面那几件事。
「70% 的 PR 来自 agent」，这句话的单位是什么
长文的引言里写着：超过 70% 的 PR 归因于本地或云端的 agent。
PR 是 pull request，程序员改完代码后提交的一次合并请求，是团队协作里最小的一个交付单位。
这个数字这几天传得很广。传播量最高的那条中文帖把它写成了「全公司 70% 的代码 PR 全由 Agent 接管」，英文和韩文的高赞转述里，动词也变成了「来自」和「生成」。
同一家公司在半年里给过六个比例，它们量的不是同一件事。
年初的时候，CTO 说这个数「还不到百分之一」。3 月 10 日，Pragmatic Engineer 写的是「11% 的 PR 由 agent 发起」；这家媒体次日的更新版里还有另一个数：编辑器内由 AI 生成的代码占 65% 到 72%。
4 月 14 日，还是那位 CTO，说的是「约 11% 的后端线上代码改动由 agent 写成」。5 月 6 日的一季度财报电话会上，CEO Dara Khosrowshahi 的说法又变了，他说的是「约 10% 的提交代码由自主 agent 完成」。
到 8 月，数字跳到 70% 以上，动词也换了。3 月用的是「发起」，4 月用的是「写成」，8 月用的是「归因于」。
Uber 没有公布这个「归因」的规则。 一个 PR 要满足什么条件才算归到 agent 头上，agent 参与到什么程度算数，自主性有没有门槛，这些一个字都没写。
规则不公布，这个数就没法往两边推。它既不能读成「agent 独立提交了七成 PR」，也不能反过来断定那七成全是人手动敲出来的。能确定的只有一件事：70% 和 4 月的 11%、5 月的 10%，量的不是同一个东西。
把一次会话拆成六项相乘
Uber 把总支出写成了一个乘法式：使用人数 × 人均会话数 × 每次会话的轮数 × 每轮的请求数 × 每次请求的 token 数 × 每个 token 的单价。
token 是模型计费的最小单位，文本会被切成一个个 token，账单按它来算，具体切法随模型而变。
六项相乘，意味着任何一项减半，总数就减半。而这六项的性质完全不同。
前两项，Uber 明确说要往上涨。人用得越多、用得越频繁越好，这是采用率。最后一项，每 token 单价，是供应商定的，能做的只有换模型。
中间那三项，Uber 是这么定义的：
agent 在工程师真正提出的那个请求之上，替自己加的活。
价格那一项 Uber 同样在优化，但按原文的说法，大部分优化精力放在了中间三项上。
一条查询，两条路
中间三项里，「每次请求的 token 数」是最容易看出问题的一项。
agent 每说一句话，都要把之前的全部对话历史、项目上下文、工具返回结果重新发一遍。所以任何能压缩单次载荷的做法，在一次会话里都会被反复放大。
Uber 内部有一个统一的 MCP 网关。MCP 是模型上下文协议，一套让模型调用外部工具的通用接口。网关是所有调用的统一入口，认证和权限都在这儿管，按原文的说法，它后面接了 1000 多个 MCP 服务器。
麻烦出在这套协议的默认行为上：它会把所有工具的说明书一次性塞进会话，不管你这次用不用得到。 这里的说明书指的是每个工具的参数定义，模型要靠它才知道这个工具怎么调。
Uber 给的数字是：装了 100 多个工具，光是这些说明书就要占掉 5 万到 7 万 token，而且每一轮对话都重发一遍。用户还一个字没输入。
第三方软件的说明书更长。原文举了三个例子：某个办公套件一个服务器塞了 49 个工具，说明书约 2.2 万 token；某个消息类产品 34 个；某个项目管理产品 46 个。
装上两三个供应商的服务器，agent 背着的说明书就比它要改的那个文件还大，而这时候用户还没开始提问。
Uber 的解法有点反直觉：把 MCP 从上下文里拿掉。
一条路是把网关上的工具改成命令行命令，模型需要哪个就现敲哪个，网关在调用发生的那一刻才去解析。另一条路是工具搜索，让模型先搜目录，只把用得上的那几个加载进来。两条路的效果一样：说明书不进上下文了。
903 和 402
工具变成命令行命令之后，模型就能把好几个动作写进同一个脚本里批量执行。这一点对来回次数多的工具特别管用。
原文举的例子是查一次数据库：走标准流程，模型要先发请求，再轮询两到五次状态，最后取结果，每一步都是一个独立的回合，每一步的返回都落进上下文。改成脚本之后，中间的等待在后台跑完，只有结果回来。
Uber 在同一个 Claude Code 会话里，拿五种 SQL 查询各走了一遍两条路。SQL 是查数据库用的语言。
一条只取一行的最简单测试查询，走工具调用花了 903 个 token，走脚本 402 个，省 55%。数行数的那条是 954 对 403，省 58%。取 20 行的分组查询，1600 对 457，省 71%。查一张宽表的 50 行是这张表里的极端一行，走工具调用花了 1,431,594 个 token，走脚本 900 个，那是因为整张宽表的返回被原样灌进了上下文。
原文自己没拿那个极端值当结论。它强调的是前三行：哪怕返回的数据量小到可以忽略，脚本这条路照样能省一半以上。省下来的是说明书的初始化、来回轮询、以及模型一步步复述自己在干什么，跟返回的数据有多大关系不大。批量场景下这个效应会叠加，原文的说法是超过九成。
Uber 已经为最常用的那些服务预置了 25 个以上的 code-mode 技能包，把常见流程默认走上这条路。
缓存写着贵，读着便宜
主流模型都提供提示词缓存：把前面的上下文存住，后面几轮就不用按全价重发。缓存读只要标准输入价的 0.1 倍，但写缓存要加价：存 5 分钟加 25%，存 1 小时加一倍。
于是缓存有效期怎么选，取决于两轮对话之间隔多久。Anthropic 提供 5 分钟和 1 小时两档，OpenAI 提供 30 分钟。
Uber 的观察是，工程师经常开着会话去干别的，一走就超过 5 分钟。默认的 5 分钟缓存于是频繁失效，回来接着聊就得按全价重建一遍上下文。他们把交互式会话统一改成了 1 小时，子 agent 保持 5 分钟不变，因为它们干的都是一次性的短活。
还有两个默认值也被改了。
一个是自动压缩的阈值定在 40 万 token，哪怕用的是支持 100 万上下文的模型。上下文越长，每轮重发的成本越高，所以他们提前动手压。
另一个是推理强度默认调到中档。模型输出的 token 比读进去的 token 贵好几倍，而它「想」的那部分同样按输出计费。
找东西的时间
第三项是「每轮的请求数」，对应的是 agent 在一个回合里来回折腾了多少次。
一个没有依据的 agent，失败得慢，不是失败得便宜。它会带着越来越大的上下文，一遍遍去下一个地方再找找看。
Uber 的代码库有几亿行，数据表几千张。他们为此建了一张 AI 上下文图，接了 30 多个内部系统，包含服务、工程团队、事故记录、PR、设计文档、部署、数据集和历史查询记录。
这张图有 2400 万个节点和 8000 万条连线，节点分 86 类，连线分 117 种。连线表示的是关系，比如「这个服务属于那个团队」「这张表被那个查询用过」。任何 agent 都可以用自然语言去查它。
同一个问题、同一个模型，接了图的那个 agent 查了历史使用记录，找到那张被 50 多位分析师用过的表，38 秒给出答案。没接图的那个花了 20 分 09 秒，翻服务代码、开了 2 个子 agent、撞了 3 次错，最后得出的结论是这个数据集查不了。这个结论是错的。
这张图真正解释的是另一件事：为什么 Uber 后来要把活往托管 agent 里搬。会话跑在自己笔记本上、上下文全靠人肉提供的时候，成本既没法计量也没法优化；同样的任务收进一个有明确边界的托管 agent，才谈得上给它配基准测试、挑模型、算单位成本。
在他们的分层图里，最上面那层是五个有名有姓的专用 agent，各自对应软件生命周期的一段，每一个都有自己的计价单位：每个合并的 PR 多少钱、每次代码评审多少钱、每条告警多少钱。而最底下那层，也就是工程师自己在笔记本上开的会话，写的是「没有任务边界」。
曲线自己说的话
长文给了两组图，图和文字的口径不完全一样。
第一组是 2 月到 8 月的采用曲线。周活跃用户涨了 7 倍，agent 请求量涨了 9.4 倍，这两条确实在往上走，虽然中间有过回落。
第三格是总成本。原文的措辞是「自 4 月起相对稳住」。
这三张图都没有标 y 轴数值，只能看走势。成本那条曲线的走势是：2 月起陡升到 5 月，中间掉过一次又涨回来，7 月明显下探，8 月冲到了整张图的最高点附近，最后一个点略微回落。
它不是一条平线。「相对稳住」这个说法站得住，但这几天流传最广的那句「总账单一分没涨」，原文里找不到对应。
第二组是把模型固定住之后的单位成本，这样才能把优化的效果和换模型的影响分开。按每千次请求算，比峰值低了 34%；按每次会话算，比 6 月峰值低了 52%。
两条线的走法不太一样。每千次请求那条从 3 月开始下行，6 月末触底，之后一路回升到 8 月，末端明显高于低点。每次会话那条从 6 月见顶后大幅下降，7 月到 8 月大致走平。
原文只说了「距峰值低多少」，没说「还在降」。
每一块钱对应一个单位的活
终端状态栏里有一个实时的花费计数器。Slack 会在预期支出的 50%、80%、100% 三个点提醒。额度不够可以走审批。
还有一个会话分析看板，直接读会话记录，标出 16 种反复烧钱的用法并给出对应的钱数。
原文列了其中四种。把 Sonnet 就能干的活跑在 Opus 上。40KB 的工具返回赖在上下文里，之后每一轮都跟着重新计费。休息回来缓存已经过期，前面那截上下文按全价重建。还有一种是用户还没输入，系统指令和工具定义就先加载了 10 万 token。
6 月彭博报道的是「每个 AI 编码工具每人每月 1500 美元」。而 8 月这篇长文在讲额度的那一节，开头第一句是「为了避免硬性封顶」，并且明确写着所有交互式工具共用一个额度池，「不是按工具分预算」。
两段话是不是在说同一层政策，现有材料判断不了。可能是三个月里政策调整了，也可能一个说的是工具级默认额度，另一个说的是共享额度池。
最后
Uber 给出的结论不是某一个技巧管用。它说真正的战略变化，是把活从交互式的开发者会话，搬进完全托管的 agent 里。理由很直接：只有搬进去，用哪个模型、跑在什么环境里、花了多少钱，才谈得上被控制。
原文的说法是，与其去优化几千名工程师各自的终端会话，不如去优化一支专用 agent 组成的舰队，每一个都配好自己的基准测试和自己那个性价比最优的模型。
代码评审那个 agent 就是按这个路子做的。他们拿真实的、已知有 bug 的 PR 建了一套测试题，按难易分三档，同时看两个指标：报出来的问题有多少是真的，真实存在的问题又抓到了多少。除此之外还看每次评审的成本、延迟、超时和噪音。换模型之后，准确性上去了，每个 PR 的成本降了。
这套东西成不成立，眼下没有第三方复现过。全篇是 Uber 一家的自述，原文自己也写了免责：具体降幅取决于你的代码库、团队规模和工作流，别人的数字未必能照搬。
方法上倒是有一句可以拿走：账单里最容易被忽略的那部分，是 agent 在你提的那个请求之外，替自己安排的活。 它不出现在任何一次用户输入里，却出现在每一轮的账单上。
发表于 昨天 03:01
|
查看: 11|
回复: 0
