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