从「看」到「想」再到「做」这句话放在机器人领域本质上就是一条从感知、认知到执行的完整链路。过去几年机器人行业最热闹的讨论不再是“机械结构怎么做”而是“机器人的大脑怎么造”。尤其是大模型技术吹进具身智能之后三类模型的名字被频繁提起WMWorld Model世界模型、WAMWorld Action Model世界动作模型、VLAVision-Language-Action Model视觉语言动作模型。如果你最近在刷机器人技术相关的社区、论文或者开源仓库大概率已经被这三个缩写反复轰炸过。这篇内容我打算把三种模型彻底摊开来讲清楚它们分别解决什么问题、底层怎么做、训练和部署的关键在哪、彼此之间到底是什么关系以及我实际复现和落地时踩过的坑。无论你是刚入行的算法工程师、准备做机器人产品落地的创业者还是单纯对具身智能感兴趣的读者这篇内容都可以当作一份“从概念到实操”的参考手册来看。1. 三种模型各自解决什么问题先把“看、想、做”对齐1.1 机器人的“大脑”为什么不能只靠感知和规划要理解 WM、WAM、VLA 的价值得先回到一个基础问题传统的机器人控制链路是怎么工作的经典方案里机器人通常走“感知—建图—定位—规划—控制”这条管线。传感器拿到数据算法构建环境地图机器人在图中定位自己然后规划出一条路径或轨迹最后通过底层控制把指令转成电机转动。这套体系在工业机械臂、AGV自动导引车这些场景跑了很多年非常成熟。但这套管线有一个致命弱点每一个模块都是独立设计、独立优化的模块之间靠固定接口传递信息。一旦环境变化超出预期比如光照突变、物体被突然遮挡、抓取目标从圆柱体变成不规则块状物整个链路就容易崩。说白了传统方案里的机器人“看”是机械地看“想”是规则地想“做”是死板地做。这也是为什么具身智能领域近两年把重心转向了“数据驱动的大模型”希望用一个端到端或半端到端的模型把感知、推理、动作生成全部打通让机器人真正具备“理解环境并行动”的能力。1.2 从“看”到“想”再到“做”三种模型的分工逻辑如果把它们放到一个链条上看分工其实特别清楚。WMWorld Model负责“看”和“推演”。它学习的是环境的状态转移规律输入是当前状态和动作输出是预测的下一个状态或者一段未来的状态序列。它要回答的问题是环境接下来会变成什么样WAMWorld Action Model名字里带“Action”但本质上它还是在“想”的范畴只不过比WM更进一步。它的输入通常是当前的“观测”和任务指令输出不是单纯的下一个状态而是“为了达到某个目标接下来应该采取什么动作序列”。它更像是一个“大脑中做规划”的角色和语言模型里“思维链”的概念有异曲同工之处。VLAVision-Language-Action Model直接从“看”跳到“做”。它把视觉信息、语言指令和动作输出统一到一个模型中输入是“当前图像 语言指令”输出就是底层的动作指令例如机械臂末端位姿的增量、关节角度、移动速度等。它省略了显式的路径规划和状态预测步骤赌的是数据的力量。这个链条用一句话概括就是WM 预测世界怎么变WAM 决定下一步该做什么VLA 直接动手做。当然实际工程里边界没有这么干净很多模型是互相交叠的后面我会详细对比。2. WM / WAM / VLA 逐个拆解结构、训练方式与能力边界2.1 WMWorld Model教机器人预演未来世界模型并不是新概念早在上世纪 90 年代就有人提出过类似思想。但真正引爆这一轮热潮的是 2018 年 Ha 和 Schmidhuber 发表的那篇《World Models》以及后来在自动驾驶、强化学习领域的一系列工作。WM 的核心目标是学习环境的动态模型。具体来说给定一个当前状态可能是图像、点云、向量特征等和一个候选动作WM 要能预测执行这个动作后的下一帧状态。有了这个能力机器人就可以做“脑海中的模拟”在真实行动之前先在模型内部推演多条动作路径选出最有利的那条再真实执行。这种思路其实很像人类在下棋时的“复盘”和“算路”——我没有真实落子就能在脑子里推演几步之后的变化。从结构上看主流 WM 通常由三部分组成编码器Encoder把高维观测比如图像压缩成低维的隐状态表示状态转移模型Transition Model在隐空间里预测下一时刻的状态解码器Decoder把预测出的隐状态还原成可理解的预测帧或重建帧。训练方式上WM 的核心损失是“预测一致性”——把状态预测误差降到最小。实际工程中通常会在隐空间做预测而不是原始像素空间因为像素空间的预测计算量大且难以收敛而隐空间的特征已经过滤掉大量无关的视觉噪声。这里有一个容易被忽略的点WM 训练时常用“视频预测”任务作为自监督信号也就是让模型看一段视频的前几帧预测后面几帧。这个任务看似“只是看图说话”但它逼着模型去学习物理世界的因果关系比如物体运动趋势、遮挡关系、光影变化等。正因如此WM 在仿真环境、自动驾驶场景中往往能展现出很强的“预演”能力。2.2 WAMWorld Action Model在“想”与“做”之间架一座桥WAM 这个名字相对新一些但思路其实承接了“世界模型 决策规划”的交叉地带。如果说 WM 是在做“预测”WAM 就是在做“规划”。举个例子。你让机器人“把桌子上的红色杯子拿到厨房水槽里”传统的 WM 会先预测杯子在哪个位置、桌面状态会怎么变但 WAM 做的事是根据当前的观测桌子场景的视觉图像和语言指令“把红色杯子拿到水槽”直接解码出一系列高层动作描述或低层动作参数比如“伸向杯子 → 抓取 → 抬起 → 移动到水槽 → 放下”。在实现上不少 WAM 借鉴了语言模型里的“下一个 token 预测”思路把动作序列当成一种“动作语言”来建模。典型做法是将视觉观测编码为视觉 token将语言指令编码为语言 token把“动作序列”当作需要生成的目标序列用自回归方式逐步生成。这样做的好处很直接它不需要显式地构建完整环境地图也不需要传统规划器来算路径而是直接从数据中学出“看到什么、做到什么”的映射关系。坏处也很明显——它对训练数据的覆盖度要求极高如果训练数据里没有“红色杯子 厨房水槽”的组合模型生成的规划就可能跑偏。WAM 在应用上经常被当作一个“任务规划器”使用它输出的动作序列可以交给底层控制器执行也可以再传递一层策略网络做细化。在一些项目里WAM 还承担着“技能选择”的角色相当于在多个预设技能库中做挑选和排序。2.3 VLAVision-Language-Action Model一步到位看语言指令直接动手VLA 是当前具身智能领域最“出圈”的方向原因是它把“决策”这条路走到了极致输入图像和语言指令输出机器人的动作参数中间不做显式规划。把“感知、推理、动作”全部打包进同一个网络。VLA 的模型结构大多基于多模态大模型比如 ViT 视觉编码器 LLM 语言主干 动作解码器做扩展。训练时通常先在大规模互联网图文数据上做预训练让模型获得通用的视觉语义理解然后在机器人采集的数据集上做微调学习“视觉语言→动作”的映射。这个先预训练、后微调的范式是 VLA 相比传统模仿学习方法最大的优势——它让模型带着“世界常识”进入机器人场景而不是从零开始学抓取。说到 VLA有两个方向需要区分端到端 VLA直接输出低层动作比如 7 自由度机械臂的关节角度增量、末端位姿 delta全程一个模型搞定。代表工作如 Google 的 RT-2。分层 VLA先输出高层子目标或动作标签再交给底层策略执行。比如身处“移动操作”场景时VLA 可能先生成“走到底座旁、弯腰、伸手抓取”这样的高层行动序列再由底层模块细化成具体控制指令。我个人的经验是端到端 VLA 在仿真和单一固定场景里表现很惊艳但一上真机就容易被各种边缘情况击穿分层 VLA 的工程可控性更好适合产品级落地但中间的标签设计和子目标建模非常费功夫。而且现在很多 VLA 项目已经不只处理“抓取”这种单点任务而是往长程操作延伸——整个操作过程可能有几十步模型需要保持任务记忆和空间推理能力。比如市面上陆续有人把 VLA 用在辅助驾驶场景对视觉输入做驾驶动作决策、室内清扫、上菜服务等方向本质上都是把“视觉理解 动作执行”压缩在一个模型里解决。3. 横向对比从“看”到“想”再到“做”的关键差异3.1 一张表看清三种模型的根本差别为了让大家有直观感受我做了一张对比表。这张表是我基于目前主流论文方案和开源项目的总结不是谁家的标准定义但对做技术选型很有参考价值对比维度WM世界模型WAM世界动作模型VLA视觉语言动作模型核心任务状态预测 / 未来帧预演动作序列规划视觉语言 → 动作映射输入当前观测图像/点云/状态 动作当前观测 任务描述语言/目标当前影像 语言指令输出预测的下一个状态或未来帧高层动作序列 / 子目标序列低层动作参数位姿、关节角等是否需要显式规划器不需要但可为规划器提供预测可作为规划器替代品不需要模型内部直接决策训练数据视频序列为主自监督需要带任务标签的动作序列数据大规模图文预训练 机器人动作微调数据泛化能力对环境状态变化较敏感但对任务目标不敏感对任务目标理解较好依赖数据覆盖度依赖预训练对已知任务泛化好新任务需微调落地难度中预测任务相对可控中高动作序列的高层语义难定义高真实数据获取成本大、模型推理负载高典型应用自动驾驶未来状态预测、仿真验证任务规划、技能选择机械臂抓取、移动操作、辅助驾驶这张表里藏着一条很重要的线索VLA 和 WAM 虽然都涉及“动作”但它们的抽象层级完全不一样。WAM 输出的是“打算做什么”距离底层电机还有距离VLA 输出的是“具体怎么做”直接可以接控制层。这也是为什么很多团队会把两者串联使用——先用 VLA 理解顶级任务再用 WAM 做中层规划最后底层交给传统控制分工明确。3.2 核心差异是“预测未来”还是“直接行动”从“看”到“想”再到“做”有三种方式定位各自的关键词WM 的关键词是“预测”。它不需要知道任务目标只需要把环境演变的规律学对。打个比方WM 像天气预报——它只告诉你明天可能下雨不告诉你该不该带伞。正是这种“不带目的”的通用性让 WM 在很多需要“推演”的场景里特别有价值。比如做机器人安全评估时可以用 WM 在仿真里模拟机器人动作对环境的影响提前发现碰撞风险。WAM 的关键词是“规划”。它比 WM 多了任务意识但还没有触及物理控制细节。它像你手机上的导航软件——告诉你“前方向右转、随后直行 200 米”但不会替你踩油门。WAM 适合做机器人任务编排和技能调度目前很多具身智能公司的“大脑小脑”架构里那个“大脑”干的事就更接近 WAM 的定位。VLA 的关键词是“执行”。结构上简化为“看到什么就做什么”把逻辑推理和动作执行压缩进同一个网络。它像一位熟练的司机看到路口有行人就会自然踩刹车不需要先做一套“行人轨迹预测 刹车路径规划”的显式流程。这个“反射式”的优势正是 VLA 回应速度更快、动作更连贯的原因。这三类模型之间存在着天然的互补关系。一个有完整大脑的机器人系统理想状态应该是用 WM 构造环境认知用 WAM 推演行为路径用 VLA 落实最终动作。把三者对立起来看待是比较典型的误区。3.3 能力边界没有“全能模型”只有“场景适用”我在前面提到了负数例子这里再展开说说。WM 最大的问题在于“预测到行动”的鸿沟。你预测出了环境下一时刻的状态但具体该执行什么动作才能达到你想要的下一状态仍然需要额外求解。很多团队把 WM 训练得很漂亮却很难直接驱动真机原因就在这。WAM 的边界在于高层动作库的设计。如果你把一个复杂任务拆成了多个子动作但这些子动作本身的定义不清晰模型输出就很容易“语句通顺但语义跑偏”。我试过在移动机器人上用 WAM 做目标导航一开始子标签定义得比较粗比如“移动到目标点”结果模型总在决策出“绕圈”的规划后来把子标签细化为“向前移动 0.5 米”“左转 30 度”之后输出才稳定下来。VLA 的问题则是“数据黑洞”和“解释性弱”。端到端 VLA 的训练数据需要覆盖足够多的场景、光照、物体形态、语言表达否则真机上就会“沉默”或“乱动”。而模型为什么输出这个动作研发人员很难给出准确解释这对于安全敏感场景如带人的医疗机器人、公共场合服务机器人是巨大的阻力。4. 落地实操复现、选型与避坑经验4.1 想快速上手 VLA先走这条路线如果你是想在项目里快速验证 VLA 模型的可行性我的建议是不要一开始就自己收集数据、从头训练。成本太高周期太长而且大概率效果不稳定。更务实的路线是用一个开源的 VLA 预训练模型比如各大厂放出的抓取/操作模型权重做基础在仿真环境如 Isaac Sim、MuJoCo里加载模型验证它在你目标场景中的表现针对任务收集小规模真实数据做轻量级微调上真机测试重点观察模型在未见过物体、未见过光照环境下的鲁棒性。我在仿真里试过不少 VLA 模型有一个很深刻的印象是仿真环境里模型表现好坏和真机环境的表现相关性没有想象中高。仿真里的光照、物理引擎、物体纹理都太“干净”了模型在仿真里顺风顺水一上真机就变形。因此如果你条件允许建议尽早让模型跑真机不要过度依赖仿真指标。4.2 做 WM 和 WAM数据与标签设计是真正的门槛WM 的训练数据相对容易获取——大量视频序列就行不需要人工标注非常适合“自监督”。但这里有一个隐藏坑视频数据在机器人场景里往往存在“视角单一”的问题如果训练视频都是在同一场景、同一视角下采集的模型学到的世界动态规律会有严重过拟合换个环境就失灵。我当时拿自家办公室采集的数据训练 WM放到工厂环境里预测下一帧基本等于瞎猜。WAM 则更依赖任务标签的设计。我建议可以把标签抽象成两层宏观层目标导向标签比如“把水杯放到托盘”微观层动作原语标签比如“接近水杯”“抓取”“移动”“释放”。实际训练时如果直接让模型从宏观标签生成微观动作难度会很大更稳妥的做法是先做一个“任务分解器”把宏观标签拆解成微观标签序列再由 WAM 基于微观标签输出动作参数。这种“先拆后做”的模式工程可控性比端到端高出一大截。4.3 算力需求与推理延迟不能回避的现实问题三种模型的算力需求差别很大直接影响部署方案。WM 因为要在隐空间做预测推理消耗相对可控很多场景可以跑在边缘计算设备上。如果你是做实时性要求高的应用建议优先考虑模型量化、知识蒸馏等手段压缩推理时间。VLA 模型因为内部通常是一整个多模态大模型参数规模从几亿到上百亿不等推理压力非常大。在 40 系显卡上跑一个 7B 参数的 VLA 模型单次推理延迟可能在几百毫秒到一两秒之间。这种延迟对“机械臂抓取”这种任务来说也许还能接受但对“移动机器人避障”这种高频决策任务就很致命。我见过有团队把 VLA 用于移动机器人导航调度模型每秒钟推理一次机器人走走停停体验非常糟糕。所以如果你的项目对实时性有硬要求比较合理的设计是让 VLA 只做低频的任务级决策比如每隔几秒根据当前画面判断下一步目标底层的高频控制交给传统控制器或更轻量的策略网络来做。不要试图让一个大模型每毫秒都输出控制指令去驱动电机那是违背工程现实的。4.4 资源有限的团队应该如何选择模型方向给一个比较主观但实用的建议如果你做的是仿真机器人或者RoboCup / 机器人竞赛这种场景可以大胆用端到端 VLA 或 WAM因为环境和任务边界清晰快速试错成本低如果你做的是工业机械臂稳定抓取/分拣建议重心放在 VLA 的动作满足层但务必保留一个传统的定位模块做兜底别让 VLA 独自承担精度要求高的空间计算如果你做的是自动驾驶/移动机器人预测类场景WM 和 WAM 的价值更大因为它们可以做长期推演和风险预判而不是仅仅完成“当前帧下一步动作”的映射。说到底“模型选型”不是选最火的而是选最匹配你场景约束的。数据、算力、实时性、安全要求每一条都可能推翻“别人验证有效”的方案。5. 常见问题与排查技巧实录5.1 为什么模型在仿真里成功率高一上真机就废这个问题几乎每个做具身智能的人都会遇到。原因很集中Sim-to-Real Gap仿真到真实的鸿沟仿真环境里的物理引擎、光照、摩擦系数和现实差距仍然很大观测噪声真机视觉传感器受抖动、反光、遮挡影响输入分布和训练数据分布不一致执行误差真机电机的噪声、延迟会让 VLA 输出的动作在执行时偏离预期。排查思路通常分三步第一检查真机观测数据是否和训练数据分布差异过大如果是考虑在训练时加入随机化光照、视角、颜色扰动等来增强鲁棒性第二简化任务环境排除多余的视觉干扰第三把 VLA 的输入画面可视化人工判断模型“看到的”和训练时“看到的”是否一致。很多时候你会发现模型根本没看见目标物体那问题就不在模型而在视觉传感器配置。5.2 训练 VLA 一直过拟合应该怎么办过拟合在 VLA 小样本微调中极其常见。我踩过最深的坑是用几万条轨迹数据去微调一个几十亿参数的大模型结果验证集上表现很好换一个布局相似的场景就完全失效。这说明模型把场景特征和动作映射绑死了没有学到任务的不变量。解决方法一是加大数据增强对图像做裁剪、旋转、颜色扰动、遮挡模拟二是引入少量场景外数据做混入训练三是降低模型参数量或冻结部分层只微调动作头。千万别迷信“更多参数 更强泛化”在机器人场景里数据量远比参数规模更容易成为短板。5.3 WM 预测出来的未来帧“糊成一团”是模型能力不够吗不一定是。很多 WM 的预测模糊根源在于它学的是“平均趋势”——模型同时面对多种可能的分支物体可能向左也可能是向右预测结果是所有分支概率的平均当然会显得模糊。这就好比天气预报说“明天有 50% 可能性下雨”你不知道到底带不带伞。解决思路有三种把确定式预测改成随机式预测引入随机隐变量让模型输出多种可能的未来分支降低预测粒度从像素空间转成关键点或语义图空间让模型预测目标的离散属性而不是逐像素颜色引入条件信息用动作、任务目标等条件约束预测分支减少不确定性。5.4 模型能跑但速度太慢从哪些方向做优化优化顺序建议先软件后硬件脚本层面把模型推理改成 TensorRT / ONNX Runtime 部署通常能带来数倍加速模型层面做量化FP16 - INT8对一个 7B 参数的 VLA 模型来说INT8 量化能把显存占用降低到原来的四分之一左右架构层面考虑把大模型拆成“视觉编码器 语言主干 动作头”三段分别用不同规模的网络实现视觉编码器用轻量模型、语言主干用小模型动作头用 MLP 即可硬件层面边缘端可以考虑使用带 NPU 的板卡服务器端则优先保证推理批处理效率别一个请求独占整卡。这些优化手段没有一项是“银弹”每次改动之后都需要在真机或仿真里重新验证精度和耗时做一次平衡取舍。5.5 模型选型时应该看重哪些评估指标最后说一个很实际的话题怎么评估一个机器人基础模型的好坏。很多人一上来就看“任务成功率”但单看成功率会踩坑——成功率 90% 的模型可能在某一类特定物体上成功率只有 30%只是碰巧这一类物体在测试集中占比不高。更合理的做法是分层看指标任务成功率整体完成任务的概率分项成功率不同子任务、不同物体、不同场景下的成功率矩阵动作连贯性/平滑性动作轨迹是否存在剧烈抖动、停顿、回退推理延迟从输入到输出动作的端到端时间泛化鲁棒性在未见过场景、未见过光照、未见过物体形态下的表现。我的习惯是每次模型迭代后都跑一个固定的 benchmark 集用表格记录各项指标的变化。这样模型做任何修改哪怕只是换了一个视觉编码器都能快速定位是变好了还是变差了变差在哪一类样本上。最后想聊两句这三种模型名字听起来各占一个方向但它们之间其实是继承和演化的关系。从 WM 到 WAM 再到 VLA本质上是在“感知—规划—控制”这条经典链路上不断把更多环节“大模型化”把更复杂的环境理解能力塞进同一个模型里。我个人的体会是别把一个模型的价值押在“它是不是 VLA”或者“它是不是世界模型”这种标签上而是看它在你真实场景里解决掉多少问题、引入了多少新问题。挑最合适的那一个组合着用才是工程上最务实的选择。如果你正准备入这行我建议可以按“WM 打底理解环境、WAM 拆解任务流程、VLA 做最终动作输出”的路线去搭一套最小系统跑通之后再针对痛点做替换和升级。方向比参数重要数据比模型重要先把链路跑起来再说。