AI 陪伴硬件：对话链路与 OTA 升级怎么拆
端云协同里，把「能聊天」和「能升级」做成两条可独立演进的链路。
陪伴硬件容易做成「大泥球」：语音、模型、设备控制全耦在一起，一改提示词就要发整包固件。更稳的做法是拆成对话链路与运维链路（含 OTA），各自有版本、各自可灰度。我在端云协同项目里坚持：对话失败可以降级，升级失败必须可回滚。
对话链路
端侧负责唤醒与采集 → 云端做 ASR / LLM / TTS（或混合端侧）→ 结果回放。每次交互带 sessionId 和 turnId，便于追踪「哪一句触发了什么动作」——例如调节音量、切换角色、上报情绪标签。
超时与降级
策略要提前写死，写进配置而不是硬编码：
- ASR 超时：提示「没听清，请再说一次」，限制连续重试次数
- LLM 超时：播本地缓存话术，不一直转圈
- TTS 失败：降级为文字屏显或预录音频
云端链路建议独立 API 网关与限流，避免促销或批量 OTA 占满带宽导致交互卡死。
隐私与内容安全
儿童或家庭场景还要考虑：语音片段上传是否加密、留存多久、是否可一键删除。我会在架构评审里单独列「数据生命周期」：端侧缓存目录上限、云端 object 过期策略、审核敏感回复的拦截规则。对话链路的日志和 OTA 日志分库存，避免运维查版本时误触用户内容。
OTA 链路
版本包校验（哈希 + 签名）→ 分片下载 → 校验 → 切换 → 失败回滚。OTA 通道与对话通道隔离：MQTT topic 分开，大文件走 HTTPS，MQTT 只传 manifest 与进度。
升级状态机
空闲 → 下载中 → 待安装 → 安装中 → 成功 / 回滚中 → 空闲。每个态都要可查询，运维后台能看到设备当前版本、目标版本、失败原因码。切忌「静默升级」——用户正在对话时，应延迟安装或提示稍后重启。
远程运维
设备影子同步：在线状态、固件版本、最近错误码、磁盘与温度（若有关）。运维后台能远程抓日志片段、重启服务进程，而不是只能整机断电。日志拉取要做授权与审计，防止变成后门。
常见坑
- 对话服务与 OTA 共用同一 HTTP 连接池，升级时阻塞 ASR 上传
- 回滚镜像未预置，升级失败变砖
- 端侧未校验签名，中间人可刷恶意固件
- 升级包与对话资源混在同一分区，空间不足时两个链路一起挂
灰度与回滚演练
发版前我会在测试设备上完整跑一遍：正常升级、中断下载、校验失败、安装失败回滚。生产灰度按设备批次或地域逐步放量，观测错误码与对话成功率，而不是一次性全量。回滚演练要真实执行，不能只在文档里写「支持回滚」——很多团队第一次失败才发现回滚分区没写满。
检查清单
- [ ] 对话链路与 OTA 链路可独立发版
- [ ] 升级失败自动回滚到上一已知好版本
- [ ] 任意 session 可在云端还原关键事件顺序
- [ ] 远程运维操作有账号、时间、设备 ID 审计
智能硬件的产品感，来自对话；智能硬件的口碑，来自它坏了你还能修。把两条链路拆开，团队才能并行演进模型与固件。
产品迭代时，对话提示词和角色设定应走云端配置热更新；只有涉及端侧唤醒词、音频编解码或安全策略变更时，才触发固件 OTA。这样大多数体验优化不必等待硬件发版周期。
小结
陪伴硬件要把对话链路与 OTA/运维链路拆开，超时降级与版本回滚是产品信任的一部分。设备影子、错误码与远程日志决定你能否少跑现场。发布新固件前，先在小流量设备验证完整升级与回退。