默认旗舰模型已成成本隐患：面向 Agent 工作负载的分层模型路由
两年来的习惯很简单：直接挑你负担得起的最强模型，就此收工。到了 2026 年，这个习惯悄无声息地变成了成本模型里的一个 bug。最明显的信号出现在今年夏天：一个更小、更便宜的“flash”档模型，在开发者最看重的任务——多步骤 agentic 编程——上逐渐胜过自家旗舰款，而价格只是零头。当便宜那档都能赢下高难度基准测试时，“无条件用旗舰”就不再是安全默认项，而是纯粹的浪费。下面说说怎么修，又不至于把整个技术栈搞成科研项目。
为什么这个习惯很贵
Agent 任务不是一次大调用。单个任务会扩散成几十个小步骤：规划、选工具、格式化参数、总结文件、决定要不要继续。这些步骤大部分都很简单。把每一步都塞给前沿模型，就像坐直升机去便利店——确实能到，但你为一段步行距离付了直升机价格。陷阱在于：单次调用的成本看不见，加起来却是个天文数字。你永远不会在某一次调用时意识到自己多付了钱；你看到的只是月末账单。
三档阶梯
按档位思考，而不是按模型思考：
- 便宜/快速档——分类、提取、短重写、路由决策、“要不要结束？”这类检查。大多数步骤都落在这。
- 中档——普通推理、代码修改、中等上下文长度的工具调用。
- 旗舰档——真正困难的推理、长上下文综合，以及那种“答错一步就污染下游一切”的关键步骤。
目标是把旗舰档留给真正需要的 5%–15% 的步骤，让便宜档去扛大头。
如何为每个请求分档
两个机制配合使用：
- 对明显的情况用静态启发式判断。短提示词 + 结构化输出 + 低风险 → 便宜档。任何涉及大上下文窗口或不可逆操作 → 升级。
- 其余情况用评估把关升级。先上便宜档，只有当你的评估证明便宜档在这类输入上确实不行时，才升级到更大的模型。这是最关键的原则：升级要靠证据挣来，而不是靠假设。
如果你拿不出一项评测来证明小模型在某个具体环节确实会输，那你就不该为大模型付费。一个简单的置信度信号也很有用——当廉价模型开始含糊其辞、输出格式出错，或者 log-probs（对数概率）很低时，就向上重试一层。就算多花一次上层模型的调用，也比把所有请求都直接丢给旗舰模型便宜。
然后是「度量，否则你就是瞎猜」。你没法给没测过的东西做路由。每一步都要记录：用的是哪一层模型、token 数、延迟，以及一个成功/失败信号。然后算那个最朴素但最关键的数字——每个已完成任务的成本，而不是每 token 的成本。只盯着每 token 成本的团队，往往会因为加了太多重试，反而把每个任务的总成本弄得更糟；按任务计成本，才能让你面对现实。这个指标每月重算一次。模型价格和能力变化太快，上个季度最优的路由表，到这个季度可能已经是个错误。
常见的坑
廉价模型的假性省钱。 如果弱模型在规划步骤上出了错，下游所有步骤都会继承这个错误。把最强的模型放在规划的最顶层，廉价模型放在树叶（具体执行）层。
能力的无声漂移。 模型的一次小版本更新，可能一夜之间颠覆你的路由假设。在评测中锁死模型版本，升级前重新测试。
过度设计路由器。 对大多数团队来说，一条 50 行的启发式规则加上一条升级规则，比一个花哨的机器学习路由器更实用。只有当数据确实需要时，才去增加复杂度。
结论
2026 年的制胜动作，不是「用最好的模型」，也不是「用最便宜的模型」，而是构建一个轻薄的路由层和一套评测工具，让你能把每一步放到合适的模型层级上——并且当市场再次变化时，一个下午就能换掉底层模型。默认用旗舰模型之所以感觉安全，是因为它简单。它现在依然简单。只是不再便宜了。
你们在生产环境里现在怎么做模型分层路由？用启发式规则、机器学习路由器，还是仍然所有任务都用一个模型？很好奇你们实践中什么方法有效。