如果说上一章强调的是“模型选型本质上是在选能力组合”，那么这一章要进一步回答一个更现实的问题：当你已经接受“需要组合”之后，为什么生产级 Agent 几乎必然会走向大模型、小模型和分层路由的结构。
答案很简单，因为不分层的系统，通常活不过生产环境。
在实验阶段，把所有请求都交给最强模型，看上去是最省心的做法。逻辑简单，链路单一，效果上限也容易先拉起来。但系统一旦进入真实流量，这种做法很快就会暴露出四个问题：成本过高、时延过高、吞吐不足、能力浪费。
这里最核心的一点，是请求分布不均匀。
现实世界里的请求不是平均难度。少数请求真的复杂，需要深推理、长上下文、多轮工具和更强的生成能力；更多请求则是模式明显、目标固定、结构清楚，甚至可以被模板、规则、缓存和简单模型处理。把这两类请求全部送到同一个最强模型上，本质上是在用最高单价的能力处理大量低难度工作。
所以，分层不是炫技，而是一种经济学必然。
一个成熟系统往往会自然形成这样的能力梯队：
- 小模型或轻量逻辑，负责分类、路由、简单提取、拒答判断、结构映射、固定格式生成
- 中等模型，负责标准复杂度分析、常规工具调用和中等质量要求任务
- 大模型，负责复杂规划、冲突消解、长链推理、高价值生成和高风险任务
表面上看，这是在分模型；本质上，这是在给不同成本级别的智能能力安排合适的位置。
这里有一个非常重要的认识：小模型不是大模型的低配替代品，而是生产系统里专门承担高频、低延迟、低成本任务的关键角色。
很多团队一说到“小模型”，脑子里立刻出现“能力不够”。这个判断太粗糙了。对分类、抽取、意图识别、结构化映射、模板补全、简单路由、局部 summarization 这类任务来说，真正重要的往往不是绝对智力上限，而是单位成本、尾延迟、吞吐能力、部署灵活性和行为稳定性。只要任务边界清楚，小模型、蒸馏模型甚至规则模板的组合，常常比一直调用大模型更合理。
过去几年从 DistilBERT、TinyBERT 到今天各种蒸馏、小模型和任务专用化实践，已经反复证明一件事：在很多可定义、可评测、目标明确的子任务上，最佳工程解并不是“最大的模型”，而是“足够好的模型”。
这也是为什么领先平台越来越直接提供模型梯队，而不是只卖旗舰模型。官方产品线本身就在告诉开发者：同一业务里的不同环节，本来就该用不同等级的能力。
但仅仅有“大中小模型”还不够。真正决定系统是否有效的，是路由。
因为分层一旦成立，紧接着就会出现一个核心问题：什么请求该留在当前层，什么请求必须升级到更强层。
这就是升级条件问题。
升级条件定义得太松，系统会迅速退化为“几乎所有请求都走大模型”，成本失控，分层名存实亡。升级条件定义得太严，又会让真正复杂的请求被低能力层误处理，表面节约了成本，实际上牺牲了质量和风险控制。
所以，分层系统最关键的设计，不是“有没有多模型”，而是：
- 分层边界是否清楚
- 升级阈值是否可解释
- 默认兜底层是否明确
- 降级或回退是否安全
- 路由效果是否被持续评测
这也是为什么近年的 routing 研究越来越不只是讨论“怎么挑模型”，而是在讨论 query difficulty、uncertainty、deferral rule、fallback、budget constraint 和 routing eval。因为真正决定分层系统价值的，不是模型数量，而是不确定时怎么办。
从理论上讲，这可以被理解成一种“选择性处理”问题。系统需要允许自己在低把握时拒绝在当前层做最终决定，而是选择升级、回退或者交给默认强模型。这个思想早在传统机器学习里的 selective classification 就已经出现，只是在 LLM 时代，它变成了更复杂的多层路由和多模型级联。
于是，一个成熟的路由器，通常不只回答“把请求送给谁”，还隐含回答另外三个问题：
- 当前层的把握够不够
- 升级是否真的值得
- 如果升级失败，最后的兜底是什么
这就是为什么很多高质量研究和平台实现，都把路由和级联放在一起讨论。因为真正有效的结构，往往不是一次性静态分配，而是“先让低成本层尝试，再根据评分、阈值和预算动态决定是否继续升级”。
换句话说，分层路由不是一棵装饰性的决策树，而是一套预算约束下的连续决策系统。
这时，成本平衡的含义也会变得更精确。它绝不只是“哪个模型单价更便宜”，而是“在既定质量与延迟目标下，整个系统如何获得更好的有效产出”。
这里要特别纠正一个常见误解：大模型系统的成本，不是只由模型标价决定。
真实成本同时受以下因素影响：
- 输入 token 长度
- 输出 token 长度
- 上下文前缀复用程度
- 缓存命中率
- KV cache 占用
- batch 策略
- prefill 和 decoding 是否互相干扰
- 目标 SLA 下可实现的有效吞吐
也就是说，两套看起来调用同一个模型的系统，真实经济性可以完全不同。
如果一个系统 prompt 极长、前缀难以复用、上下文噪声重、KV cache 管理差、prefill 与 decoding 互相拖慢、缓存命中率又低，那么它即使选了“便宜模型”，也可能跑得非常昂贵。反过来，如果系统把前缀稳定下来、善用缓存、合理切分上下文、让高频任务留在小模型层，再用更合理的 serving 策略承载大模型，那么整体成本结构会完全不同。
所以，分层路由的背后，其实还站着一整套服务经济学。
很多经典 serving 论文已经说明，推理成本不是线性的“模型越大越贵”这么简单。prefill 和 decoding 对资源的要求不同，长上下文会推高 prefill 负担，KV cache 会挤压并发空间，而调度方式会直接影响吞吐和尾延迟。换句话说，大模型到底贵到什么程度，不只是模型本身决定，还取决于你如何服务它。
这就是为什么 prompt caching 这类机制会在今天变得如此重要。因为它实际上改变了真实输入成本的计算方式。对于长对话、长前缀、代码库、重复文档分析这类场景，只要前缀能复用，缓存就不再是“小优化”，而是直接进入成本模型的核心变量。
从系统设计角度看，这会反过来影响分层策略：哪些请求适合聚合成稳定前缀，哪些流程适合模板化，哪些任务值得走缓存友好的路径，哪些查询应该先经过轻量过滤再交给大模型。
到了这里，分层路由就不再只是“模型选择”，而是“请求治理”。
再从产品实践看，这种结构也早已不是理论图纸。越来越多企业案例都在采用类似的套路：小模型或 heuristics 做 routing 和 retrieval，大模型做 generation；规则、模板和 guardrails 先吃掉不需要复杂智能的部分；缓存负责处理重复上下文；复杂请求再逐级升级到更强模型。也就是说，真实系统已经默认把“不是所有事都值得调用大模型”当成常识。
因此，本章要强调的一个核心观点是：分层的本质，不是让系统看起来更高级，而是让智能能力按照经济价值分布。
一个没有分层的系统，常常会出现三种浪费。
第一种，是能力浪费。 简单请求占用高价值能力，导致高成本资源被低价值任务消耗。
第二种，是时延浪费。 本可以几十到几百毫秒完成的任务，被统一放进高时延链路。
第三种，是上下文浪费。 大量重复前缀、固定提示和稳定结构，被一遍一遍重新计算。
而分层恰恰是在逐一消除这些浪费：用小模型吃掉简单部分，用路由把复杂部分筛出来，用缓存和模板吃掉重复部分，用强模型只处理真正值得它处理的部分。
但这里也必须提醒一点：分层不是“模型越多越好”。
如果分层边界不清楚，路由阈值没有经过评测，回退机制不明确，甚至每一层职责都在漂移，那么多模型系统只会增加复杂度，而不会增加效率。一个糟糕的路由器，会比没有路由器更贵；一个没有清晰升级规则的分层系统，会比单模型系统更难 debug；一个没有回归评测的路由策略，会随着模型更新逐步失效。
所以，分层要成立，至少要满足四个前提：
- 每一层有清晰职责
- 升级条件可被验证
- 默认兜底明确
- 评测体系持续运行
只有这样，分层才能从“架构图很好看”变成“经济性真的更好”。
一个很实用的方法，是先用最强模型把全链路跑通，得到质量上限；再观察哪些步骤其实稳定、模式化、可结构化；然后逐步把这些步骤下沉到小模型、规则、缓存或模板；最后用评测验证整体质量是否仍在目标线之上。这个过程其实就是把系统从“智能昂贵型”不断打磨成“智能分层型”。
所以，本章真正要建立的认识是：
大模型、小模型和分层路由，不是可选的优化技巧，而是 Agent 走向规模化、可持续和可治理时的基本结构。它们解决的也不只是“省点钱”，而是在保证质量的前提下，把智能能力分配到真正值得它出现的地方。
因此，分层路由的本质不是模型花样，而是运行经济学。