最近圈子里最热的一条消息，就是某专注L4级自动驾驶商用车研发的公司（下文统称A公司）与某头部物流平台（下文统称B平台）正式达成战略整合，计划共同打造面向城市末端配送的RoboVan“超级航母”，并开启双品牌运营模式。
这则消息我第一时间就看到了，说实话并不意外。过去两年我持续在关注无人配送这个赛道，A公司和B平台的接触早有端倪，只是谁也没想到会以“整合”这么高的规格落地。所谓“战略整合”不是简单的签战略合作协议，而是涉及到团队、技术、产品线、运营网络的深度绑定，这在自动驾驶行业是非常少见的大动作。
这篇文章我想围绕这个事，拆解几个维度的内容：为什么无人配送会成为物流巨头和自动驾驶公司的共同选择？RoboVan到底是什么东西、技术上有哪些核心环节？双品牌运营模式下，技术底座如何共享、品牌又怎么区隔？以及从实操角度讲，这类无人配送车在落地过程中会遇到哪些典型问题、怎么排查。无论你是自动驾驶行业的工程师、物流领域的产品经理，还是对这个赛道感兴趣的投资人，这篇内容应该都能给你一些可参考的信息。
1. 为什么是RoboVan？先从“最后一百米”说起
1.1 末端配送的运力困局
先说个我自己的观察。城市末端配送这个场景，过去十年其实一直在变，但有一个永恒的矛盾：单量每年在涨，人力成本每年在涨，但配送费几乎没怎么涨。以一台常规的城市配送车为例，一个司机一天能完成的配送趟次是有限的，而且存在着明显的波峰波谷：早高峰、午高峰、晚高峰运力紧张，其他时段车辆大量闲置。从物流平台的角度看，这意味着两件事：一是高峰期的运力必须靠溢价去抢，二是低谷期的固定成本没法摊薄。如果能把一部分城配线路的“驾驶位”拿掉，把人力成本从固定成本变成可选的运营成本，整个成本结构就会发生质变。
RoboVan解决的正是这件事——它把这个场景里最贵的“人”拿掉，同时把车的有效运营时间从一天8小时拉到一天接近20小时。我曾经参与过一个城配线路的成本测算，一辆载重一吨左右的纯电厢式货车，折旧加能耗加维护，每公里的综合成本在2块多钱，但如果请一个司机，每公里的人力成本要再加3到4块钱。也就是说，司机成本占到了单公里总成本的六成左右。这个比例放在任何一个行业，都是值得用技术去颠覆的数字。
有人会问，为什么不用无人快递车或者无人机？这个问题的答案其实在于载重和距离的匹配。无人快递车（小尺寸、低速、低载重）适合的是园区、校区、封闭小区内部最后几百米的配送，它跑不快、装不多，出不去开放道路。无人机适合的是跨障碍物的点对点急件，但它受天气和空域管制影响太大，而且载重非常有限。RoboVan是厢式货车形态，载重可以做到几百公斤到一吨以上，巡航速度可以覆盖城市快速路和主干道，它真正切入的是“从分拨中心到驿站/快递柜”这一层城配网络。
这里我画一个简单的对比，方便理解三种无人配送工具的定位差异：
| 工具类型 | 适用距离 | 载重能力 | 时效特征 | 核心瓶颈 |
|---|---|---|---|---|
| 无人机 | 跨障碍点对点（3~10公里） | 5公斤以内 | 分钟级急送 | 空域管制、天气限制 |
| 无人快递车 | 最后一百米（0.1~1公里） | 30~100公斤 | 小时级 | 速度低、无法出园区 |
| RoboVan | 城市转运（3~15公里） | 300~1500公斤 | 小时级批量转运 | 路权合规、算法复杂度 |
所以可以这样理解三层配送体系：无人机管“点对点急送”，无人快递车管“最后一百米”，RoboVan管“最后三公里到十五公里的城市转运”。RoboVan卡的位置，恰恰是运力弹性需求最大、人力替代价值最高的一层。
1.2 物流平台为什么要All in RoboVan
B平台作为物流平台，手上的牌很明确：全国性的分拨网络、末端驿站体系、海量的订单数据。但它的短板在于“运力”——不是没有运力，而是运力的成本结构降不下来。我见过很多物流平台的运营报表，城配运力成本在整个履约成本里的占比通常在三到四成。如果把司机成本从里面剔除，哪怕车辆折旧和运维成本增加，整体测算下来，单件履约成本依然有30%以上的下降空间。
更关键的是，RoboVan能解决一个此前无解的问题：夜间运力。传统的城配车司机需要休息，凌晨时段基本停摆。RoboVan没有这个限制，夜间充电波谷时段把车充满，凌晨到清晨时段进行干线转运和驿站补货，正好错开白天的交通高峰。这意味着同样的车队规模，日运营时长几乎翻倍，车辆的资产周转效率大幅提升。物流行业有一个很朴素的公式：一台运输工具的盈利能力，等于单趟毛利乘以每天的趟次。无人车能把“每天趟次”这个变量从两趟拉到四趟甚至五趟，这个杠杆效应是任何精细化管理都做不到的。
所以当A公司带着L4级自动驾驶方案找到B平台时，双方其实是一拍即合：A公司需要场景和数据来打磨算法，B平台需要无人化运力来重塑成本结构。物流平台做RoboVan不是赶时髦，而是算了一笔非常清晰的账之后做的决定。
1.3 自动驾驶公司为什么需要物流平台
反过来看A公司的处境。A公司在L4级自动驾驶商用车领域有完整的技术栈，包括感知、定位、决策、规划和控制，也有自己的整车方案。但L4无人配送的量产落地，卡在三个短板上：
- 场景不够：算法需要海量真实路采数据，没有场景就等于没有弹药，只能在固定测试园区里打转。
- 运营太重：无人车的日常运维、充电、清洁、保险、路权协调，都是重资产生意，自动驾驶公司普遍不擅长这一块。
- 合规门槛高：各地对无人配送车上路有不同的管理要求和测试流程，需要有人去跑通这些流程，而且要持续维护关系。
B平台恰好补齐了这三块。B平台在几百个城市有分拨中心和末端网络，能提供真实运营场景；有成熟的车辆运维体系和保险资源；有长期与各地管理部门打交道的经验，合规更顺畅。所以这个整合不是简单的甲方乙方关系，而是双方把各自最强的资产放进同一个盘子：A公司出“大脑”和“身体”，B平台出“血管”和“神经”。
2. 双品牌运营的逻辑：技术底座共享，品牌定位区隔
2.1 为什么不是合并，而是双品牌
很多人看到“战略整合”可能以为两家要合并成一家公司，实际上从披露的信息看，合作方式是“共建RoboVan超级航母，开启双品牌运营”。这就有意思了——在自动驾驶行业，“合并”和“双品牌”是完全不同的打法。
合并意味着组织、团队、文化的深度整合，执行难度极大，而且两家公司的基因不一样，合并之后容易产生内耗。自动驾驶公司是技术驱动，讲究算法实验、快速迭代；物流平台是运营驱动，讲究流程规范、成本控制，两者碰撞在一起，如果不能很好地处理文化差异，内耗会比产出大得多。双品牌则保留了各自的独立性：A公司在自动驾驶领域的技术品牌继续存在，B平台的物流服务品牌也继续存在，双方在共同的底层平台上造出一款或多款RoboVan产品，各自用自己品牌对外运营。
我个人的理解是，双品牌运营的核心在于三个层面的协同：
- 技术层：统一的自动驾驶中间件和硬件平台。不管RoboVan挂什么品牌，底层的传感器方案、计算单元、算法模型是同一套，这样研发投入可以摊薄，迭代速度更快。
- 数据层：双方的路采数据、运营数据、用户反馈数据全部打通。A公司拿到的数据喂给算法迭代，B平台拿到的数据喂给调度系统优化，数据飞轮转起来之后，双方的能力是同步增长的。
- 运营层：共用一套车队管理、充电维护、远程监控的运营网络，只是在用户端用不同品牌露出。
对于物流平台来说，双品牌意味着不会把运力命脉完全绑在单一技术供应商上——即使未来双方合作出现变化，B平台依然可以基于共建的技术底座发展自己的无人车队。对于自动驾驶公司来说，双品牌意味着可以借助物流平台的品牌势能快速打开市场，同时保留自己作为技术品牌的独立融资和发展空间。这个平衡在商业上是很巧妙的。
2.2 技术底座怎么共享
既然说“超级航母”，那一定有一个共用的技术底座。我基于行业通行的做法来补充一下这个底座应该长什么样。从硬件层看，一辆RoboVan的硬件拓扑一般包括：
- 传感器套件：前向主激光雷达（通常是1~2颗，负责中远距离感知）、补盲激光雷达（车身四周，负责近距离盲区）、毫米波雷达（全天候，负责速度测量和雨雾场景）、摄像头（多目相机，负责红绿灯识别、车道线识别、交通标志识别）、超声波雷达（泊车和近距离防碰撞）。
- 计算单元：一个车规级的高算力平台（现在主流在200~500 TOPS），跑感知融合、预测、规划和控制算法，另外通常会有一个冗余的备份计算单元。
- 定位模块：RTK-GNSS接收机 + 高精地图 + IMU（惯性测量单元）+ 轮速计的融合定位方案。这个组合在城市峡谷、隧道、高架桥下等GNSS信号遮挡场景尤其重要。
- 线控底盘：转向、制动、驱动都要支持线控接口，且需要满足功能安全等级，这一块直接决定了无人车能不能在关键时刻执行安全指令。
从软件层看，双品牌共用的部分主要是中间件和基础算法模块。感知融合模块把激光雷达点云、摄像头图像、毫米波雷达目标进行融合，输出统一的障碍物列表和语义地图；高精地图与定位模块负责地图数据的采集、更新、分发以及实时定位；预测与决策规划模块负责预测周围车辆和行人的轨迹、决策行为选择、生成局部路径；远程监控与接管系统在异常情况下让远程操作员介入。这个远程监控模块在无人配送场景极其重要，不能全交给车端算法，必须有远程操作员在异常情况下介入。
双品牌不等于两套技术，更现实的方案是：一套中间件，两套上层应用配置。A公司更侧重自动驾驶功能的完整性和新功能首发，B平台更侧重物流运营的效率指标和调度体验。底层的ODD（设计运行域）定义、安全策略和功能降级逻辑完全一致，这样运维团队只需要学一套系统，降低培训成本。我见过太多合作项目死在“各搞一套”上，双方都觉得自己有技术积累，结果两套系统对接起来光是标定和联调就耗费了半年，最后只能推倒重来。
2.3 品牌定位怎么区隔
既然双品牌，那就涉及定位问题。我个人预测这个双品牌会有比较明显的区隔：A公司品牌会主打“自动驾驶技术领先”，面向B端技术客户和行业开发者，强调L4能力、算法迭代、硬件方案的开放性。而B平台品牌会主打“智慧物流服务”，面向商家和C端用户，强调配送时效、成本优势、服务网络覆盖。这种品牌区隔在消费电子行业很常见——同一条产线出来的产品，贴不同的品牌，针对不同的客群，但在自动驾驶行业这是一种相对新颖的打法。
以前自动驾驶公司卖的是“解决方案”，物流平台买的是“运力服务”，两者不在一个维度上竞争。现在通过双品牌，两家公司实际上是在共享底层能力的同时，分别从“技术售卖”和“运力售卖”两个方向收割市场。不过双品牌运营也有挑战，最大的问题在于品牌信任背书：L4级无人配送车出了安全事故，消费者不会区分是哪家公司的算法、哪家平台的运营，只会记住“这个牌子的无人车出事了”。所以在安全事件响应、媒体沟通、事故定责机制上，双方必须有一套非常明确的协同方案，这件事比技术本身更考验管理层的智慧。
3. RoboVan的核心技术细节与落地要点
3.1 感知系统的配置逻辑
我先说传感器配置，因为这是RoboVan成本的大头，也是很多团队最容易走弯路的地方。早期无人配送车流行“堆料”，一颗高线束主激光雷达加一圈低线束雷达加十几个摄像头，单车传感器成本能逼近一辆豪车。后来行业逐渐清醒了，现在的共识是做“够用且安全冗余的传感器套件”。
RoboVan的传感器配置，我见过的主流方案大概是这样：
| 传感器 | 数量 | 核心作用 | 关键指标 |
|---|---|---|---|
| 主激光雷达 | 1~2颗 | 前向中远距离感知 | 128线以上，探测120米+ |
| 补盲激光雷达 | 4颗 | 近距离低矮障碍物感知 | 车头前方1~3米盲区覆盖 |
| 摄像头 | 6~8个 | 红绿灯、车道线、标志识别 | 360度覆盖，兼作远程画面 |
| 毫米波雷达 | 4~6颗 | 速度测量、恶劣天气感知 | 雨雾天保持目标检测 |
| 超声波雷达 | 12个 | 低速泊车、近距离防碰撞 | 盲区补盲 |
这套配置下来，单车传感器成本大概占整车BOM成本的三分之一到四分之一。如果未来激光雷达成本继续下探，比例还会进一步降低。
提示：传感器配置不是越多越好，每增加一类传感器，就增加一层标定、融合、故障诊断的复杂度。核心原则是“感知能力冗余但不浪费，算力够用但留有余量”。
另外要特别强调一点：摄像头的安装角度一定要兼顾算法需求和人类视觉习惯。远程操作员在接管时，需要看到和驾驶员视角接近的画面，如果摄像头角度不对，远程接管时操作员会非常难受，接管效率和准确率都会下降。这个问题在纯算法导向的团队里经常被忽略，属于典型的“工程细节打败技术团队”的问题。
3.2 定位系统的多源融合
RoboVan的定位问题，我在实际项目中被问过最多的问题是：没有高精地图能不能跑？答案是能跑，但性能和安全性都不是一个量级的。高精地图给无人车提供的是“先验信息”，没有先验，感知系统就得从零开始理解每条道路的结构，这意味着大量的计算和极高的出错概率。
RoboVan的定位方案一般是多源融合，每一路信息都有自己的优势和短板：
- RTK-GNSS提供绝对位置基准（厘米级），但在高架桥下、高楼林立的城市峡谷、隧道里，卫星信号会丢失或产生多路径效应，误差可能到米级。
- IMU提供高频运动状态推算（航位推算），短时间精度高，但会漂移，尤其是在频繁启停的城市配送场景里。
- 轮速计和转向角用于构建车辆运动学模型，补足IMU的低速漂移。
- 激光点云与高精地图的配准（NDT/ICP匹配）在GNSS失效时提供位置修正。
- 摄像头识别到的车道线、停止线、路牌，也可以作为语义定位的输入。
把这五路信息做一个EKF（扩展卡尔曼滤波）或者因子图优化，输出一个带置信度评分的位置估计。如果在某个瞬间GNSS信号丢了同时点云匹配分数很低、车道线识别找不到，系统会判定定位置信度不足，这时候策略是降速并请求远程介入，而不是硬着头皮继续开。这个“承认自己不知道”的能力，比测量精度本身更重要——无人车不能像人一样凭感觉开车，它必须有一套明确的置信度评估机制来告诉系统“我现在不可靠”。
3.3 决策规划：怎么开得像一个“老司机”
RoboVan的决策规划模块，目标不只是安全，还要“不被人骂”。城市配送场景里最容易被骂的，是无人车在路口犹犹豫豫、该走不走，后车喇叭按成一片。所以A公司这类L4团队在规划模块上会花很大的精力做“行为合理性”。
具体来说，决策模块会分成几个层次。全局规划基于高精地图和实时路况，计算从A点到B点的宏观路径，包括车道选择、路口选择。行为决策处理交通规则和交互博弈，比如前方车辆打右转向灯，是选择跟随、超车还是减速等待对方完成变道？这个需要一套基于规则和学习的混合决策框架。运动规划在行为决策的约束下，生成一条平滑、安全、满足车辆动力学约束的局部轨迹，通常用Frenet坐标系下的轨迹采样和代价评估来做，代价函数里权衡碰撞风险、舒适性、效率、规则符合度等因素。控制执行把规划出的轨迹转换为方向盘转角、油门、刹车的指令，控制算法主流是用MPC（模型预测控制）或者PID加前馈的组合。
经验之谈：RoboVan的规划参数和乘用车Robotaxi的规划参数差异很大。乘用车追求的是在复杂交通流里“挤进去”，RoboVan追求的是“稳妥到达”。末端配送的场景固定、路线重复度高，完全可以把大部分路段的限速设低一些，换更低的接管率和更稳定的体验。很多团队在早期调试时喜欢把车速拉高，实测下来接管的次数飙升——城市配送不是比谁跑得快，是比谁不被打断。一辆RoboVan的配送时效，用户能接受的缓冲窗口通常在三十分钟左右，你慢五分钟到、十分钟到，感知差异并不大，但如果你因为速度过快导致一次接管，可能整条线路都要停下来，反而更慢。
3.4 安全冗余是底线
L4无人配送车不能只靠算法“够好”，必须在系统架构上就考虑失效场景。这部分我简单列一下行业通行的做法：
- 计算单元双冗余：主计算单元故障时，备份单元能在100毫秒内接管，车辆自动降速进入最小风险状态。
- 线控底盘冗余：转向系统双路供电、双路信号，制动系统采用电子液压制动加机械备份的冗余方案。
- 电源系统冗余：主电源失效时，备用电源保证转向、制动、通信系统继续工作足够时间让车辆安全靠边。
- 远程监控平台：车辆每隔一定时间上报运行状态，平台能实时看到车辆的位置、速度、感知状态、健康度。一旦出现“自动驾驶系统无法处理”的情况，远程操作员可以下发减速靠边或切换人工遥控指令。
这里要强调的是：安全冗余不是拼硬件，而是拼“失效场景下的行为设计”。一个设计良好的L4系统，不只是要在正常工作的时候表现优秀，更要清楚“我什么时候不行了、不行了之后怎么安全退出”。这一点上，行业内的共识是“宁可多停，不可硬冲”。无人车在复杂路况下选择保守策略，短期看会降低通行效率，长期看是在保护整个品牌的信任基础——尤其是双品牌运营的情况下，一次安全事故影响的不是一个品牌，而是两个品牌的公众认知。
4. 实操过程：从技术到运营，RoboVan怎么跑起来
4.1 从测试到运营的“四级跳”
我参与过的无人配送项目，从技术成熟到规模化运营，通常要走四个阶段。封闭场地测试在固定的测试园区里验证基础的感知、规划、控制功能，主要目的是刷掉低级bug，比如传感器标定错误、控制指令延迟、规划轨迹抖动这类问题。开放道路测试（安全员跟车）在限定区域和限定时段上路，车上保留安全员，随时准备接管，这个阶段主要验证真实交通流下的系统稳定性，以及和交管、路权方、附近居民的磨合。开放道路测试（远程监控）去掉车上的安全员，由远程操作员监控若干辆车，这是无人配送从“能跑”到“能撤人”的关键，也是成本结构真正变好的开始。规模化运营是在一个城市或一个片区内投入一定数量的RoboVan，与现有的物流分拨流程完全打通，接受实际订单的检验。
A公司和B平台的整合，最大的跳跃就是从第二阶段或第三阶段直接跳到第四阶段成为可能。B平台把RoboVan纳入自己的分拨网络和末端网络，“车队调度”不再是自动驾驶公司自己摸索的事情，而是直接复用物流平台成熟的调度和管控系统。这一步的价值怎么强调都不过分——很多自动驾驶公司死在“能跑”到“规模化”之间的无人地带，不是因为技术不行，而是因为缺调度系统、缺运维网络、缺服务SOP。有了物流平台这张网，RoboVan从“实验品”变成“产品”的距离被大幅缩短。
4.2 数据闭环：算法进化的汽油
RoboVan的算法迭代依赖数据闭环，这一点怎么强调都不过分。在无人配送项目里，我见过很多团队忽略或者不重视数据回收环节，结果就是算法在实验室测试很好，一上线就“见光死”。数据闭环的核心环节包括：
- 场景数据采集：每辆车在运营过程中持续回传感知数据和决策日志，尤其是“接管事件”和“逼停事件”的数据。这些数据是算法迭代的黄金素材，因为它们精确标出了算法在哪一类场景下不够好。
- 自动标注与人工标注：对采集到的数据进行自动标注（利用预标注模型），再由人工对困难样本进行精标注。成本控制的关键是让自动标注的准确率足够高，否则人工标注的工作量会把数据团队淹没。
- 仿真回放：把真实路采数据转化为仿真场景，在仿真环境里重放和验证算法改进效果。注意，这里要保证仿真场景的“保真度”，否则算法在仿真里有效、上线后又失效，这是仿真验证最大的坑。
- 影子模式：让新算法在后台以“影子”方式运行，在真实交通流中静默验证新算法的决策质量，与当前线上版本做对比，只有当新版本在大量测试场景中都优于旧版本时才灰度上线。
我特别想强调影子模式这个环节。很多团队嫌麻烦，直接在仿真里跑几个场景就上线新版本，结果往往在没想到的corner case上翻车。影子模式虽然增加工程成本，但它是保证RoboVan算法持续进化且不倒退的保险丝。做数据闭环要配置一个专职的算法工程团队，负责数据管道、标注流程、仿真平台和版本发布，这个团队的规模通常是感知、规划等核心算法团队的六成左右。
4.3 运营侧的关键环节
RoboVan从“技术项目”变成“运营项目”之后，考验的重点就变了。技术团队这时候主要盯的是故障率、接管率、算法迭代速度，但运营团队要盯的是更接地气的事情。充电和能源管理层面，无人配送车队需要基于线路长度、载重、天气来规划充电时间，夜间谷电充电能大幅降低电费成本，但需要车队管理系统支持“充电排班”。我见过一个很典型的反面案例：所有车辆在同样时间集中充电，充电桩过载，电网跳闸，整个车队当晚趴窝，第二天运力直接清零。
车辆卫生和维护层面，这个听起来很琐碎，但车辆的传感器镜头脏污会导致感知性能急剧下降。运营SOP里必须包含每日的车身清洁和传感器表面检查，而且要设定触发条件——车辆每运行满一定里程或小时数，强制进入自动洗车和清洁流程。路权协调和舆情管理层面，无人车在路上的行为会直接影响公众认知，一个急刹车、一次影响交通的故障停车，都可能被拍下来发到网上，运营团队需要有专门的岗位来处理这类事件，要能在半小时内做出公开回应。保险和事故处理层面，L4无人配送车的保险设计逻辑与传统商用车不同，需要基于运营数据来定保险费率，而且要有一套清晰的事故定责流程：是算法问题？是传感器故障？是远程接管失误？这些责任界定直接影响后续的产品改进方向。
5. 常见问题与排查技巧实录
5.1 传感器污损导致的感知性能退化
这是无人配送车日常运营中发生频率最高的问题。我见过不止一次，摄像头被泥水遮挡、雷达表面结了一层灰尘，感知结果就出现大量误检或漏检，最典型的场景是雨后过积水路面，车身甩起来的泥水正好打在侧向摄像头上，系统就开始把路边的柱子识别成障碍物，然后频繁刹车。
排查思路：
- 先看远程监控平台上报的各项传感器健康度指标，一般摄像头有遮挡检测算法，激光雷达有点云质量统计。
- 如果发现某辆车的误检率异常升高，优先怀疑传感器表面污损，调出该车最近的摄像头画面确认。
- 处理方式很简单：清洁传感器表面。但更好的做法是在调度系统里加一条规则：车辆每运行满一定里程或小时数，强制进入自动洗车和清洁流程。
5.2 GNSS定位漂移导致的“画龙”现象
城市高楼区域，RTK-GNSS容易出现多路径效应，定位结果在车道内抖动，导致车辆在车道里“画龙”（左右摆动）。这个现象在傍晚时段尤其明显，因为太阳角度低，卫星几何分布和信号反射路径都会发生变化。排障步骤：
- 查看定位模块的协方差输出和融合置信度。如果置信度低，系统应该已经降速。
- 对比同一路段不同时间的定位表现，多路径效应和卫星几何分布有关，有时候是时间段的问题，换个时间点情况会好很多。
- 增强定位冗余：在关键路口和高架桥下部署地面的UWB信标或路侧定位设备，辅助车辆定位。这个做法在很多城市级项目中已经在用了。
5.3 路口复杂交互导致的通行效率低下
城市路口的无保护左转、人车混行是无人配送车最难处理的场景。经常出现的情况是：行人和电动车在车前反复穿过，车辆只能在路口僵住，后面的车喇叭一片。这个问题我见过太多运营事故和用户投诉的案例了。解决思路分两层：
- 策略层：在ODD设计时，对无保护左转之类的困难场景做“白天降频、夜间放开”或“绕行选择”的优化。RoboVan配送路线并非固定不可变，调度系统完全可以绕开高难度路口，虽然路线长一点，但整体时效反而更稳。
- 算法层：通过影子模式积累路口交互数据，不断优化预测模型，让车辆学会“预判行人的下一步动作”，而不是等人走到跟前才反应。行人站在路边看手机，和行人站在路边身体朝向马路，下一步动作的概率分布完全不同。
5.4 远程接管通道中断
如果4G/5G信号在隧道或信号盲区丢失，远程接管通道会暂时不可用。这种情况处理的核心是“分级降级”：信号丢失时间短时，车辆按当前规划继续低速行驶，避免在隧道内停车；信号丢失时间超过阈值，车辆在安全位置靠边停车并打开双闪；信号恢复后，车辆自动重新联线并汇报历史轨迹。这里要特别注意：车辆的全部运行数据要本地缓存，信号恢复后自动补传，否则会丢数据。我参与的一个早期项目因为没有做本地缓存，车辆每次穿隧道就丢一段数据，算法团队调试了整整两周才发现是这个问题。
5.5 多车协同调度冲突
当RoboVan车队规模上来之后，多车调度冲突会成为运营的主要问题。最典型的是多台车同时到达同一个分拨仓的同一个装卸口，导致拥堵和等待。这个问题的根源不是路由算法不够好，而是末端仓的装卸口资源没有纳入调度模型。解决办法是在调度系统里把装卸口当成一个“资源”来管理，车辆提前申请装卸时段，系统按优先级和预估到达时间动态分配。还有一个容易被忽视的问题是充电桩资源的调度，如果充电桩数量不够，调度系统必须能预测每台车的电量和剩余续航，按优先级排队充电，而不是等车趴窝了再处理。
6. 写在后面：整合之后的“远虑”
这次的战略整合，短期看是两个公司的资源互补，长期看其实是在赌一个趋势：城配无人驾驶的规模化拐点是否会在未来两三年内到来。我个人判断，RoboVan赛道的拐点有三个指标：单公里运营成本对标人力成本、日有效运营时长超过20小时、每万公里接管次数降到极低水平。三个指标全部达到，无人配送车就不仅仅是“技术项目”，而是真正能独立面对市场竞争的运力产品。
从A公司和B平台的整合方式看，他们明显是想通过双品牌运营在拐点到来之前，先占住场景、占住数据、占住用户心智。这是一场“抢时间”的竞争——谁先跑通“技术-场景-数据-成本”的正循环，谁就在下一阶段的无人配送市场拥有统治力。至于“超级航母”这个说法，我觉得倒不算夸张。物流网络的毛细血管加上自动驾驶的大脑，如果真能协同运转，它带来的不只是一个新产品，而是整个城配体系运作方式的改变。
我在这个赛道看过太多的“合作”与“整合”，很多合作说到底就是甲方花钱买乙方的技术委托开发，签完合同各干各的，表面上热热闹闹，实际没有沉淀任何共有的东西。A公司和B平台这次如果真的能把技术底座、数据网络、运营体系全部打通，并且用双品牌的方式跑通商业闭环，那它给整个行业立了一个非常有价值的样板——自动驾驶公司和物流平台的“共生”模式。
当然，船越大，转向越难，风险越集中。整合之后如何解决组织摩擦、如何统一安全标准、如何在双品牌之间分配收益，这些问题任何一个处理不好，都可能让“超级航母”变成“超级负担”。这条路没有现成的参考坐标，两支团队只能摸着石头过河。作为从业者，我个人非常期待看到他们交出的阶段性答卷。后面如果这个项目有新的进展，比如首批RoboVan的量产细节、双品牌的定价策略、或者运营数据披露，我会再开一篇文章跟大家一起拆解。
