1. 从“看”到“想”再到“做”：机器人模型三兄弟到底在争什么

做机器人决策系统这几年，圈子里一直有个争论：想让机器人真正干活的“大脑”应该长什么样？有人押注世界模型（World Model，简称 WM），觉得只要模型能把环境动态学明白，规划就是水到渠成的事；有人提出在WM基础上叠加动作预测，搞出了WAM（World Action Model）这种带动作头的世界模型；还有人直接走端到端路线，把视觉、语言、动作全塞进一个大模型里，这就是被炒得最热的VLA（Vision-Language-Action Model）。

这三个概念放在一起很容易让人头晕，尤其是刚入行的朋友，经常把WM和VLA混为一谈，觉得反正都是让机器人“看懂世界然后行动”的大模型。但我在实际项目里折腾过一段时间后，可以明确告诉你：这三者的定位、训练方式、适用场景差别非常大，选错了路线，轻则模型效果拉胯，重则整个项目推倒重来。

这篇内容不打算复述论文里的公式推导，而是想以一个实际做机器人决策系统开发的视角，把WM、WAM、VLA这三类模型掰开揉碎，讲讲它们各自解决什么问题、内部是怎么工作的、落地时候有哪些坑，以及面对一个具体任务时到底该怎么选。无论你是刚接触具身智能的研究生，还是在工业界做机器人软件架构的工程师，这篇文章应该都能帮你节省不少调研时间。

顺便说一句，题目里“从「看」到「想」再到「做」”这个说法，其实是这三类模型能力边界的真实写照：WM擅长“看”（感知和理解环境动态），WAM尝试“想”（在预测未来时内生出动作意图），VLA天生就是“做”（直接输出动作指令）。但真相没那么简单——它们之间并不是严格的递进关系，而是各有各的适用边界，下面我们一个个拆。

2. WM、WAM、VLA的底层逻辑与核心差异

2.1 WM：先把世界运行的“物理规律”塞进网络里

世界模型这个概念其实很早就有，但在深度学习时代被推到了新高度。老一代搞过机器人控制的朋友应该熟悉系统辨识和状态估计，那其实就是最朴素的“世界模型”——用状态空间方程描述机器人本体和环境。现在的WM基本上是把这套思路换成了神经网络来表达，而且规模更大、表征能力更强。

WM的核心任务是学习环境的状态转移函数。给定当前状态和动作，模型要能预测出下一时刻的状态。听起来简单，但真正做起来有几个坎：

状态怎么定义是个大问题。视觉输入的话，是直接用像素做状态，还是先抽象成潜在向量？如果直接用像素，预测下一帧图像的计算量会大得吓人，而且图像的细节对决策很多是无用的。所以主流WM（比如Dreamer系列）都走“潜在空间预测”的路子：先用一个编码器把观测图像压成紧凑的向量，在向量空间里做预测，再用一个解码器把预测结果还原成可理解的观测。这个设计和自编码器非常像，但多了对动作条件的建模。

训练目标也很有讲究。WM不是直接学“哪个动作好”，而是学“给定动作会发生什么”，本质上是自监督学习，只需要大量的“状态-动作-下一状态”三元组数据，不需要人工标注动作好坏。这一点在真实机器人场景很关键，因为动作标签好采集（记录执行的动作就行），但“好/坏”标签很难大规模标注。

有了转移函数之后，机器人就能通过“想象”来做规划了。最经典的用法是模型预测控制（MPC）：在当前状态出发，随机采样N条未来的动作序列，用WM分别预测每条序列对应的未来状态，再用一个奖励函数评估这N条轨迹的好坏，挑最好的一条执行第一步，到下一时刻重新规划。这个流程在计算上比强化学习在线探索要稳得多，因为不需要真机试错，所有“试错”都在模型内部完成了。

不过话说回来，WM也有明显的短板。它严格来说不通语言，你给我一句“把红色杯子放到托盘右侧”，WM没有直接入口去解析这句话。它的专业是理解“杯子从A挪到B之后，托盘上的空间会产生什么变化”这种底层物理因果。所以单纯靠WM做高层任务规划，很难跟人类的指令对接上。

2.2 WAM：在世界模型上长出一只“动作的手”

WAM（World Action Model）这个概念相对新一些，但思路很朴素：既然WM已经在潜在空间里学会了状态转移，那能不能顺便让它在预测未来的时候，把“应该采取什么动作”也一起预测出来？这样一来，世界模型就不只是被动地“想未来”，而是主动地“想怎么做”。

我自己理解WAM的关键设计在于“联合预测”和“动作头”的引入。普通WM的输入端有当前状态和动作标签，输出端是下一状态；而WAM的输入可以是状态和任务描述（比如目标图像、目标状态向量），输出端除了预测未来状态，还多了一个动作分支，用来直接输出达成目标所需的动作序列。

打个不完全准确的比方：WM像是一个会做物理推演的物理学家，你给他初始条件和控制输入，他能告诉你系统接下来怎么演化；WAM则更进一步，你只告诉他“我想要这个结果”，他自己就能反推出一连串控制指令。

WAM的训练数据要求比较高，因为你需要同时提供“状态转移”的监督信号和“动作结果”的监督信号，相当于得把整个数据集里的每一条样本都标注清楚“当前状态+期望目标→执行动作→结果状态”。这在仿真环境里还好办，如果换成真实机器人场景，数据采集的成本会明显增加。这也是为什么目前WAM的公开工作多集中在仿真和半仿真环境里。

从应用角度看，WAM最适合的场景是“目标明确但路径灵活”的控制任务，比如机械臂从一堆零件中挑出特定型号并装配到指定位置。这类任务如果直接用端到端VLA，可能因为语言描述太复杂而过拟合；如果用纯MPC加WM，又需要你手动设计密集的奖励信号。WAM刚好卡在中间：目标用图像或向量表达，动作由模型内生成，奖励函数不需要特别精细。

2.3 VLA：把语言、视觉、动作揉进同一个大模型

VLA是这三者里商业热度最高的，毕竟搭上了大语言模型（LLM）的顺风车。基本架构大家都比较熟悉了：视觉编码器负责把摄像头画面变成视觉token，语言指令通过LLM的tokenizer变成文本token，两者拼在一起送进大模型的Transformer层里做多模态融合，最后在输出端解出动作token或者离散化的动作id，再经过动作解码器还原成真实关节/末端速度指令。

VLA最大的优势是继承了LLM的“常识推理”能力。比如你跟它说“桌面比较乱，先把所有文件推到一边，再放杯子”，它能在高维语义层面理解任务分解，然后输出一个初步的动作序列。这在以前的机器人流程里是不可想象的——传统视觉伺服或者模仿学习，哪能处理“把文件推到一边”这种含糊指令。

但VLA的坑也很多，最典型的就是“动作精度不够”。LLM擅长的是离散符号处理，但机器人控制需要的是连续、高频、高精度的数值输出。现在的VLA大多采用动作token化，把连续的动作空间离散成几百到几千个bin，本质上是有损压缩的。你要抓一个特定的螺丝钉，位置偏差2毫米可能就失败了，而动作离散化带来的误差可能远超这个量。所以现在很多工业级的VLA落地，都会在VLA后面再接一层传统的运动规划器或者PID控制器做细粒度修正，而不是把VLA的输出直接发给电机。

部署成本是另一个绕不开的话题。VLA模型动辄几B到几十B的参数，推理一次的动作生成延迟通常在100毫秒以上，这对于要求1kHz控制周期的精密操作来说完全不够用。目前不少团队的折中方案是异步架构：VLA跑在远程GPU服务器上，以5-10Hz的频率输出宏观的“动作意图”（比如目标点位、轨迹关键帧），本地实时控制器在两次意图之间做插值和微调。这种“远程大脑+本地小脑”的架构在NVIDIA Alpamayo这类面向车载/辅助驾驶场景的开源VLA推理模型里也看得到，只是把本地控制换成了车辆底盘控制。

2.4 三者的本质差异：信息流结构决定能力边界

搞到这一步，可以给三者画个清晰的边界了，我用一张表总结：

这张表不是要划分高下，而是告诉你三者定位完全不同。WM像是一个高精度的“物理引擎”，它不懂人话，但懂物理规律；WAM像是一个“目标驱动的动作生成器”，它在物理引擎的基础上多了反推动作的能力；VLA则更接近一个“通晓语义的任务规划器”，它的强项是理解复杂指令和环境语义，弱项是实现层的高频控制。

在我实际测试过的几个开源项目里，感受最明显的是：如果任务环境复杂但语义明确（比如“倒水时不要洒出来”），VLA明显更靠谱；如果任务需要高精度且目标可以用图像描述（比如“把销钉插入孔径3mm的孔”），WAM的表现可能比VLA更稳；如果纯粹做运动规划而目标是“避开障碍到达目标点”，WM加MPC的经典组合反而最轻量高效。

3. 从零搭建一个对比实验：拿同一任务考验三类模型

理论说了一堆，不如直接看实操。我给大家拆解一个我实际跑过的对比项目：目标任务是让一个6自由度机械臂完成“从桌面夹取一个蓝色积木，放到右侧的红色框内”，这三个模型分别怎么实现、效果怎样、有哪些参数要调。

3.1 环境与数据：先用仿真把流程跑通

先说环境。我用的仿真环境是PyBullet加自建的桌子任务场景，原因是PyBullet部署简单、URDF支持好，而且能方便地拿到状态的ground truth，对调试WM和WAM非常友好。如果你有条件用MuJoCo或者Isaac Lab，原理一样，只是物理参数和渲染管线不同。

数据层面分三条线：WM的数据好搞，纯状态转移数据，不需要标签。我采集了2万条“状态+随机动作+下一状态”的样本，状态向量是“机械臂关节角+蓝色积木位置四元数+红色框位置”，动作向量是6维的关节角速度。随机动作加了一点高斯噪声，保证状态空间被充分覆盖。

WAM的数据需要额外加目标条件，我在每条样本前面附带了目标状态向量（红色框的位置和朝向）。为了让模型学会“完成夹取放入”这个完整技能，数据不是简单随机采样，而是用脚本化的专家策略生成演示轨迹，比如先用预编程的路径移动到积木上方，下降夹取，再平移放到框里。每条轨迹都记录了完整的状态、动作、下一状态序列。

VLA的数据形式完全不同，需要图像、语言指令和动作的 triplet。语言指令我做了几条模板的自动扩展，比如“拿起蓝色积木放到右边红色框里”“把蓝色方块搬运到红色区域内”。图像用PyBullet的渲染器输出，分辨率压到224x224。这个数据集的采集成本比WM高一个量级，因为每一帧都要保存图像，而且动作标签需要对齐到控制频率。

3.2 WM实现：MPC加奖励函数的老派路线

WM实现我直接用了DreamerV3的简化思路，但为了不把文章写成长篇大论，说一下核心参数和坑。编码器用的是4层CNN把224x224的观测压成256维潜在向量，状态转移用GRU结构，预测头输出状态的高斯分布均值和方差，损失就是负对数似然加上KL正则项。

规划部分用随机采样MPC。每步选动作时，我随机采样512条长度为10步的动作序列，每条序列用WM滚动预测未来状态，然后用一个手写的奖励函数打分。这个奖励函数是让我头疼的部分：最初只设了“夹爪与目标积木距离越小越好”，结果机器人很聪明地把手臂移到积木正上方，然后往下压，积木被压飞了，距离反而小了。后来我加了“积木与红框中心距离”和“夹爪闭合状态”等惩罚项，又出了一堆新问题。调试了好几天，才把奖励权重调到一个能用的状态。

这里有个心得：WM本身不产生行为，行为的质量完全取决于你喂给它的奖励函数。任务稍微复杂一点，奖励函数设计的工作量不会比传统控制少太多。这也是WM落地时最容易被低估的隐性成本。

最终效果：在仿真里，成功率大概在78%左右，单步规划耗时约30ms（这个值取决于GPU，我用的是一张消费级显卡），算下来每步都有不错的实时性。但失败样本里有一半是最后放积木时的位置偏差大于2cm，说明WM的预测精度在长时程推演后会累积漂移。

3.3 WAM实现：让模型学会“想”出动作序列

WAM在数据上是WM的扩展，网络结构也类似，但在输出端我做了一个改动：除了状态预测头，还加了一个并行的动作预测头。训练时用多任务损失：状态预测部分用预测值与真实值的负对数似然，动作预测部分用动作的均方误差。

测试下来，WAM在训练过程中学得比WM要慢一些，因为动作监督信号本身就更复杂，尤其是指令性目标（我要把积木放到右边红框）和动作序列之间不是简单的一一映射。但收敛之后，效果还是挺不错的。

我实测的一个小亮点是：WAM在推理时不需要每步像MPC那样在线采样，而是输入“当前状态+目标状态”后，直接一步输出5步的动作序列，然后机器人执行前2步，再重新调用模型更新。这种“模型预测控制+模型直接输出动作”的混合模式，既避免了MPC逐帧采样的计算开销，又保留了滚动更新的鲁棒性。

成功率做到了86%，比WM路线高出8个点。分析原因，主要是WAM的预测目标里融合了动作信息，使它在决策时能“看到”动作的效果，而不是像WM那样只管状态推演、把动作好坏全交给外部奖励函数。缺点也有，就是需要额外的专家演示数据，而且目标状态如果换了表达方式（比如这次是红框，下次是绿色框），需要重新跑一轮微调。

3.4 VLA实现：接入开源模型并做LoRA微调

VLA部分我没有从头训练大模型，说实话个人和中小团队也没这个资源。我直接接了一个开源的VLA基础模型（类似OpenVLA的路线），然后用自采的数据做了轻量级微调。做法是把数据集中图像和指令封装成对话模板，动作离散化成256个bin，用标准的next-token-prediction损失微调模型后部的LoRA层。

这里要特别提一下在LibrO这类多任务基准上测试VLA的过程。LibrO有固定的任务集、场景分布和评估协议，很多初学者直接把模型放上去跑，发现指标上不去，就开始疯狂加数据。我踩过的坑是：LibrO的评估对语言指令的格式非常敏感，同一个任务，指令用“pick up the blue cube”和“grab the blue cube”，结果能差十几个点。所以跑基准之前，先看看他们评估脚本里用的是哪几个模板，把你自己的微调数据里的指令风格对齐过来，事半功倍。

在精度控制上，VLA直接输出的离散动作没法直接用于真实机械臂控制。我在VLA后面加了一层末端轨迹平滑器和逆运动学解算，把VLA输出的“宏观动作意图”转化成6个关节的角速度指令。这个过程不是免费的，VLA一次推理大概120ms，加上后续运动学解算，整体控制频率只能做到10Hz左右，只适用于低速、粗放的操作任务。

最后我的测试结果是：VLA在LibrO基准上的零样本成功率在52%左右，LoRA微调之后提升到71%，但和WM/WAM的技能级成功率相比，它更擅长的是“理解”而非“执行”。如果你让我用一句话总结这个对比实验的结论：把语言理解能力最强的VLA当动作级控制器用，短时间内很难打赢专用模型；但把WM/WAM当高层规划器用，在复杂任务泛化上又不如VLA。这不是谁替代谁的问题，而是系统设计中不同层级的取舍。

3.5 训练与部署的经验数据

训练环节有一些具体的参数和硬件数据值得分享。WM和WAM的参数量都在100M以下，用一张NVIDIA RTX 4090级别的显卡，跑2万条样本大概需要4小时就能收敛。VLA基础模型参数在7B级别，即使只微调LoRA，一张4090的显存也勉强够用（需要开梯度检查点），一次微调跑10个epoch大概花了两天时间。

推理时的硬件差异更明显。WM和WAM可以在机器人本地的Jetson Orin NX这类边缘设备上跑，单步推理延迟都能控制在20ms以内；VLA则必须依赖远程GPU服务器，延迟受网络波动影响很大。如果你的机器人是移动式的，网络不稳定时VLA决策就跟不上节奏。这倒不是说VLA不能上端侧，而是目前7B级别的VLA在端侧跑还不现实，用更小的量化版本又会进一步牺牲精度。

部署架构上我最终采用的是“VLA远程决策+WAM本地规划+实时控制器”三层结构：VLA负责根据图像和自然语言指令生成宏观任务分解（比如“移动到积木上方→下降→夹取→平移→释放”），WAM负责把每一步宏观意图展开成具体的动作序列，实时控制器（PD加前馈）负责执行底层关节指令。三者通过ROS 2的话题通信，VLA和WAM跑在不同的进程里，通过网络或共享内存交换数据。实测这个结构的成功率能达到88%，比任何单一模型都好——这也验证了我的一个看法：未来的机器人智能系统大概率是混合架构，而不是一个模型通吃所有。

4. 模型选型与落地中的常见误区

很多朋友私信问我最多的问题就是“这三个模型到底哪个最强”，说实话这是个伪问题。我在项目里跑了一圈之后，总结了几个常见的选型误区和避坑经验，希望能帮大家少走点弯路。

4.1 误区一：把VLA当万能控制器

VLA在语义理解上确实最强，但如果你直接把动作输出接到真实机器人上，大概率会翻车。核心原因前面说过，动作离散化和推理延迟是大问题。我见过不止一个团队，在演示视频里VLA表现得很惊艳，但一上真实产线就露馅——抓取成功率从仿真里的70%掉到现实里的20%。

如果一定要用VLA做控制器，我的建议是加一层中间表示，比如输出“目标末端位姿”而不是关节角。这样即使推理延迟高一点，底层的运动规划器也能在目标点之间做插值。还有一个更实用的思路：让VLA输出机器人的“可执行动作模板ID”，比如“接近积木”“夹爪闭合”“抬起”“移动”这些预定义动作原语，由底层的技能库去执行。这样可以大幅降低VLA的输出难度，精度也能保证。

4.2 误区二：忽略WM的奖励函数设计成本

很多人觉得WM“不要奖励信号”，因为它靠自监督训练。但注意，训练阶段确实是自监督，可是用WM做规划的时候一定需要奖励函数来评估未来轨迹的好坏。这个奖励函数的设计难度，经常被大家忽略。

一个真实的案例：我同事在做一个“倒水”任务时，同WM做MPC规划，奖励函数定义为“水杯倾斜角度接近目标值、移动轨迹平滑、终点位于目标杯上方”，结果仿真跑得非常好，一上真机就发现水洒得到处都是。原因很简单，仿真里的“洒水”物理没有精确建模，奖励函数根本体会不到“洒”这个概念。后来他换用WAM直接从人类演示轨迹中学习倒水动作，反而效果更稳。

所以如果你面临的任务有复杂的物理交互，我建议优先考虑WAM或者VLA这种直接从数据中学习动作的路线，而不是费大量精力去设计一个完美的奖励函数。WM更适合那些可以用低维状态直接描述、物理交互简单的任务。

4.3 误区三：在真机上盲目做端到端训练

VLA的终极形态是“图像进、动作出”，很多人一上来就想在真机上收集几万条数据直接开训。但这个路线的坑比想象中多得多。真机数据采集慢、成本高，一个简单的抓取任务，采1万条有效轨迹可能要连续跑一周，而且机器人本身会磨损。更麻烦的是数据分布不均衡，机器人总是朝一个方向抓取，模型很容易学会“盲抓”，换个位置就废了。

我的建议是：真机数据只做微调，预训练或大数据量的训练尽量在仿真里完成。仿真到现实的迁移（Sim-to-Real）虽然也有一堆域差问题，但至少有domain randomization、joint space noise injection这些成熟手段可以缓解。真机部署时再用少量数据做适配性微调，这在很多开源项目里都有成功先例，是比较稳妥的路径。

4.4 落地时的工程彩蛋：延迟分解与缓存策略

最后分享一个工程层面的小技巧。当VLA在远程GPU上推理时，通信延迟和推理延迟是两码事。我用ROS 2测试时发现topic传输延迟有时能占到总延迟的30%。解决办法是把VLA的输入图像压缩到更小的分辨率，并只在关键帧触发推理，局部路径用WAM来规划。这样VLA甚至能以2Hz的频率工作，但整体系统依然能平滑运行。

这个做法在NVIDIA Alpamayo面向辅助驾驶的VLA推理设计中也有体现，他们把VLA的推理频率控制在10Hz左右，但利用过去帧缓存和异步执行来保证控制的实时性。对我们做机械臂的来说也一样：别让VLA成为每帧都会调用的高频函数，把它当做一个“任务意图刷新器”用，系统的稳定性会好很多。

5. 混合架构：三者在同一系统中的各自位置

聊到这里，很自然的结论就是：与其纠结选WM还是WAM还是VLA，不如想想怎么把它们组合到一个系统里，各用所长。我越来越多的经验表明，“分层混合架构”才是走向实际应用性价比更高的方案，VLA做眼和脑，WM做物理推演，WAM负责生成动作轨迹，再往下接传统控制。

拿我之前做的一个“桌面整理”任务来举例。系统接收的自然语言指令是“把桌面上的螺丝钉都收到蓝色盒子里”。VLA首先识别图像，找到画面里所有的螺丝钉和蓝色盒子，输出了一个高层任务序列：逐个螺丝钉执行“接近、夹取、移动、释放”。这个阶段里，VLA更像是一个“任务编排器”，它不需要知道机械臂的关节角，也不需要计算避障轨迹。

任务序列生成后，交给WAM去规划每个子动作的具体轨迹。WAM的输入是“当前状态+目标螺丝钉的位置”，输出是一段关节空间的轨迹点。由于WAM是在仿真里学的，它在应对稍微变化的布局时也能泛化，成功率表现已经可以接受。

最后，底层实时控制器负责把WAM输出的轨迹点转成力矩指令，并处理碰撞避免、奇异点规避等约束。如果遇到VLA和WAM都没有预料到的突发情况（比如螺丝钉滚到桌子边缘了），底层控制器会立即触发安全停止，同时把异常反馈给系统，由VLA重新规划新方案。

这个架构里的每个模型都不完美，但组合起来以后，单个模型的问题被其他层掩盖了不少。我在这个系统上跑了上百次测试，成功率稳定在90%左右，而用任何单一模型都达不到这个水平。所以我的结论是：作为从业者，不应该陷入“哪个模型好”的站队思维，而是应该设计一个“让每个模型做自己最擅长的事”的系统。

6. 写在最后的实操心得

如果这篇文章只能留一句话，那就是：WM、WAM和VLA不是替代关系，而是分工关系。我见过太多人拿着VLA的名头去申请项目，却发现实际部署时处处是坑；也见过有人迷信WM的“预测一切”能力，最后被奖励函数设计折磨到放弃。对我来说，最好的实践是：先搞清楚任务的瓶颈到底是“看不懂环境”“想不好动作”还是“执行不了指令”，然后针对这个瓶颈选择合适的模型组合方式。

实操层面，再强调几个我在这个过程中沉淀下来的细节：

• 数据采集时，仿真环境的物理参数要加随机化，否则换一架同型号机器人就可能失效。

• 评测模型时，用多个指标而不是只看成功率：轨迹平滑度、最大关节力矩、碰撞次数、任务时长都很重要，很多模型成功率看着不错，但轨迹歪歪扭扭，根本没法上真机。

• 如果你是在校生或刚起步的团队，优先跑通WM路线，因为它在数据成本和硬件要求上最低，能帮你快速理解具身智能的核心问题；再逐步迭代到WAM和VLA，不要一上来就挑战最大的模型。

最后想说的是，机器人模型这个领域更新极快，今天的最佳实践过半年可能就显得笨拙了。但“看、想、做”这个分层框架大概率还会持续生效，因为它是从控制理论时代就沉淀下来的系统化思想。无论模型怎么换，一个结构清晰、职责分明的系统，永远比一个什么都想干的“缝合怪”走得更远。