1. 一个被问烂了的问题背后其实是两个完全不同的世界这两年只要聊机器人控制几乎绕不开一个场景学术会议的茶歇、技术群的深夜讨论、甚至产品评审会上总有人抛出类似的问题——“既然Transformer这么强为什么波士顿动力还在用老一套控制理论”“隔壁组用强化学习让机器狗学会了后空翻为什么机械臂抓个瓶子还是用传统规划”我最早看到都是机器人控制为什么走路用RL干活却用Transformer这个说法时第一反应是这问题本身有歧义。它把控制当成了一件铁板一块的事好像机器人身上所有的决策都可以塞进同一个模型里。但真正做过机器人系统的人都知道腿足机器人的运动控制和机械臂的操作控制表面看都属于机器人控制实际上面临的物理约束、环境假设、评价指标、失败成本完全是两个维度。这篇文章我会尽量把这件事讲透先说清楚腿足运动为什么天然适合强化学习RL再说操作任务为什么近年越来越多人倒向Transformer架构然后聊一聊这两种路线各自的天花板和现实陷阱最后给出一个不那么站队的判断——在实际工程项目里它们大概率会长期共存而不是谁取代谁。先给一个我自己的结论不是走路用RL、干活用Transformer这个分工天然正确而是这两类任务的数学结构和工程约束恰好分别把RL和Transformer推到了聚光灯下。搞清楚背后的逻辑比记住结论重要得多。2. 先拆一个基本问题机器人控制里的走路和干活到底差在哪2.1 腿足运动一个连续、高频、模型难建的动态过程走路这件事从力学角度看是一个典型的高维、非线性、强耦合的欠驱动系统。四足机器人一条腿至少3个主动自由度全身12到16个自由度每一步都涉及支撑相和摆动相的切换地面反作用力、关节力矩、身体姿态、质心轨迹全部耦合在一起。更麻烦的是地面接触是离散事件。脚落地的瞬间接触力发生跳变摩擦锥约束只在接触点成立一旦脚打滑整个动力学模型就失效。传统方法想建模需要精确知道地面刚度、摩擦系数、地形几何而这些在实际场景里几乎都只能估算。这个问题的本质是系统的真实动力学模型很难写准但系统的行为目标却非常直观——别摔倒往前走能跟上指令速度。换句话说你不知道世界怎么运转但你知道什么叫表现好。2.2 操作任务离散、有语义、强调对象与工具的理解工业机械臂抓瓶子、插孔、装配、码垛物理上同样是非线性多体动力学但因为基座固定、负载变化范围可控、环境结构化程度高动力学模型反而可以建立得相当准。一个6自由度工业臂用牛顿-欧拉法或拉格朗日法写出完整动力学方程配合厂商提供的惯量参数力矩前馈能做到相当可靠。那干活难在哪难在语义理解目标物体在哪、什么姿态、该用哪种夹爪策略、夹具怎么避障、多步动作怎么排序。你让机器人把桌上的杯子放到托盘里杯子在哪这个问题消耗的算力和心智能量比手怎么伸过去大得多。2.3 两类任务的核心矛盾完全不同我把两者的差异整理成一个对照表方便后面讨论维度腿足运动走路操作任务干活动力学准确性差接触和地形不确定较好结构化和负载可控控制频率高关节级需1kHz以上低规划级10-50Hz足够成功标准连续数值指标稳定、速度、能耗离散任务抓没抓牢、插没插进环境变化连续变化同分布内泛化语义级变化跨分布泛化失败代价摔倒可重试物理损伤可控撞坏工件、伤人的可能性高数据获取同一地形可反复试错真实操作数据昂贵试错成本高这个表基本解释了为什么两条技术路线会分道扬镳RL需要大量试错数据但每一步的反馈信号可以连续不断地从传感器里拿正好匹配走路这件事的滚动优化特性Transformer擅长从大量离散数据里学习长程依赖和语义模式正好匹配操作任务中看-想-动的决策链条。3. 走路为什么是RL的主场从仿真到实机的完整逻辑链3.1 免模型RL解决了动力学建模难这个死结传统腿足控制的主流方案是模型预测控制MPC加全身控制WBC先简化为质心动力学用MPC在线算未来一段时间的足端力分配再用WBC把力映射到各关节力矩。这套东西在实验室平地上已经非常成熟MIT的Cheetah系列、国内的几款四足产品早期都是这个路子。但MPC的痛点很明显每一帧都要解一个带约束的优化问题计算量不小模型一旦简化碰到软地面、斜坡、台阶就抓瞎参数调起来极其痛苦一个地面刚度参数可能就要调一周。而且不同地形要切不同的模型参数场景一换工程师头皮发麻。免模型强化学习的思路是彻底绕开动力学建模不需要显式写出地面模型智能体自己在环境里试试错了给负奖励走稳了给正奖励通过海量交互直接学出一个状态到动作的映射。这一下把建模难变成了探索难而探索难的问题恰好可以被仿真环境暴力解决。3.2 仿真到实物迁移Sim-to-Real为什么在这个领域特别好用腿足运动被RL攻克的另一个关键原因是仿真和真实的差距sim-to-real gap可以被系统性地填平。四足机器人在地面行走核心物理过程是接触力学而现代物理引擎MuJoCo、Isaac Gym、Bullet对刚性接触的模拟精度已经相当高。再加上Domain Randomization——训练时随机化地面摩擦、机器人质量、电机力矩系数、延迟时间——学出来的策略天然对参数波动不敏感。我见过一个很典型的案例在Isaac Gym里并行开几万个环境用一个小时内训出来的策略直接部署到真实机器狗上步态已经能跑了。这在传统MPC路线里几乎不可想象MPC的部署链路里每一步都要人工干预。3.3 更隐蔽的优势RL策略天然是时间连续的闭环RL学出来的神经网络策略输入是当前的状态关节角度、角速度、机体姿态、指令速度输出是关节位置或力矩指令本身就构成一个高频闭环。这个结构天生适合走路这种需要毫秒级响应的任务——不需要人在回路里做高层决策所有的反馈都在网络前向传播里完成。我记得业内有个经验数据腿足RL策略的推理频率通常在200Hz到1kHz之间。为什么这么高因为触地瞬间的冲击如果不及时处理几毫秒内就可能把姿态带偏。神经网络的一次前向传播在嵌入式GPU上只需要零点几毫秒完全扛得住这个频率。3.4 走路任务的成功信号连续RL的奖励工程好做也有上限做RL的人都知道奖励设计是门玄学。但腿足任务的幸运之处在于成功与否不是0或1而是一个连续谱不倒能走给正奖励走得稳给更多速度跟上指令再给更多能耗低还可以加一个惩罚项。这种连续的、多维的、密度很高的奖励信号刚好是RL最擅长优化的对象。不过要泼一盆冷水走路RL的奖励设计其实远比看上去复杂。光一个别摔倒是不够的你得平衡前进速度、姿态稳定、能耗、步态对称性稍不留神就会学到螃蟹步——机器人确实前进了但姿态极其丑陋且能耗高。这也是现在很多团队用风格奖励style reward参考真狗步态数据和对抗式奖励的原因。4. 干活为什么偏偏拥抱Transformer从感知到决策的语义化转型4.1 操作任务的真正瓶颈不在控制误差而在理解任务回到机械臂的问题。假设目标是把不同形状的零件插到对应孔位里。传统方案是视觉识别定位、运动规划器算轨迹、力控做柔顺插入。这套流程的问题是每一个环节都是独立模块误差逐级放大一旦目标物体的姿态超出预设范围整个流程就崩。本质上传统操作链路缺一个跨模态的语义理解层它需要同时理解视觉图像里这是什么物体、什么姿态语言指令里插到哪个孔以及本体感受里现在夹爪碰到物体了没有。这种多模态对齐能力恰好是Transformer架构的看家本领。4.2 从RT-1到RT-2Transformer在机器人操作里的进化路径Google的RT系列是这条路线最典型的样本。RT-1的思路是把机械臂的摄像头图像、本体状态、语言指令全部token化丢进一个Transformer里做序列建模输出离散的动作指令。RT-2更进一步直接把机器人数据和大规模互联网图文数据混合训练让模型具备了一定的常识推理能力。为什么Transformer在这里比RNN、CNN、MLP都合适三个原因注意力机制天然支持长程依赖操作任务经常是看一眼桌子→决定抓哪个→伸手→调整姿态→抓取→放到目标点这个序列跨度几十步RNN容易遗忘Attention可以任意位置直接关联。统一的多模态嵌入图像、文本、关节状态、动作标签都可以映射到同一个语义空间Transformer的QKV机制天然接受异构输入。规模化能力这是最关键的——Transformer架构的收益会随着数据量和模型参数量上升而持续增长CNN饱和后再加数据提升有限Transformer没有这个瓶颈。4.3 数据从哪来操作领域的ChatGPT时刻还差一个规模化的数据引擎既然Transformer这么适合操作任务为什么不是所有团队立刻拥抱它因为数据。语言大模型有整个互联网当语料库图像模型有几十亿张图片但机器人操作数据呢机械臂真实执行一次抓取需要传感器记录图像、力矩、位置、成败标签效率极低一条数据十秒钟标注成本却比文本高得多。真实场景数据量全球加起来估计也就百万级轨迹跟语言模型动辄万亿token完全不在一个数量级。所以目前行业的折中方案是仿真数据为主、真实数据微调、预训练模型做底座。比如在Isaac Sim里批量渲染场景用领域随机化生成海量操作数据再在真机上用几千条人工采集数据做微调。这个路线的可行性和上限是目前学术界和工业界厮杀最激烈的地方。4.4 一个反直觉的点操作任务其实不排斥RLTransformer和RL正在合流这里要澄清一个误区标题说干活用Transformer好像操作任务里RL被淘汰了其实没有。真正的主流趋势是把Transformer当策略网络的主干用RL去训练它。比如谷歌的RT系列部分工作、清华和上交的一些操作工作都是Transformer policy RL优化。原因很简单Transformer出力的是长程语义建模能力RL提供的是试错优化的能力两者解决的问题并不重叠。你让Transformer直接用行为克隆BC从数据里学泛化能力受限于数据覆盖度你让RL从零开始学一个Transformer策略探索空间太大很难收敛。所以两者合流几乎是必然——先行为克隆预训练再用RL微调这已经是不少团队的标准配方。5. 边界条件与误用陷阱什么情况下走路用RL和干活用Transformer都可能是错的5.1 RL走路的三个隐形天花板安全、现实差距、算力成本即使RL在腿足领域已经非常成功它也不是银弹。第一个天花板是安全。RL策略的本质是黑箱你很难证明在某个没见过的地形上它一定不会摔倒。军用、救援、医疗场景对这种不确定性容忍度很低传统MPC虽然参数难调但每一步都有明确的优化目标和约束表达出了问题工程师能解释。第二个是sim-to-real的上限。Domain Randomization能掩盖一部分仿真差距但碰到形变物体、流体地面、极端摩擦力分布仿真模型本身就不靠谱RL学出来的策略在真机上可能就是另一个行为。第三个是训练算力。一个四足机器人走路的RL训练动辄几十GPU小时起步操作任务的Transformer策略训练更是百卡量级中小团队不一定扛得住这个成本。5.2 Transformer干活的三个认知误区别把大模型当成万能控制器反过来Transformer在操作任务里也有被过度神化的趋势。第一个误区是以为Transformer直接输出关节力矩。实际上绝大多数机器人Transformer输出的是高层动作比如末端位姿增量、离散动作类型、运动规划的cost map低层还是交给传统控制器。你不可能让一个Transformer以1kHz的频率去算每个关节的电流指令计算开销和延迟都受不了。第二个误区是忽视实时性。大模型前向推理动辄几十毫秒甚至几百毫秒而操作任务里接触状态变化的速度远高于这个时间尺度。所以真正落地的系统里大模型往往只做任务规划和轨迹点子生成真正的力控和柔顺操作还是靠底层专用控制器。第三个误区是把互联网预训练的常识直接当成操作技能。RT-2能告诉你杯子通常在桌子上这个常识但不代表它知道这个杯子的材质是易碎的夹持力要小一点。物理交互层面的经验只能从真实物理交互数据里来——这也是为什么现在讨论很热的世界模型最终还是要靠机器人自己的交互数据来验证。5.3 一个实际工程中更容易踩的坑混合架构里的模块通信如果你决定走高层Transformer 低层RL或MPC的混合路线会遇到一个非常现实的工程问题两个模块之间的接口怎么设计Transformer输出的意图是语义级的——把红色杯子放到托盘中央。这个意图要传递到低层控制器需要翻译成轨迹目标点、速度约束、力上限等参数。问题是语义空间和物理空间之间的转换往往需要大量手工设计的中间层比如抓取位姿估计器、避障规划器、力控参数表。接口设计得好系统如虎添翼设计得不好高层的智能化一点也落不到执行层反而变成累赘。我自己在项目里常用的做法是让高层输出一个候选轨迹集合而不是单条轨迹低层用安全约束过滤再选一条满足所有硬约束的轨迹去执行。虽然计算量大了点但工程可靠性高很多。6. 选型决策框架真到自己做项目时该怎么选6.1 三类典型的任务画像我根据自己看到的实际项目把机器人控制任务粗略分成三类每一类的最优方案不一样任务画像典型场景推荐主线方案理由连续动态控制四足/双足行走、跑酷、平衡RL为主要策略来源MPC做安全兜底动力学建模难试错代价小仿真可靠离散操作规划抓取、装配、整理、工具使用Transformer做语义理解与任务规划传统控制器执行多模态语义对齐是核心瓶颈精密力控操作插孔、打磨、拧螺丝传统力控阻抗/导纳为主RL或学习算法只在补偿环节用精度要求极高试错成本高现有学习算法稳定性不够这个表格不是说三者互斥而是告诉你资源有限的时候应该把重心押在哪。6.2 资源约束下的现实选择如果你是学生或者小团队没有几百张GPU我建议这么分配精力走路类项目优先用现成的RL框架Isaac Lab / Isaac Gym在仿真里把baseline跑通再用Domain Randomization提高迁移成功率。别自己造物理引擎也别一上来就调奖励函数先跑通最简单的再一点点加约束。干活类项目优先用已有的视觉-语言-动作模型VLA做预训练底座再微调自己的数据。别从零训练Transformer成本太高且没有意义。数据用仿真批量生成做预训练真机数据只做最后一步精调。混合系统优先保证低层控制器的稳定性高层模型哪怕弱一点系统还是能跑反过来低层不稳高层再智能都是空中楼阁。6.3 一个决策checklist最后给出我自己在做技术选型时反复使用的checklist供参考任务失败的安全代价有多高高代价任务尽量别把黑箱策略放在最底层。任务是在线连续决策还是离线单步决策连续决策RL有优势离线语义决策Transformer有优势。环境模型能不能建准能建准MPC和传统控制仍然是最优解建不准才轮到RL和Learning。数据的未标记但低成本仿真可刷还是高成本真实操作前者适合RL试错后者适合Transformer做预训练。是否需要跨场景、跨物体的语义泛化需要就上Transformer不需要就别给自己添乱。7. 我的一些个人体会别被标题带节奏架构选择永远是任务倒推的做了几年机器人控制相关的项目我的体会是技术圈特别喜欢制造范式对立——RL vs MPC、Transformer vs 传统控制、端到端 vs 模块化。但实际操作下来真正好用的系统几乎都是混合的差别只是不同模块的占比和接口设计。走路用RL这件事本质上是向模型不确定性妥协的结果——我们放弃了对每一个物理细节的建模努力用大量试错换来了对未知环境的适应能力。干活用Transformer本质上是向语义复杂性妥协的结果——我们放弃了对每一步动作的显式编程用海量数据换来了对任务意图的理解能力。两者的出发点不同落脚点自然也不同。从2024到2025年VLA视觉-语言-动作模型的进展已经很明显地在把Transformer在操作领域的份额进一步推高与此同时腿足RL在四足产品上的落地也进入了规模化复制阶段。两条线短期内不会交汇成同一条路而是会各自在合适的任务域里深化。真到自己做项目的时候我建议别纠结该站哪一队而是先回答三个问题我的任务失败代价是什么我的数据来源是什么我的算力预算有多少答案出来技术路线的选择基本也就出来了。技术选型不是站队是一场基于约束条件的最优化。