先说结论
因为武汉萝卜快跑事故，国家暂停了 L4 级牌照的发放，百度股价在节前重挫。中国的 Robotaxi 是不是要完了？
萝卜快跑武汉事故不是中国 Robotaxi 的终局，而是强云端依赖式无人驾驶的第一次城市级信任破产。
表面上看，这是一次 Robotaxi 的事故。但真正重要的不是近百辆车坏了，也不是百度股价跌了，甚至不是中国暂停了新的 L4 级牌照发放。更重要的是，像百度使用的这种强云端依赖的无人驾驶，出现了第一次城市级的信任破产。
无人驾驶实际上有很多流派，百度采用的是最保守的一种：车尽量什么都不干，所有的事情通通到云端去干。
武汉事故真正暴露了什么
事情是怎么发生的？3 月 31 号晚上，武汉街头不是一辆无人车出问题了，而是一套用云端管理城市车队的系统，当着所有人的面失灵了。
一辆车坏了叫事故；一批车在同一个时间窗口，在多个核心路段、高架桥、主干道上同时趴窝，就不是普通事故了，而是系统性失败。
萝卜快跑最可怕的不是不会开，而是出了事故以后自己怎么收场的问题。
过去大家会问：
- 它到底能不能自己开？
- 到底跑了多少公里？
- 订单多少单？
- 成本降了多少？
这是原来大家关心的事情。但是武汉之后，大家开始问一些新的问题：
- 这车断网以后怎么办？
- 云端失联以后怎么办？
- 客户被困住怎么办？
- 交警来了以后能干嘛？
- 一个城市的车队同时出问题以后，谁来收场？
为什么会问这样的问题？因为这些车突然就停在了高架桥、主干道、隧道里，直接在原来位置停下来了，没有靠边停车，没有做任何规避，也没有办法恢复。交警到现场，拿它也没办法。
最后顾客在车上不敢下车，因为在高架桥上，旁边的车呼噜呼噜地过，万一下来被碰着了算谁的？最后是等到交警到现场指挥交通，把前面的车拦住以后，顾客才敢下车，然后从高架桥上走下来。这个还是非常吓人的。
百度的问题不是不会做 AI，而是它还在用老的互联网中心化平台思维，去管理一个必须分布式自救的现实世界安全系统。这事是走不通的。
互联网产品宕机，用户骂几句就可以走了；搜索引擎挂了，用户换一个搜索引擎也能跑；地图导航错了，用户也可以重新规划；广告系统出 bug，最多少赚点钱，也不是什么大事。
但是 Robotaxi 宕机，车会停在高架上，顾客会被困在车里，交警要上去救人。因为一旦堵车，高架上停了车以后，救援车辆也上不去，都堵在底下。交警也只能把摩托车停在底下，然后走上去，城市交通就直接被拖垮了。
这一次百度的事故，是很多集中式管理都喜欢的那种模式：一个大屏幕看全城，一个中心管全局，一个按钮控制所有。可现实世界不是 PowerPoint，大屏黑了，按钮失灵了，中心宕机了，所有的车就真的原地停那了。这个事是不行的。
百度采用这样的方式，也不是说百度的思想就多么守旧，而是可能有些政府就喜欢这种方式。当我需要去管理的时候，可以通过中心一把就管理住它。现在可以看一看，这种中心管理一旦出了问题以后有多么可怕。
3 月 31 号到底发生了什么
根据 Reuters 2026 年 4 月 1 日的报道，武汉警方表示，百度 Apollo Go，也就是萝卜快跑，在武汉发生了由于系统故障导致的大范围停运。
大家注意，“系统故障”是武汉交警给出的定论，而百度自己给的叫“网络故障”。其他人又给了一些别的定性，所以他们在这一次事故的定性上是不一样的。根本原因还在调查之中，到现在为止其实也没有公布最后的原因。
Reuters 还提到，至少 100 辆萝卜快跑的车受到了影响，有乘客因为道路车流太大，不敢直接下车，需要报警求助。本地媒体也称，部分乘客被困接近两个小时。
大批报警是在 3 月 31 号晚上 8:57 开始的。地点主要是二环路、三环路、高架桥梁、隧道、主干道以及部分核心通勤路段。
有没有坏在不太核心的地方？可能也有，只是人家可能自己下车就走了，把车扔那儿，也没有造成特别严重的拥堵，所以就没有报道出来。现在报道出来的，肯定都是这些显眼包。
用户最关心的问题不是车有没有坏掉，而是这些车是不是都坏了。答案不是。百度在武汉一共有 500 多辆车，这一次报道的是 100 多辆，但是具体数字并没有最终准确的统计，只是被爆出来是这么多。
那是不是某一个区域所有的车都坏了？是不是这个区域网断了？其实也不是。只是在特别核心的区域，报道出来的这些车比较显眼而已。而且就算是相同的区域，也有一些萝卜快跑的车顺利开过去了，有一些车就停在高架或者主干道中间，乘客不敢直接下车。
SOS、客服与远程协助的失灵
SOS 和客服远程协助体验失灵。车里有个 SOS 按钮，你去按，没人理你。因为他们这个呼叫中心压根也没想到会有 100 多辆车同时呼叫，不可能平时配那么多人手在里头。如果配那么多人手，在没有人呼叫的时候，这不就是亏钱吗？
远程协助也没有起到任何效果。车辆肯定已经判定自己出问题了，没有办法通过远程解锁，也没有办法通过远程协助让这个车开走，等于直接在那头把车锁了。
最后只能是交警介入，而且城市交通受到了极大的影响。这就是这一次事故的表现。
车停下来不一定是错。他们采用的叫最小伤害原则，就是发现不对了、不会开了，那就停在这不动了。但是错就错在它停在了不该停的地方，直接停在高架桥上，停在隧道里。
而且它停完以后，谁都拿它没办法，最后只能靠百度派维修人员到现场去，才可以把车开走。交警到那儿都没法把车弄走，因为它把这车锁住了。
“系统故障”还是“网络原因”
武汉警方的说法，路透社引述叫“系统故障”，也就是说系统故障导致的。这个说法可信度还是比较高的，因为信息来自警方通报，多家媒体也跟进了，现场视频和乘客反馈相互可以印证。
但是系统到底哪儿故障了？是车辆故障、云端故障、网络故障、地图故障、调度故障、版本更新故障，还是运营商网络故障？这些就没有详细解释。
百度客服说的是“网络原因”。甩锅给网络原因的意思是：这个责任不在我身上，责任是网络的问题。为什么会说这样的话？这一两年里，中国出现过几次一些场所或者单位开手机信号屏蔽器，导致一片范围内的 GPS 信号或者手机信号直接断网，这个是发生过几次的。百度也希望把这个锅甩出去。
从现在的情况看，应该并不是发生事故的地方就断网了，因为那些地方也有一些百度萝卜快跑的车开过去了。大概率还是云端抖动了。
当这些车辆到高架桥、到这些比较繁忙的地方时，肯定会非常频繁地跟云端进行通讯。百度的方案就是车端不做什么决策，只是把数据采集回来，在云端做决策。
到高架桥上的时候，总要稍微多注意一点、多小心一下。当云端服务器发生抖动的时候，什么叫抖动？就是现在负载比较大，有点转不过来的状态，可能有一些信息没有及时回传。
在高架桥上开的这些车说：我前面该拐弯了，你又没告诉我该怎么办，那就停这吧。它们就干了这么一个事情。
为什么说这是强云端依赖的失败
什么叫强云端依赖式无人驾驶？简单说，就是车辆不是一个完全独立的大脑，它需要跟云端系统保持高度通讯。
云端负责深度参与：
- 全局路径规划；
- 车辆调度；
- 远程监控；
- 异常判断；
- 安全校验；
- 远程协助；
- 部分应急决策；
- 车辆状态管理。
这种模式在商业上很有吸引力，因为它可以降低单车的算力成本，统一管理车队，统一升级算法，统一调度订单，方便监管接入。这也是政府最喜欢的方式，也很方便地方政府做智能交通展示，方便企业讲城市级自动驾驶网络的故事。所以这就是中国企业跟中国政府双向奔赴的一个结果。
但是它的致命缺陷是：云端越强，车端就越弱；中心越强，边缘就越危险。
如果云端稳定，一切看起来都很美好。但如果云端抖动，或者某些网络不是那么稳定，所有车同时都在等指令，就会发生像武汉这样的事情。
所有这种中央控制，或者说收权、集权管理，都会造成巨大的单点故障风险。一旦中间的服务器挂了，大家就全趴菜。
最小风险策略为何没有兜住风险
这一次百度这些车采用的叫最小风险策略。也就是当我不知道该怎么办的时候，我要想办法采取一个可以把风险降到最低的策略。百度处理的方式就是原地停车：我现在收不到信息了，啪，我就停那了。
只有百度这么干吗？不是，谷歌也这么干。应该是今年早些时候，洛杉矶出现过一次大停电，所有的交通信号灯全停了。特斯拉的车没有任何问题，该去哪去哪。而谷歌的车因为没有信号灯，也采取了最小风险策略的处理方式，也是停在路当间不动，跟百度这个玩法是一模一样的。
这种策略的目标是什么？就是识别异常，比如网络上没有信息回来，或者信号都没了。识别异常以后，降低车速，打开双闪，寻找安全区域。
按道理说，应该找个安全区域停下来，或者靠边停车，提醒顾客，呼叫救援，保持通讯，必要的时候释放车门，等待人工处理，甚至它应该还有一些自主恢复的能力。
但是百度这一次做的，是直接在中间就停住了。因为本车的决策能力极差，算力极差，所以它没有能力在很高的车流里靠边停车，只能在最中间的地方啪一下站那不动。是不是像咱们的新手司机一样？
双闪有可能是开了，呼叫救援肯定是失效了，因为他们在设置呼叫中心的时候，就没有想过需要有这么多人跑来呼叫。
至于事后的自动恢复，也没有做。按道理说，现在不行了，停在这了，等到网络好了，等云端没有抖动了，可以重新连上的时候，是不是可以重新恢复？没有。
其实很多这种系统一旦锁死，就没法在本地判断到底为什么锁。如果直接给你恢复了，接着往前开也很吓人，万一被黑客劫持了呢？
所以百度采用的方式就是：一旦被锁住，就彻底停住，直到有人到现场去维修为止。这也算是一种安全方法，虽然看着很笨，但是这种策略也是有原因的。
百度的问题：太相信云端
百度的问题不是不会做云端，而是太相信云端了。搜索引擎可以有一个中心大脑，自动驾驶不能只有一个中心大脑。Robotaxi 首先不是一个平台生意，而是一个安全工程。
这一次彻底暴露了百度作为老互联网公司的通病。不能简单说百度的技术不行，百度技术还是相当不错的，特别是很多从百度出来的人，在创业时还是可以做出很不错的产品的。
现在全国做 AI、做自动驾驶的很多人，都是从百度挖出来的。百度是中国最早押注 AI、最早做自动驾驶、最早搭建 Apollo 生态的公司。
根据百度 2025 年四季度财报，Apollo Go，也就是萝卜快跑，2025 年第四季度完成了 340 万单无人运营出行，季度内周出行高峰超过 30 万次。截至 2026 年 2 月份，Apollo 向公众累计提供了 2,000 万次出行服务，全球足迹达到 26 个城市，累计自动驾驶里程超过 3 亿公里。
但是问题是，百度太像一家老牌互联网企业了。老牌互联网企业擅长什么？擅长中心化，把所有东西封在自己机房里，跟相关利益方、主管方商量怎么处理。下面的使用者只管用就完了，其他的别问。
百度过去的核心能力是中心化搜索引擎、中心化排序算法、中心化云计算。在 PC 互联网时代和移动互联网时代，这套系统非常有效率。因为一旦在中心把它聚集起来，各种维护成本就很低。中心越强，效率就越高；平台越大，数据就越多；调度越统一，商业化就越容易。
但是到了 Robotaxi 这里，这套理论就不行了。因为 Robotaxi 不是一个网页，不是一个 APP，也不是搜索框，不是广告系统。
Robotaxi 是一辆真车，坐在车上的是真人，旁边跑的也是真实的社会车辆，脚下是真实的道路，前方是真实的桥梁、高架、隧道、红绿灯、施工区域和交警。
这个时候用互联网平台思维去管理现实世界安全系统，就会出问题。管理百度的这些政府机构，肯定也是喜欢中心化管理。但是到现在，不能这么玩了。
百度过去的路径依赖，是把复杂的问题收回中心，用算法、数据、平台统一解决掉。但是无人驾驶需要的，是每一辆车必须先成为一个独立可靠的安全单元。
也就是说，云端只能是辅助，车端必须能够自救。远端可以协助，但是车不能离开远端就直接脑死亡，这事是不行的。平台可以调度，但是调度中心不能是唯一的大脑。
所以百度这次的问题，不是简单的网络不好，而是老牌互联网企业的平台病。它太习惯把所有东西放在中心系统里。搜索可以这么做，广告、地图都可以这么做，但是无人驾驶不能这么干。
集中管理为什么天然会造成单点故障
这个事故最值得玩味的地方就是，强云端依赖路线非常符合企业、地方政府和监管三方共同的审美，大家都觉得非常好。
企业为什么喜欢集中？集中了以后，车队好管理，算法好升级，数据好回收，订单好调度，成本好控制，商业故事好讲。
地方政府为什么喜欢集中？也很简单，可以做智慧交通，可以上线城市大脑，可以搞示范区，可以做大屏展示，可以说自己是智能驾驶第一城。武汉肯定喜欢这个。
监管为什么喜欢集中？看得见、管得住，有总开关，有统一接口，有平台责任主体。出了事我该罚谁，能搞得很清楚。出事可以找一个公司来问责。像社交媒体、各种手机 APP，不都是按这个方式来管的吗？
所以强云端路线看起来是一个非常先进的东西：一张大屏幕，一套系统，一个云中枢，一群无人车，一个城市级的自动驾驶网络，非常漂亮的一套系统。
但是工程世界里有一个非常朴素的常识：你把所有东西接在一个中心里，就一定会造成一个中心级的故障点。它这儿出问题了，就没法整。
平时它叫高效，出了事它叫连坐；平时它叫统一管理，出事它叫一起趴窝；平时它叫城市大脑，出事叫群体脑死亡。这就是武汉这次事情的一个大的结论。
很多集中式治理最讽刺的地方就是，它总以为集中就是安全的，总以为一个中心看得见，一切就可控。但是技术系统经常用最残酷的方式提醒他们：中心不是安全本身，中心是最核心的故障源。
集权式系统最迷恋的，就是一张大屏幕看全城。可惜现实世界不是 PowerPoint。你可以把车、路、人、云、订单、监管全部画在一张图上，但是只要这个中心大脑抽风了，图上所有的小车就真的给你停在路上，死给你看。
4 月 29 日监管暂停
4 月 29 日监管暂停，这也不是一个小事。3 月 31 号武汉发生事故，4 月 1 号开始有报道。大家开了半天会以后，国家说，把全国的 L4 级，也就是做 Robotaxi 的牌照发放暂时停一下吧。
当天百度的股价就死给你看了，其他几家做无人驾驶出租车的上市公司也一起躺枪。
暂停发放的意思是，原来已经有的还能继续跑，但是暂时不能增加了。
这其实已经是百度第二次造成全国性的 L4 级牌照发放暂停了。上一次是 2024 年年底，当时百度在武汉投放无人出租车以后，一堆人出来投诉，特别是网约车司机。你来抢我饭碗了，我肯定要投诉你。
这些车开得很慢，造成交通堵塞，还经常无故停车，突然啪一下停了，停完以后再往前开，就像最新的新手一样，容易造成事故。很多人举报以后，国家也叫停了 L4 级牌照的发放。
但是在 2025 年年初，大概停了一两个月左右，就继续恢复了，还接着往前走。
这一次又是因为百度，又把这个事情给停下来了。国家也要想一想：我们这种方式是不是有问题？
远程接管为什么没有生效
武汉政府要求百度在它的中心配人，按什么样的比例来配？叫 1:3。就是你在中心有一个可以开模拟仿真出租车的司机，外面可以有三辆无人出租车。意思是，这三辆车里如果坏了一个，你可以让司机在远程接管这辆车，然后把它开走。
现在就要去找到原因：为什么当时这 100 多辆车坏了？你有 500 辆车，按道理说至少有 100 多个真人司机在中央机房里等着接管这些车辆，怎么坏了以后就彻底不动了呢？这个肯定还是要求百度去解决的。
百度应该还是会继续做这种中央管理的无人驾驶出租车。它要向政府解释，当时到底出了什么原因，哪个程序设计有一些逻辑错误，导致采用了最小安全策略以后，远端无法接管，最后必须要上人，必须要人到现场去处理。
按道理说，出了问题以后，网络重新恢复，或者云端服务器抖动结束以后，应当由云端的远程真人司机去接管这个车辆，把车接着往前开，或者开到路边上去。百度现在没有做到。
接下来就是它要如何把这个事情做到，然后重新通过认证、通过审核以后继续往前走。
这一次暂停时间也不会特别长。虽然这次是由工信部这边直接把 L4 级牌照叫停了，但是武汉要做自动驾驶第一城，要这个政绩，还是会快速把这件事情推进下去的。
中美 Robotaxi 路线的分裂
中美两国 Robotaxi 路线现在出现了分裂，这也不能说谁赢了谁输了。中国现在肯定是在急踩刹车，先停下来。美国现在在踩油门。
百度出事了，特斯拉在起飞，因为特斯拉现在已经把没有方向盘的车量产下线了，叫 Cybercab。
现在无人驾驶出租车方案大概有三套。
特斯拉路线
第一套是特斯拉的，云端基本上不管，完全靠本地处理。云端也可以进行一些简单的订单管理、简单调度，但是真正开车都是在本地。
所以前面洛杉矶大停电的时候，谷歌的车都停那不动了，而特斯拉的车全都正常开走了。人遇到停电没有红绿灯怎么开，特斯拉也怎么开。
谷歌路线
谷歌其实也不是云端遥控。谷歌云端负责的是车队调度、地图更新、远程协助、模型训练、长尾场景的一些支持。
什么叫长尾场景？就是遇到一些特殊情况，这个是在云端处理的。但是谷歌的车在没有红绿灯的时候，确实就站那不动了。
谷歌的车有一定自动驾驶能力，不像百度的车，离开云端就彻底不动，而且锁死以后解不开。
所以对比起来，也不能说百度输了、特斯拉赢了、谷歌站中间，不能这么讲。真正的对比是谁能够证明自己的无人驾驶在失效的时候是安全的。
因为自动驾驶这个事，不能保证它永远都是有效的。在失效的时候该怎么办，这才是这些 Robotaxi 真正要回答的问题。
百度还有机会吗
百度还有机会吗？有，一定有。
我不认为 Robotaxi 会因为武汉的事情就结束，也不认为百度的萝卜快跑会因为一次事故就退出历史舞台。甚至可能反过来，越早暴露问题，越有机会去维修。
但是百度必须回答以下几个问题。
- 这次的事情到底是怎么发生的？是网络、云端、车端、版本更新、系统调度，还是各种因素叠加？但是在中国，可能最后这个原因我们永远也不可能知道。
- 为什么近百辆车在同一个时间窗口里触发事故？
- 为什么车辆没有安全靠边？你不能停在路当间。
- 车端是否具备离线应急模式？现在看，百度的车可能就没有这个能力。谷歌的车有这个能力，特斯拉的车有这个能力，百度的车就不行。
- 远程安全员为什么不能接管？现在出问题的是 20% 的车，而按照武汉市政府的要求，它配了 30% 的真人司机在远程等着接管这辆车，那么为什么不行？最后一定要让人到现场去把车开走。
- SOS 和客服为什么没有形成有效救援？顾客在车上被困住以后，按 SOS 按钮、呼叫客服的时候，没人理他，客服中心直接卡死了。
- 武汉实际投入了多少车，故障车到底占比多少？现在有的报道说武汉投入了 400 辆车，有的说 500 辆车，还有一些媒体直接报道说武汉投入了 1,000 辆车。到底是多少？到底坏了多少？这个数字从来没有人搞清楚过。
- 未来如何避免同类事故发生？这是百度必须要解决的问题。
当然，这些问题最后可能没有办法给民众一个公开的解释，但至少要给政府和监管部门一个解释。等它解释明白了以后，L4 级牌照还会继续发下去，我们只管等就好了。
武汉作为试点城市，肯定会非常积极地推进这件事情继续往前发展，要不然这个政绩就没了。甚至其他一些城市的领导如果想要这个政绩，也会积极推动说：来我们这儿试试吧。至于交通堵塞了，或者出了点什么事故，这个不在他们的考虑范围内。
回到开头的结论
萝卜快跑武汉事故不是中国 Robotaxi 的终局，但是它确实是一个分水岭。
它打碎了一个非常漂亮、非常危险的幻觉：只要车队规模大、云端调度够强、城市大脑够聪明，Robotaxi 就自然成熟了。
现实恰恰相反。Robotaxi 最难的不是在天气好、网络好、路况好、乘客安静的时候把人送到目的地。它真正的困难是，网络断了、云端抖动了、顾客慌了、路上堵了，在这个时候，系统能不能把风险降下来。
过去大家问的是：这辆车会不会自己开？武汉事故之后，真正该问的是：这辆车失联以后，会不会自己收场？能不能靠到路边去？能不能把人放到一个安全的地方？
从今天开始，L4 的竞争不再只是比较运营城市的数量、累计订单量、自动驾驶里程。未来真正要比的是断网以后的能力、车端自治的能力、现场救援的能力、透明复盘的能力。这个在有些地方估计就比较难了。
这一次百度展示了，他们在武汉出了问题以后，没有隔离和恢复的能力。百度这次的问题不是简单的网络不好，而是老牌互联网企业的平台病：什么都想统一管理，最后什么都一起失灵。
百度不是没有机会修复，萝卜快跑也不会因为一次事故就退出历史舞台。如果百度仍然把问题解释成一句“网络故障”，仍然不公开完整复盘，那么下一次事故，市场和监管恐怕就不会再把它当成一个技术故障了，而会把它看作一次路线失败。一旦百度被判定为路线失败，那它是非常惨的。
真正的未来，不是所有车听一个中心大脑指挥，而是每一辆车在中心失灵的时候，仍然知道怎么保护自己、保护乘客，也保护这座城市。
