9月初有一则数据被不少技术社区转载：Uber内部构建了超过3600个AI Agent技能，日均执行任务超过3万次，其中七成的PR代码审查已经交给Agent完成。更值得关注的是效率曲线——2026年2月到8月，Agent的周活跃用户增长了7倍，请求量增长了9.4倍，但总的AI支出基本持平。据披露，这背后的关键是一套"六因子成本公式"，用于优化模型路由、Token缓存和调用策略，最终把每千次请求的成本压低了34%，单次会话成本压低了52%。
这组数字之所以值得细看，不是因为"降本"两个字本身，而是因为它指向一个几乎所有高频调用Agent系统都会撞上的问题：当调用量指数级增长时，成本能不能只是线性增长，甚至不增长。
为什么"一个模型打天下"撑不住规模
多数团队搭建Agent系统的第一版架构，往往是所有请求统一路由到同一个大模型。这套方案在验证阶段没问题——请求量小，容错空间大，工程投入也省。但一旦进入规模化运行，问题会集中暴露：
- 大量请求其实是重复或低复杂度的，用旗舰模型处理是明显的算力浪费；
- 上下文越攒越长，重复计算的部分越来越多，Token成本随调用次数线性甚至超线性上涨；
- 没有分级机制，一次简单的确认类任务和一次复杂的多步推理任务，付出的算力成本是一样的。
Uber的六因子成本公式没有公开完整细节，但从其"模型路由+Token缓存+调用策略"三个动作可以反推出一个相对成熟的通用思路：先分层，再决定谁来处理，能不重复计算的部分尽量不重复计算。
分层路由的基本形状
把一个Agent系统拆成"规划层"和"执行层"两层，是目前业内验证过的一种可行路径：规划层负责理解意图、拆解任务、决定策略，通常需要更强的推理能力；执行层负责具体执行动作，大部分场景下用轻量模型甚至规则引擎就能完成，只有在置信度不够时才升级到更强的模型。
用伪代码表达大致是这样：
def route_request(task, context):
# 第一步：缓存命中检测，避免重复计算
cache_key = build_cache_key(task, context)
cached = cache.get(cache_key)
if cached and not is_stale(cached, task):
return cached
# 第二步：复杂度评估，决定初始路由
complexity_score = estimate_complexity(task)
if complexity_score < LOW_THRESHOLD:
result = execution_model.run(task, context) # 轻量模型/规则引擎
else:
result = planning_model.run(task, context) # 高能力模型
# 第三步：置信度校验，低置信度触发升级
if result.confidence < CONFIDENCE_THRESHOLD and complexity_score < LOW_THRESHOLD:
result = planning_model.run(task, context) # 升级重试
cache.set(cache_key, result, ttl=compute_ttl(task))
return result
这套结构里有三个动作在真正起降本作用：缓存前置（避免同类请求重复算）、按复杂度分流（大部分请求走轻量路径）、置信度兜底（低置信度才升级，而不是一开始就用大模型兜底所有场景）。三者叠加，才有可能在请求量增长9.4倍的情况下把总支出摁住。
对长时运行、高频调用系统的参考意义
这套架构思路并不只对代码审查类Agent有用。任何需要长时间运行、持续产生调用请求的系统——比如需要连续处理语音流、逐句转写并做语义判断的场景——都会面临类似的成本曲线问题：调用频次高、上下文累积快、大部分片段其实是常规内容，只有少数片段真正需要复杂语义理解。
对这类系统而言，分层路由的意义不只是省钱，更是让"贵的能力"用在刀刃上：常规内容交给轻量模型或规则层快速处理，只有触发风险信号或语义模糊时才升级到能力更强的模型做二次判断。这也是为什么"模型路由"正在从一个成本优化手段，逐渐变成长时Agent系统的默认架构选择，而不是可选项。
