ELI5 · 说人话
机器人厂商各说各的方言。平台干的活只有一件：把一百种方言，翻译成一种普通话，让上面的业务系统一辈子只用学这一种。
先看为什么
机器人从 10 种涨到 100 种：左边从 50 条变 500 条，右边从 15 条变 105 条。乘法变加法，这就是中间那一层唯一存在的理由。
整体长什么样
分层的检验标准只有一条：接第 101 家厂商时，只有第 2 层要动。1、3、4 层一行代码都不该改。
怎么加第 101 家
插件只需要交出三样东西，内核凭这三样就能驱动任何机器人：
一个厂商的解析代码抛异常、死循环、内存泄漏，不能把整个网关拖死。独立进程或独立线程池，超时就掐。
内核里出现 if (vendor == "A") 的那天，插件化就死了。差异全部下沉到插件的 capabilities()。
插件按版本注册到插件仓库，网关动态加载。新增一家不该影响已经在线的 10 万台老设备。
插件解不出来的字节，原样存进死信队列。不然厂商改了个字段，你连排查的证据都没有。
说同一种话
「移动」这件事，一百种机器人都会。那它就该只有一个名字 move(x, y)。剩下的差异用四件套描述：
移动、清洁、载货、开舱门、拍照。业务先问「你会不会」，再决定派不派活给它。
带 cmdId、参数、超时。指令是请求，不是结果——发出去不等于做完了。
到点了、卡住了、电量低了、任务完成了。终态只能由事件确认，云端不许自己猜。
位置、电量、载荷、固件版本。属性会变，所以要存在「影子」里，还要带时间戳。
云里的替身
有了影子，业务查 10 万台设备的状态就是查一次 Redis，不用去戳 10 万条长连接。机器人离线时，影子还在，只是多了一个 offline 标记和最后一次上报时间。
影子怎么设计？三段状态 · 逐字段时间戳 · 收敛闭环 →还活着吗
离线要让业务「快速感知」，靠的不是让业务每秒来问一次，而是平台把事件推出去。10 万台设备被轮询，能把数据库打穿；被订阅，只是多了一条 Kafka 消息。
一条指令的一生
敢重试的前提是幂等。幂等靠这四条同时成立：
机器人侧记住最近执行过的 N 个 cmdId，见到重复的直接回上次的结果，不再执行第二遍。
指令按 deviceId 分区，一台设备一条队。不然「前进」和「停止」谁先到都不确定。
1s / 2s / 4s，最多 3 次。无限重试会在机器人恢复的瞬间把它砸死，这叫重试风暴。
ACK 只证明「收到了」。真正的完成必须等一条 task.finished 事件，云端不许自行改成完成。
断了怎么接回来
机房抖一下，10 万台设备同时掉线。如果它们都等 1 秒后重连，你会在第 1 秒被自己的设备 DDoS。抖动就是给每台机器发一个不一样的号。重连回来之后还有三件事：
会话恢复：凭 clientId 找回原来的订阅关系，不要求设备重新注册一遍。
补发离线期间攒下的指令，按原顺序。过期的（比如 10 分钟前的「立刻停车」）直接丢弃并告警。
全量上报一次自己的真实状态，把影子里那份过期的信息覆盖掉。
对不上怎么办
云端影子和真机不一致是常态，不是故障。你要做的不是消灭它，是让它在几秒内自己收敛。三层兜底，越往下越慢也越彻底：
设备一连上，先把完整状态整个交出来。这一次覆盖，能解决掉大部分不一致。
每 30 秒的心跳里捎上状态 hash。云端一比对，不一样就主动拉一次全量。代价只有几个字节。
按分区扫描，几分钟一轮，专门捞那些「不确定」的指令和长期没动过的影子。兜最后一层底。
谁去干这活
调度器和指令下发是两件事：调度决定「派给谁」，下发负责「送到并确认」。把它们揉在一起，抢占任务时你会同时改两台机器人的状态，然后就再也说不清楚了。
从 10 万到 100 万
连接状态存 Redis，消息进 Kafka。网关节点挂了随便重启，设备退避重连后落到别的节点也一样能用。
不用全局锁，也不用分布式事务。按 deviceId 分区之后，单台设备的有序性是免费的。
一台设备的影子约 2KB，100 万台也就 2GB 左右。一个 Redis 集群装得下，查询是 O(1)。
早高峰 100 万台同时上报，直连数据库必炸。中间垫一层 Kafka，业务方各自按能力消费。
让 AI 来指挥
Agent 不该拿到设备的原始协议，甚至不该知道设备是哪家厂商的。它只能看见能力网关暴露出来的那几个动词，而且每个动词都带着参数范围、批量上限和权限标签。「把这层楼所有车召回」——先看 Agent 有没有 fleet.recall，再看批量上限是不是被超了。
红线
TCP 连着不代表进程活着。只信业务层心跳，漏三拍判离线；连接断开只是提前触发，不是唯一依据。
重发必须复用同一个 cmdId，去重放在设备侧。云端做不到真正的幂等——你永远不知道那条丢的是请求还是回执。
内核里出现厂商名就是红线。差异全部关在插件里，插件之外的代码不认识任何一个品牌。
别让业务轮询。判定离线的那一刻把事件推进总线，订阅方毫秒级收到，顺手把在途指令标成不确定。
超时只能标「不确定」。终态由机器人上报的事件确认，或者等对账收敛。云端擅自改状态，业务就会拿着假数据做决策。
能力白名单 + 批量上限 + 危险动作二次确认，三样缺一不可。再加全链路审计，出事至少能查清是谁下的。
厂商说什么，是插件的事；
业务听到的，永远只有一种说法。