模型退役前别只换接口：企业AI迁移演练清单

当生产系统依赖的模型进入退役倒计时，最危险的做法不是“没有找到新模型”，而是把迁移理解成改一个模型名称。提示词、工具调用、结构化输出、知识检索、权限、时延和成本都会随模型变化；即使接口没有报错，业务结果也可能已经偏离。

2026年9月18日，GitHub公告将在10月19日从Copilot各类体验中退役多款模型，并要求用户在截止日前更新工作流和集成。GitHub官方公告 微软的模型生命周期政策进一步说明，模型进入Retired后推理请求不再可用；迁移前应使用企业自己的应用、提示词和代表性数据，同时比较质量、时延与成本。Microsoft生命周期政策 这不是某一家厂商的偶发变化，而是生产AI必须长期面对的运行条件。

白泽的判断是：模型退役应按一次受控业务变更管理。企业要交付的不是“新模型调用成功”，而是旧链路可盘点、新旧结果可比较、灰度过程可观察、失败能够切回、旧模型能在证据完整后退出。

一、先做基线：知道哪些业务会被模型退役击中

第一份交付物不是测试报告，而是模型依赖账本。至少记录：业务流程、模型与版本、调用入口、提示词版本、结构化输出协议、工具权限、知识库版本、区域与配额、流量、峰值并发、允许时延、人工接管方式、数据负责人和业务责任人。

不能只查代码里的模型名。生产依赖还可能藏在低代码流程、定时任务、浏览器插件、供应商SaaS、边缘盒子、报表脚本和人工操作手册中。盘点时要沿“输入从哪里来—模型做什么判断—结果触发什么动作—谁承担后果”逐段追踪。

建议把现状基线拆成四组：

没有同口径基线时，迁移后只能看到“能调用”，无法判断业务是变好还是变坏。

二、用风险模型排优先级，不要平均迁移

企业通常同时依赖多个模型，不可能全部同一天深度验证。可以用一个简单的风险分数排队：

迁移风险分数 = 流量权重 × 业务影响 × 错误发现延迟 × 动作不可逆性。

每项按1至5分评估。只读问答的动作不可逆性低；自动发货、设备控制、合同生成或客户承诺更高。错误能在数秒内被规则发现，发现延迟较低；需要月底对账才暴露的问题更高。

以下数值是方法推演，不是客户实测：某质检辅助流程四项分别为4、4、3、3，风险分数144；内部知识问答为3、2、2、1，风险分数12。前者应先准备双跑、人工闸门和回滚，后者可在低风险人群中快速灰度。不要把144与12当成跨企业统一阈值，它只用于本企业内部排序。

迁移成本也不能只看新模型单价。建议用“适配开发 + 双跑推理 + 人工裁决 + 回归测试 + 监控运维 + 回滚保留”计算全成本。若新模型单次便宜，但结构化输出不稳定导致人工复核增加，总成本仍可能上升。

三、建立最小迁移单元：把变更边界锁住

一次迁移的最小单元应包含模型、系统提示词、业务提示词、输出Schema、工具清单、知识库快照、采样参数、超时重试、权限策略和评测集版本。给这一组对象分配唯一release_id，避免发生“模型换了，同时提示词也改了，却不知道是哪项导致退化”。

迁移输入至少包括：

• 退役通知与准确截止日期；
• 当前依赖账本和调用流量；
• 代表性正常任务、历史失败样本与高风险边界样本；
• 人工裁决规则和责任人；
• 新模型区域、配额、数据边界与功能兼容清单；
• 当前版本的一键切回条件。

迁移输出至少包括：

• 候选模型比较报告；
• 差异清单和适配记录；
• 冻结的回归集与裁决结果；
• 灰度计划、观测看板与值班表；
• Go/No-Go签字记录；
• 旧链路退役及证据归档记录。

四、六步迁移：从发现到真正退役

第一步：发现

建立退役日历和通知责任人。通知不能只发给云账号管理员；模型所有者、业务负责人、IT运维、信息安全和采购都要收到。每周自动扫描供应商生命周期页与内部依赖账本，把“距离退役天数”变成可见指标。

第二步：盘点

按release_id定位所有入口，并随机抽取真实请求验证账本是否完整。对于找不到负责人、没有回滚路径、无法说明输出用途的调用，先标为No-Go，不直接切换。

第三步：适配

在隔离环境接入候选模型，逐项验证API、上下文长度、结构化输出、工具调用、图片或音频能力、区域配额和内容安全策略。不要在这一步顺便重写全部业务逻辑。适配范围越大，归因越困难。

第四步：验证

新旧模型使用同一批输入双跑。自动指标只负责筛查，严重错误、工具动作与业务终态要由具备资格的人员裁决。训练或调优数据与回归集按时间或业务批次隔离，防止测试集泄漏。

第五步：放量

建议按影子、内部用户、低风险流量、受控业务、全量五档推进。每档都有观察窗口和停止条件。双写可能产生副作用时，只执行旧链路动作，新链路只记录建议；不要让两套Agent同时写ERP、MES或设备控制系统。

第六步：退役

只有在旧模型流量归零、回滚窗口结束、账单与告警无残留、文档和应急手册更新后，才删除旧凭据与部署。提前删除会失去回滚，永不删除则会留下权限、成本和影子依赖。

Microsoft的模型迁移指南同样把过程拆为Discover、Assess、Adapt、Validate、Roll out和Retire六个阶段，并强调迁移很少是一次二元切换。Microsoft模型迁移指南

五、验收门槛：同一张表决定Go或No-Go

阈值应在测试前由业务、技术和风险负责人共同签字，不能看完结果再调整。下面是可直接改写的模板，示例数字属于方法推演：

绝对阈值要根据场景调整。生产控制、质量放行和外部承诺不应直接套用普通问答阈值；高风险动作应继续保留人工确认和确定性控制。

六、角色责任：谁发现、谁裁决、谁切换

业务负责人定义哪些错误不可接受，并签署业务Go/No-Go；模型或算法负责人维护候选模型、评测集与差异分析；系统集成人员验证Schema、工具和上下游接口；数据负责人确认样本来源、隐私和知识库版本；安全负责人检查权限、审计与供应商边界；运维负责人负责流量切换、监控、值班和回滚；采购与法务核对服务条款、区域、费用及供应商退出条件。

任何一个高风险流程都必须有唯一的迁移负责人。多人参与不等于共同承担模糊责任。切换窗口前要明确：谁能按下回滚、谁能冻结业务动作、谁负责通知现场、谁确认恢复。

七、回滚不是“把模型名改回去”

可回滚要求旧模型仍可用、旧提示词和Schema可恢复、旧知识库快照可定位、旧权限策略未删除，同时新旧请求能够通过release_id区分。

建议演练四类故障：

1. 新模型超时或被限流；
2. 结构化输出字段缺失；
3. 工具调用重复或参数越权；
4. 质量指标正常，但业务终态异常。

回滚触发后，先停止扩大流量，再冻结高风险动作，切回旧release_id，核对排队与重试请求，最后确认ERP、MES、工单或设备状态没有重复写入。仅看到HTTP 200不能证明回滚完成。

如果退役日已经到达、旧模型无法调用，就进入降级而不是回滚：转人工、切到确定性规则、暂停高风险动作，或只保留查询能力。企业必须在退役日前演练这一条“旧模型永久不可用”的路径。

八、30天执行清单

如果剩余时间不足，不要压缩高风险验证来追赶日期。优先降级业务范围：先关闭自动动作，保留人工辅助；先保证可追溯和可停止，再追求全部功能不变。

九、白泽判断：把模型可替换性当成生产能力

模型生命周期越来越短，企业不能把某个模型名称写成业务系统的永久前提。真正可持续的架构，不是同时接入最多模型，而是有统一业务输入、稳定输出契约、可复用评测集、受控工具层、版本证据和可演练的切换路径。

对于重庆及西南制造企业，建议先选一个依赖大模型但仍有人工作为最终确认的流程，完成第一次模型迁移演练。把切换时间、严重错误、人工复核和全成本测清，再决定哪些流程可以扩大自动化。AI只有进入真实流程、产生可验证结果，并在模型变化时仍能受控运行，才算真正落地。

常见问题

厂商提供自动升级，还需要自己验证吗？

需要。自动升级解决部署动作，不等于证明新模型适合你的提示词、知识、工具、区域、配额和业务终态。至少要运行代表性回归集并检查高风险样本。

公共榜单能代替企业回归集吗？

不能。公共榜单可以缩小候选范围，但无法覆盖企业自己的字段、流程、失败代价和工具权限。最终Go/No-Go必须基于本企业数据和人工裁决标准。

退役前来不及完整迁移怎么办？

先缩小权限和业务范围，保留人工确认或确定性规则，暂停不可逆动作。宁可降级，也不要在没有回归和回滚证据时直接全量替换。

一手资料与核验日期

1. GitHub Changelog，Upcoming deprecation of selected GitHub Copilot models in mid-October，发布于2026年9月18日，事件日期为2026年10月19日。官方原文
2. Microsoft Foundry Models lifecycle and support policy，核验于2026年10月12日；页面说明生命周期、通知和迁移边界，具体日期可能调整，应在实施前再次核验。官方文档
3. Microsoft Foundry Model migration process，核验于2026年10月12日；页面提供六阶段迁移方法。官方文档

未取得平台热榜和搜索量；本文不把厂商公告热度包装成市场数据。所有示例阈值与风险分数均为方法推演，不代表白泽客户成绩。