# 当 AI 获得瘫痪一座城市交通的权力 LLMS 索引： [llms.txt](/llms.txt) --- > 3 月 31 日晚，武汉萝卜快跑车队出现大规模同时故障。真正值得警惕的，不只是自动驾驶翻车本身，而是云端集中管控架构可能把单车故障放大成城市级系统性风险。 ## 昨晚武汉发生了什么 3 月 31 日晚，百度旗下萝卜快跑无人驾驶出租车在武汉发生大规模系统故障。据 [快科技报道](https://finance.eastmoney.com/a/202604013691391126.html)，多名司机和乘客在社交平台发布视频显示，当晚武汉多辆萝卜快跑在行驶过程中突然停下。 截至本文写作时，武汉交警通报称，事件初步判断为系统故障，乘客均已安全下车，无人员受伤，具体原因仍在进一步调查。下文的技术判断，基于公开信息与行业常识推断。 一位乘客发视频称：车辆突然停在马路中间，屏幕显示 “5 分钟工作人员前来处理”，结果等了 20 分钟也没见人影，拨打客服电话接通 1 秒就挂了。 社交平台上也有用户表示，萝卜快跑大面积停在路上不动，造成事故与拥堵风险。行车记录仪显示，在二环火车站往经开万达方向，至少有 3 辆萝卜快跑停留在快车道上，其中一辆已被后方车辆追尾。 武汉一位交警向媒体透露： > **“萝卜快跑系统出故障了，是他们公司的问题，有百八十台。乘客按个按钮，车门可以开，但是人在环线上下不来。我们今天救了很多人。”** “我们今天救了很多人” 这句话从一个交警嘴里说出来，说的不是洪水，不是地震，说的是有人坐了个出租车。官方口径强调的是 “无人员受伤”，但仅仅是大批乘客被困在环线与高架这样的场景，本身就已经足够说明问题。 昨晚的事件还远未达到瘫痪全城的程度。但它暴露出了一条通往那个后果的清晰路径。 -------- ## 大规模同时故障，说明了什么？ 这里有一个关键的技术判断需要做出： **从目前公开信息看，这更像不是单车自动驾驶感知/控制本身失灵，而是车队与云端之间暴露出的系统性耦合问题。** 为了讨论方便，自动驾驶系统可以粗略分成两种架构倾向： **第一种是 “自主式自动驾驶”**：车辆本地搭载完整的感知、决策、控制系统，本地算力足够独立运行。特斯拉 FSD、Waymo 这类方案虽然实现路径并不相同，但都更强调车端完成核心驾驶闭环。云端可以用来做数据回传、OTA 升级、远程监控，但车辆的核心驾驶能力不依赖云端。云挂了，车至少还应具备安全靠边停下的能力。 **第二种是 “云端管控式车队运营”**：车辆的行为在很大程度上受云端调度和管控系统的支配。路线规划、任务分配、远程接管、状态监控，甚至部分驾驶决策，都依赖与云端的实时通信。 从昨晚的故障表现来看，萝卜快跑的运营模式 **更接近后者**。它不仅仅是 “无人驾驶”，更像是一个由云端统一管理的无人车队运营平台。 为什么能做出这个推断？因为 **大量车辆同时故障这个现象本身就是证据。** 如果是本地自动驾驶系统的问题，比如某个传感器型号有缺陷、某个本地算法有 Bug，故障会是 **随机的、分散的、渐进的**。不同的车在不同的时间、不同的路况下触发问题，不太可能在同一个晚上大面积同时趴窝。 当然，同时故障还存在其他可能的解释：比如推送了一个有 Bug 的 OTA 本地软件更新、通信运营商基站在该区域出现故障，或者某个安全策略在特定条件下被批量触发。但无论具体原因是哪一种，它们都指向同一个结论： **这些车共享了某个关键的单点依赖。** 当这个单点失效时，大量车辆可能同时失去正常行驶能力。 这就是问题所在。 -------- ## 云上的车队，路上的石头 在纯数字世界里，“单点依赖” 的代价是可以接受的。你的 SaaS 服务挂了，用户刷不了页面。你的云数据库宕了，交易延迟几秒。恢复之后一切照旧，最多赔个 SLA。但当系统控制的不是像素而是 **几吨重的钢铁** 时，故障的性质就完全不同了。 一个错误的配置推送，不是返回 500 错误码，而是大量车辆同时停在城市快车道上。你的乘客不是看到一个 “服务暂时不可用” 的页面，他是被困在高架桥的快车道上，能开门但无处可去，旁边 80 码的车流呼啸而过。 **`NullPointerException` 在你的 Web 应用里是一行日志。在无人车队系统里，它是路上的石头，车里被困的乘客，和三环线上几公里的拥堵。** 传统出租车不会批量故障，一千个司机是一千个独立节点，一个人抛锚不影响其他人。但高度耦合的无人车队不是这样。它们共享同一套核心依赖。这套依赖一出问题， **所有车同时变成路障**。这不是普通的交通事故，这是一种全新的、由软件架构缺陷导致的城市基础设施风险。 这让我想起了 2022 年的一件事。 -------- ## 滴滴的前车之鉴 2022 年 8 月，滴滴在北京搞了个 [“西单打车免单”](https://www.ithome.com/0/634/977.htm) 活动，结果数千辆网约车涌向西单，核心商圈严重拥堵，甚至 [蔓延到了府右街](https://m.soundofhope.org/post/645617)。事后，滴滴内部也承认这次活动策划得很糟糕。 当时有网友评论：“滴滴想让哪儿堵哪儿就堵。” 一个促销活动就能严重拥堵首都核心区交通，这种能力本身让人不安。 滴滴后来先被 [七部门联合审查](https://www.cac.gov.cn/2021-07/02/c_1626811521011934.htm)，后又被网信部门 [处以约 80 亿罚款](https://www.cac.gov.cn/2022-07/21/c_1660021534306352.htm)。讨论焦点是数据安全，但 [德恒律师事务所的分析](https://www.dehenglaw.com/CN/tansuocontent/0008/022000/7.aspx?MID=0902) 点出了更深层的问题：当企业掌握的数据和能力达到一定量级，“其作为营利组织将具有公共机构的性质……若不对其‘权力’加以约束，企业将能影响整个国家安全与稳定”。 但滴滴的 “权力” 毕竟是间接的，它通过算法调度人类司机，司机有自由意志，可以不听，可以变道，可以靠边。 **平台和物理世界之间，隔着一个人。** 萝卜快跑取消了这个缓冲层。它不是 “建议” 车怎么开，它直接控制车。系统说停，车就停。乘客只能按按钮开门，然后发现自己站在高架快车道中间。 **滴滴的问题是 “数据即权力”。萝卜快跑的问题是 “控制即权力”，是直接的、物理的、不可协商的控制。** -------- ## 通往瘫痪的路径 2019 年，佐治亚理工学院（Georgia Tech）物理学家 Peter Yunker 团队在《Physical Review E》上发表了一项 [研究](https://www.sciencedaily.com/releases/2019/07/190729111337.htm)，用渗流理论模拟联网汽车被同时瘫痪的后果： **高峰时段，只需让路上 20% 的车辆随机停下，城市交通彻底冻结。** 10% 就足以阻止急救车和消防车通行。而且这是保守估计，没考虑溢出效应和公众恐慌，实际所需数量会 [显著更低](https://spectrum.ieee.org/hacking-gridlock)。 据报道，昨晚故障的萝卜快跑约有 “百八十台”。对于拥有数百万辆车的武汉全城而言，这个数字微不足道，远未达到 20% 的城市冻结阈值。但城市交通不是均匀分布的。有媒体援引当地交管部门数据称，武汉三环线晚高峰流量约 22000 辆，运行车速仅每小时 11.3 公里，本身就在严重拥堵边缘。 **在一个已经饱和的局部路段上，几十辆车同时停在快车道上，其破坏力会被急剧放大。** 这次事件展示的不是全城瘫痪的结果，而是通往那个结果的路径。上面的研究讨论的是理论上的联网车辆同步停摆机制，不能把阈值直接套到昨晚武汉的事件上；但它确实说明了一件事：随着无人驾驶车队规模的增长，如果 “单点故障导致集中趴窝” 的架构缺陷不被修正，未来某一天，故障车辆的数量完全可能触及那个临界点。 巧合的是，研究者当年论文的开头写了一个假想场景： *“2026 年，在高峰时段，你的自动驾驶汽车突然停下阻塞交通。你爬出来，看到视野所及的每条街都瘫痪了……”* 他们把时间设定在 2026 年。现在是 2026 年 4 月，武汉发生了令人不安的相似一幕。 唯一的区别是：论文假设的是黑客攻击。现实里是否涉及外部攻击，目前没有任何证据；但即便只是系统自身故障，只要架构设计存在单点依赖，也足以造成相似后果。 -------- ## 这不是技术问题，而是架构选择的后果 让我把逻辑理清楚。 如果萝卜快跑的每辆车都是真正意义上的 “自主式自动驾驶”，本地算力完备、不依赖云端做核心驾驶决策、具备独立的安全停靠能力，那么昨晚这种大规模集中停摆现象，理论上就不该如此容易发生。因为独立节点不该以这种方式一起倒下。 昨晚之所以会出现这种集中停摆现象， **至少说明这些车在某个关键环节上并不独立**。它们共享了同一个单点依赖，或者共享了同一类会被批量触发的失效机制。一旦那里出问题，大量车辆就会同时失去正常运行的能力。 这是一个架构选择。选择集中管控模式，可能是因为成本，本地算力贵，云端调度便宜；可能是因为控制，统一管理更方便运营。但这个选择的代价是： **把单车故障的风险，更容易放大成城市级别的系统性风险。** 类比一下：这就像把一个城市的所有红绿灯都连在同一套系统上，而没有本地降级能力。系统正常运行的时候，一切都很美好，集中调度，全局最优。但系统一旦出问题？所有红绿灯同时失控。 任何一个做过分布式系统的工程师都知道，这种架构放在关键基础设施上是很难让人放心的。电网要分区，银行要分层，DNS 要有本地缓存。 **凡是涉及物理世界安全的系统，都必须具备在中心节点失效时独立运行或安全降级的能力。** 至少从目前公开信息和现场表现看，萝卜快跑昨晚没有向公众充分体现出这种能力。 -------- ## 制度跟上了吗？ 我不反对无人驾驶技术，但技术价值不是逃避制度安排的借口。自动驾驶车队运营，是对城市交通基础设施的占用和控制，需要的监管层级不应低于电网、水务、燃气这些城市生命线工程。 核电站也有价值——我不是说自动驾驶车队的危害等同于核电站，但它们在一点上是共通的：**涉及公共安全的技术，必须在监管框架就位之后才能大规模部署。** —— 允许一家公司在没有监管框架的情况下在城市中心建核电站，出了事之后说 “我们会持续优化技术” 显然是荒谬的。 几个需要回答的问题： **单一系统的 “爆炸半径” 是否受限？** 大量车辆同时趴窝，说明缺乏故障隔离机制。应该像电网分区一样，确保单一故障不能波及全部车辆。 **车辆是否具备脱离云端独立运行的能力？** 失联时必须能自主安全靠边停车，而不是停在快车道中间。这应该是强制准入门槛。 **应急响应能力是否与车队规模匹配？** 客服电话接通 1 秒就挂，说明应急体系在大规模故障面前完全崩溃。投多少车上路，就要有处置等量故障的能力。 2026 年 3 月，有研究者也警告：如果不加管控，自动驾驶承诺中的机器人出租车乌托邦，可能变成一场永久的、高科技交通堵塞。 **我们正在把城市交通的命脉，交给一些至少尚未向公众充分证明自己具备大规模同时故障成熟预案的运营方。这不是纯粹的技术问题，更是权力问题，是责任问题。** 今天愚人节。希望这只是一次足够让行业清醒的预警，而不是更大事故的预告。