芯耀
与非AI
583
近日，百度旗下萝卜快跑的无人驾驶出租车，在行驶中突然集体 “原地趴窝”。87辆停在路中央打着双闪的自动驾驶汽车，导致武汉多条核心路段瘫痪近3个小时。
有乘客被困在高架车流里近2个小时，车内SOS按钮只机械回应 “系统异常”，客服电话迟迟无法打通，最后靠交警才得以脱困。
武汉交警初步判定事件为“系统故障”，而百度官方则一再三缄其口。网上很多分析把原因指向了 “通信异常”。
果真是如此吗？下面我来说下自己的一些看法。
这锅，不该网络背
作为智能网联汽车的“大动脉”，通信网络常常在出问题时成为第一背锅侠。但从专业角度来看，这次真不关网络的事。
既然是智能网联汽车，那无线联网必然是最最基础的强需求。萝卜快跑在其官方网站上指出，其汽车设计有“十重安全冗余”，通信是其中重要的一重。
在其中的“5G冗余”中，我们可以看到有“独立双模组”、“5G双卡双待双频并发”、“安全数据链路48ms切换”。下面我们逐个分析。
独立双模组：车端搭载两颗物理上完全独立的车规级 5G 通信模组，其中任何一个模组工作异常，理论上都不会影响车俩运行。
5G双卡双待双频并发：车里配有两张SIM卡，分别接入两家运营商的网络。这样就算一个运营商的网断了，车辆依然可以连接另一张网络正常工作。
并且，这里的5G还支持双频并发。也就是说，车辆接入的每个网络都同时配置了两个不同频段的小区，即使一个小区故障退服了，另一个小区也会保障车辆联网。
安全数据链路48ms切换：当系统检测到安全链路的主通信链路的质量下降时，可在48 毫秒内切换到备用链路，理论上不会任何出现数据传输中断。
车辆端的5G通信冗余备份，简直是武装到了牙齿，真是想断网都难。并且，这么多车的通信系统同时出问题的概率基本为零。
那会不会是基站出了问题？有这个可能。
但综合判断下来的结果是：基站也没有出问题。
5G网络主要由基站和核心网组成。分布在各个地点的多个基站连接到统一的核心网，并通过核心网来交换数据。
在密集城区，每隔几百米就有一座基站。
3月31日晚上，萝卜快跑在武汉多个地点同时趴窝。如果是基站问题导致的，那就要两家运营商的多个基站同时发生故障，这基本不可能。
如果是两家运营商的核心网同时了出问题，那将导致大片的基站退服。这绝对是个炸裂级别的新闻，带来的损失远比近百辆萝卜快跑集体趴窝大。
那么，会不会是晚高峰的网络拥堵，让车辆和云端的通信不畅导致的呢？
要知道，大家上班上学的路线不怎么变，同一地点的话务特征是有周期性的，没有重大活动的话，本周二和上周二的晚高峰的话务量也是差不多的。
为什么2月24日萝卜快跑还跑地好好的，一周之后的3月31日就集中趴窝了呢？这显然不是高峰期网络拥塞可以解释的。
萝卜快跑的自动驾驶采用“车路云一体化”架构，云端相当于整个系统的大脑。车辆就像腿脚，只负责感知和执行，一切驾驶指令都要从云端决策并通过网络发给汽车。
从前面的分析可以得出，故障不是车的问题，不是路的问题，也不是网络的问题，那必然是云端这个大脑出了问题。
过度依赖云端，就像把鸡蛋全放在了一个篮子里。真正成熟的自动驾驶，需要两条腿走路。
车路云架构的缺陷
自动驾驶有两条技术路线，一条是单车智能，另外一条是车路云协同。
单车智能
所谓单车智能，就是把驾驶的所有动作，即感知、决策、执行都在车内完成。
车自己的摄像头、激光雷达、毫米波雷达负责看路，车自己的车载芯片负责算路、做决策，车自己的执行系统负责踩油门、刹车、打方向。
云端呢？只负责车队管理、地图更新、模型训练，软件OTA等，不会覆盖本地自动驾驶决策。
因此，单车智能路线的适应性极强。哪怕完全断网，没有任何路边设备，车该怎么开还是怎么开，核心能力不打折。
车路云一体化
这条路线需要车端、路侧、云端三方协同，而网络则是连接车路云的“大动脉”。
车端：车载单元接收路侧单元和云端下发的协同数据，并将自身感知的数据与外界数据进行精准融合，执行自动驾驶任务。
路侧：融合激光雷达、毫米波雷达、红外相机等多种传感器，感知距离可达500到1000米，对闯红灯、鬼探头、远处事故都了如指掌，当于给车开了“上帝视角”。
云端：可利用强大的算力运行端到端自动驾驶大模型，负责为大规模车队分配运力、规划全局最优路线，并可直接下指令“微操”车辆行驶。
网络：也就是蜂窝车联网，即C-V2X，提供低时延高可靠的连接，让车与车、车与路之间直接对话，也可以支撑车辆与云端的大规模数据传输和指令下发。
车路云一体化方案通过云端和路侧分摊算力，车端的硬件配置可以做得更轻量，从而大幅降低车辆成本，非常有利于萝卜快跑这样的Robotaxi大规模部署。
在港口、矿山、固定公交线或基础设施完善的城市核心区，车路云还能实现绿波带通行、全局避堵，通行效率远超单车智能 。
然而，车路云一体化的路线的系统性风险也是显而易见的。
如果云端宕机或通信链路中断，车端往往缺乏足够的本地兜底能力，就会导致大量车辆像丢了魂一样集体失能，造成系统性的交通瘫痪。
而萝卜快跑，正是把“聪明云+傻瓜车” 的高度中心化架构做到了极致。L4级自动驾驶最核心的路径规划、实时决策、风险处置、大模型推理能力，全部集中在了云端大脑。
它的第六代无人车虽然搭载了双1200TOPS的AI芯片、38个传感器，号称拥有10重安全冗余，但却没有被赋予完整的离线决策权限，结果跟云端断联之后连安全靠边停车都做不到。
本地主导，云端辅助才是王道
单车智能和车路云这两条路线不是互斥的，应该互为补充。
单车智能有了路侧和云端的高维度信息补充，可以预知车辆自身传感器无法感知到的盲区及视距之外的路况信息，自动驾驶决策自然如虎添翼。
Waymo、Cruise、Zoox等主要海外Robotaxi玩家，都采用的是以单车智能为主，远程协助为辅的路线，云端主要用于全局优化、远程监控和模型迭代。
车路云一体化架构，在中国城市这样的高密度、行人和非机动车混杂的交通环境中是具有一定优势的，但驾驶决策不能高度依赖云端，也要给车辆本地在特定场景下自主驾驶的权限。
这样一来，在云端断联的情况下，无人车由本地算力决策驾驶，就算自动驾驶级别降低，也能通过执行最小化风险策略，做到缓慢靠边停车，不至于停在路中央造成大面积交通拥堵。
安全兜底是标准要求
国标 GB/T 44721—2024《智能网联汽车自动驾驶系统通用技术要求》规定：当设计运行条件即将不满足，L4自动驾驶系统及时执行最小风险策略并能使车辆在不满足设计运行条件之前达到静止；若因特殊情况使设计运行条件突然不满足，自动驾驶系统立即执行最小风险策略并能使车辆达到静止。
也就是说，不管是网络不通还是云端异常，只要系统判断这车没法再开了，就得执行“最小风险策略”。
最小风险策略是指所采取的使车辆达到最小风险状态的措施。
萝卜快跑的最小化风险策略显然是打双闪并原地停车。这样对于自身来说确实风险最小化了，毕竟它都停下来了，乘客也没有受伤。
但在武汉这种高密度城市高架、主干道场景下，“原地停车”反而制造了更大系统性风险，如后车追尾、交通拥堵等。
为明确最小风险策略要求，标准即将更新。
在2026年2月份起草完成，准备替代GB/T 44721—2024的《智能网联汽车自动驾驶系统安全要求》意见征集稿中指出：对于 L4 级自动驾驶系统，若发生安全档案中描述的执行最小化风险的情况，自动驾驶系统应使车辆达到最小化风险状态，且应符合以下要求：
a) 具备执行变更车道过程的能力；
b) 最小化对用户和其他道路使用者的安全风险；
c) 旨在将车辆移至不妨碍交通的地方静止。
也就是说，类似的事件再发生，自动驾驶汽车就要能完成自动变道，并把车安全停在路边，最小化安全风险。
写在最后
基于自动驾驶的Robotaxi，正在从偶尔尝鲜的猎奇体验走向忙碌生活通勤的日常。然而这条路注定荆棘密布，不可能一马平川。
本次的萝卜快跑的系统故障给行业敲响了警钟：商业化运营追求高效与低成本，这本无可厚非，但自动驾驶的底线永远是安全可靠。每次故障，都是对乘客信任的透支。
毕竟，当一位疲惫的打工人坐进没有司机的出租车时，他不关心自动驾驶产业发展的宏大叙事，他想要的只是在路上安安心心地眯一会，车就平稳安全地开到了家门口。
— END —
