具身机器人调度通讯怎么设计，才不会被现场一次网络抖动搞瘫痪？

最近帮一个做具身机器人调度平台二次开发的客户做现场排查：他们一台四足机器人在仓库里执行巡检任务，走到 WiFi 信号死角抖了一下，整条任务链当场瘫痪二十分钟——这就是这一篇要复盘的代价。

做调度平台绕不开的一个选择：机器人跟平台之间，走一条通道还是两条？ 走什么协议？

早期试过的两条弯路

弯路一：只走 WebSocket

我们一开始图省事，所有通讯都走一条 WebSocket 长连接：实时状态、任务下发、进度回执都在这条线里。

第一版跑起来挺顺，但很快暴露问题：

• 🕳️ 状态事件一多，回放很难——断线期间的消息怎么补？补多了又重复
• 🐢 任务下发的高可靠性要求扛不住——一条连接挂了，整个链路都受影响
• 🔁 断线恢复期间消息时序混乱——状态先到、任务后到，机器人行为错乱

弯路二：只走 MQTT

后来换思路，全部走 MQTT 主题。消息可靠性好了，回放也容易了。

新的问题：

• ⏱️ 实时状态类的延迟不理想——MQTT 主题订阅开销对高频遥测不友好
• 🔌 现场网络抖动时，重连周期长——遥测数据偶尔几十秒才更新一次
• 🎛️ 服务质量等级（QoS）的选择要权衡——开高了网络开销大，开低了又丢消息

行业里典型的折中思路

跟几个做同类系统的同行聊，主流做法其实都偏向"按消息类型选通道"：

• 🎮 实时状态、遥测、控制类：走更轻量的长连接，延迟优先
• 📦 任务下发、进度回执、审计事件：走更可靠的消息通道，完整性优先

本质上就是：每种通道擅长的事不一样，别试图一个协议扛所有。

我们现在的大致思路

不能说我们的方案是最优解，但经过几轮迭代，相对稳定：

• 🚀 高频遥测、实时状态、关键告警：走轻量长连接，消息可丢但要快
• 📦 任务下发、进度回执、审计回执：走可靠消息通道，支持重发和回执确认
• 🛡️ 两类通道都做心跳、断线重连、过期丢弃：避免陈旧数据污染当前状态
• 🔍 断线恢复时：高频类不补（最新覆盖即可）；任务类要补，避免重复执行

一些反常识的细节

• 🎯 断线时间窗口很重要——过短导致正常波动被误判，过长导致恢复不及时
• ⏰ 时间戳必须统一——跨通道串联时，时间戳不一致会把因果关系搞乱
• 🚫 不要在通道里塞"通用消息"——一旦放开，每种通道都会变成"什么都得管"的杂货铺

写在最后

通讯架构这件事，最容易犯的错是"选一个协议当万能解"。真正稳的系统，靠的不是某个神奇的协议，是每种消息走最合适的通道。

我们给客户讲解这套架构的时候，喜欢用一个比喻：实时类像"打电话"，任务类像"寄快递"。你不会用电话寄一份重要合同，也不会用快递打一通紧急会议。

关于作者：越微智能（Yuewell）专注具身智能与工业 AI 视觉落地，基于自研 VLA 多模态大模型，提供全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶）与工业级视觉算法定制，支持从算法、硬件到产线实机部署的全栈交付。