RK3588 别再用一个 JSON 走天下了，边缘 AI 配置体系这么搭
很多做边缘 AI 设备的团队，把精力全放在算法和性能上，配置体系却是一个 config.json 塞到底。
开发阶段没问题，一到量产和运维阶段，问题全来了：
🔹 改一个参数要翻几百行，运维经常改错地方
🔹 不同客户配置差异大，每次部署手动改一堆，容易漏
🔹 配置格式一改，旧设备配置加载不了，升级后启动失败
🔹 改了配置忘了重启，配置不生效，还以为程序有 bug
🔹 想批量改上百台设备的某个配置，只能一台台 SSH 上去改
行业里有过很典型的事故：运维手滑把相机端口改错一位，四路相机全部拉流失败，设备"看着在跑、实际啥也检测不到"，远程排查了半天才发现是配置写错了。
配置体系不是"几个文件"的小事，而是一个需要认真设计的工程子系统。
五层配置架构：职责分离
把配置从硬件到业务分成五层，每层职责、权限、热加载能力都不同：
🔹L1 硬件配置——BSP 版本、内核参数、设备树。只能烧录，改完必须重启，只有固件工程师能碰
🔹L2 系统配置——网络、NTP、日志级别、内存阈值。部分支持热加载，运维工程师改
🔹L3 算法配置——模型路由、模型路径、NPU 实例数。走 OTA 升级或管理 API，算法工程师管
🔹L4 设备配置——设备 ID、平台地址、鉴权 token、推送协议。首次部署向导 + 管理 API
🔹L5 业务配置——相机列表、算法任务、ROI、防误报档位。存数据库，客户界面改，完全热加载
分层的核心价值：职责分离 + 权限分离 + 热加载能力分离。运维只能改业务和设备层，工程才能改算法和系统层，硬件层只有烧录能改。
热加载：改了配置为什么不用重启
对 7×24 运行的设备，配置热加载意味着"调整不中断服务"。行业常用的触发方式有三种：
🔹 信号触发（发个信号通知进程重载）
🔹 文件监听（监听配置目录，文件写完就触发）
🔹 管理接口调用（远程发个"重新加载"请求）
最怕的是加载到一半崩溃，配置变成"半新半旧"。解法是"全量加载 + 原子替换"：先读新配置到临时对象、完整校验、通过后一次性原子替换旧的，失败就保留旧配置并打日志。
校验：把"改错配置"拦在启动前
每一层配置都要有独立校验规则，加载时自动验，验不过就拒载并给出明确错误：
🔹 必填、格式、范围、枚举、依赖、唯一性、存在性——七类校验规则
🔹 校验规则最好也"配置化"（写在一个独立的 schema 里），新增字段不用改代码
🔹 不同层校验失败的处理不同：业务配置拒绝该条修改、系统配置用默认值兜底、硬件配置烧录前就拦
版本管理与迁移：解决"升级后配置不兼容"
每层配置带独立版本号，启动时对比：
🔹 版本匹配 → 直接加载
🔹 版本偏低 → 跑迁移脚本自动升级旧格式，迁移脚本要幂等、要备份、要能回滚
🔹 版本偏高 → 拒绝加载（软件太旧，解析不了新格式）
远程配置管理
通过平台远程批量改设备配置，不用一台台 SSH。但必须守住安全线：
🔹 鉴权（带有效 token 才接受）+ 校验（失败拒用）+ 审计（谁、何时、改了什么）+ 回滚 + 灰度
一句话收尾：好的配置体系，让设备"开箱即用、改了即生效、升级不踩坑、批量好管理"；差的配置体系，让运维每天在"改错、排查、重启"里打转。
关于作者：越微智能（Yuewell）专注具身智能与工业 AI 视觉落地，基于自研 VLA 多模态大模型，提供全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶）与工业级视觉算法定制，支持从算法、硬件到产线实机部署的全栈交付。
