具身机器人多品牌接入：别再把核心写死了，否则新接一个品牌要改两周
最近帮一个做具身机器人平台二次开发的客户做多品牌接入，他们现场既有四足巡检、双足迎宾、又有复合臂机器人——三个品牌、三套协议，每接一个就要改核心这种事，在他们项目里发生过不止一次。
刚接到第一个调度平台项目时，我们差点踩了一个大坑。
早期那个"看起来很合理"的写法
客户A 用宇树、宇树搞不定让客户B 也来用，宇树不行上优必选……
我们最早的做法，是直接在调度主流程里写：if brand == "宇树": …、elif brand == "优必选": …。
第一天确实挺顺，第三天崩了。新接一个品牌，要改核心状态机；改完核心状态机，又把之前接好的一个品牌的回归测试跑挂了。改一次心惊一次。
行业里反复翻车的根因
后来复盘，这其实是把"产品迭代节奏"和"架构稳定性"绑在了一起。每接一个品牌都要改核心流程，意味着：
- 🐛 新品牌的 bug 风险会污染老品牌
- 🐢 老客户的功能升级被新客户的接入节奏拖慢
- 🔥 测试覆盖成本指数级上升
这在行业里其实是典型的"用 if/else 假装抽象"——看起来分开了，本质上还耦合。
我们最终走通的那条路
后来我们做了一个关键切分：让核心只认"通用动作语义"，不让品牌字眼进主流程。
具体怎么做？大致思路是：
- 🎯 在核心调度侧，只定义"导航、移动、抓取、语音、识别"这一类通用动作
- 🔌 每个品牌单独做一个适配插件，把通用动作翻译成品牌私有指令
- 📦 任务下发时，核心只关心动作+参数；适配插件关心怎么落地
- 🚫 主流程里禁出现任何品牌分支、禁出现任何品牌私有字段
这样一来，新接一个品牌，只新增一个适配器插件 + 一份配置，主流程一行不动。
一个反直觉的取舍
有人问：为什么不让适配器"共享"？我们的答案是：不允许。每个品牌的协议细节、错误码、重连策略都不一样，强行抽象反而会变成"看似通用、实则谁的特性都缺"。
写在最后
接入多品牌这件事，表面上是个 SDK 对接问题，本质是个架构边界问题。边界一旦画清，后面接二十个品牌也不慌；边界不清，每接一个都在给自己挖坑。
这是我们开发综合调度平台学到的第一课：先有抽象，再接产品。
关于作者：越微智能（Yuewell）专注具身智能与工业 AI 视觉落地，基于自研 VLA 多模态大模型，提供全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶）与工业级视觉算法定制，支持从算法、硬件到产线实机部署的全栈交付。
