Uber 软件工厂实践：如何规模化管理 Agent、Token 成本与模型路由

当 AI 编程从个人工具变成团队基础设施，问题就不再只是“哪个模型更聪明”，而是：如何让数千个 Agent 稳定运行，如何知道成本花在哪里，如何让不同任务使用合适的模型，以及如何避免工具定义和上下文把每次请求越堆越大。

Uber Engineering 在 2026 年 8 月发布的《Running a Software Factory Efficiently at Uber Scale》，分享了他们在大规模软件开发流程中管理 Agent、模型、工具、上下文和成本的经验。原文披露的规模数据属于 Uber 自身环境，不能直接外推到其它团队；但其中的拆解方法非常适合用来设计 GPT88 API 和 Agent Harness 的成本治理体系。

本文重点整理方法论，不复述所有内部系统名称，也不把 Uber 的内部数据当作 GPT88 的性能或价格承诺。

一、软件工厂不是“给每个人发一个聊天机器人”

软件工厂可以理解为一套围绕软件生命周期运行的 Agent 生产系统：

需求、代码、测试、发布和运维
              ↓
       多个专用 Managed Agent
              ↓
   统一 Harness、模型路由、工具和观测
              ↓
     质量、成本、可靠性和人工升级

这类 Agent 不只负责写代码，还可以处理：

• 代码审查；
• CI 失败自愈；
• E2E 测试与视觉验证；
• On-call 告警分诊；
• Incoming Bug 调查；
• 依赖、文档和代码维护；
• 需要人工复核的高风险操作。

核心变化是：越来越多的工作不是由人主动打开工具开始，而是由受控的 Managed Agent 按规则、事件或计划触发。

二、四层 Agent 使用模型

Uber 将 Agent 使用组织为从通用到专用的四层。层级越高，团队对模型、工具、流程和成本的控制通常越强。

层级	典型形态	优点	成本与治理特点
个人交互层	工程师在终端或 IDE 中直接使用 Agent	灵活，适合探索和临时任务	成本与质量依赖个人习惯
团队 Harness 层	统一配置、认证、工具和上下文的交互环境	行为更一致，容易观测	可统一默认模型、缓存和预算
Managed Agent 层	专门处理 Code Review、CI、告警或 Bug 的 Agent	输入输出明确，适合自动化	可以建立专属 Benchmark 和模型路由
软件工厂层	多个专用 Agent 组成完整 SDLC 流程	规模化、可持续运营	需要统一成本、质量、权限和人工升级

不要一开始就追求最高层级。适合的进阶顺序是：先把个人任务跑稳定，再抽象出团队 Harness，最后把边界清晰、重复度高的工作变成 Managed Agent。

三、先拆成本，再讨论“如何省钱”

Agent 会话成本不应只看模型单价。更有用的拆解方式是：

会话成本
≈ 活跃用户 / 调用量
× 每个会话的请求次数
× 每次请求的输入 Token
× 每个请求的输出 Token
× 单位 Token 价格

如果使用缓存和子 Agent，还需要继续拆开：

• 模型单价；
• 输入 Token 数；
• 输出和推理 Token 数；
• 每个任务的 Turn 数；
• 工具 Schema 和工具结果的上下文占用；
• Cache Read 和 Cache Write 成本；
• 重试、超时和错误请求；
• 子 Agent 的数量与模型选择；
• 人工复核和最终返工成本。

这能避免一种常见误区：只盯着 Token 单价，却忽略了一个错误的工具调用、一次无效重试或一份过大的工具 Schema 会在整个会话中反复被重新发送。

两类指标要分开看

一类是采用和参与度指标：

• 周活跃用户；
• 周 Agent 请求数；
• 使用 Agent 的团队和项目数量；
• 交互式会话与托管任务的比例。

另一类是效率指标：

• 每千次请求成本；
• 每次会话成本；
• 每个完成任务成本；
• 成功率、超时率和重试率；
• 代码审查的 Precision、Recall 和 F1；
• 延迟、噪声和人工升级比例。

采用量增长本身不是问题。真正需要关注的是，单位任务成本、质量和可靠性是否同时得到控制。

四、模型选择：用真实工作建立 Pareto 前沿

不同任务不应该默认使用同一个最强模型。Uber 的做法是为每个 Managed Agent 建立真实工作 Benchmark，然后比较不同模型在成本、质量和可靠性上的表现。

Benchmark 的四步方法

1. 从 Agent 的真实历史工作中抽取样本；
2. 为样本建立已知答案、缺陷或验收标准；
3. 让不同模型在同一个 Harness 和输入条件下运行；
4. 比较完成任务成本、质量、延迟、超时和噪声，选择当前 Pareto 最优方案。

所谓 Pareto 最优，不是所有指标都第一，而是不存在另一个模型能够在成本更低的同时质量更高、可靠性更好。模型能力和价格会变化，所以前沿需要持续重测。

代码审查是一个好例子

可以用包含已知 Bug 的真实 Pull Request 构建评测集，再按简单、中等、困难分层。评价维度包括：

• 是否发现真正的缺陷；
• 是否误报无关问题；
• Precision、Recall 和 F1；
• 每次审查成本；
• 延迟和超时；
• 结果噪声；
• 是否需要人工复核。

一个模型即使单价更高，只要每次任务更容易通过验收、减少返工，实际的“完成任务成本”仍可能更低。反过来，单价便宜但经常失败的模型，也可能因为重试和人工修复变得更贵。

主 Agent 与子 Agent 不必使用同一个模型

主 Agent 负责任务拆解、上下文判断和最终评估，子 Agent 负责边界清楚、输入明确的局部工作。子 Agent 通常不需要最强推理能力，可以使用更便宜、更快的模型，并保留手动覆盖能力。

主 Agent：理解目标、拆任务、评估结果
    ↓
子 Agent：搜索、提取、格式化、运行局部检查
    ↓
主 Agent：汇总、复核、决定是否交付

这不是简单地把模型降级，而是根据任务职责做路由。子任务越明确，越适合使用成本友好的模型。

五、Prompt Cache：缓存策略要和会话节奏匹配

每一轮请求通常都会携带部分或全部对话历史、项目上下文和工具结果。Prompt Cache 可以避免重复按完整输入价格计算，但缓存写入和读取本身也有不同成本。

选择 TTL 时，要看用户多久会回来继续同一会话：

会话类型	更应关注的因素
连续快速交互	短 TTL 通常足以命中后续请求
工程师经常离开数十分钟	更长 TTL 可能减少缓存过期后的完整重建
短生命周期子 Agent	短 TTL 更容易匹配任务寿命
定时或批量任务	应按批次和启动间隔单独评估

不能只看到“缓存读取便宜”就把所有内容都放入缓存。缓存前缀应该稳定、可复用，并且不包含不必要的用户特定秘密或高频变化内容。

建议拆分：

稳定系统规则 / 工具契约 / 项目基线
          → 缓存前缀

当前任务 / 临时结果 / 高变化状态
          → 动态上下文

不同模型和 Provider 的缓存 TTL、读写价格和实现细节可能不同。使用 GPT88 时，应以当前模型目录、用量记录和控制台计费口径为准，不要把某一家 Provider 的缓存倍率硬编码成所有模型都相同。

六、MCP 工具太多时，不要把全部 Schema 塞进 Prompt

标准 MCP 集成的一个问题是：会话启动时可能将大量工具定义直接加载进上下文，即使当前任务根本不会调用其中大多数工具。

当工具数量上升，Schema 本身会产生三类成本：

• 首次 Prompt 变大；
• 每轮请求反复携带工具定义；
• 工具选择空间变大，模型更容易选错或重复调用。

方案一：按需搜索工具

不要让 Agent 一开始看到全部工具，而是提供一个工具目录搜索能力：

用户任务
  → 搜索工具目录
  → 只加载相关工具 Schema
  → 调用工具
  → 返回摘要结果

这种方式适合工具数量从几十增长到数百或数千的环境。

方案二：CLI Tool Resolution

将工具投影为 CLI 命令，模型需要时通过 Shell 调用，CLI 再在网关侧解析具体 MCP 服务和工具。

Agent → CLI 命令 → 工具网关 → MCP Server → 结果摘要

优点是工具 Schema 不必全部常驻当前会话，还可以集中处理鉴权、审计和策略。

但 CLI 不是自动安全的。必须限制：

• 可执行命令集合；
• 参数 Schema；
• 工作目录；
• 网络目标；
• Secret 访问；
• 输出大小和敏感字段；
• 写操作与人工确认。

方案三：Code-Mode 批量执行

如果工具调用需要查询、轮询、分页或多步组合，可以把循环放进受控脚本，让模型只接收最终摘要：

普通模式：模型发起 → 返回原始结果 → 模型判断 → 再发起

Code-Mode：模型生成脚本 → 子进程完成循环 → 只返回摘要

这可以减少中间轮次、重复 Schema、轮询状态和原始大结果对上下文的污染。批量任务中，原本 N 次模型 Turn 可能被压缩成一次脚本调用。

需要注意：Code-Mode 不能绕过权限。脚本执行环境仍应使用 allow-list、超时、资源限制、网络限制和审计日志。

七、上下文工程：让 Agent 更快找到答案

在大型代码库和数据系统中，Agent 花费大量 Turn 的地方往往不是生成代码，而是寻找信息：哪个服务依赖这个表，哪个团队维护这个模块，最近一次部署是什么，历史上类似故障如何解决。

“上下文工程”的目标，就是把这些关联关系提前组织起来，减少 Agent 漫无目的地搜索。

可以建立统一的 Context Graph，连接：

• 服务和仓库；
• 团队和负责人；
• Incident 和 Pull Request；
• 架构文档和部署记录；
• 数据集、数据表和历史查询；
• 变更、告警和运行环境。

这类图谱不一定要一次性做成巨型平台。小团队可以从一个任务索引开始：

文件 / 服务 / 表
  → 所属团队
  → 相关文档
  → 最近变更
  → 常见故障
  → 验证命令

目标不是给模型更多资料，而是更快给它正确资料。没有上下文的 Agent 可能不断搜索、启动多个子 Agent、反复失败，最后仍然得出错误结论；有结构化上下文的 Agent 可以更早锁定入口并减少无效请求。

八、可见性：让工程师知道成本和质量正在发生什么

如果 Agent 的成本只有月底账单才可见，用户很难及时调整行为。一个更好的 Harness 应该在运行时显示：

• 当前会话成本；
• 当前用户或工作区累计成本；
• 输入、输出和缓存用量；
• 请求次数、重试和超时；
• 当前模型和子 Agent 模型；
• 是否触发了预算或风险提示。

预算提醒比硬性封顶更灵活

可以设计分级提醒：

达到预期成本的 50% → 提示当前趋势
达到 80% → 建议拆分、换模型或暂停
达到 100% → 请求升级或人工确认

预算不一定要按单个工具分开。对于多个交互式 Harness，建立共享的用户级或团队级额度，有时比每个工具各设一个小预算更容易管理；自动运行的 Managed Agent 则可以有独立额度和升级流程。

会话分析要给出可执行建议

只显示“本次花了多少钱”还不够。会话分析应该定位成本驱动因素，例如：

• 简单任务却一直使用高价模型；
• MCP 结果过大，后续每轮重复携带；
• 长时间暂停后缓存过期，重新构建完整前缀；
• 系统提示和工具定义占用过多初始上下文；
• 反复重试相同的失败请求；
• 子 Agent 使用了不必要的高推理模型。

每个问题最好配一条具体建议：换模型、压缩上下文、改成工具搜索、调整 TTL、减少重试或拆分任务。

九、把这些经验转成 GPT88 Agent 的落地方案

第一步：先建立任务分类

把工作分成：

• 交互式探索；
• 代码生成和修改；
• 代码审查；
• 文档与知识检索；
• CI 和测试修复；
• 批量数据或媒体任务；
• 高风险生产操作。

每一类任务记录成功标准、可接受延迟、最大重试次数和人工升级条件。

第二步：为每类任务建立小型 Benchmark

不要先问哪个模型最强，而是准备 10—50 个真实样本，至少包含：

• 正常任务；
• 边界任务；
• 资料不足任务；
• 容易误判任务；
• 需要拒答或转人工任务。

用同一套 Prompt、工具和验收脚本比较候选模型，再记录任务完成成本，而不只是单次请求价格。

第三步：给主 Agent 和子 Agent 分配不同默认模型

主 Agent 负责理解、规划和验收；子 Agent 负责局部、明确、可验证的工作。子 Agent 默认使用更经济的模型，复杂任务允许人工覆盖。

第四步：控制工具上下文

把所有 MCP 工具一次性加载改成：

• 工具目录搜索；
• CLI 解析；
• Code-Mode 批量脚本；
• 结果摘要和分页；
• 高风险写操作人工确认。

第五步：把成本显示放进 Harness

最小版本至少显示：

模型：xxx
请求次数：x
输入 Token：x
输出 Token：x
缓存命中：x
重试次数：x
估算成本：x

动态价格和倍率应从 GPT88 控制台或当前用量数据获取，不要把价格写死在前端或 Skill 中。

第六步：把优化变成持续循环

采集真实任务
  → 建立 / 更新 Benchmark
  → 比较模型、Prompt、工具和缓存策略
  → 发布新默认配置
  → 观察质量、成本和可靠性
  → 记录失败样本
  → 继续改进

模型会更新，工作负载会变化，团队使用习惯也会变化。一次测出来的最优模型，不会永远最优。

十、常见误区

误区一：只比较模型单价

应该比较完成任务成本、成功率、返工和人工复核，而不是只看每百万 Token 价格。

误区二：所有任务使用同一个旗舰模型

简单提取、格式化、搜索和局部检查往往不需要最强推理。统一使用高价模型，会把大量成本花在不影响结果的地方。

误区三：把所有工具定义都放进系统 Prompt

工具越多，Schema 成本和选择歧义越高。应优先使用搜索、按需加载和 Code-Mode。

误区四：为了省钱关闭所有上下文

无上下文的 Agent 会花更多 Turn 去找路，甚至做出错误判断。正确目标是减少无效上下文，而不是减少所有上下文。

误区五：只做月度账单，不做运行时可见性

等月底才发现成本异常，通常已经错过了最便宜的修复时机。

误区六：把 Uber 内部数字当作行业基准

内部代码库、团队规模、供应商价格、缓存策略和工作负载都会影响结果。可复用的是测量和优化方法，不是具体百分比。

十一、验收清单

设计或优化 GPT88 Agent Harness 时，可以用下面的清单检查：

• 已按任务类型定义完成标准；
• 每个重要 Managed Agent 都有真实工作 Benchmark；
• 模型比较包含质量、成本、延迟、超时和重试；
• 主 Agent 与子 Agent 有不同的默认模型策略；
• 工具不会无条件把全部 Schema 加载进每个会话；
• 大结果、轮询和批量操作支持摘要或 Code-Mode；
• Prompt Cache 的 TTL 与会话间隔匹配；
• 上下文中不重复携带不必要的工具结果；
• Agent 能通过结构化上下文更快定位文件、服务和数据；
• 运行时能看到 Token、缓存、重试和成本；
• 达到预算阈值时会提醒、暂停或请求升级；
• 高风险写操作、部署和外部消息需要人工确认；
• 失败样本会回流到 Benchmark 和 Skill 改进流程；
• 动态模型、价格和配额以 GPT88 当前控制台和 API 返回为准。

总结

Uber 的软件工厂实践可以浓缩成一句话：把 Agent 当成需要 Benchmark、路由、预算、上下文、权限和运维的生产系统，而不是一个无限使用的聊天窗口。

规模化之后，真正有效的优化通常来自减少零价值工作：减少无效 Turn、减少重复输入、减少不必要的高价模型、减少全部工具 Schema 的预加载、减少失败重试和减少 Agent 漫无目的的搜索。

对 GPT88 用户来说，最实用的落地顺序是：先按任务建立验收标准，再用真实样本比较模型；随后为子 Agent 选择合适的成本档位，按需加载工具，压缩和缓存稳定上下文，并在 Harness 中显示实时用量与成本。这样既能扩展 Agent 使用规模，也能让每一次 Token 消耗都更接近实际业务结果。

本文整理自 Uber Engineering 的《Running a Software Factory Efficiently at Uber Scale》。文中的内部规模、成本变化和系统名称属于 Uber 的公开分享与其自身环境；本文提炼的是可迁移的方法论，不代表 GPT88 对相同结果、价格、模型能力或成本节省幅度作出承诺。