在自动驾驶被“接近完美”的预期中不断包裹时，一场突如其来的系统性失灵，彻底撕开了那曾被暗藏已久的“伤口”。

3月31日，百度旗下 Apollo Go 在中国武汉发生了一次异常事件，超过100辆萝卜快跑（Robotaxi）在道路中途集体“罢工”，部分乘客被困长达近2小时，甚至还出现了至少3起被追尾事故。

这类事故之所以引发关注，不仅因为规模，更因为它属于“本不该发生”的那一类。按照自动驾驶的基本设计原则，即便完全失去数据连接或远程支持，车辆也应具备执行基础安全操作的能力——比如缓慢靠边停车，进入所谓的“最低风险状态”。

但在武汉，这些车辆却直接停在车流之中，甚至包括高架道路，让乘客在“下车不安全、不下车更焦虑”的两难中等待。

更令人不安的，是后续响应的缺失。乘客反馈称，与客服建立联系本身就需要漫长等待，而承诺“即将到达”的人工支援却迟迟未响应。

这种表现，与2025年12月20日 Waymo（谷歌母公司 Alphabet 旗下的自动驾驶公司）在旧金山因停电引发的系统拥堵形成了某种诡异的呼应：当大量车辆同时请求远程协助时，后台系统反而成为新的“单向故障”。

但两者之间的差异，同样耐人寻味。Waymo 的车辆本身并未失灵——它们知道在红绿灯失效时应按四向停车规则行驶，只是在人类交通秩序突然混乱的情况下，选择“打电话回总部”请求判断。

但武汉的情况截然相反，在交通秩序正常的情况下，数百辆萝卜快跑同时发起请求，而拥有约70名远程操作员的系统迅速被压垮，车辆在十字路口“集体发呆”，阻塞交通。

相比之下，百度此次事件更接近一种“硬失效”：车辆直接停止运行，且未能自行转移至安全区域。这意味着问题可能不只是远程支持系统，而更可能涉及更核心的控制逻辑，甚至是整车系统层面的异常。

问题的根源，很可能隐藏在中美自动驾驶路径的差异之中。在与多家企业交流后可以发现，中国厂商往往更倾向于“中心化”架构：依赖云端调度、集中控制，以及未来规划中的 V2X（车对外界的信息交换，也叫车路协同）体系，通过大规模基础设施提升效率。而美国厂商则更强调“去中心化”，尽量让单车具备独立决策能力，减少对外部系统的依赖。

这种差异，在平时或许体现为成本与效率的权衡，但在极端情况下，却可能演变为风险的放大器。中心化系统的优势在于统一调度，但一旦核心节点失效，就可能拖垮整个车队；而去中心化系统虽然冗余更高，却也可能在极端复杂场景下陷入“各自为战”的困境。

当然，武汉事件仍有其他可能解释。例如，一次存在缺陷的软件更新，可能触发了车辆的保护性停机；又或者，后台系统检测到某种潜在危险，被迫执行紧急“全局刹车”。

但无论是哪种情况，一个关键问题始终存在：为什么在已知乘客被困的情况下，系统仍无法将车辆移至更安全的位置？这要么意味着车辆本身失去了基本控制能力，要么意味着存在比“停在路中间”更严重的风险隐患。

从行业角度看，这类事件并非完全负面。正如没有人在封闭测试场中能穷尽所有极端情况，大规模真实道路部署，本身就是为了“暴露问题”。

Waymo 在旧金山事件后已承认准备不足，并开始改进远程支持与应急响应机制。同样，百度也大概率会从此次事故中吸取教训，例如增强系统冗余、优化软件回滚机制、提升应急人力调度能力等。

但更深层的挑战在于架构层面。如果问题源自过度依赖中心系统，那么修复将不仅仅是“打补丁”，而可能需要对整个技术路线进行重构——这意味着时间成本可能以“年”为单位计算。

面对质疑，百度至今未对外界询问作出回应，仅由当地警方以“系统故障”一语带过。在一个高度依赖公众信任的行业，这种沉默本身也会成为风险的一部分。