开源模型受限以后，最先失灵的是回归判断

外部限制一旦落到开源模型身上，最先坏掉的往往不是“还能不能下载”，而是“这次结果还能不能和上次放在一起看”。模型名还在，接口也还能接，真正变难的是判断线开始漂了：同一套提示词、同一批样本、同一个工作流，跑出来的结果已经不是同一种行为分布。

这件事在纸面上看起来很简单，实际碰上以后就很烦。原来能通过的输出格式突然多了一点解释，原来稳定的函数调用顺序开始换位，某些区域里多了一层策略提示，或者同一条请求在不同入口下拿到的上下文长度不一样。单独看每一处都不算事故，凑在一起就会把回归判断弄乱。

先坏掉的是比较口径

很多团队会先盯着 benchmark 分数，但分数只适合说明能力大概在哪，不适合说明“现在的行为还能不能接在旧流程后面”。真正上线的地方，不是模型单跑一题，而是它要和解析器、工具调用、重试、缓存、审核、路由一起工作。只要其中一环换了口径，分数就会失去参照意义。

最典型的情况，是评测集里看不出问题，线上却开始掉链子。测试样本足够干净，模型答题也很像样，可一旦接到真实输入，少量字段漂移就能把后面的自动化步骤带偏。结果看上去像“模型还能用”，实际上是“比较方式已经失效”。

基线要按工作流保存

要把这类变化压住，靠的不是多跑几轮榜单，而是把基线做成可重放的工作流。输入要带版本，输出要带 schema，工具响应要能回放，失败样本要保留原始上下文。只有这样，换到别的模型、别的区域、别的策略以后，才知道偏差到底出在模型本身，还是出在前后链路。

这类基线最怕只存一个分数和一个结论。分数会被拿来安慰人，结论会被拿来写汇报，真正有用的细节却不见了。后面一旦限制收紧，团队只能重新补样本、重新补口径、重新补异常边界，等于把本来可以一次做完的比较工作拆成了好几轮返工。

迁移真正贵的是重新建立信心

模型受限之后，迁移动作看起来像换一个可用项，实际上是在重新建立“这套流程还算稳定”的信心。信心不是靠一次成功调用堆出来的，而是靠一组可以反复验证的比较结果撑出来的。没有这组结果，换过去只是暂时可跑；有了这组结果，换过去才算进入可控范围。

这也是为什么有些团队表面上已经完成替换，内部却还要拖很久才敢放量。真正卡住的不是接入动作，而是没人敢回答：旧流程里最重要的那些边界，到了新模型上是否还成立。只要这个问题没答清楚，任何“已完成迁移”的说法都只是阶段性口径。

只适合被测的部分才值得重建

不是所有场景都值得把回归链做得这么重。临时对话、轻量生成、一次性摘要，这些地方的边界本来就松，过度建设反而浪费时间。但只要模型开始参与代码生成、信息抽取、路由决策、工具执行，回归判断就不再是附属品，而是工作流的一部分。

外部限制会把这个差别放大。能不能继续用，通常只是最表面的那层；真正决定团队能不能稳住的，是有没有一套稳定的方法，把新结果重新放回旧基线里比较。比较这件事一旦站住，迁移就只是工程问题；比较一旦失效，后面所有判断都会开始摇晃。