开篇 · 一个反直觉的事实

用量涨 7 倍，成本却不涨

这是 Uber 的「软件工厂」做到的事——而且不是靠砍价或降级工具。

70%+的 Pull Request 由本地或云端 Agent 贡献
3,600+工程师们构建的 Agent Skill，覆盖整个软件开发生命周期
3 万+每天执行的 Agent Skill 次数

从 2026 年 2 月到 8 月：

7 倍所有 Agent 产品的周活用户增长
9.4 倍每周 Agent 请求量增长
↓ 稳定而总 AI 花费自 4 月起相对稳定（靠全面优化）

固定住一个模型来隔离自身优化收益后：每 1000 次模型请求的成本从峰值下降 34%，每次会话成本从 6 月峰值下降 52%。

他们靠的不是「买更便宜的模型」，而是——消除「零价值的浪费 token」。这堂课带你搞懂：一个超大团队，怎么把 AI 编程成本当成工程问题来「测量 + 优化」。

第 1 课 · 成本方程

先把成本「拆开」，才能逐项优化

Uber 把 AI 使用组织成四层，从最专门到最通用。越往上，对成本、质量、模型选择的控制越强。

四层 Agent 使用

1
受管 Agent（Managed Agents）最专门。代码审查、自愈 CI 失败、on-call 告警分诊、bug 调试……由系统自动发起，人只做审查/升级。
2
受管工作流半自动、有明确边界和审批点的任务流。
3
交互式 Agent（本地/云端）工程师主动发起的会话。
4
通用对话最通用，控制最弱。

关键洞察：越「受管」越省——因为你可以完全控制模型路由、执行环境和开销。

成本方程：一次 Agent 会话的成本 = 这几项相乘

用户数 × 会话数采纳 & 参与度（这一项要保持增长）
× 请求数/会话优化机会点 ①
× Token/请求优化机会点 ②
× 价格/Token优化机会点 ③

前两项代表「采纳」——想让它涨；中间三项是「优化机会」——Agent 在工程师真实请求之外，为自己额外做的活，大部分精力都花在这里。

第 2 课 · 优化「价格/Token」

哪个模型跑哪份活？—— Pareto 最优

厂商定 token 价，你决定「哪个模型跑哪份活」。Uber 的原则：给每份负载选Pareto 最优的模型——即「成本/完成任务、输出质量、模型可靠性」三者都不被别的选项完胜。

基准驱动的模型选择（四步，对每个受管 Agent 都适用）

1
用 Agent 的真实工作构建基准不是用通用题，是用它真正要干的活。
2
在一个 harness 上跑同一个接口，服务任何模型（前沿或开源权重）。
3
切换到 Pareto 最优，然后继续切前沿每几周就移动一次。

例子：uReview（AI 代码审查）从真实 PR 里的已知 bug 建基准，按难易分级，打 precision/recall/F1 + 每审查成本 + 延迟 + 超时 + 噪音。切模型后 F1 上升、每 PR 成本大幅下降。

🎯 最有影响力的一招：子 Agent 默认用「弱模型」

会话里有两个默认设置：初始会话模型 + 子 Agent 模型。其中子 Agent 默认设置被证明是最有影响力的杠杆，而且越来越重要。

👆 点我看「为什么」
第 3 课 · 优化「Token/请求」

每一轮都在重发全文，省一点就复利

每一轮对话都会重新发送「完整历史 + 项目上下文 + 工具结果」。任何能减少单请求 payload 的东西，都会在整个会话中复利。

三个默认配置，直接砍 token

1
自动压缩：400K tokens 就触发即使是 100 万上下文窗口的模型，也在 400K 就压缩——平衡模型性能 vs 缓存突发和重复输入成本。
2
推理努力默认 Medium输出 token（含内部推理）计费倍率远高于输入。Medium 对一大类任务都够用，直接砍掉最高成本的 token 类别。

Prompt 缓存：TTL 选对，省一大笔

缓存了前缀上下文，后续读取只要标准输入价的 0.1 倍。但写入有溢价：5 分钟缓存 1.25 倍、1 小时缓存 2 倍。

工程师常常让交互会话闲置超过 5 分钟。缓存 TTL 该怎么设？

对。频繁的闲置间隔会让 5 分钟前缀缓存失效，每次都花全价重建上下文。Uber 因此把交互会话切到 1 小时 TTL。而子 Agent 保留 5 分钟，因为它们的任务是短促的单次执行。

🎯 最大的坑：MCP 把所有工具 schema 塞进每个会话

标准 MCP 会把所有工具 schema 直接加载进每个会话——哪怕你根本不会用。装 100 个工具，就要给初始 prompt 加约 5-7 万 token 的 schema 开销，之后每轮都重发。

👆 点我看 Uber 的解法

code-mode：把「多轮轮询」压成「一个脚本」

工具以 shell 命令方式调用函数时，模型能在一个脚本里批量执行多个动作。对「话痨」型工具协议尤其有用。

标准 MCP

每条 SQL 查询：发请求 → 轮询 2-5 次状态 → 取输出。每次轮询都进模型上下文。

code-mode

整个流程变成一个 Python 循环，轮询跑在子进程里，只有「总结」回到上下文。

实测：同样的 5 条 SQL 查询，code-mode 减少 token 超过 50%；批量工作流里，N 轮模型往返变成一个脚本，节省超过 90%。

第 4 课 · 优化「请求/轮」

没「接地」的 Agent，失败得又慢又贵

一个没接地的 Agent，会反复发送不断膨胀的上下文窗口，去「再多搜一个地方」。提前给更丰富的信息，是减少这种搜索开销最有力的一招。

Uber 的解法：AI Context Graph（上下文图）

面对几亿行代码、几千张表的代码库，Agent 大部分轮次花在「定位信息」而不是「生成代码」。Uber 建了一个统一的网络：

2,400 万节点（nodes）
8,000 万边（edges）
30+内部系统整合（服务、团队、事故日志、PR、架构文档、部署、数据集、历史查询）

任何 Agent 都能用自然语言查询它。

🎯 实测对比：接地 vs 未接地

✅ 接地（有 Context Graph）

查历史用量 → 找到 50+ 分析师用过的那张表 → 38 秒给出答案。

❌ 未接地

看不见那张表 → 花了 20 分钟查服务代码、spawn 2 个子 Agent、撞 3 次错误 → 错误地断定「数据集不可查询」。

同一个任务：38 秒 vs 20 分钟还答错。差的就是「上下文工程」——提前把该知道的信息给到位。

第 5 课 · 可见性 & 教育

让人看得见成本，才能收敛

最后一类杠杆，是「可见性 + 反馈循环」，让工程师和 Agent 更快收敛。

实时成本计数器 + 分层 + 提醒

1
状态栏实时计数会话成本永远显示在终端里。
2
Harness 池一个共享 tier 覆盖所有交互 harness，不是每个工具单独预算；受管 Agent 单独分层。
3
Slack 提醒花费到预期 50/80/100% 时提醒，让工程师有时间规划。
4
简单审批流升 tier 经理签字，快速生效。

会话分析仪表盘：16 种反模式

状态栏只显示总花费，看不出「成本驱动因素」。会话分析仪表盘直接检查会话轨迹，标记 16 种反模式，每种配上财务影响和针对性修复。比如：

  • 次优模型路由：简单多轮会话却跑在 Opus 上，Sonnet 就能搞定。
  • 上下文窗口膨胀：40KB 的大 MCP 响应留在上下文里，后续每轮重复计费。
  • 缓存过期低效：长时间中断后恢复会话，过期缓存逼着全价重建前缀。
  • Prompt 初始化开销：在用户还没输入前，就预加载 10 万 token 的系统指令和工具定义。
结业 · 测一测

你真的懂了吗？

Q1. Uber 用量涨 7 倍但成本稳定的核心原因是？

对。原话：「通过消除浪费的、零价值的 token 消耗，而不是只靠更低的单价或降级工具。」

Q2. 为什么子 Agent 默认用「更弱」的模型？

对。分工：主模型做任务分解+评估，子 Agent 执行。定义好输入输出的活，弱模型就够了。

Q3. 标准 MCP 的大坑是？

对。100 个工具就加 5-7 万 token schema 开销，每轮重发。解法是 CLI 解析 + 工具搜索，按需加载。

Q4. 「接地」vs「未接地」Agent 的关键差异是？

对。同样任务：接地 38 秒答对，未接地 20 分钟还答错。上下文工程是最有力的省 token 杠杆。
恭喜
🎓

你抓住了这篇文章的核心

AI 编程成本，是一个可解的工程问题。
先拆成方程，再逐项测量、逐项优化——靠消除浪费，而不是砍单价。

一句话带走的 6 个结论

1️⃣ 用量涨 7x，成本稳定 —— 靠消除零价值 token。

2️⃣ 成本方程：用户×会话×请求/会话×Token/请求×价格/Token。

3️⃣ 模型选择：基准驱动 + Pareto 最优，子 Agent 默认弱模型。

4️⃣ 砍 Token/请求：自动压缩、Medium 推理、缓存 TTL、CLI 解析、code-mode。

5️⃣ 砍请求/轮：Context Graph 让 Agent「接地」。

6️⃣ 核心战略：从「交互式工作流」转向「全受管 Agent」。

原文：《Running a Software Factory Efficiently at Uber Scale》by Uber Engineering

本页为互动教学演示，基于 Uber Engineering 的原文 提炼整理，仅供学习。