异构机器人集群：编排层比算法更容易先崩

多机器人协作的项目，我见过好几个。回头看，几乎没有一个是死在单机算法上的，多数卡在编排层：任务发下去了，但没人知道谁在做、做到哪了、失败了该怎么办。

「异构」到底难在哪

同型号的一批机器人，编排是工程问题；不同型号、不同厂商、不同代际混在一起，编排就变成协议问题。

• 通信中间件不同。有的走标准话题订阅，有的只提供私有接口。
• 能力描述不统一。同样是「能搬运」，载重、精度、续航都不一样。
• 时钟不同步。每台机器有自己的时间基准，日志拼起来对不上。
• 升级节奏不同。你不能要求所有机器同时停机升级。

这四条里，前两条花钱能缓解，后两条只能靠架构解决。

编排层要管的四件事

顺序不能颠倒。很多项目一上来就做分配算法，结果能力描述都没统一，分配再聪明也没用。

任务分配：集中式还是协商式

集中式简单，一个调度器说了算，冲突少、可解释。缺点是调度器一挂，整个集群停摆。

协商式没有单点，但会出现「都以为对方会去」的空档，调试成本高。

我的选择是混合：常态走集中式，调度器不可用时退化成按区域自治。大部分场景下，简单方案的可维护性比最优解更值钱。

时钟：最容易被忽略的一类问题

多机日志对齐、轨迹回放、事件因果判断，全都依赖时间基准。我踩过一次：两台机器日志拼起来显示「先发生后触发」，实际是反的，排查了两天。

后来强制要求所有节点在启动时同步一次，并且每条记录带上本地时钟和参考时钟两个值，相对顺序靠参考时钟，本地耗时靠本地时钟。这个方法不优雅，但足够稳。

失败恢复：机器人不能随便重试

微服务里重试是常规操作，机器人不行。一台机器卡在通道中间，你让它重试，结果可能是两台撞在一起。

所以恢复策略必须带物理约束：先确认现场状态，再决定是原地等待、退回安全位还是换机执行。任何自动恢复动作都要有超时兜底。

什么时候不值得上集群

如果任务之间没有耦合，单机加人工调度跑得更好。集群的价值出现在「任务有依赖、资源要共享、规模超过人工排班能力」之后。

在那之前上集群，基本是给自己造一个更难维护的单机系统。

可观测性比算法更值得投

集群项目里，我最先投的不是调度算法，而是可观测性。理由是：调度算法出问题你能看见，现场状态出问题你看不见。

具体做了三件事：给每台机器上报能力与负载的快照；把任务的生命周期做成可查询的事件流；把每次恢复动作连同触发原因一起记录。

这三件事做完之后，大部分「奇怪的行为」都能在几分钟内定位。反过来，如果只盯着优化分配策略，你会一直在解决症状。

最后补一句关于测试的建议：集群行为很难在仿真里完全复现，能上真机做小规模长跑，就不要只在仿真里验收。仿真通过只说明逻辑没错，跑得住才说明工程可用。

免责声明：本文为工程实践复盘，所述架构取舍基于个人项目经验，不构成任何技术选型或采购建议。