工业设备的 AI 升级为什么必须能一键退回旧版本

给工业设备升级 AI 能力，和给手机推送一次系统更新是两件事。产线停机一小时的成本，往往高于升级带来的全部收益。这决定了升级方案的设计重心：先保证退得回来，再考虑升得上去。

升级失败的代价由谁承担

工业现场的升级风险集中在时间上。设备在升级窗口内无法执行原有任务，这个窗口不能随意延长。如果升级后表现不符合预期，需要多长时间恢复到可用状态，是必须提前回答的问题。

常见的问题在于回退路径没有被设计。团队把精力放在升级本身，默认升级会成功。一旦不成功，只能现场重装或者等远程支持，恢复时间不可控。

因此升级方案需要先明确一件事：出现问题时，多少时间内能恢复到升级前的状态。这个时间应当作为方案指标之一，与升级带来的能力提升同等对待。上限需要与生产部门共同确认，而不是由技术团队单方面设定。

一键退回要具备什么条件

一键不是指一个按钮，而是指回退过程不需要人到现场、不需要重新配置、不需要重新调试。要满足这三点，需要几个前提。以下三项缺任何一项，回退都可能退化为现场处理。

首先是版本共存。设备上要同时保留新旧两套版本，回退只是切换引用，而不是重新安装。这要求存储空间提前预留，而不是事后腾挪。

其次是配置独立。模型版本与运行配置要分开管理。多数异常来自配置而非模型本身，如果两者绑定，回退模型会连带丢配置，恢复过程反而更复杂。

第三是状态可判断。切换是否成功，需要有明确的自检环节。设备在回退后自动执行一项验证任务，通过后才解除告警。

版本与配置要一起回退

现实中还有一种更棘手的情况：新版本已经跑了几天，才发现某个边界条件下的表现不如旧版本。这时已经不是回退到升级前，而是回到几天前的运行状态。

这要求版本记录与运行数据能够对应。每台设备在某个时间段用的是哪个版本、哪套配置，需要可查。否则排查会退化成猜测，也无法判断问题是否由版本引起。

回退动作本身也要留痕：谁发起的、什么时候执行的、影响哪些设备。多厂区环境下，这个记录是后续复盘的基础。