设备详情页上只有一个 version = 2.7.4，看起来很清爽。可是一旦现场设备“在线但数据解释错了”，这个数字几乎不能回答任何有用问题：运行的是哪一份二进制？加载了哪套阈值和端点？平台按哪个能力模型解释遥测？这三个问题的答案可能来自三个不同发布时间，也可能由三个不同团队负责。
本文的结论很直接：**把固件、运行配置和设备模型压成一个版本号，会把独立变化伪装成一次整体升级；当设备数量、硬件修订或接入平台增多后，故障定位、兼容判断和回滚都会失去确定性。**更稳妥的做法是维护一个三轴版本向量，并让每一次激活都通过明确的兼容性合同。
这里的“设备模型”不是产品营销名称，而是平台用来解释设备能力的可执行语义：属性类型、单位、读写权限、枚举、命令参数、原始点位映射和迁移规则。固件决定设备能做什么，配置决定这台设备现在怎样运行，设备模型决定平台怎样理解和控制它。三者相关，但不能互相代替。
1. 管理对象不是一个版本号，而是一组受约束事实
一个可运维设备至少需要记录 hardware_revision + firmware_version + config_version + model_version。硬件修订通常变化最慢，却会约束可刷入的固件；固件携带驱动、协议栈和控制逻辑；配置携带站点参数、采样周期、端点、证书引用和功能开关；设备模型则定义平台侧的语义和命令边界。把它们显示成一行没有问题，但底层必须保留四个独立事实。
如果只保留统一版本，团队通常会落入两种坏选择。第一种是任何阈值修改都重新发固件版本，结果是二进制未变却产生大量“固件发布”，审计记录无法区分代码风险和参数风险。第二种是配置和模型静默覆盖，设备页面仍显示旧固件版本，看似没有变更，平台实际上已经换了状态解释或控制约束。前者制造噪声，后者隐藏风险。
更关键的是，这三条轴的生命周期不同。固件需要构建、签名、校验和设备侧安装；配置需要 schema 校验、作用域解析和原子激活；设备模型需要映射完整性、兼容性分类和平台侧发布。若为了“统一”而强迫它们共用同一生命周期，最慢、最重的发布路径会吞掉所有轻量变化；若统一版本只是一个展示标签，它又无法提供真正的约束。
因此，统一编号最多只能是一个 release manifest 的外层名称。manifest 可以声明本次推荐组合，例如 firmware 2.7.4 + config 18 + model 6，但它不应该抹掉三个子版本，也不应该把“推荐组合”误写成“唯一合法组合”。真实设备群中会长期存在安装中、离线、回滚后和分批迁移的多个有效组合。
下面的决策流强调一件事：先确定变化归谁所有，再判断组合能否激活。不要从“这次叫 2.8.0 还是 2.7.5”开始讨论。
flowchart TD
A("发现需要变更"):::slate --> B{"改变设备执行代码吗？"}:::blue
B -->|是| C("新固件版本"):::blue
B -->|否| D{"改变站点运行参数吗？"}:::cyan
D -->|是| E("新配置版本"):::cyan
D -->|否| F("新设备模型版本"):::violet
C --> G("生成兼容性声明"):::orange
E --> G
F --> G
G --> H{"目标组合通过准入？"}:::orange
H -->|通过| I("绑定并激活"):::green
H -->|不通过| J("保持旧组合并记录阻断"):::slate
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
2. 先判断“谁解释谁”，再决定哪条版本轴递增
版本归属最容易在模型和配置之间混淆。一个温度上限从 80 改成 75，是配置变化；温度字段从整数摄氏度改成带一位小数的华氏度，是模型变化；设备滤波算法从移动平均换成卡尔曼滤波，通常是固件变化。判断依据不是“改动发生在哪个文件”，而是它改变了执行逻辑、运行参数，还是数据/命令的语义合同。
| 变化 | 主版本轴 | 为什么 | 典型验证 |
|---|---|---|---|
| 驱动、协议栈、控制算法改变 | firmware | 改变设备执行的代码 | 签名、硬件修订匹配、升级与启动健康 |
| 采样周期、端点、阈值、功能开关改变 | config | 在既有能力内改变运行方式 | schema、作用域、秘密引用、原子激活 |
| 属性类型、单位、枚举、命令参数或点位映射改变 | model | 改变平台对设备的解释和控制合同 | 映射完整性、读写安全、迁移证据 |
| PCB、传感器或存储器件替换 | hardware | 改变固件可执行前提 | BOM/修订号、引导程序与驱动兼容 |
这张表不是为了把所有变更塞进单一格子，而是为了确定“主责任轴”。例如新增一个采样模式可能同时需要固件支持、配置启用和模型暴露。正确做法不是选择其中一个版本号覆盖其余两个，而是分别递增受影响的轴，再用 manifest 声明它们的依赖关系。多轴变化并不可怕，隐式依赖才可怕。
每条轴还需要独立所有者。固件负责人对二进制来源、签名、硬件支持范围和启动健康负责；平台配置负责人对 schema、默认值、作用域和秘密引用负责；设备模型负责人对语义、映射、命令安全和兼容分类负责。一个人可以兼任多个角色，但审计记录仍应说明是在什么角色下批准了什么变化。
Grus 的现有实现提供了一个具体例子：released 的设备模型版本不允许修改描述、diff、兼容分类、baseline 或迁移证据；需要变化时必须创建新版本。设备绑定还要求 model version 已 released，并与设备的 product 和 source identity 匹配。这不能证明所有平台都应复制同一代码，但它说明“发布后不可变 + 显式绑定”可以把模型从一份会漂移的 JSON 变成可追溯运行事实。
3. “兼容”不是一句标签，而是一份组合准入合同
团队常把 compatibility 写成 backward_compatible: true，却不说明对谁兼容、验证了什么、有效到何时。这样的布尔值在事故中几乎无用。兼容性必须至少包含消费者、生产者、版本范围、迁移动作和验证证据，否则系统无法自动拒绝危险组合。
对固件而言，消费者通常是硬件修订和 bootloader；对配置而言，消费者是固件内的配置 schema；对设备模型而言，消费者既包括数据接入与标准化链路，也包括命令服务和规则引擎。一份 model version 即使能解析历史遥测，也可能不再允许旧固件接受新命令。把“读兼容”和“写兼容”拆开，通常比一个总布尔值更诚实。
一个足够实用的准入记录可以包含：artifact identity、supported hardware revisions、requires firmware range、config schema version、model compatibility class、migration id、evidence digest 和 approved by。它不必一开始就做成复杂规则引擎，但必须能回答“为什么这台设备允许绑定这个组合”。
Grus 的 model release checklist 把映射为空、冲突、blocked mapping 和 missing schema 视为阻断；unknown、provisional 和未映射 raw DP 则进入 degraded，需要带原因和到期时间的 waiver。这个设计的重要性不在字段名，而在于它拒绝把“未验证”自动解释为“兼容”。当受影响设备已经存在时，空映射不是一个可晚点补的文档问题，而是会让平台失去解释和控制能力的发布阻断。
实际准入还要绑定设备的 observed state，而不是只看 release catalog。平台应记录设备报告的当前固件、最后成功配置版本、effective model version、硬件修订和最近确认时间。若设备离线或证据过期，系统可以排队计划，却不应宣称组合已经生效。desired state 是意图，reported/effective state 才是运行事实。
当平台跨厂商接入时，还要防止“同一个 product key”被误当成全局身份。模型版本至少应绑定 tenant、source platform 和 product identity；若设备来源改变或产品键复用，兼容性必须重新求值。否则一份在 A 厂商云上成立的点位映射，可能被错误套到 B 厂商同名产品上。
4. 三类回滚不是同一个动作
固件回滚通常意味着切换分区、恢复旧镜像或重新刷写，它可能被 bootloader、安全计数器和数据格式迁移限制。配置回滚更像重新激活一个经过 schema 校验的历史快照，但其中的证书、端点或密钥引用可能已经失效。设备模型回滚则是平台重新解释数据和命令；它不会自动把已经写入的新格式历史数据变回旧格式，也不会撤销新命令对现场造成的物理结果。
因此，“保留上一版本即可回滚”只在最简单的实验室场景成立。生产回滚必须同时声明可逆对象和不可逆副作用。数据库或设备持久化格式如果发生不可逆迁移，固件回退可能启动失败；配置如果引用已经吊销的凭据，恢复旧 JSON 只会制造新的连接故障；模型如果删除了单位换算或枚举映射，回退后历史曲线可能发生语义漂移。
更稳妥的策略是为每条轴定义不同的退役条件。固件在目标硬件上完成健康观察且旧镜像超过恢复窗口后才能退役；配置要在所有作用域完成收敛、旧秘密被替换且离线设备处理策略明确后才能退役；设备模型要在绑定设备迁移完成、读写兼容窗口关闭、历史数据解释策略确定后才能退役。退役不是“没人再选它”，而是“系统已经证明不再需要它恢复或解释状态”。
如果一次发布同时改变三条轴，应先安排可观察的顺序，而不是同时翻转。例如先发布向后兼容的新模型，让平台能读新旧数据；再发布支持双 schema 的固件；随后激活新配置；确认迁移完成后，最后关闭旧模型和旧配置。顺序取决于依赖方向，但原则相同：先让消费者理解两种状态，再让生产者开始产生新状态。
这也说明版本治理和 OTA rollout 是不同问题。灰度、分组、暂停与恢复解决“把某个已准入 artifact 安全送到设备群”；版本治理解决“这个 artifact 与配置、模型、硬件组合后是否仍然合法”。没有前者，事故半径不可控；没有后者，团队只是更谨慎地发布了一个不兼容组合。关于分环与回滚执行，可继续阅读IoT OTA 灰度与回滚策略。
5. 从最小机制开始，但不要省掉可追溯性
小规模团队不需要先建设一个庞大的“版本治理平台”。如果只有一种硬件、一个固件分支和少量静态配置，一份签名 manifest、一张兼容矩阵和设备侧 reported state 就能建立基本秩序。最小实现可以是关系表加发布 Gate，而不是通用策略语言。
但有四件事不能省。第一，每个 artifact 必须内容寻址或至少带不可变 digest，避免同一版本号指向不同内容。第二，发布后的版本记录不能静默编辑；修正意味着新版本或显式撤销。第三，设备必须报告实际生效版本和确认时间，平台不能用 desired state 冒充结果。第四，每次绑定、waiver、回滚和退役都要保留操作者、原因、证据与 trace。
这套机制也有明确不适用边界。对于完全离线、没有远程配置、没有平台语义映射且生命周期很短的单机设备，三轴治理的收益可能小于维护成本；用构建版本、出厂配置校验和硬件修订记录即可。相反，只要系统出现多硬件修订、远程配置、第三方平台接入、可写命令或长期历史数据中的任意两项，把版本继续压成一个字符串就会把成本推迟到事故调查和迁移阶段。
最终应追求的不是“所有设备都升级到最新版”，而是每台设备都有一个可证明的合法组合。最新版可能因为硬件修订不支持而非法，旧版也可能在补丁窗口内仍然合规。版本治理的核心指标因此应是未知组合数、阻断组合数、证据过期数、迁移中设备数和无法回滚的变更数，而不是单一的 latest-version adoption rate。
当团队能从任一设备追溯到硬件、固件、配置、模型、兼容证据和审批记录时，版本号才真正成为运维工具。否则，它只是一个让界面看起来确定的标签。
参考资料
结论
固件、配置和设备模型应该分别版本化，再通过 manifest 与兼容性合同形成可准入的组合。变化先归属到正确版本轴，组合通过证据 Gate 后才绑定和激活，回滚与退役则按各自不可逆副作用处理。这样做增加了少量元数据和审核工作，却换来可定位、可拒绝、可迁移和可审计的设备状态。
