萝卜快跑武汉集体趴窝：无人车露出了最吓人的一面

3月31日武汉街头的萝卜快跑集体趴窝，场面确实挺魔幻的。但抛对这个B公司（BAT中的B）的失望。我也想分析一下，到底是什么样的一坨，才能让几百台号称L4级别的自动驾驶车辆变成高架桥上的路障。

瘦客户端架构的软肋：云端一断，边缘算力无法接管

目前自动驾驶主要分为两派：一派死磕单车智能，把感知和决策算力全部堆在车端；另一派则是高度依赖车路云协同。萝卜快跑的架构偏向后者。

在这种体系下，车端更像是一个挂载了大量传感器的瘦客户端。它只负责收集激光雷达和摄像头的数据，执行基本的控车指令，但很多全局的路径规划、复杂路况博弈以及远程调度，依赖的是云端服务器的实时下发。

这就导致了一个致命问题：一旦通信出了问题，不管是遇到基站信号拥堵、运营商网络抖动，还是云端服务器宕机。车辆就和大脑失联了。当云端指令无法到达，而车端本地的边缘算力不足以支撑完整的L4级决策，系统就只能进入宕机。

Fail-Safe 降级策略：为什么选择在快车道原地躺平？

这次事故最大的问题是，就算断网死机，利用残存的传感器靠边停车不行吗？停在车流穿梭的高架正中间算怎么回事？

在自动驾驶的工程设定里，有一个概念叫最小风险状态。当系统判断自己失去了安全行驶的能力（比如断网/传感器故障），会采取最保守的动作来规避风险。对于缺乏强大本地单车智能的车辆来说，断网后的所谓最小风险，就是直接原地刹停。

这个动作在封闭测试园区里没问题，但在车流滚滚、时速80公里的城市高架上，原地停车明显是风险最大的选择。

系统为什么不设定靠边停车？因为在断网状态下靠边停车，需要极高的本地感知和决策能力：要识别侧方有没有车，要判断距离，要打转向灯并线。一旦在这个变道过程中发生任何剐蹭，系统决策失误，企业就要担全责。而根据现行的交规逻辑，车辆如果在路上保持静止，后车撞上来大概率是后车追尾全责。

所以系统采取了最简单粗暴的策略：切断动力，原地刹停。这也是算法在规避定责上的最优解。交规逻辑下，车辆在车道内保持静止，后车撞上来大概率是后车追尾全责；但如果系统在断网盲目变道期间发生剐蹭，就是自动驾驶主动肇事。算法选择了法律风险最小的选项，但这把风险甩给了其他司机。

缺失的底层冗余

如果说原地刹停是能力问题无奈之举，那么乘客被困车内、SOS 按键失灵，则说明整个系统本身就没用做底层安全冗余，属于态度问题了。

一台合格的智能网联汽车，其智驾域（负责自动驾驶）、座舱域（负责交互）和车身控制域（负责门锁等）在底层逻辑上应该是物理隔离的。每一部分发生问题时，不应该影响其他部分的正常使用，前段时间某品牌高速上被语音助手关闭大灯也是一个典型的底层混淆的问题。

车门锁死、紧急求助电话打不通，说明这台车的应急通信模块和座舱门锁控制，与自动驾驶主网络绑定过深，甚至用的同一个信道。系统没有为最极端的断网情况预留一套独立的纯机械解锁方案或备用通信通道。软件层面的一断全断。

自动驾驶是一个极度复杂的系统工程，算法的成熟需要时间喂养。但无论是单车智能还是车路协同，在关乎人命的安全冗余上，绝不能没有底层兜底。这次事件说明，在核心的容灾架构设计上，这套系统距离真正的成熟商业化，还有一段必须补足的技术功课。