ARTICLE · 986873
Uber 如何用 AI Agent 把软件开发做成“工厂”——用量涨 9.4 倍,账单却稳住了
2026 年 8 月底，Uber Engineering 发布了一篇重量级博客《Running a Software Factory Efficiently at Uber Scale》（Uday Kiran Medisetty 撰写）。它不是又一篇“我们用了 Claude/Cursor 后效率翻倍”的故事，而是真正把 AI Agent 在企业级软件开发生命周期（SDLC）里规模化落地后的成本与运营问题讲清楚了。
核心数字很扎眼：
超过 70% 的 Pull Request 归因于本地或云端 Agent（有人类 review/escalation）。
工程师已构建 3600+ 个 Agent Skills，每天执行超过 3 万次。
从 2026 年 2 月到 8 月中旬：全公司（工程师 + 非工程师）每周活跃用户增长 7 倍，每周 Agent 请求量增长 9.4 倍。
总 AI 花费从 4 月起基本稳住。固定同一模型后，每 1000 次模型请求成本从峰值降约 34%，每个 session 成本从 6 月峰值降 52%。
这不是“换了更便宜的模型就完事”，而是一套系统化的 成本方程 + 分层架构 + 优化杠杆。下面拆开讲。
一、什么是“软件工厂”？
Uber 把 AI 使用分成 四层（从专用到通用）：层越高，对成本、质量、模型选择的控制越强。越来越多 session 不再由人类发起，而是由 Managed Agents（托管式智能体）自动处理：
AI 代码审查（uReview）
自愈 CI 失败
带视觉验证的端到端 PR
On-call 告警分流
Bug 调试
各种代码维护任务
人类只做 review 和升级处理。这已经从“工具”变成了“能自己开工的劳动力”。
他们把成本拆成可独立优化的几项（adoption × engagement × 中间各种 token/请求浪费）。前两项要继续增长，中间三项才是优化主战场。
二、成本优化的核心杠杆
1. 按真实工作负载选模型（Price / Token）
不是“默认最强模型”，而是：
- 用真实任务建 benchmark（例如 uReview 用带已知 bug 的真实 PR，分 easy/medium/hard，看 precision/recall/F1、成本、延迟、噪声）。
- 在统一 harness 上跑各种 frontier 和 open-weight 模型。
- 选 Pareto 最优（成本/完成任务、质量、可靠性）。
- 持续移动，因为 frontier 每几周就变。
子 Agent 默认用更弱、更便宜的模型（任务明确、输入明确，不需要顶级推理），主模型只负责分解和评估。这是目前最有效的杠杆之一。
2. 大幅砍掉每次请求的 Token（Tokens / Request）
默认配置：即使模型支持 1M context，也在 400k token 触发自动压缩；推理努力默认 Medium（输出 token 更贵）。
Prompt Caching：工程师经常离开会话超过 5 分钟，所以把 interactive session 的 TTL 从 5 分钟调到 1 小时（cache read 只要 0.1x 价格）。子 Agent 仍用短 TTL。
工具调用大改造：
统一 MCP Gateway 管理 1000+ 内部 + SaaS 工具。
不再把全部 tool schema 塞进 context（100+ 工具能加 5–7 万 token，每轮都重复付费）。
改成 CLI 动态解析 + 工具搜索（按需加载）。
Code-Mode：让模型写脚本在子进程里批量执行工具（尤其是聊天式协议，比如 SQL 查询要轮询多次）。简单查询能省 50–70% token，宽结果集接近 100%，批量工作流超过 90%。
3. 减少无效轮次（Requests / Turn）
最大杀手是“Agent 在瞎找东西”。Uber 建了 AI Context Graph：约 2400 万节点、8000 万边，整合 30+ 内部系统（服务、团队、事故、PR、设计文档、部署、数据集、历史查询等），Agent 用自然语言查询。
对比实验：有图的 Agent 38 秒给出正确答案；没图的花了 20 分钟、开了 2 个子 Agent、报了 3 次错，还得出错误结论。
4. 可见性与教育，而不是硬性封顶
终端状态栏实时显示本次 session 和累计花费。
共享花费层级 + Slack 在 50%/80%/100% 时提醒。
升级需要经理审批，但流程很快。
Session 分析仪表盘：直接扫 trace，自动标出 16 种反模式（错误模型路由、context 膨胀、缓存过期、初始化开销过大等），并给出金钱影响和修复建议。
三、更深层的战略启示
从交互式会话转向 Managed Agents
单个工程师在终端里聊天很难系统优化。把工作搬进托管环境后，模型路由、执行 harness、运营成本全部可控。每个 Managed Agent 配专属 benchmark 和 Pareto 模型，比优化几千个个人 session 更高效、更可扩展。用“结果单价”衡量，而不是“token 单价”
看 cost per merged PR、cost per review、cost per alert，同时跟踪质量（revert rate、F1、MTTR）。这才是真正的 ROI。平台优先于 Agent 本身
他们背后有完整基础设施：Model Gateway（日处理 1 亿+ 请求）、MCP Gateway、预热的 DevPods、Skills Marketplace、Context Graph、统一助手 Cortana 等。没有这些，Agent 很容易变成“能跑但贵且不可靠”的玩具。方法论可复制，量级不可
真实工作负载 benchmark、成本拆解、缓存与工具调用优化、可见性反馈循环——这些原则适用于任何规模。但 2400 万节点的图、统一网关、大规模 Skills 市场，需要平台团队投入。小团队可以先从“默认更便宜模型 + 工具 schema 不进 context + 实时成本可见”做起。
写在最后
Uber 的故事证明：Agent 做生产级工作不是能不能的问题，而是 运营纪律 的问题。用量可以指数级增长，成本可以稳住甚至下降，前提是你把“浪费的零价值 token”当成工程问题来系统解决，而不是只靠模型降价或简单限流。
他们自己总结得很精准：核心战略转变是从“工程师交互式工作流”走向“完全托管的 Agent 舰队”。优化一群带 benchmark 的专用 Managed Agents，远比优化成千上万个个人终端 session 更划算、也更可持续。
如果你正在公司里推 AI Coding Agent，这篇博客值得反复读。真正的瓶颈已经从“模型能力”转向了“如何把 Agent 当成可运营的生产线来管理”。