Uber的Agent请求涨了9.4倍,为什么账单没有同步失控?

2026年8月27日,Uber在官方博客披露了一组很少见的企业Agent数据:

  • 从2月到8月中旬,使用Agent的每周活跃人数增长了7倍,每周请求量增长了9.4倍;
  • Uber工程师已经创建3600多个Agent技能,每天执行超过3万次,超过70%的PR可归因于本地或云端Agent; 
  • 固定使用同一模型时,每千次请求的成本比高点下降近34%,每次会话的成本比6月高点下降52%。

与此同时,Uber官方对AI总支出的描述是:从4月起相对稳定
我们理解一下这里的“稳定”,指的是请求量增加很多后,支出没有按同样速度增长,并不等于总账没有增长。

那么,Uber到底做对了什么?

01、Uber第一步,拆解总支出

Uber把Agent总支出拆成六个相乘的因素。
总支出 = 用户数量 × 每位用户的会话数 × 每次会话的交流轮数 × 每轮模型请求数 × 每次请求的Token数量 × Token单价

换成人话就是,这笔钱有多少人在用、每人开了多少次会话、每次会话来回多少轮、每轮要调用模型几次、每次请求带入多少上下文并生成多少内容,以及所用模型的Token价格。

从已公布的数据和措施看,Uber没有把省钱建立在压低用户数和会话数上
它更关心中间三项,减少不必要的会话轮数、每轮请求数和每次请求的Token数量。
最后一项Token单价,取决于调用哪个模型。单价更低不等于一项任务更便宜,Uber的模型选择正是围绕这个问题展开。

1. 用户和会话可以增长,成本管理不等于限制使用

Uber从2月到8月中旬把Agent周活跃人数做到了原来的7倍,每周请求量做到了原来的9.4倍。周活和请求量与公式里的用户数、会话数并非完全同一口径,但足以说明使用范围在扩大。
它们上升,账单通常也会增加,却同时说明更多工作开始交给Agent。

更多人使用Agent,是业务覆盖面变大。
一个任务反复调用同一工具、重复读取相同资料,是过程在空转。

前者需要看结果是否值得,后者才是优先要找的浪费。
如果企业只盯着总账,很容易把两件事混在一起。
Uber让使用继续增长,再从后面几项下手,正是这个思路。

2. 会话轮数和每轮请求数,先处理无进展调用

我们先把调用分成三类。
第一类直接产出可用结果。
第二类暂时没有最终答案,却通过检索、规划、探索、试错或校验让任务更接近完成。
第三类既没有带来新信息,也没有改变下一步行动,只是在重复消耗。

一次失败如果排除了错误路径,仍然属于有价值的试错。需要处理的是沿着同一路径重复失败、反复读取相同资料和调用无关工具,也就是我们定义的第三类——无进展调用。

Uber发现,在庞大的代码和数据环境里,Agent的大部分轮次都花在寻找信息上。为此,它把服务、团队、事故记录、PR、设计文档和数据使用记录连接成一套可查询的内部关系图,让Agent先找到相关资料,再开始处理任务。

效果很直观。
同一个问题,有这套关系图时,Agent用38秒找到正确答案。没有它时,Agent查了20分钟,调用两个子Agent,遇到三次错误,最后仍然答错。
Agent越早拿到正确资料,搜索、调用工具和错误重试都会越少。这项改动压低的是公式里的会话轮数和每轮请求数。

有些工具调用上,Uber还把查询、等待和取回结果这类固定步骤交给程序。模型最后只接收一份摘要,不必每一步都参与。
这同样减少了来回轮数和重复请求,Token用量也会跟着下降。Uber的测试显示,即使查询结果很小,Token用量也能减少一半以上。

3. 每次请求的Token,输入和输出两手抓

每次请求的Token分成两部分。
一部分是模型读进去的前文、项目资料和工具结果,另一部分是模型经过推理后生成的内容。
Uber选择输入输出两手一起抓。

输入端,Uber把连续会话的前文缓存起来,减少重复输入的费用,同时在上下文累计到约40万Token时进行压缩。

工具也会占用上下文。Uber通过统一入口接入了上千个内部工具和第三方软件接口。如果一开始就把100多个工具的说明全部交给模型,用户还没提出问题,初始输入就会增加约5万到7万Token。Uber改为先搜索,需要哪个工具时再加载对应说明。

输出端,Uber把交互式Agent的默认推理强度设为中等,避免多数任务一开始就使用更耗Token的推理档位。

这些动作都对应公式里的每次请求Token数量。前两项让模型每次需要阅读的内容更短,后一项减少普通任务中过多的推理输出。

4. Token单价,选择能更快完成工作的模型

只比较每百万Token的价格,有点像只看每公里车费。
一个便宜模型如果更容易漏掉问题、调用超时或者触发重试,就会制造更多无进展调用。单次请求虽然省钱,整项任务可能更贵。

Uber选择模型时,会同时比较完成任务的成本、输出质量和运行可靠性。

以代码审查Agent uReview为例,Uber用包含已知问题的真实PR建立测试集,再检查它能发现多少问题、发出多少错误提醒,同时记录每次审查花多少钱、需要多久、是否超时。

Uber称,更换模型后,审查质量提高了,每个PR的成本也明显下降。

模型能力和价格会变,同一个任务最合适的模型也会变。企业需要保留切换模型的能力,真实任务的评测结果负责告诉它什么时候该换。

02、Uber第二步,让浪费被看见

前面的公式只是一个算账方法,不会主动告诉管理者哪次会话突然变贵,也不会自己跳出来说明钱为什么花多了。

Uber没有用统一的硬上限把所有人拦住。
工程师可以在开发工具里看到当前会话的支出,费用达到预计额度的50%、80%和100%时会收到提醒。

会话分析工具还会识别16类常见问题,并显示它们造成了多少费用。
这些问题包括简单任务使用过强的模型、上下文持续膨胀、缓存过期后重新读取全部前文,以及任务开始前加载过多说明。
问题被定位到具体会话后,工程师和管理者才能判断该改模型、上下文、工具设计,还是任务表达和使用习惯。

这些提醒和分析的作用,是找出六项中的哪一项在异常上升,让企业在任务还没有失控时处理。

03、Uber第三步,按工作结果算账

前面几章主要讨论调用成本,仍然不能直接回答一项工作有没有完成。

对于能够明确判断是否完成的Agent任务,Uber还设置了另一组成本指标

  • 每个最终合并的PR花多少钱(PR提交以后还要经过检查和修改,最终合并才说明这项代码修改被项目接受)
  • 每次代码审查花多少钱
  • 每次告警处理和清理任务花多少钱

不同任务还要搭配相应的质量指标。

以uReview为例,Uber会看准确性、错误提醒、耗时和超时;其他任务则按需要观察代码撤回、修复时间或完成数量。

成本、质量与数量放在一起,才能判断每个Agent是否用更少的钱交付了同样可靠的结果。它比请求数和会话数更接近工作结果。

当然,仍然不能代表这些代码最终创造了多少收入或业务价值。

官方文章公开了这些指标的定义,却没有公布每一类Agent完整的任务结果数据。但已经足以提醒我们一件事:企业得先定义什么叫解决问题,才算得出每个结果的成本。

04、普通企业怎么借鉴Uber

对于其他企业,哪怕无法原样复刻Uber,也能带走以下几点启发:

第一,用真实任务找出无进展调用,再选择模型。

Uber用真实PR持续评测模型。
我们可以先挑选一批常见并且容易验收的工作,规定什么情况算完成,再让不同模型处理同一批任务。除了调用费用,还要记录完成率、重试次数、人工修改时间和结果质量。

这样才能看出哪些调用真正推进了工作,模型是否合适也由企业自己的任务决定。

第二,让费用能追到任务和结果。

Uber公开的指标里,包括每个合并PR、每次代码审查和每次告警处理的成本。

我们可以先记录谁在使用、属于哪个团队、用于哪个项目、调用了什么模型、最后有没有完成。失败重试、工具调用和人工返工也要计入任务成本。

缺少这些信息,企业只能看到Token总账,无法知道支出增加带来了更多工作,还是更多浪费。

第三,让规则在任务进行时生效。

Uber把成本控制放在任务执行过程中。工程师在开发工具里看到当前会话的支出,系统按预设档位提醒;管理者再通过会话分析,定位模型、上下文和工具造成的浪费。在费用变大之前就让问题暴露出来,而不是等到月底才看一张总账。

我们可以先从一两个场景开始,规定一次任务最多使用多少Token、失败后最多重试几次、连续调用工具多少次以后转交人工,再逐步增加按团队、项目和模型区分的规则。如果某个任务频繁重复调用,应先检查Agent的状态管理、工具返回和重试逻辑,再看模型选择、任务写法和使用方式,最后决定是否收紧额度。

这套规则让费用有处可查,异常出现时也能及时停下来。

05、Uber的经验是有边界的

Uber的做法最适合代码审查、告警处理和清理这类流程清楚、结果容易验收的工作。软件开发里的PR、测试、合并和撤回通常都会留下记录,企业可以据此判断Agent完成了什么。

换到销售方案、市场策划和管理决策,结果往往要过更长时间才显现,也很难归给某一次调用。企业需要自己重新定义什么算完成、质量达到什么标准,不能直接套用。

Uber能把费用追到任务,依靠的是数千个技能、统一工具和完整的内部记录。

普通企业更适合先选一两个边界清楚的场景,把调用费用、人工审核、返工和错误代价一起记下来,再逐步细化规则。能复制的是按任务看投入产出这个思路,具体指标和管理深度仍由业务决定。

看到AI费用上涨就统一收紧,像因为几辆车在绕路,就让所有人少出门。

企业可以先保留能够带来合格结果的使用,再把过强模型、重复读取、无效搜索和失败重试造成的消耗找出来。

Token单价固然重要,但我们最终要看的,是这些Token有没有让任务更接近完成。


速石Token中枢产品系列:

产品介绍    选型指南   元驭一体机  Enterprise企业版

fastHub MaaS入口:https://hub.fastone.cc/

END

速石科技致力于成为
一家提供"端到端统一计算解决方案"的公司
半导体/智能制造/能源/新药研发/人工智能
说到计算,统统在我们碗里
而且自下而上全栈适配国产化生态系统
同时,打造高校新质生产力教学科研创新平台
以产业经验赋能高校教学与科研场景
培养实战型人才

相关推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注

微信扫一扫

微信扫一扫

微信扫一扫,分享到朋友圈

Uber的Agent请求涨了9.4倍,为什么账单没有同步失控?
返回顶部

显示

忘记密码?

显示

显示

获取验证码

Close