摘要：当无人车的 AI 搞不定的时候，行业有没有一套成体系的应急管理机制？答案是没有，连一个参考标准都没有。本文从武汉萝卜快跑事件出发，回顾 Robotaxi 行业近期的三记重锤，扫描 ISO/SAE/IEC/中国四大标准体系在远程运营领域的全部空白，分析武汉事件后中国监管的根本性转向，并介绍 ROAM（Remote Operations & Anomaly Management）开源参考架构的四个模块、十种运营模式与 52 条标准扫描结果。
3 月 31 日，武汉。
近百辆萝卜快跑在晚高峰时段于高架路段同时熄火。乘客被困车内，SOS 按钮无响应，客服热线打不通。最终解决方案是什么？
交警，一辆一辆地，手动救。
整个过程持续了两个小时。
同一天，大洋彼岸，美国参议员 Markey 发布了一份名为《Remote Back Seat Operators》的调查报告。他向七家头部自动驾驶公司（Aurora、May Mobility、Motional、Nuro、Tesla、Waymo、Zoox）提了一个很简单的问题：
你们的无人车到底多久需要一次远程人工干预？
七家公司的回答高度一致——商业机密，拒绝回答。
这两件事凑在一起，指向了同一个问题：当无人车的 AI 搞不定的时候，行业有没有一套成体系的应急管理机制？
答案是没有。更让人不安的是，连一个参考标准都没有。
一、Robotaxi 的三记重锤
把时间线拉长一点看，2025 年底到 2026 年初这几个月，行业连续挨了三记重锤。
2025 年 12 月 13 日，旧金山电网故障。 Waymo 的 20 多辆车失去通信，瘫在路上。应急服务拨打 Waymo 热线 31 次，累计等了 2 小时 36 分钟。Waymo 事后承认：断网的时候，他们没有办法把整个区域的车统一召回来。
2026 年 3 月 31 日，武汉萝卜快跑事件。 规模更大——近百辆车同时出问题，乘客被困在高架桥上。所有远程系统集体失效：SOS、客服、远程干预，全部瘫痪。
再往前，2023 年 10 月，Cruise 在旧金山拖拽行人 6 米。 远程操作员没能及时干预，NHTSA 罚了 150 万美元，车队全面召回。
三起事件发生在不同国家、不同公司、不同技术路线上。但暴露的问题惊人地一致：当系统性故障发生的时候，没有人知道该怎么办。
这不是某家公司管理不善的问题，是整个行业缺一块东西。
二、行业到底缺了什么？
缺的不是技术，是治理体系。
我们做 SOTIF，有 ISO 21448。做功能安全，有 ISO 26262。做场景测试，有 ISO 34502。做信息安全，有 ISO/SAE 21434。
但是——远程运营与异常管理？
我做了一次系统扫描。结论是：
ISO 体系——零。SAE 体系——零。IEC 体系——零。
SAE J3016 甚至明确拒绝定义"远程操作"这个术语，理由是"各方定义不一致"。
中国的标准体系稍微好一点，但问题是"四路并行，各自为政"：
- 通信口有 YD/T 4778-4783 系列（5G 远程驾驶）
- 汽车口有在研的强制 GB
- 交通口在做远程安全员资质标准
- 网安口在做整车信息安全
四套体系互相之间，没有一个整合性的参考架构。
说白了：大家都在做"技术要求型"的标准——告诉你"应该做到什么"。但没有人做"参考架构型"的标准——告诉你"应该怎么做、谁来做、做了怎么衡量"。
这就好比消防法规定了建筑必须配灭火器，但没有人定义过灭火器应该放在哪、谁负责检查、多久检查一次。
Markey 报告还披露了一个很有意思的数据：各家公司远程协助的通信延迟差异巨大。有的公司本土延迟 100 多毫秒，海外站点飙到 250 毫秒。学术界的共识是，300 毫秒是远程操作员驾驶表现显著下降的临界点——有些公司的数据已经在逼近这条线了。
但由于联邦层面没有统一的延迟标准，各家公司实际上在自己给自己定安全阈值。这就像高速公路没有限速牌，每个司机自己决定跑多快。
三、武汉事件之后，监管变了
武汉事件的后续影响远超很多人的预期。
事件发生后 14 天内，国家三部门（工信部、公安部、交通运输部）紧急召开全国安全监管会议。超过 10 个试点城市同步收紧准入、暂停扩区、全面排查。
整个行业的监管逻辑发生了一次根本性转向：
从"包容审慎、鼓励创新试错"，转向了"安全底线刚性化、全链条责任闭环化"。
具体来说，新的监管方向包括：
- 监管范围从单车安全扩展到"云-网-边-车"系统性安全
- 要求车辆必须配备独立的最小安全系统，在云端和网络全部失效时仍能自主完成缓停、靠边、双闪、开门
- 建立"准入-运营-退出"全生命周期动态监管
- 发生重大系统性故障的企业，吊销资质且 3 年内不得重新申请
这说明什么？监管已经意识到了系统性故障的风险。但监管能做的是画底线，行业真正需要的是一套可操作的参考架构。
四、个人尝试：ROAM 开源框架
最近几天，我借助 AI 的力量，做了一件事：把这个领域缺失的参考架构先搭起来，开源出去，让大家一起迭代。
项目叫 L4 自动驾驶远程运营与异常管理开源框架（Remote Operations & Anomaly Management，ROAM）。
- ROAM GitHub：github.com/AutoZYX/ROAM
- ROAM 网站：roam.autozyx.com
- ROAM 事件交互式探索：roam-explorer.autozyx.com
Apache 2.0 开源协议，任何人都可以用、可以改、可以贡献。
ROAM 不是一份 PPT 或白皮书，是一套可执行的治理体系，目前包含四个模块：
4.1 事件数据库
16 起结构化事件记录，覆盖 Waymo、Apollo、Pony.ai、Cruise，每条记录有统一的 YAML 格式和字段定义，可以跨运营商对比分析。
4.2 场景分类体系
6 大类、27 个子场景，覆盖从系统性故障到乘客被困的全部异常类型。每个场景附带严重度（S0–S4）和紧急度（U0–U3）分级。
4.3 三层决策参考架构
- Layer 1：AI 自主处置，目标覆盖约 70% 异常
- Layer 2：AI 辅助 + 人工确认，约 25%
- Layer 3：远程驾驶或线下救援，约 5%
每层有明确的响应时间目标，超时自动升级。
4.4 评价基准
8 项 KPI——MTTR、AI 自主处置率、误升级率、漏升级率、操作员接受率、通信延迟、乘客安全感知、合规率。
除了这四个模块，ROAM 还做了两件事：
- 梳理了 L4 自动驾驶未来可能出现的 10 种运营模式（不止 Robotaxi，还包括 OEM 订阅、个人共享、L4 公交、无人配送、矿区港口专用等），并为每种模式建立了 10 模式 × 3 层 × 4 维度的责任矩阵
- 系统扫描了全球范围内与远程运营相关的 52 条国际和国内标准，确认了"参考架构"这一细分领域的完全空白
五、标准化倡议：这个领域需要一个国家推荐标准
开源框架只是第一步。长远来看，这个领域需要的是一个正式的标准。
个人判断是：立项一个国家推荐标准，名称初步考虑为 《智能网联汽车 自动驾驶系统 远程运营与异常管理参考架构》 。
为什么是"参考架构"而不是"技术要求"？
因为"技术要求"已经有很多标准在做了（GB《智能网联汽车自动驾驶系统安全要求》草案附录 C.2、YD/T 4778-4783 等），但行业缺的是一个把这些要求串起来的整体框架——定义场景分类、处置流程、责任分工、KPI 体系。
这不是一蹴而就的事。我们的节奏是"开源先行、标准缓行"：
- 近期：通过 GitHub 项目持续积累事件案例、完善分类体系、沉淀 KPI 基线
- 中期：与行业专家一起讨论和完善，正式立项 GB/T
- 远期：基于国内标准向 ISO/TC22 提交新工作项提案
武汉事件之后三部门的监管转向，恰恰印证了这个领域的标准化需求已经从"学术呼吁"变成了"产业刚需"。
还有一个容易被忽视的趋势：L4 自动驾驶的未来不只是 Robotaxi。
Tesla 的长期路线图中，L4 能力将通过订阅方式卖给个人车主。NIO、小鹏、吉利等 OEM 在推进高速场景下的私人 L4 车辆。这意味着 OEM 要从"造车的"变成"提供远程运营服务的"——每卖出一辆 L4 车，就要为这辆车提供 7×24 小时的远程支持。
这个角色转变，目前没有任何标准覆盖。ROAM 的 10 种运营模式和责任矩阵，就是为了提前回答这个问题。
六、一个邀请
如果你是 Robotaxi 运营商的安全工程师——ROAM 的事件数据库需要更多真实案例。
如果你是 OEM 的 L4 产品经理——ROAM 的 10 种运营模式和责任矩阵，可能会帮你回答"未来我的车卖给消费者后，远程运营谁来负责"这个问题。
如果你是 标准化工作者——欢迎一起讨论国标立项的可行性和时间节点。
如果你是 学术界同仁——ROAM 的 52 条参考文献和六大技术支柱分析，可以作为你研究的起点。
- ROAM GitHub：github.com/AutoZYX/ROAM
- ROAM 网站：roam.autozyx.com
- ROAM 交互式探索：roam-explorer.autozyx.com
说来惭愧，做 ROAM 这个项目的起因很朴素：2026 年 3 月 31 日晚上看到武汉的新闻时，我第一反应不是技术评论，而是一个很实际的问题——如果这种事发生在我参与的项目上，我能拿出一套标准化的处置流程吗？
答案是拿不出来。因为行业里根本没有这个东西，凭一己之力，也根本无法完善上述 ROAM 参考框架中的任何一个模块。
所以我选择了开源。不是因为开源听起来高尚，而是因为这个领域的问题太复杂、变化太快，任何一家企业或一所大学闭门造车都搞不定。运营商遇到的新型异常、OEM 对运营模式的创新、监管方的政策关切——这些信息必须在一个公开的平台上汇聚，才有可能沉淀出一套经得住实践检验的治理框架。
无人车出了事，总得有人定义"怎么兜底"。这件事不能再等了。