去年冬天，凌晨两点多，我的手机响了。一个 Dallas 客户的仓，机房交换机例行重启，RCS 断了十几分钟，二十多台小车齐刷刷停在原地，产线等着料。值班的人只会一台一台重启小车，越重启越乱，最后是我远程指导他们先别动，等网络恢复再按流程恢复任务。那一晚我算明白一件事：RCS 断网这事，早晚会发生，区别只在于你是第一次在生产高峰时遇到，还是已经演练过。
小车和 RCS 的关系，是身体和大脑的关系。大脑断联了，身体听谁的？原地站着等，还是按记忆把手头的活干完？这完全取决于三处配置。而这三处配置，每家厂商的默认策略都不一样，签合同的时候没写清楚，上线后就是一颗雷。
第一处：失联了，小车是停还是走
RCS 和小车之间是靠网络心跳保持联系的。心跳断了，小车要先判断：这是网络抖了一下，还是真断了？这个"失联判定时间"就是第一处配置。设得太短，网络闪断一次，全场小车急停，复位半天；设得太长，真断网了小车还在按过期指令瞎跑，撞了货架你都不知道。
判定失联之后，策略一般分两档。保守档：原地停车，等待指令，适合人车混行、通道复杂的仓。激进档：切换本地模式，按小车本地缓存的地图和任务，把当前这一单跑完，然后找个不挡路的地方停下。听起来激进档更"智能"，但它有个前提：本地地图必须是最新的。如果 RCS 刚下发了临时管制区，小车还没同步就断网了，它按旧地图跑，可能一头扎进正在施工的通道。
我的建议：通道复杂、人车混行的仓，选原地停车；全封闭、路线固定的产线配送场景，可以考虑本地续跑。但不管选哪个，降速是必须的，断网状态下小车必须比平时跑得慢，这是安全底线，写进验收标准里。
多说一句网络本身。很多断网根本不是"网坏了"，是无线覆盖有死角。小车跑到两个 AP 中间漫游切换失败，心跳断了几秒，RCS 以为它失联了。RCS 服务器尽量走有线接入，别跟小车抢无线；仓库的 AP 做覆盖冗余，重点查通道拐角和高货架背后的信号。上线前让小车满场跑一圈做漫游测试，信号弱的地方先补 AP，比事后调参数管用得多。
第二处：任务缓存在哪，恢复后听谁的
RCS 断网期间，已经派发到小车的任务去哪了？这就是第二处配置：任务队列。小车本地一般会缓存当前任务和接下来的一两个任务，缓存深度的每家不一样。缓存浅的，断网超过几分钟，任务就没了，网络恢复后 RCS 要重新派发；缓存深的，小车能按记忆多干一会儿。
真正的坑在网络恢复那一刻。RCS 恢复后看到的是"断网前的世界"，小车手里是"断网期间干了的活"，两边一对账，对不上。有的系统设计是"小车上报、RCS 认账"，断点续传；有的设计是"RCS 说了算"，把断网期间的任务全部作废重派。如果是后者，小车已经送到产线的那托料，系统里显示"没送到"，会再派一车过去——重复配送，产线边上堆两托料，算谁的？
所以签合同时就要问清楚：断网恢复后，任务状态以谁为准？重复执行的任务怎么去重？这两个问题写进合同附件，比什么承诺都管用。选型阶段别只看正常流程的演示，专门让厂商演示一次"断网五分钟再恢复"，看任务对账逻不逻辑自洽，演示时支支吾吾的，八成是这块没做扎实。
第三处：人工接管，谁有权、怎么恢复
断网超过一定时间，现场一定会有人想"我来开"。第三处配置就是人工接管：谁有权把小车切到手动模式？怎么切？切手动的小车，网络恢复后是自动归队，还是必须人工一台一台确认？
我见过最乱的一次：断网后三个班组的人各自为战，有人推车、有人重启、有人直接断电。网络恢复后，RCS 里一半小车显示"离线"，一半显示"任务异常"，调度员花了两个多小时才把全场理顺。复盘发现，根本原因是没有"断网应急流程"——谁是指挥、谁不许碰车、恢复后按什么顺序归队，全都没定。
正确的做法：指定断网应急负责人，一般是当班主管；除负责人外，任何人不许手动挪车、不许断电重启；网络恢复后，由负责人按清单一台一台确认状态，再统一发恢复指令。这个流程要写进操作手册，新员工上岗培训就要讲。权限也别给太大，手动模式的操作权限只给到班组长一级，普通操作员能看到状态就行。
验收那天，记得真拔一次网线
说了这么多，落地就一句话：上线验收时，真拔一次网线。不是在会议室里看厂商的幻灯片演示，是在你的仓库里，生产状态下，把 RCS 的网线拔了，看每一台小车怎么反应。记录下来：几秒判定的失联、是停是走、走了多远、恢复后任务对不对得上、有没有重复派单。这份记录就是你的断网应急预案的底稿。
而且别只验一次。每季度做一次断网演练，跟消防演习一样，流程化。网络设备会老化、RCS 会升级、小车固件会更新，任何一次变更都可能悄悄改掉默认策略。演练不用搞很大，挑个生产低峰，拔网线十分钟，看流程还走不走得通。
断网不可怕，可怕的是第一次断网发生在生产高峰。把演练做在前面，凌晨两点的电话就会少很多。说到底，RCS 断网考验的不是小车有多智能，而是你的预案有多具体。
