来源 · Uber Engineering / X: 阿易 AI Notes
Running a Software Factory Efficiently at Uber Scale
来源
原始文章、报告或对话- 出处
- Uber Engineering / X: 阿易 AI Notes
- 链接
- x.com/AYi_AInotes/status/2093864816079208512
- 采集
- 2026.08.31
摘要
Agent 采集整理，不是原文Uber Engineering 发布技术长文披露：全公司 70% 的代码 PR 已由 AI Agent 接管，API 调用量半年增长近 10 倍，但总 AI 账单零增长，单次会话成本降低 52%。五项具体降本手段包括：强弱模型分工（规划用大模型、执行用轻量模型）、上下文缓存从 5 分钟延长至 1 小时（续用原价 1 折）、1000+ 内部 MCP 工具按需挂载（避免开局灌入 7 万 token 工具定义）、Code-mode 消灭话痨轮询（单项 token 省 90%）、2400 万节点知识图谱导航（问题定位从 20 分钟降至 38 秒）。日常流水线每天跑 3 万多次任务。
判断
对新闻本身的总结判断Uber 的案例证明，AI 成本曲线不是不可控的——调用量涨 10 倍而账单不涨，核心在于把 Agent 当作工程系统而非对话工具来设计。五项手段中，上下文缓存延长和 MCP 工具按需挂载是杠杆最高的两项：前者将重复上下文的边际成本压到 1 折，后者把工具定义的 token 开销从'固定成本'变成'变动成本'。
观察
这条新闻带来的延伸思考与趋势
当行业普遍焦虑'AI 账单贵到用不起'时，Uber 的实践指向一个结构性结论：问题不在模型定价，在于调用架构。多数团队的 AI 使用方式仍是'一问一答'模式，token 浪费在重复上下文传输和工具定义灌入上。Uber 的做法本质上是把云原生架构的成本优化思维搬到了 AI 调用层——缓存、路由、批量执行。对于正在构建 Agent 工作流的团队，这提示了一条可落地的路径：先审计 token 流向，再做架构级优化，而不是单纯靠换更便宜的模型来降本。