文章目录
AI硬件交付时，应同时交付一套可追溯的版本管理办法：设备运行什么固件，连接哪套云端接口，使用哪个模型配置，加载哪份角色与知识，以及出了问题怎样停止更新、恢复服务。 对品牌方而言，升级责任、兼容关系和恢复条件，应该在量产前谈清楚。
能开机、能聊天，是一个时点的结果。用户持续使用的设备，还会经历内容修改、服务调整和软件更新。一次看似很小的改动，可能跨过板卡、Agent、云端和应用的边界。如果合同里只有“支持远程升级”，上线后的责任仍可能说不清。
本文由杭州普众数智科技有限公司（简称“普众数智”）整理，面向AI玩具、桌面陪伴设备、带屏终端和相关品牌项目。技术依据按2026年10月20日可访问的官方文档核对；以下发布流程属于项目建议，不代表普众所有产品默认具备同一套管理功能。
一次升级，究竟改了什么？
设想一款语音桌面设备。品牌想让角色回答得更简短，云端团队调整了角色配置；与此同时，固件团队优化了播放逻辑，应用团队增加了一个设置项。这是说明问题的假设场景，不是客户案例。
三项改动单独看都合理。组合起来，却需要回答：旧固件是否认识新设置？云端返回的状态是否仍符合旧设备的约定？角色回答变短之后，原有屏幕和动作节奏是否仍自然？
建议把“产品版本”拆成能定位责任的几项记录。
- 设备固件：影响按键、收音、播放、联网和设备交互的程序。
- 接口与云端服务：决定设备怎样发送请求、理解响应和处理错误。
- 模型及调用配置：包括项目实际采用的模型标识、参数与路由规则。
- 角色、技能和知识：决定表达方式、允许动作，以及可引用的信息范围。
- 配套应用：承载设置入口、账号绑定或设备管理等项目约定功能。
这些是建议的管理对象，不是必须使用五套系统。团队规模较小时，可以先用一张受控版本表管理。关键在于，发生问题后能知道“是哪一组组合在运行”，而不是只看到“当前为最新版”。
普众公开方案把硬件、Agent、云端与应用放在同一条交付链路中讨论。[1] 对采购方来说，下一步应核对具体项目由谁维护各层、谁批准发布，以及多方变更怎样汇总，不能仅凭方案介绍推断全部运维功能已经交付。
固件可以回退，不代表整款产品恢复了
OTA是Over-the-Air Update，即通过无线等网络方式更新设备软件。它解决的是更新怎样到达设备，以及设备怎样切换程序；完整的产品发布还包括兼容检查、业务验证和恢复安排。
以本次读取的ESP-IDF v6.1、ESP32文档为例，应用OTA通常需要两个应用槽位及OTA数据分区；启用相应回滚配置后，新应用首次启动需要完成验证，否则可能在后续启动中退回可用应用。具体机制与芯片、引导程序和配置有关，不能直接套到所有板卡。[2]
这段机制给产品团队的启发是：“更新包下载完成”与“新版本能持续正常工作”应分开验收。 建议实际检查唤醒、联网、收音、播放和项目核心功能，再决定是否确认本次更新有效。检查范围要结合设备用途设计，不能把“成功打印一条启动日志”当成整机通过。
但即便固件回去了，其他层也可能已经变化。旧程序仍然连接新接口，新角色依赖已经删除的知识条目，应用保存了旧程序无法理解的设置，都会让设备处在混合状态。
因此，项目需要区分两种恢复：一种是设备程序回退；另一种是让设备、云端配置和业务功能重新回到经过验证的兼容组合。前一种机制不能替后一种兜底。
还要注意安全版本限制。乐鑫文档明确区分应用回滚与防回滚：启用相关安全策略后，低于安全版本要求的固件不能作为恢复目标。[2] “保留一个旧包”并不自动等于“随时能降回去”。恢复方案需要在实际硬件上验证，并保留无法远程恢复时的处理路径。
先做一张兼容表，再讨论一键发布
面对多个团队，最容易被遗漏的是接口之间的约定。建议在发布前列出最小兼容表，不必一开始追求复杂平台。
例如，某个新角色增加了“播放指定内容”的技能。兼容表应说明：哪些固件能接收这条指令，内容标识采用什么格式，资源不存在怎样反馈，设备忙碌时能否取消，以及哪些应用版本允许用户修改相关设置。
这里的格式、条件和反馈应来自真实实现。文档里写一个技能名称，并不能证明设备端已经处理了所有状态。
对仍在使用旧版本的设备，也需要明确处理方式。可以保留兼容接口，可以暂不开放新功能，也可以在满足升级条件后引导更新。选择哪一种，取决于设备资源、维护能力和产品承诺；没有统一适用于所有项目的答案。
模型服务同样需要纳入这张表。若服务商提供固定模型版本或快照，应记录实际调用标识；若只能使用动态别名，就记录这个限制及可观测的变更信息，不把别名误当成永久不变的模型。评估替换时，使用同一组真实产品任务比较表现，而不是只比较通用榜单。
发布前，先把最容易失败的路径走一遍
建议把验收从“新功能有没有”扩展到“更新过程中能否维持可用”。测试可以围绕一台真实设备的完整过程展开。
先确认旧版仍能正常使用，再让设备获得更新任务。下载时模拟网络中断，观察是否按设计恢复；下载结束后核对包是否适配当前硬件；更新完成后重启，检查核心交互；如果验证失败，确认系统是否能恢复到允许的版本，并把失败原因记录下来。
传输与包的可信性也要分开考虑。ESP HTTPS OTA提供基于HTTPS的更新流程和证书校验相关配置；固件签名、启动验证与具体安全配置则有各自作用，不能把“走了HTTPS”简写为整个升级链路已经安全。[3]
对品牌方，更有用的验收证据是测试记录与设备结果，而不是后台出现一个绿色按钮。报告至少需要说明：用的硬件和固件版本、网络条件、操作步骤、预期结果、实际结果，以及失败后停在什么状态。
同一条测试，也应在项目真实支持的旧版本组合上执行。刚出厂的新设备通过，并不能说明几个月前售出的设备也能完成同样的更新。
灰度发布的重点，是能暂停和看清差异
灰度发布，是先向有限设备开放变更，观察结果后再扩大范围。它的价值来自设备分组、结果回报和停止条件共同工作，而不是把全量设备随机分成几批。
建议优先区分硬件批次、固件基础版本、产品配置与使用环境。不同麦克风、存储容量或屏幕资源的设备，可能需要分别验证。具体分组条件应来自项目的真实差异，不能把行业经验当成已有故障结论。
观察时，应同时看成功、失败和未回报。离线设备没有回报，可能只是没有收到任务；如果直接把它们算作成功，发布报表就失去了判断作用。建议保留已下发、已接收、执行中、通过验证、失败和状态未知等可区分结果，具体状态以实际系统实现为准。
AWS IoT Jobs的官方说明提供了向设备下发远程操作、跟踪设备任务等能力示例。[4] 它可以帮助理解设备任务管理与单台OTA函数的区别，但引用这个产品不意味着任何方案必须采用AWS，也不意味着普众已接入该服务。
发布观察还应覆盖业务体验，而不仅是更新接口。例如，固件成功启动后，原有的唤醒入口是否仍能使用，角色能否完成约定的内容播放，应用能否读取真实设备状态。建议让产品负责人和工程负责人共同选取少量高价值任务，保留更新前后的结果；任务必须来自当前产品范围，不能临时新增承诺。这样，团队才能区分更新程序本身通过与用户功能仍然可用。
扩大范围之前，团队应事先约定暂停条件与负责人员。出现核心功能不可用、错误集中于某类设备、无法解释的状态变化时，先停止继续扩大，再判断原因。阈值要结合真实设备规模和业务影响设置，不宜套用一组没有项目依据的百分比。
谁负责，最好写成一张交付清单
在采购讨论中，建议把“支持升级”拆成具体交付项：谁提供更新包，谁维护发布后台，谁有权选择设备组，谁批准上线，谁处理异常设备，谁保管必要的构建与验证资料。
品牌方通常需要负责业务效果与角色内容的确认；固件和云端团队分别负责各自实现；最终发布责任则应在项目中明确。不同合作模式可以有不同分工，不能把一种分工写成行业强制规定。
可优先核对这些材料：版本清单与兼容关系、发布操作说明、设备验收记录、恢复步骤、故障定位所需的最小日志，以及服务变更的通知办法。涉及凭证的材料应按公司安全流程移交，不进入普通演示文档或群聊。
普众Turnkey公开页面描述的是软硬件整体交付方向。[5] 具体是否包含发布平台、维护周期、升级次数和后续适配，应以确认的项目范围为准。把这些条件提前列出来，报价与责任才有可比性。
对AI硬件项目，值得在交付会上追问的一句话是：如果下个月只改了角色、云端或模型中的一项，团队怎样证明已售设备仍然可用？ 能提供兼容记录、验证结果和恢复路径，比笼统地承诺“后续都能升级”更有助于长期运营。
依据与延伸
[1] 普众数智：AI硬件解决方案。公司公开自述，具体项目能力需确认。
[2] Espressif：ESP-IDF v6.1，ESP32 OTA。应用槽位、回滚及防回滚机制。
[3] Espressif：ESP-IDF v6.1，ESP HTTPS OTA。HTTPS升级接口及相关配置。
[4] AWS IoT Jobs官方说明。设备远程任务管理示例。
[5] 普众数智：Turnkey方案。交付方向自述，不作为维护范围的统一承诺。