具身机器人任务状态机：为什么扛不住现场一次网络抖动？

最近帮一个做具身机器人平台二次开发的客户做现场排查：一台双足机器人执行迎宾任务，走到大厅转角 WiFi 抖了一下，状态机直接卡死二十分钟——客户问"这单现在到底什么状态？"，我们答不上来。这就是这一篇要讲的事。

调度平台最难的不是"做出一个能跑的版本"，是"扛住现场所有异常"。

早期那个"够用"的二态

我们第一版的任务状态，就两个值：成功 / 失败。

听起来够用吧？现场跑了一周就被打脸了。

典型场景：机器人执行到第 3 步时卡住了——既没成功，也没失败，就是"卡在那"。客户问：“这单现在到底什么状态？”

我们答不上来。

状态表达不出来，运维就要"猜"

"猜"是状态设计不完整最直接的成本：

• 🎯 客户问客服"我订单卡哪一步了"，运维要查日志才知道
• 🐛 状态字段没区分"机器人没收到"和"机器人执行失败"，根因排查要花几小时
• 🔁 重试时不知道该不该重发——失败可能真失败，也可能只是中间态
• 📉 报表数据全是"成功 + 失败"两个桶，长期看不到中间健康度

行业里典型的"五态"思路

跟几个做过类似系统的人聊，大家后期基本都会收敛到一个共同的状态集合：

• ⏳ 待执行：任务刚创建，还没下发
• ▶️ 执行中：已经下发，机器人接到开始执行
• ✅ 步骤完成：每一步单独报完成，方便定位进度
• 🎉 成功：全部步骤走完且确认通过
• 🛑 失败：因安全、超时、人工终止等原因结束

看着简单的几个状态，每个都对应一类现场异常场景。

几个关键的设计取舍

我们后来总结了一些设计状态机的"反直觉经验"：

• 🚫 不允许跨态跳变——比如不能从"待执行"直接跳到"成功"
• 🚫 不预留"未知"状态——状态必须是明确语义，遇到"未知"等于设计漏了一个状态
• 🎯 每个状态都有进入条件——靠事件驱动进入新状态，不靠定时器兜底
• 🔁 必须有"幂等键"机制——客户重复点击或网络重发，不能产生重复任务

还有一个隐形的"幂等"

任务级别有幂等，事件级别也要有幂等。同一事件被机器人发了多次，平台不能重复处理。这是分布式系统的基本功，但在机器人现场特别容易踩——网络抖一下，事件就会被重发。

我们的做法大致是：

• 📦 每条消息带唯一 ID
• 📦 平台用这个 ID 做去重
• 📦 即使消息被重复接收，处理逻辑只跑一次

写在最后

状态机这件事，第一版往往是最简单的，但也是最经不起现场考验的。

客户不会按文档里的"理想流程"用系统，他们会按现场实际场景用。状态机设计得不够细，所有异常都要靠人肉兜底——这事儿无法长期可持续。

我们现在评估一个调度平台是否"成熟"，第一眼看的就是状态机。状态机糙的，其他地方再漂亮也不靠谱。

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