百度萝卜快跑“系统故障”：自动驾驶AI的可靠性才是胜负手

2026-04-01，武汉街头出现了一个让自动驾驶行业“脊背发凉”的画面：多辆百度 Apollo Go（萝卜快跑）无人出租车在道路上集体“趴窝”，有乘客被困车内长达两小时。多方媒体与社交平台视频显示，车辆不仅停在路边，甚至停在快速车道等更危险的位置。当地警方对外称之为“系统故障”，波及至少 100 辆车。

这类事件最刺痛的点不在于“发生了故障”——任何复杂系统都会出错——而在于故障的形态是“群体性瘫痪”。当同一套软件、同一套远程平台、同一套运行策略被大规模复制，系统的收益会被放大，系统的失误也会被同步放大。

把它放进我们这个系列《自动驾驶 AI：Tesla 与中国车企的发展路径对比》的语境里，这个案例其实在提醒所有玩家：**真正决定长期优势的，不是你能跑多快，而是你在最糟糕的那一天还能不能“稳住”。**可靠性与韧性，正在成为 AI 驱动汽车竞争的分水岭。

群体性“趴窝”意味着什么：不是单车问题，是平台问题

先把结论说在前面：**单车故障是工程问题，群体性停摆通常是“平台级失效”。**它可能来自调度与车端状态机、通信链路、云端授权、地图/定位服务、远程协助系统、甚至运维发布策略的某个关键节点。

从公开信息看，百度尚未披露具体原因，但外界看到的现象（多车同时冻结、部分位置危险、乘客滞留时间长）更像是以下几类“平台级模式”之一：

• 云端依赖过重：车端某些关键决策或安全状态需要云端“确认/心跳”，一旦云服务异常，车端进入保守停驶，但停的位置与退出机制设计不完善。
• 统一版本/策略下发导致同步失效：一次配置变更、证书/令牌过期、策略回滚失败，可能让大量车辆在同一时间进入异常状态。
• 远程接管/远程协助拥塞：当大量车辆同时需要人工或远程系统介入，队列瞬间堆积，导致“能停下但走不了”，乘客体验被拉长到以小时计。

这也是为什么机器人出租车（robotaxi）行业越来越绕不开一个词：Operational Safety（运营安全）。安全不只发生在“行驶中”，也发生在“停下来之后如何处置”，包括乘客撤离、车辆移位、道路协同、报警与救援等一整套流程。

一句可以被引用的判断：自动驾驶的竞争，不只看模型会不会开车，更看系统崩溃时会不会“有序地失败”。

自动驾驶AI的真实战场：可靠性、韧性与“可运营性”

行业里很多团队把 KPI 放在“接管率”“里程数”“开城速度”。这些指标当然重要，但从商业化角度看，robotaxi 与智能驾驶真正的门槛是可靠性工程。

1）可靠性不是“少出错”，而是“出错时不扩散”

对大规模车队来说，最危险的不是某辆车某次误判，而是：

• 同一缺陷被复制到 1,000 辆车
• 同一依赖被绑定到同一云区域
• 同一策略被一次性推送到整个城市

所以可靠性要回答三个问题：

1. 故障能否被局部化？（城市/区域/车队批次隔离）
2. 能否自动降级？（从无人到远程协助，从远程协助到安全靠边）
3. 能否快速恢复？（回滚、热修复、旁路机制、现场处置能力）

2）韧性靠架构：端云分工、冗余与“最小可用”

我更倾向于把自动驾驶系统拆成两类能力：

• 必须车端闭环的能力：感知-规划-控制的基础安全闭环、最低限度定位、刹停与靠边策略、乘客交互与应急解锁。
• 可以云端增强的能力：全局调度、复杂地图更新、车队监控、数据回传与训练、运营优化。

当系统把“必须闭环”的能力也押注在云端，遇到通信或云服务抖动时，就容易从“性能降级”直接变成“业务停摆”。这次武汉事件，无论根因是什么，都再次证明：端云分工的边界划错了，后果会以乘客体验和道路风险的形式体现出来。

3）可运营性决定规模化：不是能跑，而是能管

很多人低估了 robotaxi 的“运营复杂度”。它不是卖一辆车给用户就结束，而是 7×24 小时车队在线：

• 需要远程协助中心的容量规划
• 需要清晰的异常分类与处置 SOP
• 需要与交管、道路救援形成联动
• 需要把“乘客被困”的概率压到极低

当事故视频开始在社交平台扩散，品牌信任的损耗远超一次技术故障本身。

Tesla vs 中国车企：路线不同，但都会被“同一张考卷”检验

结论先说：端到端路线和多传感器多供应商路线，都会遇到可靠性与韧性问题，只是暴露方式不同。

1）Tesla 的端到端优势：一致性与迭代速度，但也更怕“系统性缺陷”

Tesla 更强调端到端模型与大规模数据闭环。它的强项在于：

• 车端能力更完整，理论上对云端依赖更少
• 统一软硬件栈带来迭代效率
• 大规模量产车队提供训练数据

但同样的统一也意味着：一旦核心策略或模型版本存在系统性缺陷，影响面也可能非常大。区别在于，Tesla 的问题更可能体现为“驾驶行为异常的分布性风险”，而 robotaxi 平台类玩家更可能体现为“运营系统停摆的集中性风险”。

2）中国车企常见的多传感器/多供应商方案：冗余更容易做，但协同更难

不少中国车企与自动驾驶公司采用多传感器（摄像头+雷达+激光雷达）、多域控制器、再叠加地图/高精定位/云控等方案。优点是：

• 冗余相对直观：一种传感器失效，另一个还能兜底
• 在特定场景（园区、固定路线）落地速度快

难点也很现实：

• 供应商链条长，故障定位与责任切分复杂
• OTA、策略下发、云端调度的组合更“像互联网系统”，更需要 SRE 能力

百度这次事件之所以值得行业反复复盘，就因为它提醒了所有中国玩家：当你把“车”做成“可调度的互联网节点”，就必须用云服务的标准来做车队可靠性。

从这次事件提炼的 5 条工程清单：谁先做到，谁更有长期优势

下面这 5 条，我认为会在未来 2-3 年变成“自动驾驶规模化的基础设施”。如果一家公司做不到，跑得再快也会被一次系统性事故打断节奏。

1. 灰度发布与城市隔离：任何策略/证书/配置更新，都要支持按城市、按车队批次灰度，且一键回滚。
2. 端侧“安全靠边”必须独立可用：即便云端断联，车辆也能完成安全停靠、告警、乘客引导与应急解锁。
3. 远程协助容量要按“峰值事故”设计：不是按日常工单量，而是按“100 辆同时异常”的极端场景压测。
4. 故障树与演练机制常态化：像航空与云计算一样做 tabletop exercise（桌面推演）与演练复盘，把异常处置变成肌肉记忆。
5. 对外透明与可核查：事故通报、恢复时间线、影响范围、改进措施要可追踪。沉默会让市场用最坏的方式脑补。

可引用的一句话：自动驾驶的护城河，越来越像云计算：比的不是功能多少，而是故障能不能被控制在“可接受的半径”内。

对投资人、车企与城市管理者：下一步该看什么指标？

如果你在评估 Tesla 或中国车企（含 robotaxi 平台）的长期优势，我建议把关注点从“单次演示”挪到“体系指标”。更接近真相的指标包括：

• 车队级可用性（Fleet Uptime）：按城市与时段统计服务可用比例
• 远程协助介入率与平均处理时长：尤其是拥塞时的尾部时延（P95/P99）
• 端云断链下的最小可用能力：断网/断电/定位异常时，车辆能否可控退出
• 重大故障 MTTR（平均修复时间）：从发现到恢复服务的时长
• 乘客安全事件闭环时间：从乘客发起求助到人员响应到问题解决

这些指标听起来“没那么酷”，但它们决定了能不能跨城扩张、能不能出海、能不能把保险与监管成本压下来。

可靠性会决定全球化：出海不是换个城市跑，而是换套规则跑

百度此前公开提到计划在迪拜部署超过 1,000 辆自动驾驶车。无论具体节奏如何，出海都会把可靠性要求抬高：

• 合规更严格、问责更清晰
• 对故障通报与数据留存的要求更高
• 当地公众对“被困两小时”的容忍度更低

这也是为什么我认为：未来竞争力不只在模型能力，而在“AI + 软件工程 + 运营体系”的综合体。

写在最后：下一次“系统故障”，会把谁的优势暴露得更清楚？

武汉这次 robotaxi 停摆事件，给行业上了一堂很贵的课：**自动驾驶 AI 走向规模化之后，最怕的不是“偶发事故”，而是“系统性停摆”。**它会同时打击安全信任、运营效率与监管预期。

对 Tesla 和中国车企而言，这张考卷迟早会发到每个人手里：当传感器异常、云端抖动、远程协助拥塞、甚至一次错误配置同时发生，你的系统还能不能让车辆安全退出、让乘客尽快离开、让城市交通不被拖垮？

如果你正在评估自动驾驶 AI 路线（端到端 vs 多传感器多供应商）、或在做智能驾驶/robotaxi 的落地规划，我建议从“功能清单”转向“可靠性清单”。真正的长期优势，往往藏在这些不显山不露水的工程细节里。