Uber 的软件工厂，真正在调度的不是代码，而是智能体。超过 70% 的 PR 由本地或云端 agent 完成，工程师在 SDLC 里攒了 3600 多个 agent skill，每天调用超 3 万次。从 2026 年 2 月到 8 月，全员周活跃用户涨了 7 倍，但 AI 总支出自 4 月以来趋于平稳。
会话运行的四个层级
从最专业到最通用，我们把 AI 采用分成四层。层级越高，对成本、质量和模型选择的掌控力越强。
专业化智能体（Specialized Agents）跑在 Uber 云上，由智能体驱动加人工在环。覆盖代码生成、验证、部署、观测、维护五个环节，对应 Minion（意图到 PR）、u Review（PR 到代码审查）、Agentic XP（实验完成到结果解读）、Conan AI（告警到 AI 根因分析）、Fawkes（定时任务到维护）。每个都有以结果计量的成本指标，比如每个合入 PR 的成本、每次审查的成本、每次告警的成本、每次清理的成本。任务边界最窄，有真实基准，可以跑帕累托最优的模型，每一美元都对应一个工作单元。
通用智能体（General Agents）是交互式的，跑在 Uber 云上，同一技能以托管方式运行。代表是 Cortana：零配置、无处不在的智能体任务执行，可调用任意技能，按每次查询计费。
带技能的会话（Sessions w/ Skills）是交互式的，跑在你的笔记本上，同一技能在本地运行。可以用 3600 多个黄金技能完成智能体任务，按每次会话计费。
原始会话（Raw Sessions）也是交互式的，跑在笔记本上，上下文自己带。用 Claude Code、Codex、Open Code 等工具，靠提示词、上下文和引导完成任务，按每次会话计费，但没有任务边界。
成本方程：六个相乘的项
任何一个层级的智能体会话，成本都能拆成几个可独立度量和调优的项：
总支出 = 用户数 × 每用户会话数 × 每会话轮次数 × 每轮次请求数 × 每请求 token 数 × 每 token 价格
前两项代表采用度和参与度，我们希望它们在整体用户群中持续增长。中间三项才是调优空间：它们是智能体在工程师实际发起的请求之上、为自己做的工作。大部分精力都投在这里，包括帮智能体更快规划、压缩多余轮次或错误、优化输入 token 等机制。
度量体系：按周按月跟踪什么
我们按周和按月跟踪一整套指标，支撑短期和长期预估。
组合层（Portfolio）：总归因成本、去重归因用户数、每个工具或智能体的成本、用户数与支出占比。回答钱花在哪、是哪个工具带来的变化。
单位经济性（按工具）：每用户成本、每用户请求数、每 1000 次请求成本、每次请求的输入输出和总 token 数、每百万 token 成本、每 1000 次会话成本、每活跃会话小时成本、提示词缓存命中率。回答工具是真的变便宜了，还是只是用量转移了。
模型经济性（按模型）：成本与成本占比、请求量与请求占比、每 1000 次请求成本、每百万 token 成本。回答哪些模型发布切实改变了账单，是在相同还是不同的单 token 价格下。
驱动因素分解：成本变化按顺序拆成使用度（用户数）、参与度（每用户请求数）、输入工作负载（每请求输入 token 数）、输出工作负载（每请求输出 token 数）。精确解释数字为什么变动，不留无法解释的残差。
托管智能体结果：对每个托管智能体，以结果计量的成本（每个合入 PR 的成本、每次审查的成本、每次告警的成本、每次清理的成本）、质量信号（回滚率、F1、MTTR）、体量（合入的 diff 数、发布的审查数、分诊的告警数）。回答每个托管智能体是否在每单位交付价值上变得更便宜，质量在模型迁移中是否保持平稳。
优化杠杆总览
对应成本方程的每一项，有一组杠杆：
每 token 价格：基准驱动的帕累托最优模型选择、模型默认设置。
每请求 token 数：默认 40 万 token 上下文上限与中等推理强度、提示词缓存、工具搜索与经 CLI 解析的 MCP 触发、工具触发的代码模式批处理、经网关路由的 SaaS MCP。
每轮次请求数：图谱锚定的上下文、持续的技能优化。
可见性与教育：状态栏实时成本计数器、可见性与支出档位、会话分析仪表盘。
调优每 token 价格
token 价格由厂商定，但哪个模型跑哪个工作负载由我们决定。在所有托管智能体层级，我们为该工作负载选最具帕累托效率的模型。帕累托效率意味着成本除以完成任务数、输出质量和模型安全性三者的综合。
模型选择分四步，对每个托管智能体都一样：
用该智能体的真实工作搭建基准验证。
在一个运行框架（harness）上跑该智能体，框架能在同一 API 后接入任意模型，前沿的或开放权重的都行。
切到当前帕累托最优的模型，并持续切换。前沿每隔几周就会移动一次。
面向未来，我们持续利用自托管智能体的聚合洞察来测试和上线各种模型路由策略，由此持续优化工作负载表现。
以 u Review 为例，它负责所有 PR 的 AI 代码审查。我们用带已知 bug 的真实 PR 搭建基准，按简单、中等、困难分层。针对这些 bug 评估精确率、召回率和 F1，同时评估每次审查的成本、延迟、超时和噪声。切换模型在大幅提升 F1 的同时明显压低了每个 PR 的成本。图中虚线是帕累托前沿线，位于其左下方的所有点都被某个更便宜或更好的设定超越。
我们还利用大型 monorepo 中数千个真实 PR，在内部建立了 Uber SWE 基准，让前沿模型和开放权重模型跨不同任务类型评测，为整个 SDLC 托管智能体的模型选择提供依据。
交互式界面里 token 单价是固定的，但你可以策略性地管控 token 在不同模型之间的分配。有两个默认设置主导这种分配：会话初始模型和子智能体（subagent）模型。
子智能体默认设置被证明是最有影响力的杠杆，而且重要性还在增长。发起子智能体的会话比例持续上升，最新模型能力让多智能体编排更加有效之下更显突出。我们将其默认设置为一个更弱、更经济的模型，仍允许手动覆盖。主模型负责作业分解和结果评估，子智能体负责执行细化工作，通常不需要前沿层级的推理能力。
调优每请求 token 数
每一轮次都会重新发送完整的对话历史、工程上下文和工具结果。任何能压缩单次请求负载的手段，回报都会在整个会话中复利累积。
所有交互式运行框架都使用统一的封装层来做安装管理、配置、认证和成本可视化。其中两项基准化默认配置直接压低了每次请求的 token 消耗：
即使对 100 万 token 上下文窗口的模型，也在 40 万 token 时自动触发压缩（compaction）。这一阈值在模型性能与缓存突发、重复输入 token 开销之间取得平衡。我们的测量显示，全局范围的每请求输入 token 数出现了有意义的下降。
推理强度默认为中等（Medium）。在主力模型上，输出 token（包括内部推理 token）的计费费率是输入 token 的数倍，这一策略调整直接压低了最高成本 token 类别的支出。对一大类作业，中等推理强度在成本与质量之间取得了良好平衡。
提示词缓存策略由厂商提示词缓存读写的经济性决定。缓存前面的上下文可以避免反复支付全价，使后续读取的成本降至基准输入 token 费率的 0.1 倍，原因在于每一轮次都会重新传输完整对话历史。不过写入溢价各不一致：5 分钟缓存条目的写入成本是 1.25 倍，1 小时条目则是 2 倍。所以，选最优 TTL（存活时间）取决于轮次之间间隔的时长。可用的 TTL 选项包括 Anthropic 提供的 5 分钟和 1 小时，以及 OpenAI 提供的 30 分钟。
我们将默认的 5 分钟 TTL 切换为 1 小时窗口，因为工程师经常让交互式会话空闲超过 5 分钟。这些频繁的空闲间隔此前会让前缀缓存失效，迫使系统以全价重建上下文。相比之下，子智能体保留 5 分钟缓存 TTL，因为它们的执行范围仅限于单个短生命周期任务。
通过 Shell 执行 MCP 工具
在 Uber，所有 MCP（模型上下文协议）交互都通过一个统一网关路由。这个单一入口覆盖 1000 多个 MCP 服务器，包括内部 MCP 和第三方 SaaS MCP，实现集中认证和策略执行。
但默认 MCP 会把所有工具的 schema 直接加载到每个会话中，无论工程师在该会话中是否会触发它们。部署了 100 多个工具时，这种预加载会给初始提示词增添约 5 万到 7 万 token 的 schema 开销。
为解决这种上下文膨胀，我们引入了两种互补的调优机制：
CLI 工具解析：用让模型执行一条 shell 命令取代直接 MCP 集成。CLI 在触发时动态地向网关解析并调用所需工具，从而把 Uber MCP 的 schema 从会话上下文中彻底移除。我们内部 MCP 网关的整体 1000 多个 MCP 工具都被投射为 CLI 命令。
工具搜索：让模型可以搜索工具目录、按需只加载所需工具，进而扩展到数千个工具。通常能减少工具定义的 token 占用，而且即使可用工具库不断扩大也能维持较高的选择精确率，这种方法缓解了上下文膨胀。
代码模式：把轮询循环移出上下文
当工具以 shell 命令的方式直接调用函数时，模型可以在单个脚本中批量执行多个动作。这种批处理对话痨型工具协议特别有利。在标准 MCP 工作流中，每个动作都需要一个单独的模型轮次来发出请求、把原始响应加载进上下文窗口、再顺序处理结果。比如，执行一条 SQL 查询需要提交请求、轮询状态 2 到 5 次、再取回输出。代码模式把这一整套流程精简为一个无人化的 Python 循环，使中间轮询完全不进入模型的活跃上下文。左侧，模型亲自参与轮询循环，每个响应都落入它的上下文；右侧，循环在子进程中运行，只有摘要返回。
我们在同一会话中通过两条路线运行了 5 条一致的 SQL 查询来测量：
前三行揭示了主导结论：即使结果集极小、远低于响应大小限制，代码模式也能将 token 用量减少 50% 以上。这些效率并非来自绕开大体积数据负载，而是来自消除不必要的开销，包括 schema 初始化、多轮轮询和冗余的渐进推理。
批量工作流会使效果复利放大：原本需要 N 个模型轮次的循环变成一个脚本，节省幅度累积超过 90%。我们保证标准工作流默认走最经济的路径，依托为访问频率最高的 MCP 服务器部署 25 个以上预构建的代码模式技能。
SaaS MCP 的管控
管控第三方软件比我们内部工具困难得多。厂商构建 MCP 服务器时会暴露产品的全部能力，因为他们无法预判具体客户的使用方式。比如，某办公套件把 49 个工具打包进一个工具集，需要约 2.2 万 token 的 schema；而某即时通讯厂商和某工程跟踪厂商分别附带 34 个和 46 个工具。加载两三个厂商工具集后，智能体背负的 schema 开销在用户输入第一个提示词之前就已超过它要编辑的文件本身。
为解决这个问题，我们把 SaaS MCP 服务器通过我们的 MCP 网关路由，使用与内部 MCP 一致的机制。我们还把所有这些 MCP 暴露为 CLI，供任何智能体界面触发。此外，我们在代码模式组件中为每个服务器编写专门的技能，以封装常见工作流。这解锁了跨众多 SaaS 厂商的高效率智能体工作流。
调优每轮次请求数
一个缺乏上下文锚定的智能体失败得又慢又贵，它会反复发送不断膨胀的上下文窗口，只为再多搜一个地方。在一开始就带来更丰富的信息，仍然是压缩这种搜索开销唯一最强大的杠杆。
数亿行代码、数千张数据表，智能体的大部分轮次都花在锚定信息上，在 Uber 庞大的代码与数据生态中。为此，我们构建了 AI 上下文图谱（AI Context Graph）：一个包含 2400 万个节点和 8000 万条边的统一网，覆盖 86 种节点类型和 117 种边类型。它整合了来自 30 多个内部系统的数据，包括服务、项目团队、事故记录、PR、架构设计说明、上线、数据集和历史表使用查询，并允许任何智能体用自然语言查询它。
同一提示词提交给同一模型，有图谱锚定的智能体查询了历史使用记录，定位到那张被 50 多位分析师使用的特定表，并在 38 秒内给出了答案。相反，没有锚定的智能体看不到那张表，派生出 2 个子智能体，撞上 3 个错误，它花了 20 分钟检查服务代码。
可见性与反馈回路
这一组杠杆是可见性和反馈回路，帮助工程师和智能体更快收敛。
我们在运行框架的状态栏中放了一个实时成本计数器，跟踪每个运行框架的实时花费，以及每个用户跨所有运行框架的总花费。
为避免硬性限额，我们实现了实时支出跟踪和自助提醒：
状态栏实时计数器：运行中的会话成本始终显示在终端里。
运行框架池：所有交互式运行框架共用一个档位，而不是按工具分别预算；托管智能体则有单独的档位。
Slack 提醒：在预期支出的 50%、80%、100% 处发出预警，使工程师有时间规划。
便捷的审批链路：档位升级由经理签批，迅速生效。
成本检查技能与提示：一个仪表盘技能，可按需查看成本明细，并在状态栏提供实时指导。
这些机制让工程师可以自行评估作业的投入产出比（ROI），同时抑制失控的开支。
状态栏虽然突出了一个会话的总支出，但无法看到成本驱动因素或可执行的改进步骤。通用指南带来的是高层原则，无法评估每个开发者个人的工作流。会话拆解仪表盘通过直接检查会话产物弥合了这一差距。
它直接内置于运行时中，无需任何设置或开通。执行 cost dashboard 技能会拆解该用户在其使用的所有运行框架上、跨本地和远程云沙箱的全部会话轨迹。它不是产出一个聚合度量，而是跨会话标记出 16 种不同的反模式，并为每种反模式配上其财务影响和针对性的修复建议。部分类别包括：
模型路由欠佳：在 Opus 上执行 Sonnet 完全能胜任的简单多轮会话。
上下文窗口膨胀：大型 MCP 负载（比如 40KB 的响应）滞留在上下文中，在后续轮次中反复计费。
缓存过期低效：长时间中断后恢复会话，过期的提示词缓存迫使系统以全价重建前缀。
提示词初始化开销：在用户输入任何内容之前，就预加载了 10 万 token 的系统指令和工具定义。
下一步在推什么
扩充托管智能体集群：对每个新智能体，我们遵循一致的路线图：确立目标结果度量、组建评估基准、确定帕累托最优模型。这套体系化方法旨在将 SDLC 的每个阶段都推向工厂成熟度模型的更高层级。
动态模型路由：我们正把基准覆盖边界扩展到更多编程语言、代码仓库和智能体形态。鉴于模型能力差别巨大，有效的模型路由高度依赖全面的评估。
深化上下文图谱集成：我们正在为更宽泛的自主智能体解锁图谱查询能力。
把会话分析演进为实时工程师指导：通过从周期性批量检测反模式转向持续的轨迹观测，我们的目标是直接向工程师提供个性化的实时效率建议。
持续的技能改进：我们正在研究一种自动化方式，从智能体技能执行中记录小痛点（papercut），并从收集到的轨迹中自动生成技能更新。
管控和遏制不断上涨的 AI 编码开支，同样是一个可解的工程问题。我们在用量扩大 7 倍的同时，实现了各项指标单位成本的下降，并维持甚至抬高了输出质量，而不是仅仅依赖更低的单价或降级工具。
核心的战略转变是从交互式工程师工作流转向完全托管的智能体。把 SDLC 工作负载迁移到托管环境中，就能完全掌控模型路由、执行框架和运营支出。优化一个由专业化托管智能体构成的集群，每个智能体都配有专门的评估基准和一个帕累托高效的模型，本质上比优化数千名工程师的个体终端会话更具成本效益，也更具可扩展性。
