定义
Dynamic Group（动态分组）按规则（如 Device Tagging 标签、产品型号、固件版本等）自动筛选设备，成员随设备属性变化自动更新。与 Static Group 互补，适用于批量 OTA、按区域批量操作等场景。
规则配置与更新
动态分组规则可基于 Device Tagging 标签、产品、固件版本、在线状态、区域等属性组合。规则采用表达式形式（如 tag.region=华东 AND firmwareVersion<1.2.0），平台定期或实时计算匹配设备集合。设备属性变化时，成员自动增减，无需人工维护。适用于「所有华东区待升级设备」「所有离线超过 7 天的设备」等动态目标场景。与 Device Grouping 设备分组能力结合，支持层级与混合分组。
与 DMP 的集成
设备管理平台在 OTA 任务、配置下发、批量操作、告警规则等场景支持动态分组作为目标。选择动态分组后，任务执行时实时解析成员，确保目标准确。与 Static Group 静态分组可并存，动态分组侧重自动匹配，静态分组侧重人工管理的固定集合。支持将动态分组当前成员快照转为静态分组，便于审计与回溯。
应用场景
适用于按固件版本批量升级、按区域批量配置、按健康分筛选待维护设备等。动态分组可显著提升大规模设备管理的效率与准确性。
规则何时重算组成员
动态分组的技术含义，是用一条可重复计算的规则描述“哪些设备算在内”，而不是保存一份手工点选的名单。规则的输入通常是标签、产品、固件版本、在线状态或健康分等已经写在档案上的属性。成员在每次计算时得出。计算可以在属性变化时触发，也可以在有人查看或任务执行时触发。这两种时点看到的集合可能不同，所以必须说明这份分组被使用时到底何时重算。规则本身不保存历史成员，除非系统另外做了快照。
适合动态分组的，是条件本身就是目的，例如“当前仍低于某固件版本的设备”。不适合的是法务或变更窗口要求事后复原“当晚到底升了哪几台”，那种名单在执行前就要冻结。规则里的每个字段都要设备真的有，并且含义稳定；用自由填写的备注做条件，计算结果会随写法波动。与空中升级结合时，创建任务可以预览当时的成员，执行时应说明用的是预览快照还是执行瞬间的重算。空结果要显示成“没有匹配”，不能显示成“规则出错”，否则人会反复放宽条件，最后圈进过多设备。
任务发出后成员又变了
最容易出的事故，是升级任务绑定动态分组，执行持续数小时，期间有的设备升级成功后版本变了，被规则移出，有的设备刚被打上标签，被规则移入，于是中途加入的设备也收到了包，已经完成的设备又被另一条规则处理。操作者记住的是创建时的数量，结束时的数量对不上。另一个问题是规则引用的标签被批量重命名，分组在无人编辑规则的情况下变成空集或全集。在线状态写进规则时，设备抖动上线会反复进出分组，依赖分组的告警跟着抖动。
把动态分组的当前成员手工删掉一台，下次重算又会加回来，操作者以为排除已经生效。若业务需要排除，应把排除写进规则，或改用静态名单。嵌套规则若互相引用，可能算不出稳定成员。预览人数和执行人数不一致时，要以执行清单为准，并保留那份清单。设备健康度刚调整权重后，按分数圈选的分组会整体变化，这不是设备突然变坏，而是规则输入变了。此时应暂停依赖该分组的自动动作，等分数窗口重新稳定再恢复。
预览人数和执行清单
动态分组在人观看时算出的人数，和任务真正执行时算出的人数，中间隔着所有属性变化。升级要持续数小时的话，成功升完的设备会因为版本变了而被规则移出，新打上标签的设备又会被移入，于是中途加入的设备也收到了包。操作者记住的是预览时的数量，结束时对不上，也无法回答当晚到底包含了谁。需要追责或复盘的任务，应在执行前把成员冻结成清单，规则之后怎么变都不再影响这一次。若业务就是要“现在仍满足条件的都处理”，则应在执行记录里按实际清单保存，而不是事后用今天的规则重算昨天的范围。
从预览里手工删掉一台没有用，下次重算会加回来。要排除就写进规则，或改用不会自行变化的名单。规则引用的标签被批量改名时，分组可能在没人编辑规则的情况下变成空集或全集。在线状态写进规则，设备抖动会反复进出，挂在分组上的告警跟着抖动。嵌套规则互相引用时可能得不到稳定成员。预览为空应显示没有匹配，提示人去检查条件，而不是显示成错误后诱使人放宽到几乎全部设备。健康分的权重刚调整时，按分数圈出的成员会整体变化，这是输入变了，不是设备突然变坏，依赖它的自动动作应先停一下。