Uber 目前通过单一统一网关运行超过 1,000 次模型上下文协议（MCP）服务器交互，以实现集中化的策略执行。该公司分享了其在大幅降低生成式 AI 成本方面的关键经验。
此前，Uber CTO Praveen Naga 因透露公司在数月内“烧光”年度 AI 预算而引发关注。随后，Naga 发布系列文章阐述 Uber 如何通过调整底层杠杆削减 AI 成本，措施包括扩展供应商中立的管理型智能体、优化提示词缓存、提高工具和 MCP 使用效率、构建高效可复用的智能体技能，以及为工程师提供实时成本可视性。
用量激增，成本持平
Uber 杰出工程师 Uday Medisetty 在博客中披露，2026 年 2 月至 8 月期间，Uber AI 编码工具的周活跃用户数增长 7 倍，周智能体请求量攀升 9.4 倍，但自 4 月以来总花费基本保持平稳。若剔除优化努力带来的影响，Uber 将每千次请求的成本从峰值降低约 34%，单次会话成本降低约 52%。
Uber 默认将“辅助”任务分配给较小模型，仅顶级推理任务使用昂贵模型。其内部基准测试流程支持跨不同任务类型运行前沿模型和开放权重模型，并利用输出结果指导所有软件开发生命周期（SDLC）管理智能体的模型选择。Databricks、荷兰新银行 bunq 等企业也采用了类似方法。
破解 MCP 模式开销难题
Medisetty 指出，工具访问架构本身是一个关键成本杠杆。将更多智能体（负责代码审查、自动修复 CI 失败、端到端 PR 验证、警报分类、Bug 调试及代码维护等）连接到更多 SaaS MCP 服务器，会产生累积性的令牌成本，体现在每次会话的每一步操作中。
主要挑战在于第三方软件管理。供应商设计的 MCP 服务器旨在暴露完整产品功能，无法预见特定客户使用情况。例如，一个工作区套件将 49 个工具捆绑到单个服务器中，需要约 22,000 个令牌的模式数据；消息传递和项目跟踪供应商则分别提供 34 和 46 个工具。智能体携带的模式开销甚至超过用户输入提示词前正在编辑的文件大小。
Uber 表示，仅安装 100 多个工具，模式开销就使初始提示词的令牌数量增加约 50,000 至 70,000 个，且由于对话每一步都会重新发送完整历史记录，这种开销在会话每一步都会被重复计算。
三大途径实现降本
Uber 采取三种主要途径解决这一问题：
- CLI 工具解析：赋予模型运行 shell 命令的能力，在需要时针对网关解析并调用正确工具，避免模式数据占用上下文空间。所有 1,000 多个网关工具均以此方式暴露。
- 工具搜索：对于不适用 CLI 解析的场景，模型可搜索可用工具目录，按需拉取与特定任务相关的定义，而非预加载所有内容。该方法具备可扩展性，开销不随工具库规模增大而增长。
- 代码模式（批处理）：允许模型编写小脚本，在子进程中运行整个序列并将最终摘要返回，替代标准 MCP 中每个工具操作的独立往返交互。
这三种机制帮助 Uber 将单次会话的工具模式开销从 50,000–70,000 令牌的基础水平降至接近零，适用于通过同一网关路由的内部系统和第三方 SaaS 工具。此外，Uber 还为最常用工具构建了约 25 个预打包的“代码模式技能”，使高效模式成为默认路径。
Uber 强调，这些节省是基于其代码库、团队规模和工作流程的内部成果，具体数字无法直接复制，但其方法论（基准测试实际工作、分解成本、持续重新优化）旨在被行业借鉴和应用。