工作流因为模型升级跑不动了怎么办？排查思路与修复方法

本来跑得好好的工作流，某天上游把默认模型指向了新版本，结果不是报错就是输出格式变了。这篇不讨论该不该升级，只解决已经卡住的人怎么查：先分清是接口层挂了还是输出层变了，再决定改提示词、锁模型还是临时回退。

本来跑得好好的工作流，某天上游把默认模型指向了新版本，结果不是报错就是输出格式变了。这事不讨论该不该升级，只解决已经卡住的人怎么查。核心思路就一句话：先分清是接口层挂了还是输出层变了，再决定改提示词、锁模型还是临时回退。

下面这套顺序是按「从便宜到贵」排的：先看日志、再锁模型对照、再看参数和返回结构、最后才动提示词。很多人一上来就重写提示词，结果改了半天发现是上游别名漂移了，白折腾。照着走，能少绕几圈。

先分清两类故障：跑不动和跑得动但不对

故障分两类，处理路径完全不同。「跑不动」是请求直接报错、超时、返回空，问题在接口与参数层；「跑得动但不对」是能返回但字段缺、格式乱、语气跑偏，问题在输出层。分不清这两类，后面所有排查都是瞎猜。连报错信息都拿不到的时候，先按接口层查，别急着改提示词。

• 把最近一次成功的日志和现在失败的日志并排放，只对比模型名、参数、返回结构这三处，比重新读一遍代码快得多
• 常见触发源有三个：上游把别名指向了新快照、你用的中转站换了分组、客户端自动跟随了最新版
• 稳定复现的失败才值得动代码，偶发失败先怀疑限流、超时和并发，换模型解决不了
• 别凭印象下判断，把对照结果落到纸上再往下走

把模型名写死，做一次 A/B 对照

别名会随上游漂移，快照相对稳定，把工作流里的模型名从别名改成显式快照名，这是升级事故里最常见也最容易忽略的一条。改完之后用同一段输入分别打旧版和新版，各跑三五次，看失败是稳定复现还是偶发。稳定复现再谈改代码，偶发先查限流和并发。

1. 锁定版本把配置里的模型别名换成显式快照名，改完重启服务确认生效。
2. 固定输入挑一条最短但能触发问题的输入，最好几分钟内能跑完。
3. 双跑对照旧版新版各跑三五次，记录返回结构、耗时、是否成功。
4. 判定旧版稳、新版挂=升级导致；两边都挂=你的参数或上游本身有问题。

如果你分不清手上的中转站是不是换了分组、换了上游，可以到 /sites 看它的可信度与线路说明，再决定要不要继续用它做验证。模型当前的价格与可用性随时会变，具体数字到 /price-watch 核对当时的数字，别拿旧截图当依据。

盯参数与返回结构：最容易被升级打断的地方

温度、最大输出长度、停止词这类参数的默认值可能变了，尤其是结构化输出和函数调用相关的那几项。严格模式的 JSON Schema 要求也可能变严，多包一层、必填缺失、类型不符会在升级后集中暴露。函数调用的参数命名规则有调整时，旧提示词里的示例还会反过来带偏模型。

别名漂移

配置写的是会移动的版本名，上游一动你就跟着变

参数默认值

你没显式指定的参数，升级后可能换了默认

严格 Schema

对字段、类型、必填项检查更严的结构化输出模式

最小复现

把问题缩到一条请求里，别在完整工作流里反复试

拿一条最小可复现的请求去单测，而不是在完整工作流里反复试，定位速度差好几倍。单测过了再放回工作流，能直接分清是模型问题还是你自己代码的问题。

输出变味了：改提示词而不是改代码

新版本可能对指令的服从方式变了：原来靠隐含约定能跑通的格式要求，现在得写成显式规则加一个样例。约束字段不要用「请返回 JSON」这种模糊说法，把字段名、类型、取值范围一条条列清楚。改提示词一次只动一处，并用固定用例回跑，不然你不知道是哪句改动起了作用。

• 把格式要求写成显式规则，再给一条完整样例，比反复形容更管用
• 一次只改一处，改完用同一组固定用例回跑
• 如果业务对语气和格式极其敏感，锁旧快照往往比反复调提示词便宜
• 提示词也要进版本管理，否则回退时你不知道退到哪一版

什么情况下不适用改提示词？如果你的下游是严格解析固定字段的程序，而新版本对指令服从性整体变差，这种时候调提示词是治标，直接锁快照或换回旧版更省事。判断标准是：改三次还压不住格式漂移，就放弃调提示词这条路。

回退、观察与验证：给自己留后路

先回退到能跑的版本把业务稳住，再在旁路环境里做升级验证，别在生产上边跑边调。验证要覆盖三类用例：正常输入、边界输入、以前踩过坑的输入，跑完再切。把模型名、参数、提示词版本都收进配置，下次升级改一处就能回退。观察窗口内盯错误率、重试次数和单次耗时，出现异常按原路退回。

如果排到最后发现是上游线路本身不稳定，或者你想顺手换一家更靠得住的中转站，可以到 /rankings 看看当前的可信度与稳定性排序，再挑一个做旁路验证。模型资料和参数默认值这类细节，站内模型库里有对照，升级前扫一眼能省很多事。