那些悄悄将你的高级流量路由到 Haiku 的供应商自动路由器

你的平台团队出于成本考虑采用了供应商的 "auto" 模型标识符。上线后的第一个仪表盘数据非常有说服力：在每周 eval（评估）中没有出现可衡量的质量下降，支出却减少了 34%。三个月后，在你最短、流量最高的功能点上，客户满意度已经连续两个季度下滑。一项由产品主导的调查最终将这种回归追踪到了一个工程团队无人触及的模型标识符上。代码里写的是 "auto"。而供应商一直在重新定义 "auto" 这一路整过程中的含义。

教训并不是自动路由不好。教训是，"auto" 是一个移动的目标，其分布随供应商的经济效益而漂移，而你的 eval 的代表性是供应商优化与你的产品质量之间唯一的屏障。如果 eval 与流量不匹配，那么你所庆祝的折扣，其实是从一个无人审查的质量斜坡中支付的。

这篇文章讨论的是，当你过去在代码中做出的路由决策跨越网络变成供应商的开关（knob）时，会发生什么变化。机制看起来很熟悉 —— 模型池前的分类器，简单的 Prompt 用便宜层级，难的用贵的 —— 但运营影响却并不熟悉。你不再拥有分类器。你不再能看到每个请求的决策。当成本曲线发生变动时，你无法重新验证阈值。而且当这些发生变化时，你几乎永远不会收到通知。

Auto 别名是你并未参与制定的路由策略

当你调用具体模型时 —— claude-sonnet-4-6、claude-haiku-4-5 这种显式标识符 —— 你的代码表达了一个选择，而供应商执行它。当你调用 auto 别名时，你的代码表达了一个意图，而供应商替你做决定。这种区别听起来像是哲学层面的讨论，直到你意识到：别名背后的策略是供应商根据自己的目标、自己的节奏，针对自己的负载和利润曲线进行调优的。

一个合理的自动路由器会在几百毫秒内分类 Prompt 的复杂度，将简单的查询发送给小模型，并将大模型留给复杂的查询。关于这方面的文献令人振奋 —— 调优良好的路由器报告称，与单一的大模型基准相比，成本降低了 50% 到 80%，而难点部分的质量损失不到 2%。这些数字对于被测系统来说是真实的。但当路由器的参数发生变动后，它们并不是关于你的系统的契约。

通常有两点会发生漂移。首先，分类器的复杂度阈值。一个在多个租户上运行 auto 的供应商会随着模型经济效益的变化而重新调整边界 —— 例如 Haiku 的服务成本变低了，团队就会放宽阈值，让更多流量符合条件。你的流量组合没有变，但分类器的组合变了。其次，模型池本身。供应商可以保持别名稳定，并将池化模型中的一个替换为更快或更便宜的后续版本。别名仍然指向“适合此 Prompt 的层级”，但别名下的行为已不再是你基准测试时的行为了。

这两者都是无声的变化。发布说明（如果存在的话）会将它们归类为“效率提升”或“路由改进”。你的客户端代码没有变。你的支出下降了。你信任的仪表盘显示一切正常。

Eval 是如何错过它的

Eval 套件错过回归的原因是特定的结构性问题。大多数 eval 套件是由关注难题的工程师编写的 —— 模型的推理上限、在长上下文中的指令遵循能力、处理复杂工具调用的能力。套件最终会偏重于那些看起来很难的案例，因为这些案例失败起来更有研究价值。简单的案例虽然也被包含在内以保证覆盖率，但因为它们在任何地方都能通过，所以没人会投入精力去扩展它们。

当 eval 由更长、更难的 Prompt 主导时，一个在短 Prompt 上被更激进调优的自动路由器会正确路由 eval 任务。你的 eval 在几乎每个示例中看到的都是 Sonnet，因此 eval 分数保持不变。与此同时，你的产品流量中大约 70% 是短促、频繁的 Prompt —— 自动补全、建议栏、解释图表的工具提示 —— 路由器将这些流量的大部分发送到了 Haiku。大多数用户最常接触的产品界面，现在运行的模型与 eval 所测量的模型已经不同了。

这就是“我们有良好的 eval”既是事实又毫无用处的失败模式。eval 集质量很高，它只是不具代表性。路由器的分布偏移隐藏在你的 eval 覆盖的 Prompt 与客户发送的 Prompt 之间的鸿沟中。

解决办法不是“增加更多 eval 案例”，而是按界面切分的、权重与生产流量匹配的 eval 切片。如果你的 Prompt 中有 60% 是自动补全式的，那么 eval 体量中也应有 60% 是自动补全式的案例，并根据该界面关注的维度进行评分 —— 延迟、简洁性、拒绝率、短查询的事实准确性。这样，路由分布的偏移就会使总分朝着偏移的方向移动，而不是被路由器从未触及的长上下文推理切片所吸收。

通过选择 "Auto" 你所失去的可见性

当你掌握路由决策权时，你清楚每个请求由哪个模型处理，因为代码是你选择的。而当供应商掌握路由决策权时，响应通常会告诉你实际运行的是哪个模型——但前提是你记录了它，并且将其视为一等信号，而非仅仅是一个调试字段。

一个实用的基准是：每个业务场景（surface）所使用的具体模型日度报告，以该场景总流量的百分比形式呈现。不是次数，而是占比。自动补全场景应该有一个稳定的分布：比如 95% Haiku 和 5% Sonnet，每周波动几个百分点。当这种分布发生变化时——比如 Sonnet 的占比跌破 1%，或者 Haiku 在长文本场景中的占比从 12% 跃升至 30%——在任何质量指标下滑之前，你就获得了一个关于流量路由行为变化的群体级信号。

这与将 4xx 错误率作为总流量比例进行告警（而非绝对计数）的逻辑相同。绝对计数包含太多噪声，因为业务量本身就有波动。而流量占比的波动会与你的流量模式相匹配，真正的偏移会以一种非随机的方式推动占比变化。

关键原因在于：当质量评分（quality score）出现下滑时，回归已经影响到了客户。当 CSAT 下降时，流失已经发生。模型分布的变化总是先行的，因为它是因，而非果。关注“因”能为你赢得数周的领先时间。

固定模型（Pinning）真正带给你的价值

防范隐性路由偏移最彻底的方法是不选择它：指定具体模型，而非别名。生产环境中的 AI 系统应将模型视为与其他任何有版本号的依赖项一样。你会固定数据库引擎版本，固定 Kubernetes 的次版本，通过 SHA 固定安全库。模型也是同类依赖，而别名（alias）就像镜像仓库中的 "latest" 标签一样，是个陷阱——在出问题之前它们确实很方便。

固定模型能提供别名无法提供的三样东西。

它给你稳定的合约：除非你主动修改，否则今天调用的模型与下个季度调用的模型是一致的。行为变化仍会发生——供应商可能会修正特定模型——但它们必须以不同的名称发布，这种变化是你可见且可以决策的。

它给你清晰的弃用周期：当供应商下线你固定的模型时，他们必须告知你。弃用有具体的日期、建议的继任模型以及迁移窗口。别名则没有这些，因为别名本身就是迁移路径。供应商对你不可见的路由表进行修改，就完成了你的“迁移”。

它给你可审计的经济决策：成本与质量的权衡掌握在你的代码中，而非供应商的政策里。你决定将这个场景路由给 Haiku 是因为评估（eval）结果显示它没问题。如果评估结果变了，你就更改路由。如果这个场景比你想象的更重要，你就升级模型。决策结果与其对应的 Prompt 一起存储在版本控制系统中，未来的工程师可以清楚地看到当初为何做出这一选择。

子智能体（Sub-agent）系统已经很好地模拟了这一点——模型字段接受别名、完整标识符或“继承自父级”的占位符。正确的做法是：对任何面向客户的功能使用完整标识符，将别名留给开发和探索阶段，并且只有在父级本身已固定的情况下才使用继承。

何时你会想要使用 "Auto"

在某些情况下，选择供应商路由是合理的。例如，成本波动比质量稳定性更重要的内部工具；或者是尚未确定哪个模型最合适、需要路由器的分类作为有用先验的探索性功能；以及任务复杂度完全随机、处理不佳的离群点虽令人恼火但代价不高的工作负载。

让这些场景保持安全的准则，也正是让固定模型在这些场景中显得不那么必要的准则：你必须对系统进行埋点，使路由器的行为可见。记录处理每次调用的模型，绘制每个模型的流量占比图，根据实际运行的模型（而非你预期的模型）对评估结果进行切片分析。当路由在你脚下移动时，你能在早已关注的仪表盘上看到这种变动。

架构层面的认知是：“让供应商决定”发并不是一种退出路由决策的方式——它是一种选择加入别人正在持续做出的路由决策的方式，而别人的动机并不等同于你的利益。这可以是一个合理的选择，但它绝不是免费的。其代价不会体现在可见的成本上，而会体现在你的评估套件从未覆盖到的业务场景的质量上。

在发布 "Auto" 之前的简短检查清单

在任何生产场景通过供应商的自动别名发布之前，值得问几个问题：

• 你是否记录了处理每个请求的具体模型，并且该日志可以按场景查询？
• 你的评估套件（eval suite）是否包含与使用别名的场景流量相匹配的切片，并针对这些场景关注的维度进行评分？
• 是否对每个场景的模型分布设有告警，以便在质量回归之前发现路由偏移？
• 你的合同或供应商文档是否承诺了路由策略，还是仅仅将其作为“智能路由”的营销描述？
• 你是否以书面形式确定了从别名迁移到固定模型（以及迁回）的触发条件？

如果上述任何一项的回答为“否”，那么这个别名正在为供应商谋利，而未必是在为你服务。如果这是深思熟虑后的交易，那没问题。但如果这只是在写代码定义模型时的默认选择，那就是一笔糟糕的交易。

那些在没有审计能力的情况下选择供应商路由的团队，正在任由供应商根据只有客户才能感受到的质量指标来设定其利润空间。而那些固定模型并按场景切片分析评估结果的团队，则保留了决策的自主权、成本的真实性，并在仍有时间采取行动时就能检测到回归。