Uber的Agent请求涨了9.4倍，为什么账单没有同步失控？
从2月到8月中旬，使用Agent的每周活跃人数增长了7倍，每周请求量增长了9.4倍；
Uber工程师已经创建3600多个Agent技能，每天执行超过3万次，超过70%的PR可归因于本地或云端Agent；
固定使用同一模型时，每千次请求的成本比高点下降近34%，每次会话的成本比6月高点下降52%。
与此同时，Uber官方对AI总支出的描述是：从4月起相对稳定。
我们理解一下这里的“稳定”，指的是请求量增加很多后，支出没有按同样速度增长，并不等于总账没有增长。
那么，Uber到底做对了什么？
01
Uber第一步，拆解总支出
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越早拿到正确资料，搜索、调用工具和错误重试都会越少。这项改动压低的是公式里的会话轮数和每轮请求数。
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第二步，让浪费被看见
前面的公式只是一个算账方法，不会主动告诉管理者哪次会话突然变贵，也不会自己跳出来说明钱为什么花多了。
Uber没有用统一的硬上限把所有人拦住。
工程师可以在开发工具里看到当前会话的支出，费用达到预计额度的50%、80%和100%时会收到提醒。
会话分析工具还会识别16类常见问题，并显示它们造成了多少费用。
这些问题包括简单任务使用过强的模型、上下文持续膨胀、缓存过期后重新读取全部前文，以及任务开始前加载过多说明。
问题被定位到具体会话后，工程师和管理者才能判断该改模型、上下文、工具设计，还是任务表达和使用习惯。
这些提醒和分析的作用，是找出六项中的哪一项在异常上升，让企业在任务还没有失控时处理。
03
Uber第三步，按工作结果算账
Uber第三步，按工作结果算账
前面几章主要讨论调用成本，仍然不能直接回答一项工作有没有完成。
对于能够明确判断是否完成的Agent任务，Uber还设置了另一组成本指标：
每个最终合并的PR花多少钱（PR提交以后还要经过检查和修改，最终合并才说明这项代码修改被项目接受）
每次代码审查花多少钱
每次告警处理和清理任务花多少钱
不同任务还要搭配相应的质量指标。
以uReview为例，Uber会看准确性、错误提醒、耗时和超时；其他任务则按需要观察代码撤回、修复时间或完成数量。
成本、质量与数量放在一起，才能判断每个Agent是否用更少的钱交付了同样可靠的结果。它比请求数和会话数更接近工作结果。
当然，仍然不能代表这些代码最终创造了多少收入或业务价值。
官方文章公开了这些指标的定义，却没有公布每一类Agent完整的任务结果数据。但已经足以提醒我们一件事：企业得先定义什么叫解决问题，才算得出每个结果的成本。
04
普通企业怎么借鉴Uber
普通企业怎么借鉴Uber
对于其他企业，哪怕无法原样复刻Uber，也能带走以下几点启发：
第一，用真实任务找出无进展调用，再选择模型。
Uber用真实PR持续评测模型。
我们可以先挑选一批常见并且容易验收的工作，规定什么情况算完成，再让不同模型处理同一批任务。除了调用费用，还要记录完成率、重试次数、人工修改时间和结果质量。
这样才能看出哪些调用真正推进了工作，模型是否合适也由企业自己的任务决定。
第二，让费用能追到任务和结果。
Uber公开的指标里，包括每个合并PR、每次代码审查和每次告警处理的成本。
我们可以先记录谁在使用、属于哪个团队、用于哪个项目、调用了什么模型、最后有没有完成。失败重试、工具调用和人工返工也要计入任务成本。
缺少这些信息，企业只能看到Token总账，无法知道支出增加带来了更多工作，还是更多浪费。
第三，让规则在任务进行时生效。
Uber把成本控制放在任务执行过程中。工程师在开发工具里看到当前会话的支出，系统按预设档位提醒；管理者再通过会话分析，定位模型、上下文和工具造成的浪费。在费用变大之前就让问题暴露出来，而不是等到月底才看一张总账。
我们可以先从一两个场景开始，规定一次任务最多使用多少Token、失败后最多重试几次、连续调用工具多少次以后转交人工，再逐步增加按团队、项目和模型区分的规则。如果某个任务频繁重复调用，应先检查Agent的状态管理、工具返回和重试逻辑，再看模型选择、任务写法和使用方式，最后决定是否收紧额度。
这套规则让费用有处可查，异常出现时也能及时停下来。
05
Uber的经验是有边界的
Uber的经验是有边界的
Uber的做法最适合代码审查、告警处理和清理这类流程清楚、结果容易验收的工作。软件开发里的PR、测试、合并和撤回通常都会留下记录，企业可以据此判断Agent完成了什么。
换到销售方案、市场策划和管理决策，结果往往要过更长时间才显现，也很难归给某一次调用。企业需要自己重新定义什么算完成、质量达到什么标准，不能直接套用。
Uber能把费用追到任务，依靠的是数千个技能、统一工具和完整的内部记录。
普通企业更适合先选一两个边界清楚的场景，把调用费用、人工审核、返工和错误代价一起记下来，再逐步细化规则。能复 制的是按任务看投入产出这个思路，具体指标和管理深度仍由业务决定。
看到AI费用上涨就统一收紧，像因为几辆车在绕路，就让所有人少出门。
企业可以先保留能够带来合格结果的使用，再把过强模型、重复读取、无效搜索和失败重试造成的消耗找出来。
Token单价固然重要，但我们最终要看的，是这些Token有没有让任务更接近完成。
