一套任务模型适配所有品牌机器人，到底怎么设计？

做多品牌机器人调度平台，最头疼的问题：怎么描述一个机器人任务？

四个品牌，四种任务格式——这家用 JSON，那家用文本命令，还有用 XML 的，更绝的只支持图形化拖拽，根本没有文本格式。四种格式、四种结构、四种单位（有的用米、有的用毫米）、四种命令命名。

想做一个统一的编排界面，让用户在一个界面里创建跨品牌的复合任务——几乎不可能。

三种"错误"方案，都踩过

🔹 每个品牌单独做一套编辑器——用户体验稀碎（四种操作方式），跨品牌编排不可能（只能分别建任务、人工接力），维护成本爆炸（新增品牌再做一套）

🔹 用"最强大"的格式做标准，其他品牌转换过去——本质是被那个品牌"绑架"：它的格式不是为别人设计的，硬塞很别扭；转换过程丢信息（比如抓取力这种品牌特有字段）；它一升级，你所有转换函数跟着改

🔹 自定义一套"超级格式"，什么都能表达——过度设计的另一个极端：太复杂用户不会用，实现成本极高，转成各品牌私有格式比登天还难

最终方案：参数化命令数组

踩了一圈坑，找到的平衡点是"参数化命令数组"：

🔹 一个任务 = 一组命令的有序列表
🔹 每个命令 = 一个命令字（cmd）+ 一个参数对象（params）
🔹 命令字是平台定义的标准动作语义，不是任何品牌的私有命令
🔹 参数是可扩展的对象，不同命令带不同参数

看着简单，但背后有几个关键决策，每一个都是踩坑踩出来的：

🔹 用扁平数组，不用嵌套命令链——嵌套看着"高级"，实际处处别扭；扁平数组解析简单、插入修改方便、一眼能看懂有几步
🔹 命令和参数分离，不用"命令字符串"——把命令和参数塞进一个字符串，每个用它的人都在重新实现"命令解析器"，还容易顺序错；分离后类型安全、自描述、方便校验
🔹 参数名带单位后缀——"约定俗成"是 bug 的温床。行业里有过真实事故：有人以为坐标单位是米、有人以为是毫米、适配器以为是厘米，机器人直接冲到墙上。参数名带上单位（坐标用毫米、角度用毫度、力用牛顿、时间用毫秒），从源头消灭歧义，多写几个字节省下无数小时调试
🔹 命令字是"普通话"，不是品牌"方言"——平台里只允许标准命令字，品牌私有协议由驱动适配器负责翻译。就像不管哪里人，到了平台都说普通话
🔹 任务 ID 可读可排序，别用纯 UUID——UUID 唯一但没人看得懂；用"前缀 + 日期 + 序号"这种格式，一眼看出哪天哪个任务，排查效率翻倍

消息规范：header + action + payload

任务在网络上传，要包装成消息，分三层：

🔹 header——消息 ID（幂等用）、追踪 ID（全链路溯源用）、时间戳
🔹 action——消息类型（执行、取消、暂停、急停）
🔹 payload——具体内容，不同 action 结构不同

这种分层是分布式系统消息设计的标准模式：header 统一处理、action 决定逻辑、payload 承载数据。

选型总结

🔹 别用某个品牌的格式做标准，一定定义平台自己的、品牌无关的格式
🔹 别过度设计，"超级格式"什么都难用；满足八成常见场景即可
🔹 扁平数组 + 命令参数分离，是实用之选
🔹 参数名带单位、命令字标准化、ID 可读，这些"小事"决定了平台的可维护性

一句话收尾：任务模型本质上是"平台和机器人之间、团队之间的沟通语言"。好的语言让协作顺畅、bug 减少；差的语言让系统充满"方言"和"歧义"，维护成本指数级增长。

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