服务升级模型版本后原来能做的任务失败，怎样固定证据并验证回退？

保存失败发生时的模型标识

适用于升级后格式不再稳定、引用质量下降，或此前正常的工具选择开始失败。先记录出现问题的具体时间与可获得的模型版本标识。若服务只提供动态别名，应注明无法固定底层版本，避免把相同别名误认为每次都指向完全相同的模型。

核对模型以外的配置变化

保留升级前后两份请求，逐项核对系统指令和工具Schema，再检查温度等参数是否被服务改变默认值。对应用自身的缓存也要区分命中与重新生成。先使用最小失败样本比较，避免把多个组件同时发布后的差异全部归因于模型升级。

用相同题集比较升级前后

有可用旧版本时，在隔离环境里执行同一题集，保持数据和工具返回一致。把失败分成格式错误、事实错误与任务未完成，分别记录原始输出。只有当前服务确实允许指定旧版本，且依赖接口仍兼容，才安排已有回退；否则先采用有证据支持的兼容修改。

回退后复测原来成功的任务

回退或调整后，重新运行原始失败样本，并抽查原本成功的任务，确认没有以修好一种格式为代价破坏其他任务。记录实际使用版本和每次结果，检查依赖的工具调用也能正常结束。最终结论应写明修复覆盖了哪些任务，不能只报告总平均分。

某些托管产品不提供旧模型恢复，应用层保留提示词也无法复原已撤下的底层版本。本文不承诺任何服务的版本保留期限，也没有执行真实生产切换。无法固定版本时，应保存失败时间及请求标识，把可复现的证据交给服务维护方继续核对。