无人配送车安全设计：从异常行为识别到车云协同兜底

发生在郑州的一起“无人快递车被攀爬”事件让不少人第一次意识到无人配送车在公开道路上的安全不只是“能不能避开障碍物”那么简单。新石器回应称已报告交警并启动三项改进这个回应本身比事件更值得技术人关注。无人配送车真正难的从来不是自动驾驶的“跑”而是所有异常情况下的“停”和“报”。一个路人随手攀爬就能戳中感知盲区、交互缺失、远程干预不及时三个要害。这篇文章不评价事件中的具体行为而是借这次事件把无人配送车的技术栈、安全设计缺口、可落地的改进方向完整拆开讲清楚。如果你是做自动驾驶、机器人、IoT 或安全系统开发的工程师文中关于异常行为识别、安全状态机、远程告警链路的代码与方案可以直接借鉴到你自己的项目里。1. 这条新闻真正值得技术人关注的问题无人配送车已经不算新鲜事物。在校园、园区、社区里见到一辆没有安全员的小车慢慢送快递很多人已经习以为常。但这次“被攀爬”事件能引发关注是因为它把无人车运营中一类“低频但是极难处理”的异常场景摆到了台面上。传统自动驾驶安全测试主要围绕“交通参与者”设计机动车、行人、骑行者、障碍物。车辆会学习如何避让、刹停、保持安全距离。但“行人攀爬车体”“长时间滞留车身”“故意拖拽车辆”这类行为并不在常规感知模型的训练分布里。更准确地说模型可能“看见”了车顶有东西却无法判断这个“东西”是人还是快递包裹或是其他杂物。这意味着什么意味着无人车在遇到非典型交互时很可能出现三种反应感知到了障碍物但无法分类于是进入保守停驶状态原地僵持。感知模型完全没把“人趴在车上”识别为异常目标车辆继续执行原有任务。车辆识别到异常但本地算力或策略引擎没有定义过对应的处置动作只会重复上报。三种反应都指向同一个结论无人配送车的安全设计不能只围绕“正常交规场景”做还要围绕“非正常的人车交互”做。这次事件里新石器回应的“报告交警 三项改进”本质就是补这三个层面的课感知层识别异常行为决策层增加应对策略运营层打通远程干预与事件追溯。2. 无人配送车的技术架构与安全设计思路要理解这次改进的技术含量先要把无人配送车的架构看清。它本质上是一台低速自动驾驶机器人而不是简单的“遥控车”。从功能上可以拆成五层2.1 感知层让车“看见”世界无人配送车通常搭载激光雷达、摄像头、毫米波雷达、超声波传感器。多传感器融合后车辆能实时构建周围环境的 3D 信息识别车辆、行人、骑行者、路障、锥桶等目标。在感知层面无人配送车与乘用自动驾驶车逻辑相似但有几个特殊约束计算平台功耗和体积受限不能上超大算力 GPU。传感器安装高度低对近距离目标的感知盲区更大。目标类型更聚焦但也会漏掉“非标目标”。2.2 决策规划层决定“接下来怎么办”决策规划层接收感知结果结合定位、地图、任务目标决定下一秒怎么走。典型内容包括全局路径规划从 A 点到 B 点走哪条路。局部行为决策跟车、绕行、等待、让行、靠边停车。速度规划在弯道、人行道、拥堵区域如何调速。这一层也是安全状态机的所在位置。正常情况下车辆在“巡航、减速、等待、绕行”等状态间切换异常情况下则要切换到“急停、锁车、上报、远程接管”等安全状态。2.3 控制层让决策真正执行控制层负责把决策层的指令转化为方向盘转角或差速轮速、油门、刹车的具体控制量。无人配送车速度通常不高但制动冗余、驻车机制、限速逻辑都不可少。2.4 通信层让车“连上云端”无人配送车不是完全本地自治的“单机”。它通常通过 4G/5G 网络连接云端调度平台实时上报位置、状态、视频流、日志。远程监控员可以查看车辆画面甚至在必要时接管控制权。2.5 运营平台层让车队可管理运营平台负责车辆调度、电子围栏、远程监控、任务下发、OTA 升级、故障报警。这次事件中“报告交警”和“启动改进”正是运营平台层需要承担的职责。为了更直观可以用一张表概括架构层核心组件对应安全职责感知层摄像头、激光雷达、毫米波、超声波识别障碍物、行人、异常目标决策规划层行为决策、路径规划、速度规划避障策略、紧急停车判定控制层线控底盘、制动控制、驻车控制执行刹车、锁车、驻车通信层4G/5G、远程视频回传、控制通道上报告警、接收远程指令运营平台层调度、监控、OTA、日志、事件追溯人工干预、事故记录、系统升级真正容易出现安全短板的恰恰是感知层和决策规划层。它们决定了车辆“能不能发现问题”以及“发现问题后会不会正确处理”。3. “被人攀爬”为什么会让无人车陷入困境把“攀爬”看作一个感知与决策问题可以拆解出几个技术难点。3.1 感知模型存在“类别盲区”自动驾驶感知模型的常见输出是“目标框 类别 速度”。人、车、骑行者的类别覆盖得很全但“攀爬在车身上的人”这个类别在常规训练数据里几乎没有。没有类别感知系统就会面临两难如果把它识别为“行人”行人的轨迹预测模型会认为目标在移动可能给出错误的未来位置预测。如果识别为“静态障碍物”车辆会停在原地但不知道车身上有个“人”也就无法触发针对人车接触的安全策略。很多无人车在测试时遇到过类似情况车身被贴上广告纸、被路人倚靠、被小孩触摸但车辆的行为只是“停在原地等待障碍物消失”没有任何主动交互。3.2 决策策略缺少“非正常交互”分支常规决策系统会把目标分为“可通行”和“不可通行”。“不可通行”触发停车但没有进一步细分“为什么不可通行”。如果决策系统里没有“近距离人车接触”这个状态车辆就不会主动执行“语音警告”“中控锁车”“紧急上报”等动作。它只会被动等目标离开。从产品体验来说这种“被动等待”在 99% 的交通场景里是安全的但在 1% 的非正常场景里会让人觉得车辆“反应迟钝”。3.3 人车接触后的责任判定困难一旦车辆与人发生实际接触平台侧必须有完整的事件记录事发前 30 秒的视频、感知日志、决策日志、控制指令、远程监控记录。如果事件记录链路不完整后续定责就非常困难。这次“报告交警”的动作说明运营方在第一时间启动了事件保留流程。对任何无人车运营方来说事件记录能力的建设都应该前置而不是等出事后再补。4. 新石器“三项改进”可能的技术方向推演官方没有一次性披露三项改进的全部技术细节但从无人配送车的事故响应逻辑来推演大概率围绕下面三个层面展开。4.1 感知增强从“目标检测”走向“行为识别”第一项改进大概率是感知能力的增强。传统感知系统解决“有什么东西”改进后的系统要解决“这东西在干什么”。具体来说要增加对近距离非正常行为的识别能力例如检测有人靠近车体并持续停留。检测目标出现“攀爬”“拖拽”“敲击”“撬动”等动作。将“车体附近异常滞留”作为独立事件类型建模。技术上这不是重新训练一个模型那么简单。它需要把视觉行为识别与激光点云的形变检测结合同时对算力提出了新要求。4.2 决策与交互增强增加安全状态与主动提示第二项改进会落到决策策略上。车辆需要在常规状态机之外增加“近距离异常交互”状态并设计分级响应策略识别到异常接近时语音提示持续异常时触发缓刹或急停确认被攀爬后进入锁车和上报流程。好的策略不是“一遇到人就刹死”而是“识别严重程度、分级别响应”。这能减少误报也能在真正危险时快速兜底。4.3 运营联动增强远程监控与事件追溯闭环第三项改进大概率是打通“车端—云端—运营后台”的闭环。核心包括异常事件实时上报云端立即弹窗并通知值班人员。远程喊话功能监控员可以通过车载扬声器警告现场人员。远程锁车与远程降速功能防止车辆被异常移动。事件录像与日志自动打包形成完整追溯素材。从工程角度看第三项改进最容易快速落地因为车端平台与云端平台的通道本来就存在关键是补全异常事件触发的上报策略和人工处理流程。5. 技术实现示例异常检测、安全状态机与告警上报这里用三个代码示例演示“三项改进”在工程上如何落地。示例是简化实现用于说明思路不代表新石器的具体代码。5.1 示例一近距离异常行为检测模块设计思路感知层输出目标框后由异常行为检测模块判断目标是否与车体发生“长时间近距离接触”或“攀爬行为”。# 文件路径perception/abnormal_interaction_detector.py 近距离异常行为检测模块 - 输入连续多帧的感知目标列表、车体几何信息 - 输出异常交互事件类型与置信度 from dataclasses import dataclass, field from typing import List, Optional import time dataclass class TrackedTarget: target_id: int category: str # person, rider, unknown distance_to_body: float # 与车体最近距离单位米 is_on_body: bool # 是否与车体重叠 dataclass class InteractionEvent: event_type: str # approach, cling, climbing, towing confidence: float started_at: float target_id: Optional[int] None class AbnormalInteractionDetector: 基于规则 状态统计的异常交互检测。 真实场景可替换为训练好的行为识别模型。 def __init__(self, near_threshold: float 0.8, cling_frames: int 10): self.near_threshold near_threshold self.cling_frames cling_frames self._target_on_body_counter: dict[int, int] {} self._target_near_counter: dict[int, int] {} def update(self, targets: List[TrackedTarget]) - Optional[InteractionEvent]: 每帧调用一次传入感知目标列表。 返回事件对象无异常时返回 None。 now time.time() for target in targets: tid target.target_id # 1. 检测目标是否长时间滞留在近距离区域 if target.distance_to_body self.near_threshold: self._target_near_counter[tid] self._target_near_counter.get(tid, 0) 1 else: self._target_near_counter[tid] 0 # 2. 检测目标是否与车体重叠 / 位于车身上 if target.is_on_body: self._target_on_body_counter[tid] self._target_on_body_counter.get(tid, 0) 1 else: self._target_on_body_counter[tid] 0 # 3. 判定连续超过 N 帧位于车身上触发 climbing 事件 if self._target_on_body_counter.get(tid, 0) self.cling_frames: return InteractionEvent( event_typeclimbing, confidence0.92, started_atnow - self.cling_frames * 0.1, target_idtid, ) # 4. 判定长时间近距离 已对车身产生持续接触触发 cling 事件 if self._target_near_counter.get(tid, 0) self.cling_frames * 2: return InteractionEvent( event_typecling, confidence0.85, started_atnow, target_idtid, ) return None关键逻辑说明模块以帧为粒度维护计数不依赖单帧判断能有效降低误报。climbing事件的判断依据是“目标与车体重叠”而不是简单的“距离近”。写入事件时间戳便于后续与云端日志对齐。5.2 示例二车端安全状态机设计思路车辆决策层需要维护一个安全状态机。状态包括正常行驶、接近警戒、紧急制动、远程接管。不同状态下控制指令不同。# 文件路径decision/safety_state_machine.py 车端安全状态机 - 输入感知事件、遥控指令、车辆底盘状态 - 输出当前安全状态与控制动作 from enum import Enum from dataclasses import dataclass from typing import Optional class SafetyState(Enum): NORMAL normal APPROACH_WARNING approach_warning EMERGENCY_STOP emergency_stop REMOTE_LOCK remote_lock dataclass class ControlAction: action: str # cruise, slow_down, stop, lock max_speed: float # 限速单位 km/h reason: str class SafetyStateMachine: def __init__(self): self.state SafetyState.NORMAL def on_interaction_event(self, event_type: str, confidence: float) - ControlAction: 根据感知异常事件切换状态。 这里采用保守策略置信度越高越倾向进入更高等级安全状态。 if self.state SafetyState.REMOTE_LOCK: return ControlAction(actionlock, max_speed0.0, reasonremote_lock_hold) if event_type approach: if confidence 0.7 and self.state SafetyState.NORMAL: self.state SafetyState.APPROACH_WARNING return ControlAction(actionslow_down, max_speed3.0, reasonapproach_detected) return ControlAction(actioncruise, max_speed8.0, reasonnormal) if event_type cling: if self.state in (SafetyState.NORMAL, SafetyState.APPROACH_WARNING): self.state SafetyState.EMERGENCY_STOP return ControlAction(actionstop, max_speed0.0, reasontarget_clinging_body) if event_type climbing: self.state SafetyState.EMERGENCY_STOP return ControlAction(actionstop, max_speed0.0, reasontarget_climbing_body) return ControlAction(actioncruise, max_speed8.0, reasonnormal) def on_remote_command(self, command: str) - ControlAction: 处理云端远程指令最高优先级。 if command LOCK: self.state SafetyState.REMOTE_LOCK return ControlAction(actionlock, max_speed0.0, reasonremote_lock) if command UNLOCK: self.state SafetyState.NORMAL return ControlAction(actioncruise, max_speed8.0, reasonremote_unlock) if command EMERGENCY_STOP: self.state SafetyState.EMERGENCY_STOP return ControlAction(actionstop, max_speed0.0, reasonremote_estop) return ControlAction(actioncruise, max_speed8.0, reasonnormal) def reset(self) - None: self.state SafetyState.NORMAL关键逻辑说明状态机采用“只升不易降”的保守设计一旦进入EMERGENCY_STOP必须由后台确认后才能恢复。远程锁车优先级最高这是为了保证在车端策略异常时人类还能兜底。5.3 示例三异常事件上报与远程告警设计思路车端检测到异常后通过消息通道上报云端。上报信息要包含事件类型、时间、位置、车辆 ID、现场视频引用方便云端监控人员立即处理。# 文件路径platform/alert_reporter.py 异常事件上报模块 - 将车端事件转换为统一告警体 - 推送到云端消息队列并触发监控大屏告警 import json import time import uuid from typing import Dict, Any class EventReporter: def __init__(self, mqtt_client, vehicle_id: str): self.mqtt_client mqtt_client self.vehicle_id vehicle_id def report(self, event_type: str, confidence: float, location: Dict[str, float], video_ref: str) - None: 上报异常事件到云端。 payload { event_id: str(uuid.uuid4()), vehicle_id: self.vehicle_id, event_type: event_type, confidence: confidence, location: location, video_ref: video_ref, timestamp: int(time.time() * 1000), level: self._map_level(event_type), } topic ffleet/{self.vehicle_id}/events self.mqtt_client.publish(topic, json.dumps(payload), qos1) print(f[AlertReporter] 已上报事件: {event_type} - {topic}) def _map_level(self, event_type: str) - str: if event_type in (climbing, towing): return critical if event_type cling: return warning return info # 模拟使用 if __name__ __main__: class FakeMqtt: def publish(self, topic, payload, qos1): data json.loads(payload) assert event_id in data and vehicle_id in data print(f[FakeMqtt] topic{topic} payload{payload}) reporter EventReporter( mqtt_clientFakeMqtt(), vehicle_idNDV-2025-027, ) reporter.report( event_typeclimbing, confidence0.92, location{lat: 34.7566, lng: 113.6654}, video_refgs://fleet-events/NDV-2025-027/20250218_143001_climbing.mp4, )关键逻辑说明上报使用qos1保证消息至少到达一次不因网络抖动丢失关键告警。事件 ID 由车端生成云端可以用它做幂等去重避免重复告警。video_ref指向对象存储中的事件录像云端可以立即跳转查看。上面三个模块组合起来就是一个完整的“异常检测 — 状态决策 — 云端告警”闭环。6. 如何验证改进是否真正有效官方公布的三项改进是否有效不能只停在“上线了”这个层面。从工程角度看至少要做四类验证。6.1 感知算法回归测试用历史事件数据和人工构造的仿真数据验证异常行为检测模块的召回率和误报率。召回率100 次攀爬模拟能识别出多少次。误报率正常路人经过时会不会误报。建议设定三个测试场景正常经过、长时间滞留、攀爬车体。每种场景至少跑 200 次再统计准确率。6.2 安全状态机策略测试验证车辆在异常事件触发后是否按预期进入对应安全状态。测试点包括进入EMERGENCY_STOP后车辆是否在 0.5 秒内刹停。远程LOCK指令发出后车辆是否正确锁车并驻车。事件解除后车辆能否在后台确认下恢复正常。6.3 告警链路压力测试验证大量车辆同时上报异常时云端能否及时处理。建议用 Mock 消息队列模拟 1000 辆车同时上报cling事件观察消息是否全部到达。云端 API 峰值响应时间是否超过 1 秒。是否存在事件丢失或重复。6.4 实车演练在封闭园区进行实际演练安排人员模拟攀爬、拖拽、撬门等动作观察车辆实际表现。演练结束后用车上日志复盘每一步决策确认事件记录完整性。只有四类验证都通过改进才算真正落地。7. 无人配送车异常事件常见问题与排查思路在无人配送车的日常运营和开发中有几类问题出现的频率很高。这里整理成排查表方便复用。问题现象可能原因排查方式解决方案车辆对近距离滞留人员无反应行为识别模型未覆盖该类目标查看感知日志确认目标是否被分类为行人或未知补充近距离滞留行为识别规则或模型车辆触发误报频繁急停近距离判断阈值过宽回放感知视频和数据分析目标距离曲线调整近场判定距离增加持续时间过滤远程告警延迟超过 5 秒网络链路不稳定或消息队列积压检查 4G/5G 信号质量和 MQTT QoS 设置调整弱网策略增加本地缓存重传机制事件录像无法追溯本地存储被覆盖或回传链路中断检查车辆存储策略与云端回传日志增加关键事件本地加密存储延长保留时间远程接管失败控制层未处理接管指令查看车辆状态机日志确保远程指令优先级最高并支持强制接管OTA 升级后策略异常新旧策略文件冲突查看配置版本号与回滚记录灰度发布保留最近两个可用版本车辆在异常事件后无法恢复状态机缺少恢复条件查看状态机切换日志增加后台确认恢复机制避免长期停摆8. 无人配送车安全运营最佳实践从事件出发无人配送车的安全设计可以总结为几类最佳实践适用于所有正在做低速无人车、园区配送车、巡检机器人的团队。8.1 安全设计必须覆盖“非正常交互”不要把安全设计局限在“避障”上。至少要覆盖四类非正常交互近距离长期滞留。暴力触碰、攀爬。车辆被拖拽或移动。传感器被遮挡或破坏。每一类都要有对应的感知规则、决策策略和运营流程。8.2 本地优先云端兜底网络不是永远稳定的。车端必须能在断网的情况下独立完成异常检测和紧急停车。车端本地保存关键事件录像至少保留 24 小时。断网期间的事件先本地存储恢复后补传。远程指令在云端可达时优先执行断网时依赖本地策略兜底。8.3 事件记录要像“黑匣子”一样设计无人车的事故复盘完全依赖事件记录。建议从设计之初就做到事件发生前后各 30 秒的视频、感知、决策、控制指令全量记录。所有日志带统一时间戳支持多源对齐。关键事件的事件 ID 端到端贯穿车端、边缘、云端、工单系统。8.4 分级响应不是一遇到异常就刹死过度灵敏的急停策略会增加误报影响运营效率。更合理的做法是分级响应事件等级示例车辆动作云端动作info行人短暂靠近继续行驶记录日志无需处理warning人员长时间滞留语音提示降低速度推送提醒给监控员critical攀爬、拖拽、撬门急停 锁车弹窗告警 通知值班人员8.5 事故响应流程前置化这次事件里“报告交警”是一个正确动作。但在实际运营中建议提前定义好事故响应 SOP事件确认后 1 分钟内完成云端告警。监控人员 3 分钟内完成视频查看和初步判断。涉及人身安全或财产损失时立即报警并保留完整证据。指定专人与交警、物业、客户对接避免信息混乱。8.6 持续用真实事件反哺模型迭代每次发生异常事件都应该形成复盘报告并把事件数据加入训练集或规则库。无人车的安全能力是在一次次真实事件中打磨出来的而不是一版模型就能解决所有问题。9. 这一事件给无人配送行业带来的启示从技术角度看这次事件真正有价值的地方是把无人配送车安全设计从“交通安全”拉到了“公共交互安全”的维度。自动驾驶行业过去长期关注的是如何让车在复杂交通环境中安全行驶但无人配送车的工作场景更接近“公共服务机器人”。它天天在人流密集、规则模糊的空间里工作会遇到的远不止“小汽车加塞”和“行人闯红灯”还有大量没有交通语义的人的行为。“攀爬”只是这些非典型行为的一种。未来可能还有“翻开货箱取件”“用异物堵塞传感器”“强行推动车辆”等更复杂的交互。这要求无人配送车团队在安全设计上做三个转变从“识别目标”转变为“识别行为”。从“被动避障”转变为“主动交互”。从“单机安全”转变为“车云协同安全”。新石器回应的“三项改进”如果真能落地对行业也是一个正向信号无人配送车的安全竞争正在从传感器数量和自动驾驶里程转向边缘场景的安全兜底能力。对于开发者来说这次事件也是一次很好的学习样本。当你在设计自己的机器人和无人系统时可以提前问自己一个问题如果目标不按常理出牌我的系统能识别、能决策、能上报、能追溯吗如果答案里有一个“不能”那它下一次就可能以更意想不到的方式暴露出来。趁早补齐成本远低于事后应急。