机器人调度平台任务下发：别再用硬编码JSON了，否则客户改一次要跟你吵一周
最近帮一个做机器人调度平台二次开发的客户做接口改造，他们工单系统想自己组装任务序列——结果是前后端扯皮了整整一周，谁都说服不了谁。这就是这一篇要讲的事。
最早做调度平台的时候，任务下发接口长这样。
一个字面意义上的"能动但不可用"
那时候我们提供给客户的接口，是用一个字符串数组描述任务步骤：每一步就是一个动作名字符串，比如"navigate"、"speak"、"dock"。
客户提了第一个需求：让机器人去 A 点、播一段话、再去 B 点。我们凑合写了。
客户提第二个需求：在第一步前加一个"识别"动作，让机器人先看清楚环境。我们改了三处代码。
客户提第三个需求：动作参数要可调，比如不同目标点、不同播报文案。我们开始意识到，这玩意儿每变一次都要改代码。
行业里典型的"字符串数组陷阱"
后来跟同行聊，发现大家早期都走过这条弯路。问题本质是：
- 🎭 动作语义和参数耦合——光传一个名字，前端要拼一长串参数
- 🧱 顺序被写死——客户改步骤顺序，后端必须跟着改
- 🚪 扩展被锁死——新动作要么改主流程，要么"打补丁"加特殊处理
- 🧨 每改一次都要回归全量——任何一个动作字面变了，其他动作都被影响
我们做的关键改造
把"动作名"和"动作参数"绑在一起，组成一个对象数组下发，思路大概是：
- 📦 每条指令是一个独立的对象，核心字段就两个：动作名 + 参数对象
- 🧩 参数可以任意扩展，不需要改主流程
- ➡️ 动作顺序由数组顺序决定，不依赖后端逻辑
- 🚫 主流程里禁出现"特殊步骤处理"
改完之后客户的工单系统可以自己组装动作序列，后端只负责按顺序下发给机器人。
还有一个更隐蔽的好处
参数化之后，我们第一次能在不改代码的情况下支持客户的私有动作。客户有个"开抽屉"动作，标准动作里没有，他们自己定义动作名 + 参数，平台透传给机器人侧自己处理。
这种"动作可扩展、参数可扩展"的设计，本质上是把指令的语法和词义分开，跟自然语言处理的思路有点像。
写在最后
任务下发这件事，表面上是个"传字符串"的小问题，本质上是个产品灵活性的问题。灵活性的关键，不在能不能传很多东西，而在改一个东西要不要动一堆东西。
我们现在接客户定制，最快一两天就能接一套新动作——这件事靠的不是研发加班，是早期把结构想清楚了。
关于作者：越微智能（Yuewell）专注具身智能与工业 AI 视觉落地，基于自研 VLA 多模态大模型，提供全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶）与工业级视觉算法定制，支持从算法、硬件到产线实机部署的全栈交付。
