智能体请求增长9.4倍，Uber如何让AI账单基本不涨

导语

AI 编程的规模化，难点已经从“能不能生成代码”转向“如何让大量智能体稳定、可控地工作”。Uber近日分享的软件工厂实践显示，从2026年2月到8月中旬，公司所有智能体产品的周活跃用户增长约7倍，周请求量增长9.4倍，但AI总支出自4月以来基本保持稳定。固定模型进行对照时，每1000次请求的成本较峰值下降近34%，单会话成本较6月峰值下降52%。

这并不意味着模型能力没有成本，而是说明智能体系统中存在大量可以被工程化消除的浪费。

核心做法

1. 用真实任务决定模型，而不是盲目追求最强模型。 Uber为代码评审、软件工程任务等场景建立内部基准，综合比较任务成本、准确率、召回率、F1、延迟、超时和噪音，再选择处于“帕累托前沿”的模型配置。主智能体负责拆解和评估，子智能体处理边界清晰的执行任务，因此后者通常可以采用成本更低的模型。

2. 从每个请求的token账单入手。 交互式会话会反复携带历史对话、项目上下文和工具结果。Uber将自动压缩阈值设为40万token，并把默认推理强度设为中等，以减少高价输出token。同时，提示词缓存的有效期按会话特点区分：工程师会话更适合较长TTL，短生命周期的子智能体则保留较短TTL。

3. 改造工具协议，避免无关Schema污染上下文。 直接加载大量MCP工具定义，可能在用户输入前就带来数万token开销。Uber通过统一网关、CLI封装和工具检索，让模型按需发现工具；对于高频流程，再用代码模式把轮询和批量操作放到子进程中执行，只将摘要返回给模型。相同SQL任务的测试中，这一方式可减少超过一半token消耗，批量流程的节省幅度更高。

4. 用上下文图谱替代盲目搜索。 面对数亿行代码和海量数据资产，智能体常常把大量轮次消耗在“信息在哪里”。Uber构建了包含2400万个节点、8000万条边的AI上下文图谱，连接服务、团队、事故、PR、文档、数据集等信息，帮助智能体直接定位事实依据，减少错误探索、重复调用和无效子任务。

5. 让成本可见，并形成反馈闭环。 运行时状态行会显示实时支出，系统还通过分级预算、提醒和会话分析仪表盘识别模型错配、上下文膨胀、缓存失效及工具预加载等反模式，并给出可操作的节省建议。

意义与影响

Uber案例的价值不在于某个单独技巧，而在于把AI成本当成软件工程指标管理：先定义任务结果，再建立评测基准，随后持续优化路由、上下文、工具和运行时。对于企业而言，降低账单不应等同于全面降级模型，而应优先减少重复输入、无效轮次和缺乏事实支撑的探索。

这套方法也有边界。相关成本数据来自Uber自身工作负载，且定价和供应商指标基于公开信息，不同代码库、团队规模与智能体流程未必能复现相同降幅。真正可迁移的，是“质量、可靠性与成本并行评估”的治理框架，以及将托管智能体作为统一生产系统运营的思路。

来源：InfoQ 中文