先抛个结论这个问题问得不够准确。通不通吃取决于你问的是“一套模型直接端到端跑两种任务”还是“一套预训练底座同时给两个场景做初始化”。前者目前没人能做到后者已经在路上了但中间的沟壑远比外人看到的深。最近我在跑 xbotics 这类具身智能开源社区的项目同时在用欧卡2的自动驾驶数据集练手做仿真测试两边的代码库摆在一起那种割裂感非常明显。这篇文章就把我这几周的对比折腾经验拆开讲讲从数据、模型架构、评测方式到落地姿势逐层说清楚为什么“通吃”是个伪命题而“共用底座”才是真方向。1. 自动驾驶和具身智能表面都是“智能车”底层逻辑是两套东西很多人觉得自动驾驶和具身智能差不多不都是让机器看路、规划、行动吗我在两边的仿真环境里交替跑了半个月最大的感触是它们共享的只是“感知决策控制”这个宏观框架具体到每一层的输入输出、数据结构和失败模式完全是两个物种。1.1 自动驾驶面对的是“结构化世界”具身智能面对的是“非结构化物理世界”自动驾驶的场景再怎么复杂它有一个天然红利道路是有规则的。车道线、红绿灯、交通标志、行人过马路的相对固定模式这些都是人类社会为了交通效率强行建立的结构。所以自动驾驶模型的核心任务是“在高度结构化的环境里做行为预测和轨迹规划”。我用欧卡2的数据集做测试时印象很深第一眼看上去画面很丰富但如果你把语义分割结果拉出来看类别其实相当有限路面、车辆、行人、标志、建筑、天空没了。整个世界的状态变化也相对缓慢一个物体在下一帧往哪走很大程度上受交通规则约束。具身智能完全不是这样。机械臂要抓的物体可能是杯子、螺丝、布料、水果每一类物体的物理属性都不一样——刚性、柔性、透明、反光、可变形、可堆叠。而且操作对象往往没有规则可言一个螺丝可能在零件盒里是正着的下一帧被机械臂碰了一下就变成了斜着甚至倒着的。你没法用一个预设的“物体运动规则”去预测它。这就是第一个核心差异自动驾驶世界的信息熵相对可控具身智能世界的信息熵几乎是发散的。基础模型如果在自动驾驶数据上预训练学到的是“结构化规则下的模式识别”迁移到具身操作场景时它连“这个东西会怎样受力变形”这个最基本的问题都回答不了。1.2 动作空间的维度差异方向盘角度 vs 自由度关节控制再往下看动作空间。自动驾驶的输出通常是低维连续控制量油门、刹车、方向盘转角。哪怕加上换挡、灯光控制撑死了也就5-10个控制维度。这个输出空间非常友好模型不用关心轮胎怎么转、车身怎么保持平衡那是底层动力学模块的事。具身智能要控制的是机械臂的多个关节六轴机械臂就是6个自由度双机械臂加移动底盘再加灵巧手轻松超过20个自由度。而且每个关节涉及角度、力矩、速度还要考虑奇异性规避、碰撞检测、力矩限制。我在 xbotics 社区跑机械臂仿真时就踩过这个坑同一个抓取动作用位置控制能跑通换力矩控制就抖动因为模型输出的关节角度序列没有考虑物理约束。这意味着基础模型如果要通吃两个场景它的输出头得同时支持“低维连续控制”和“高维关节空间规划”这两类任务的损失函数、评价指标和采样策略完全不能共用。你不可能用训练自动驾驶的策略梯度方法来优化一个20自由度机械臂的精细操作策略探索空间完全不是一个量级。1.3 环境反馈的实时性毫秒级闭环 vs 秒级语义决策还有一个经常被忽略的差异反馈频率。自动驾驶的决策周期虽然越来越快但本质上它的关键决策是“秒级”的——前方有障碍我变道还是刹车这个决策不需要在毫秒级别反复震荡。车辆控制层面的高频反馈由ESP、ABS这类底层系统完成AI模型做的是中高层规划。具身智能的精细操作是真正的毫秒级闭环。机械臂抓取一个易碎物品力控的反馈周期是千赫兹级别模型不仅要决定“抓哪里”还要实时调整“抓多用力”。这已经不是同一个时间尺度上的问题了。所以我现在看到有人声称“一个VLA模型既能开车又能炒菜”第一反应就是他们大概率只在仿真里做过演示或者只是把同一套视觉编码器用在了两个任务上然后把“共用Transformer主体”偷换成了“一套模型通吃”。2. 两边各自的基础模型进展都在冲刺但跑道不同既然要讨论“通吃”那就得先看看两边的基础模型各自进化到了什么程度。我按自己的观察拆成了三条线视觉语言模型底座、端到端驾驶模型、具身操作大模型。2.1 自动驾驶的基础模型主线从“感知堆叠”走向“端到端稀疏化”自动驾驶圈谈基础模型早年大家拼的是“多传感器融合规则后处理”现在主流方向其实是两派一派是模块化路线里的“大感知模型”把相机、激光雷达、毫米波雷达的数据全部扔进一个大Transformer里做统一occupancy占用栅格预测另一派是端到端路线图像输入直接出控制量中间没有显式的感知结果。我测过的那套欧卡2数据集常被用来做端到端驾驶的仿真验证。在游戏环境里端到端模型的确能玩出挺像样的跟车和变道欧卡2的物理引擎虽然简化但至少提供了连续的速度-转向-制动闭环环境比起纯图像分类的“看着像自动驾驶”要扎实很多。但真实自动驾驶的基础模型核心价值在于“跨场景泛化能力”同一个模型在不同城市、不同天气、不同光照下都能稳定输出可行驶区域和障碍物信息。这依赖于海量真实路采数据和高度冗余的传感器配置。一个有意思的细节是这类模型的骨干网络通常会用视频预训练video pretraining因为车辆视角的时序一致性对感知非常关键。2.2 具身智能的基础模型主线VLA架构和大规模模仿学习具身智能这边的基础模型以VLAVision-Language-Action为核心架构代表作就是RT-1、RT-2、Octo这一系。它们做的事情非常统一输入当前图像或视频 一段自然语言指令输出一串离散化的动作token。关键区别在于VLA的动作预测不是“方向盘角度”这种低维量而是机器人关节的目标位置序列很多模型直接用了动作分词action quantization的思路把连续动作空间离散成类似文本token的形式。我在 xbotics 社区里跑了几个VLA模型的开源实现体感是这些模型在单任务上的表现非常依赖采集数据的质量。社区里最活跃的话题之一就是“如何用更少的示教数据训练出能泛化的操作策略”。有人用遥操作采集了几百条抓取轨迹模型就只能在特定物体和特定背景颜色下工作换了一个光照成功率掉一半。这说明现阶段具身基础模型的“基础”两个字还得打引号它更多是一个可初始化的多任务底座而不是一个真正具备世界理解能力的通用策略。2.3 直观对比输入输出和训练资源不是一个量级的需求把两边的真实训练情况摆在一起差异更直观。我列一个自己跑实验时的对比表对比维度自动驾驶基础模型具身智能基础模型主要输入多相机图像、点云、GPS/IMU、高精地图单/多相机图像、本体状态关节角、力矩、语言指令主要输出轨迹点、占用网格、控制量方向盘/加减速关节目标位置、动作token序列、力控指令数据来源路采车队、仿真器采集、众包数据遥操作示教、仿真随机采样、人工标注轨迹单条数据成本相对低车跑起来就产数据极高一条有效操作轨迹可能要好几分钟人工示教评估方式仿真闭环得分真实路测接管率任务成功率泛化测试新物体/新布局训练计算量百卡~千卡GPU级别相同甚至更高动作空间大这张表最关键的一行是数据来源。自动驾驶目前最不缺的就是数据车在路上跑传感器哗哗地记录具身智能最缺的也是数据不是说没有而是高质量的“操作成功轨迹”太贵了。一条机械臂成功拧螺丝的示教轨迹人工遥操作采集可能需要一分钟这一分钟里还包含了大量无效运动清洗起来也麻烦。数据形态的根本差异决定了就算给你一套强大的基础模型架构你也没法同时喂饱两个场景。3. 挡在“通吃”面前的三个硬式矛盾数据、物理交互、安全边界有人可能会说架构上虽然不同但可以设计一个超大的多模态模型左边接车辆传感器右边接机械臂关节中间共用一个大Transformer。理论上确实可以但实操层面有三个硬矛盾基本绕不过去。3.1 数据矛盾采集成本差了两个数量级先说最致命的数据矛盾。自动驾驶的数据获取是“被动式”的只要车在合法路线上跑数据就自然来。全球范围内的路采车队一天能产生PB级数据虽然有效场景占比不高但基数大筛得出来。具身智能的数据获取是“主动式”的每一个动作轨迹都需要机器人在真实物理世界里执行一遍或者由人遥操作一遍。光是“物体抓取”这一个动作要泛化到不同形状、材质、摆放姿态需要采集的轨迹数量就是指数级增长。斯坦福的ALOHA这类系统之所以开源后大火就是因为大家意识到遥操作采集数据是最实际的生产途径但即便如此一个人一天能采集的有效轨迹也就几百条和自动驾驶一天百万帧完全没法比。这意味着如果一套基础模型同时要吃两个领域的数据它的训练权重分配必然严重失衡。你在自动驾驶数据上预训练的token数量可能占95%具身操作数据只有5%。最终这个模型的“才能”会向自动驾驶严重倾斜机械臂操作能力只是勉强能用。3.2 物理交互矛盾世界模型预测不了“接触之后的下一秒”自动驾驶不是没有物理交互轮胎和地面的摩擦力、空气阻力都是物理但这些物理规律相对稳定车辆动力学模型早就被研究得很透了。真正难的是其他交通参与者的意图预测。具身智能的物理交互是“接触式”的手指捏住物体时物体表面会变形机械臂推一下杯子杯子可能滑走力大了物体碎了。这些现象不是靠视觉就能预测的必须靠触觉、力觉信号实时反馈再结合动力学模型做闭环控制。我在 xbotics 社区看机械臂演示时注意过一个细节很多抓取模型在仿真里成功率95%以上但上真机就掉到60%。原因就是仿真环境里没有接触变形和摩擦力突变。仿真里杯子的摩擦系数是固定的真实世界里粉末状物体、带液体的容器、表面有纹路的工具每一种情况都让模型措手不及。所谓“通吃”的基础模型如果要处理这些物理交互需要一个极其准确的“世界模型”——不仅能识别物体是什么还要能预测物体在受力后如何运动。现在的视觉基础模型能告诉你“这是一个杯子”但没法告诉你“用2牛顿的力捏杯口会裂”。这不是堆数据能解决的需要重新设计状态表征把接触力、形变状态、摩擦信息全部纳入训练目标。3.3 安全边界矛盾驾驶事故和操作事故的归责逻辑完全不同第三个矛盾是安全边界。自动驾驶一旦出事故是直接的人身安全事件所以行业里的安全标准极度严格对模型的决策逻辑有可解释性要求至少得能回答问题“为什么在这个路口选择变道”具身智能的事故边界不太一样。机械臂操作失误可能就是夹坏一个零件、打翻一个容器危害范围相对小。但它在另一个维度上有风险——如果具身智能用在医疗、养老这类场景操作的错误容差就变得极低且涉及伦理责任划分。这种安全边界的差异直接影响了模型设计。自动驾驶模型倾向于“保守策略”宁可多等一秒也不冒进具身智能模型反而需要一定程度的“探索策略”因为操作场景千变万化太保守什么事情都干不成。你把这两种目标函数放在同一个模型里模型会陷入矛盾该保守还是该探索没有一个损失函数能平衡好这两件事。4. 虽然不能“通吃”但共用底座是真实存在的路径依赖说了一堆不可能不代表这件事完全没有交集。我自己的判断是“一套模型通吃”不现实但“一套技术栈底座复用”正在发生而且是必然路径。区别在于你怎么定义“套”这个字。4.1 视觉骨干网络是最大公约数两边真正能共用的部分是底层的视觉表征。无论你是自动驾驶的摄像头还是机械臂的腕部相机输入的都是一段图像序列。一个在大规模视频数据上预训练好的视觉编码器对两个领域都有价值因为它学到的是“物体是什么、在哪儿、怎么运动”的通用视觉常识。我试验过直接拿一个自动驾驶场景预训练的视觉骨干接在具身操作模型的输入端任务成功率虽然不如专用视觉骨干但训练收敛速度明显更快。这说明通用视觉底座能给具身操作提供很好的初始化省掉了从零开始学视觉特征的过程。反过来也一样具身操作数据里的物体交互信息反而能帮助自动驾驶场景理解“物体在受力后的运动趋势”只是这个信号比较微弱。4.2 语言指令接口让两个场景共享同一种“任务描述语言”另一个可以共用的是语言指令接口。自动驾驶现在也开始支持自然语言交互比如“前方路口右转”“找最近的充电桩”“在下个服务区停一下”。具身智能更不用说VLA模型天然就是视觉语言动作。如果把任务定义成一句自然语言那基础的语义理解模块——分词、意图解析、任务分解——是可以共用的。我在 xbotics 里测试过用同一个语言编码器处理两类指令一边是“在第三个路口左转弯进入物流园区”另一边是“把红色杯子放到托盘中央”语言编码器都能准确解析出关键语义。真正分叉的地方在语言理解之后车要把意图转成轨迹规划机械臂要把意图转成关节空间的动作序列。所以更务实的做法是一个通用大语言模型做任务理解然后接两个不同的动作头一个输出车辆控制一个输出机械臂动作。这已经是一些前沿工作在做的事只是它不叫“一套模型通吃”而叫“一个大脑两个身体”。4.3 仿真平台的数据生产线可以跨场景复用第三个能共用的是仿真工具链。自动驾驶用仿真器做闭环评测和极端场景生成很成熟了具身智能这一年也开始大力投入仿真数据和仿真评测。欧卡2这类游戏引擎能跑自动驾驶数据而具身智能里的桌面操作仿真环境也越来越多。两者在仿真平台的底层技术上有大量重叠场景构建、传感器模拟、物理引擎、域随机化。如果你已经建立了自动驾驶的仿真数据生产管线把它改造成具身操作的仿真数据管线工程量比从零开始小得多。至少坐标系管理、渲染、标注、回放这些模块是能直接迁移的。5. 实践下来的最优解底座共用场景分化评价分家前面说了那么多理论的最后分享一点实操层面的思路包括我实际在跑的开源项目和搭建工作流的心得。5.1 分层架构是当前最靠谱的姿势我自己搭的这套架构分为三层几乎是我对比了两边主流开源项目后能想到的性价比最高的结构第一层是通用底座视觉骨干网络 语言编码器先在自动驾驶的大规模视频数据集上预训练再用具身操作数据做增量预训练。这一步只学“感知和语义”不学任何动作。第二层是场景适配自动驾驶任务接一个轨迹解码头输入感知特征输出未来若干秒的轨迹点具身操作任务接一个动作解码头输入感知特征语言指令输出关节位置序列。两个头互相独立各自的训练数据互不干扰。第三层是闭环控制器车这边的轨迹跟踪用现成的MPC机械臂这边用位置/力矩混合控制。这一层彻底分家因为控制频率和物理模型完全不一样。好处很明显任何一边的数据变多了只需要微调对应场景的解码头和底座部分参数不会影响另一边的已有能力。坏处也明显它不是“一套模型”而是“一个模型加两个适配器”但我不觉得这有什么不好。5.2 数据增强和混合训练有限共用的实操技巧在训练策略上我试过两个技巧值得分享。第一个是比例控制混合训练时自动驾驶数据和具身操作数据的batch比例建议控制在8:2左右如果具身数据占比太高自动驾驶任务的性能会掉得很快因为操作轨迹的多样化太强会把底层视觉表征往“局部物体接触”的方向带偏。第二个是分阶段训练先用自动驾驶数据把视觉骨干训到收敛再冻结骨干层只训练具身操作的动作头。这个方式最稳尤其适合像我这样没有足够算力同时训两个大头的情况。如果后续具身数据量变大了再解冻骨干做全量微调风险也可控。5.3 评测体系的差异决定了很难“一测通吃”还有一个很隐蔽的点两边对“基础模型好不好”的评价方式完全不同。自动驾驶用接管里程、规划碰撞率、舒适性指标强调的是连续长时间的低风险运行具身操作看任务成功率、新物体泛化率、操作时长的平均优化强调的是单次任务的高质量完成。你没法用一辆车跑一万公里不接管的指标去衡量一个机械臂抓取一万次不失败的任务。因为一个是“长尾事件发生的概率”一个是“高维控制精度的均值”。评价指标不统一就算你真有一套模型也无法知道它“通吃”得好不好。所以我在最终方案里给两个场景分别建了评测集自动驾驶场景用仿真闭环测试集具身操作场景用真实机械臂的固定操作科目表。两者互不干扰只在底座版本更新时统一跑一遍回归测试确保没有退化。5.4 给想入局的人两条路线建议如果你是从自动驾驶背景想转具身智能我建议先别急着跑大模型。找个开源社区比如 xbotics把它的真实机械臂仿真环境跑通亲手用遥操作采集一百条数据再用一个很小的VLA模型微调出抓取策略。这个过程会把你对“数据”的理解彻底重置——你会明白自动驾驶里习以为常的“数据自由”在具身世界里是一种奢望。如果你是从具身智能背景想往自动驾驶靠拢我建议先拿欧卡2这类仿真游戏练手把端到端驾驶的完整闭环跑一遍感受一下“连续决策在长时间序列上的稳定性”有多难。自动驾驀模型在仿真里开得再好上真实道路的各种corner case也会教你做人。两条路线走完你自然就会明白“通吃”为什么是个伪命题。它不是一个模型能解决的问题而是一整套数据系统、评测体系、控制栈和风险边界的深度耦合。最后说个实在话与其追求一套模型通吃自动驾驶和具身智能不如把精力花在建一条靠谱的数据生产管线、搭一套能跨场景复用的仿真平台、训练一个真正通用的感知底座。这三样东西才是两个领域共同的地基。模型架构会迭代但地基的价值是长期的。这也是我为什么一直在社区里盯着仿真数据工具链的进展——那才是真正能撬动两边的东西。
