Uber 智能体请求涨 9.4 倍、账单没涨：拆开看，这不是省钱教程，是治理教程

Anthropic 的定价里，缓存读取是标准输入 token 的 0.1 倍，写入溢价 5 分钟档 1.25 倍、1 小时档 2 倍。Uber 的测算是：主对话工程师经常空闲超过 5 分钟，5 分钟缓存会在读代码/开会/等工具调用之间反复过期重建，累计下来 5 分钟 TTL 相当于 3.95 倍开销、1 小时 TTL 是 2.40 倍，1 小时便宜 39%；子智能体寿命 90 秒内跑完，没有超过 5 分钟的空隙，1 小时溢价买不到任何缓存复用，反倒比 5 分钟贵 45%。同一个供应商、同一个模型、同一套缓存机制，两种会话形态给出完全反向的答案。默认值必然错一半——只能按会话形态分场景配置。

这条不能直接套到国内。国产主流模型的缓存产品化程度不一，是否提供 TTL 档位、写入溢价是几倍、读价折扣多少，各家差别很大。想把这条策略移过来，得先把供应商的缓存价目吃透——没有"读价 / 5 分钟写溢价 / 1 小时写溢价"这三个数，就画不出 Uber 那张对比表。

代码模式：把 MCP 从上下文里搬出去

图说：左侧是标准 MCP 工具调用，每一轮 poll 都进上下文；右侧是代码模式，中间轮询在子进程里跑，只有摘要回到模型。图片来源：Uber Engineering

一次 SQL 查询在标准 MCP 下要 903 个 token（提交→轮询 2-5 次→取结果，每一步都进模型上下文）；改成代码模式后是 402 token，省 55%。批处理放大到 5 条同类查询，节省能到 90% 以上。Uber 内部 MCP 网关有 1000+ 工具全部映射成 CLI 命令，不再直接注入 Schema；100 个工具装齐的 MCP Schema 大约会给初始提示带来 5 万到 7 万 token 的开销，改成"工具检索 + CLI 解析"后，会话开始时上下文里的工具定义"接近零"。这条是三个杠杆里最普适的：它跟模型无关、跟供应商定价无关，只跟运行时的工具协议有关。国内团队想搬，路径也清楚——把 MCP 服务器藏在 CLI 后面，让模型写脚本调 CLI，中间态不进上下文。

真正的护城河：装在终端和仪表盘里

Uber 分五层做指标：Portfolio 层看总账走向、Unit economics 层看每工具经济学、Model economics 层看模型换代对账单的影响、Driver decomposition 层把变化拆解到六项因子、Managed agent outcomes 层看每个托管智能体的单位价值（cost per merged PR、cost per review、cost per alert、cost per cleanup）。同一个 34% 降幅，在这五层里能被拆到人、拆到工具、拆到模型、拆到因子；只有拆得开的下降，才知道是真降了、还是负载搬家了。反过来，一个没有 Managed agent outcomes 层的团队，连"这个智能体是不是变贵了"都答不上来。

面向工程师的一侧是 statusline 和会话分析仪表盘。终端 statusline 实时显示本次会话花了多少钱、这个用户总共花了多少；Slack 提醒在预期支出的 50%/80%/100% 触发；会话分析仪表盘自动识别 16 类反模式，Uber 原文列出的四类是：次优模型路由（简单多轮跑在 Opus 上、Sonnet 就够）、上下文膨胀（40KB 的 MCP 响应长期留在上下文里被反复计费）、缓存过期低效（长时间中断后恢复，缓存过期，前缀被完整重建）、提示词初始化开销（用户还没输入，10 万 token 的系统指令和工具定义已经预加载）。剩下 12 类原文没披露，但结构是清楚的——只要装了指标看板，反模式列表是可以生长的。

这一层，才是 Uber 复盘和市面上大多数省钱贴的分野。省钱贴给你参数（TTL、40 万 token、Sonnet），Uber 的复盘给你尺子。有尺子才能知道你的团队踩了哪几类反模式；有尺子才能判断某次换模型是省了钱、还是把 F1 分数拉了下去。

落到国内：能搬、搬不动、需要重设

能直接搬的：statusline 成本读数（几行代码，Claude Code、Codex 都能加）、MCP→CLI 的收敛（跟供应商无关，只跟运行时有关）、按周/月的驱动因子分解看板（Excel 就能做，先把六项因子的数据源接上）。这三件事都不要模型改造，只要把测量装上。

搬不动的：40 万 token 自动压缩阈值——各家国产模型的实际上下文上限不一致，得按各家上限重设；提示缓存的 TTL 分场景策略——供应商如果不给档位就没法分场景；uReview 那种"用真实 PR 做基准"——需要有历史评审数据集与 F1/召回率标注，多数团队没有这个语料，Uber 内部先攒了几千个真实 PR 才能画出前沿曲线。

需要重新设计的：Uber 用的是 Anthropic + Claude Code，token 计价与 tokenizer 相对稳定；国内团队常见组合是通义、DeepSeek、豆包混用，不同 tokenizer 下的"每请求 token"根本不能横向比——同一份文本，不同厂商切出来的 token 数量不同。Uber 那六项公式在国内要能用，最后一项（每 token 价格）必须先按各家 tokenizer 折算，或者直接换成"每千字符成本"、"每千词成本"这类可比口径，否则横比出来的结论就是错的。

Uber 这份复盘给出的顺序是反直觉的：先装表，再开车。国内团队常见的顺序是先换便宜模型、先谈裁负载、先想 RAG 优化——表都没装，看什么效果？34% 不是终点，是这套顺序跑通之后的自然结果。