1. 课程导入与全景认知
边缘AI设备指的是在靠近数据产生端完成推理或训练任务的嵌入式设备，例如产线质检相机、智能摄像头、车载计算盒、AGV控制器、电力巡检终端等。它们通常具备三类特征：算力有限但需实时响应、部署位置分散且现场维护成本高、软件与模型需要持续迭代。远程更新（OTA，Over-The-Air）就是通过网络把新的固件、应用、AI模型或配置下发到这些设备并使其生效；版本治理则是对"哪台设备、运行哪个版本、为什么是这个版本、能否回退"进行持续管理。二者合起来，构成边缘AI设备全生命周期运维的核心能力。
很多团队最初把远程更新理解为"把文件传上去、重启一下"。真正落地时会发现，难点不在传输，而在更新对象的多层性、设备环境的异构性、以及失败后的可恢复性。一台边缘AI设备上通常同时存在引导程序（Bootloader）、操作系统/内核、根文件系统、容器镜像、AI推理引擎、模型文件、业务配置等多个可更新单元，它们之间存在版本依赖。例如模型文件依赖特定推理引擎算子集，推理引擎又依赖底层驱动版本。若只更新模型而忽略引擎兼容性，设备可能启动正常但推理结果异常，这类"静默失败"比直接宕机更难排查。
1. 可靠性——更新中断、断电、网络抖动时设备不能变砖，必须能回滚到已知可用版本；
2. 一致性——批量设备要收敛到目标版本，避免长期存在多个"野生版本"；
3. 安全性——固件与模型需签名校验，防止被篡改或植入恶意内容；
4. 可观测性——更新成功率、失败原因、版本分布必须可量化，否则治理无从下手。
下面这张图给出边缘AI远程更新与版本治理的整体技术栈与数据流关系。它从设备侧的分区与更新代理出发，经传输通道到达云端更新服务，再向下连接版本仓库、灰度策略与可观测性系统，形成"下发—执行—反馈—治理"的闭环。
从图中可以看到，设备侧最关键的机制是A-B双分区：新版本写入备用分区，校验通过后切换启动标志，若启动自检失败则自动回退到原分区。这一机制把"更新失败"从灾难性事件降级为可恢复事件。与之配套的是更新代理Agent，它负责下载分片、校验签名、写入分区、触发重启并上报结果。云端则通过设备影子维护每台设备的期望版本与实际版本，用任务编排控制下发节奏，用灰度策略限制爆炸半径。
典型场景决定了技术选型的差异。以产线质检相机为例，设备数量可能只有几十台但停机成本极高，适合采用"小批量灰度+人工确认"的保守策略，更新窗口安排在换班间隙；而城市级智能摄像头可能上万台，网络质量参差，必须依赖断点续传、分片校验和自动重试，且模型更新频率高，需要支持模型热加载而不重启整机。车载计算盒则对功能安全有额外要求，更新包必须经过更严格的签名与兼容性验证，回滚时间要控制在秒级。
① 更新过程中断电，设备还能起来吗？
② 新版本推理精度下降但设备没报错，系统能发现吗？
③ 现在有多少台设备运行着非目标版本，分别是什么原因？
版本治理不是更新完成后的收尾工作，而是贯穿始终的约束条件。它要求每个更新包携带完整的元数据：版本号、适用硬件型号、依赖的引擎版本、签名信息、回滚基线。设备上报的状态也要结构化，至少包含当前固件版本、模型版本、配置版本、上次更新结果与失败码。只有这些数据齐备，"版本分布"才不是一句口号，而是可以查询、可以告警、可以驱动决策的真实视图。
本课程后续将沿着这条技术栈逐层展开：从更新包格式与签名校验，到双分区切换与回滚实现；从传输通道的可靠性设计，到灰度策略与任务编排；从版本兼容性矩阵，到可观测性指标与治理规则。第1章的目标是建立全景认知——远程更新解决"怎么把新版本送上去并生效"，版本治理解决"怎么确保每台设备运行在正确版本上且可追溯"。两者缺一不可，共同构成边缘AI设备可持续运维的基础。