Uber 的 Agent 软件工厂实践：六因子成本方程

贾克斯

Uber 的 Agent 软件工厂实践：六因子成本方程

来自
@UberEng
团队
@udaykiran
分享在全公司落地 AI Coding Agent 的完整运营体系。
https://uber.com/us/en/blog/efficient-software-factory/

过去的半年，Uber 实践带来的核心变化：
· 70%+ 的 Pull Request 由本地或云端 Agent 完成
· 自建 3600 个 Skills、每天 3 万次执行
· 周活跃用户增长 7 倍，周请求量增长 9.4 倍，但总 AI 支出自 4 月起基本持平
· 固定同一模型做对照：每千次请求成本从峰值下降 34%，每会话成本从 6 月峰值下降 52%

# Uber 的方法论框架

1. 四层架构 + 成本方程。 Uber 把 Agent 会话组织为四层（从专用到通用，越高层对成本/质量/模型选择的控制力越强），并把每次会话成本分解为六个相乘的因子：用户数 × 每用户请求数 × 每请求输入 token × 输出 token × token 单价等。前两项（采用率）要促增长，中间三项（Agent 自身产生的额外开销）是优化主战场。

2. 度量体系。 按周/月追踪五层指标：组合层（钱花在哪）、单位经济（每用户/每请求/每 token 成本）、模型经济（哪个模型发布真正改变了账单）、驱动因子分解（成本变动精确归因、不留残差）、托管 Agent 产出（按"每个合并 PR / 每次 review / 每条告警"计价，并监控回滚率、F1、MTTR 等质量信号）。

# 关键优化手段

模型选择——用真实工作做基准测试。 以代码评审 Agent uReview 为例：用真实 PR（含已知 bug、分难度）建 benchmark，测精度/召回/F1 + 成本/时延，在同一 harness 后切换任意模型，持续迁移到 Pareto 最优点——换模型后 F1 提升的同时单次评审成本大幅下降。另一个大杠杆：子 Agent 默认用更弱更便宜的模型，主模型只负责拆解和验收。

Token 压缩——每一轮都重发全部上下文，所以每省一点都会复利放大：
· 400K 自动压缩阈值（即使是 1M 上下文模型）+ 推理强度默认 Medium
· Prompt 缓存 TTL 经济学：缓存读仅 0.1 倍价格，但 5 分钟写入 1.25 倍、1 小时写入 2 倍。因工程师常闲置超 5 分钟，交互式会话改用 1 小时 TTL；短命的子 Agent 保持 5 分钟
· MCP 工具改走 CLI：100+ 工具的 schema 预载会占 50K–70K token 且每轮重发。Uber 把 1000+ 内部 MCP 服务统一走网关、投影为 CLI 命令按需解析，配合"工具搜索"按需加载
· Code-mode 批处理：把"发查询→轮询 2–5 次→取结果"这类多轮交互改成一段 Python 脚本在子进程跑，只回传摘要。实测同样 SQL 查询省 55%–71% token，宽表查询省近 100%；批量工作流节省超 90%
· SaaS 厂商的 MCP（动辄 34–49 个工具、数万 token schema）同样收编进网关 + CLI + 专用 Skills

上下文工程——最贵的浪费是"Agent 找不到信息"。 Uber 构建了 AI Context Graph：2400 万节点、8000 万条边，整合 30+ 内部系统（服务、团队、事故、PR、文档、部署、数据集血缘）。对照实验：有图谱的 Agent 38 秒答对；没有的花了 20 分钟、起了 2 个子 Agent、报 3 次错，最后还得出错误结论。

可见性与教育（软性）： 终端状态栏实时成本计数器；按 50/80/100% 预期花费发 Slack 提醒而非硬性限额；会话分析仪表盘自动识别 16 种浪费反模式（如简单任务用了 Opus、大 payload 滞留上下文、缓存过期后全价重建、开场预载 10 万 token 指令等），并给出具体金额影响和修复建议。