Agent 用得越多，AI 账单就一定按同样比例增长吗？Uber Engineering 给出的实际结果是：从 2026 年 2 月到 8 月中旬，Agent 周活跃用户增长了 7 倍，周请求量增长了 9.4 倍，总体 AI 支出从 4 月起相对稳定。
为了排除模型升级与流量结构变化的干扰，Uber 固定一个模型观察 2 月到 7 月的数据。每 1000 次模型请求的成本较峰值下降近 34%，单会话成本较 6 月峰值下降 52%。这些数字来自 Uber 自己的环境，不能直接套到其他公司；更值得复用的是它拆账单和逐项优化的方式。
先把总账拆成六个乘数
Uber 用一个简单的乘法式描述 Agent 总支出：
总支出 = 用户数
× 每用户会话数
× 每会话轮数
× 每轮请求数
× 每请求 token 数
× 每 token 价格这个式子的价值在于避免把所有问题都归因于模型单价。用户数与使用频率代表采用情况，通常希望它们继续增长。真正适合优化的是后四项：一次任务产生多少轮、每轮产生多少请求、每次请求携带多少 token，以及每类工作用了什么模型。
如果总费用上涨，只看「本月 token 多了多少」无法解释原因。可能是活跃用户增加，也可能是工具轮询让一次任务多发了十次请求，还可能是每一轮都重复携带数万 token 的工具定义。六项分开记录后，团队才能知道该改模型、上下文、工具协议，还是任务流程。
衡量成本时，分母要用完成的工作
Uber 同时观察四层指标：
| 层次 | 关键指标 | 回答的问题 |
|---|---|---|
| 总体 | 总费用、活跃用户、各工具费用占比 | 钱花在哪里，哪个工具发生了变化 |
| 单位成本 | 每用户、每会话、每 1000 次请求成本，缓存命中率 | 工具真的变便宜了，还是流量转移了 |
| 模型 | 各模型请求占比、费用占比、每 1000 次请求成本 | 哪次模型迁移改变了账单 |
| 业务结果 | 每个合并 PR、代码审查、告警处理或清理任务的成本与质量 | 每单位有效工作是否更便宜 |
最后一层最重要。一个便宜模型若需要更多重试，或者让代码审查漏掉更多缺陷，它的每 token 单价虽然低，每次有效任务的成本仍可能更高。
Uber 的 uReview 代码审查 Agent 使用带已知缺陷的真实 PR 构建基准，按难度分类，并同时测量 precision、recall、F1、每次审查成本、延迟、超时与噪声。模型只有在质量、可靠性和每次完成任务的成本上更合适，才会进入默认配置。
第一项优化：按任务选模型
Uber 的模型选择流程可以压缩成三步：
- 从 Agent 的真实工作中建立基准；
- 让多个前沿或开放权重模型通过同一套运行环境执行；
- 选择质量与成本都占优的配置，并随着模型变化持续复测。
主 Agent 与子 Agent 也使用不同默认值。主 Agent 负责拆分任务和检查结果，需要更强的判断力。子 Agent 通常接收范围明确、输入固定的工作，可以先用成本更低的模型，并保留人工覆盖选项。
这里省下的费用来自任务匹配。若只按模型排行榜统一切换，很容易在简单任务上付出过高价格，或在困难任务上因返工付出更多。
第二项优化：减少每次请求携带的内容
Agent 每一轮通常会重新发送会话历史、项目说明、工具定义和工具结果。这些内容只要留在上下文中，就会在后续轮次重复计费。
Uber 从四处减少输入：
提前压缩长会话
即使模型支持 100 万 token 上下文，Uber 也在 40 万 token 时触发自动压缩。更大的窗口提供了容量，不代表把它填满最划算。过长历史会增加重复输入、缓存重建和模型注意力负担。
把推理强度设为可测量的默认值
交互式运行环境默认使用 Medium reasoning。原因很直接：输出与内部推理 token 往往比输入 token 更贵，很多日常任务在 Medium 已能达到可接受质量。困难任务仍可提高强度，但要用基准证明额外费用带来了质量提升。
根据会话间隔选择缓存时长
交互式开发经常停顿超过 5 分钟。Uber 因此把主会话的 Anthropic Prompt Cache 从 5 分钟改为 1 小时，避免工程师回来后重新按原价写入整段前缀；短时间完成单一工作的子 Agent 继续使用 5 分钟。
缓存计费会随服务商和模型变化。按 2026 年 8 月的官方资料，Anthropic的 5 分钟写入为普通输入价格的 1.25×，1 小时写入为 2×，读取为 0.1×。OpenAI GPT-5.6支持显式缓存断点，写入为普通输入的 1.25×，并通过 cache_write_tokens 与 cached_tokens 区分写入和读取。
选择 TTL 前，先看真实会话的间隔分布。短缓存反复失效会产生重写成本，长缓存也只有在后续请求真正读取时才值得支付溢价。
工具按需加载
MCP 工具包含名称、描述与输入 schema。标准客户端可以通过 tools/list 发现这些定义，但若把所有工具一次性放进模型上下文，工具越多，固定开销越大。
Uber 的统一网关连接了 1000 多个 MCP Server。直接加载 100 多个工具时，初始提示词会增加约 5 万到 7 万 token，后续轮次还会重复携带。它采用两条路径缩减开销：
- 把内部 MCP 能力映射成 CLI 命令，执行时再解析并调用；
- 让 Agent 先搜索工具目录，只加载当前任务需要的定义。
第三方 SaaS MCP 也经过同一网关。这样既能集中处理认证和策略，也能避免多个大型 Server 的 schema 在会话开始前占满上下文。
第三项优化：把工具循环移出模型上下文
一次 SQL 查询可能包含提交、轮询状态 2 到 5 次、获取结果等多个动作。若模型逐步调用工具，每次轮询都会产生新请求，原始返回值也会进入上下文。
Uber 的 Code Mode 把这类确定性循环放到 Python 子进程中运行，最后只把摘要交给模型。在同一会话中执行五类相同 SQL 查询时，简单查询节省了 55% 到 71% token；批量流程的节省超过 90%。
这条原则可以推广到更多场景：轮询异步任务、分页读取、批量转换、汇总多次 API 返回。循环本身不需要新的模型判断时，让普通程序执行会更便宜，也更容易控制重试和超时。
需要保留的边界也很清楚。每一步都可能改变目标、需要权限判断或依赖新语义时，模型仍应参与。Code Mode 适合输入明确、停止条件明确、失败能被程序识别的循环。
第四项优化：减少 Agent 找信息的轮数
上下文贫乏的 Agent 往往会缓慢失败：搜索一个目录、再查一个服务、启动子 Agent、遇到错误后继续扩大上下文。请求次数、历史长度和错误概率会一起上升。
Uber 建立了 AI Context Graph，把服务、团队、事故、PR、设计文档、部署、数据集和历史查询等 30 多个内部系统连接起来。原文报告该图包含 2400 万节点和 8000 万条边。
在一个相同模型、相同问题的对比中，有图谱支持的 Agent 找到 50 多名分析师使用的正确数据表，38 秒完成回答；缺少图谱的 Agent 检查服务代码 20 分钟，启动两个子 Agent，遇到三个错误，最后仍给出错误结论。
这是 Uber 的单个案例，不能据此推断所有任务都能获得相同比例的提升。它说明了一个更稳健的方向：让 Agent 先获得高质量的代码、组织和数据关系，比增加盲目搜索轮数更有效。
最后一项优化：让费用随时可见
Uber 把实时费用放进运行环境状态栏，并提供跨工具的共享额度、在预期费用 50%、80% 和 100% 时发出提醒。会话分析工具检查本地与云端运行记录，识别 16 类浪费，例如：
- 简单任务长期使用高价模型；
- 大型工具返回值在后续上下文中重复计费；
- 休息后继续使用已过期缓存的会话；
- 用户输入前就加载 10 万 token 的说明和工具定义。
费用可见可以帮助工程师识别一次任务中没有产生价值的请求和 token，无需以减少 Agent 使用为目标。团队仍应把质量、完成率、返工和人工审核成本放在同一张表里。
中小团队可以从这五步开始
复刻 Uber 的 1000 多个 MCP Server 或 2400 万节点图谱通常没有必要。更小的团队可以先做五件事：
- 记录每次任务的模型、请求数、输入与输出 token、缓存读写、总费用和最终结果；
- 为一个高频 Agent 建立包含真实成功与失败样本的小型基准；
- 找出提示词中最大的固定内容，只保留常用工具，其余改为按需搜索；
- 把轮询、分页和批量操作收进一个确定性程序，只返回模型需要的摘要；
- 用每个合并 PR、有效审查或解决告警的成本衡量改动，并同时观察质量。
Uber 的案例说明，Agent 成本更像一个可拆解的系统问题。模型单价只占一个乘数，真正容易积累浪费的地方常在重复上下文、过多请求、错误路由和缺少信息。先测清六个乘数，再改最大的那一项，通常比统一换成更便宜的模型可靠。
Aide Hub 会继续分享 AI 助手、开发工具和软件工程实践。