当大模型开始操控机械臂，为什么“会写代码”不等于“会干活

一、一个反直觉的实验结果

让当前能力最强的多模态大模型去控制真实机器人，完成叠积木、倒水、操纵无人机接球、驾驶车辆走弯道、让四足机器人在被推倒后重新站稳等任务，会得到怎样的成绩？

某研究团队给出的结果相当出人意料：表现最好的模型在84个任务中只完成了16个，成功率约19%；第二名完成13个，约15.5%；后面的模型分别只完成2个、1个和1个。

这些模型在数字世界中已经可以写出通过代码评审的函数，能够完成复杂的工具调用，也可以在对话中展现严谨的逻辑推理能力。但一旦面对物理世界中的“简单”动作——抓取一个瓶子、把水倒进杯子、让机器人站稳——它们的表现却急剧下滑。

这个反差引出一个值得深入讨论的问题：当模型已经具备代码生成、视觉识别和工具调用能力之后，这些在数字环境中积累的能力，究竟能不能直接迁移到物理世界？

问题的答案并不像“能不能”这么简单。真实的情况是：模型确实可以把视觉感知、数学计算和动作控制拼接起来，但“拼接出来”与“稳定完成”之间，还隔着一段相当长的距离。

二、模型并不是在“瞎摸索”

需要先澄清一个可能的误解：这些模型面对机器人任务时，并不是完全无从下手。它们能够读取摄像头传回的图像序列，能够获取机械臂关节角度、末端执行器位置等状态信息，还能够自主编写代码完成图像分割、坐标变换、相机投影计算和控制律推导。

一个典型例子来自叠积木任务。某个模型在任务初期连续观察摄像头画面，锁定目标积木的位置，直接执行抓取与举升动作，直到第204步才第一次调用相机投影的几何计算。另一个模型则采用了完全不同的策略：先编写颜色分割代码，再通过主动移动机械臂来采样、拟合相机与机械臂之间的几何关系，完成标定后才开始抓取。

前者的策略是“先动手，遇到问题再计算”；后者是“先建模，再执行”。两条路线最终都完成了积木的放置与缩回，物理执行步数几乎相同——一个270步，一个268步。但工具调用次数相差一倍：前者23次，后者46次。

这说明两点。

第一，多模态大模型确实具备将“视觉观察—数学建模—动作执行”串联起来的能力。这不是简单的脚本回放，而是有条件的自主规划。

第二，不同模型在解决同一任务时，会展现出完全不同的“认知风格”。有的倾向在线试错与即时反馈，有的倾向先建立显式模型再行动。这种风格差异在数字任务中可能只影响效率，但在物理任务中会直接影响成功率。

三、核心问题：执行成功不等于任务完成

实验结果中反复出现一个值得注意的现象，可以用一句话概括：每一步动作都执行成功了，但任务最终没有完成。

这是理解大模型进入物理世界所面临挑战的关键。

以一个倒水任务为例。某模型需要控制机械臂接近桌面上的瓶子并完成倒水。在接近过程中，机械臂末端碰倒了瓶子，第42步时瓶子已经侧躺在桌面上。模型在自己的运行日志中写下了观察记录，提到“第一次闭合抓取未成功，因为夹爪位于倒下的瓶子上方”。它随后多次尝试用左臂抓取，但始终无法建立稳定抓持。直到第240步才切换到右臂，重新定位，到第272步完成了一次有效接近。

此时任务距离结束还剩128步的预算。模型继续尝试用右臂重新接近瓶子，但直到第400步时限耗尽，任务仍未完成。

这里隐藏着一个非常关键的细节：机械臂的每一次移动，从控制接口的返回值来看都是“成功”的。 没有报错，没有被系统拒绝，没有触发安全急停。夹爪打开、闭合、移动、停止——每一个动作都被正常执行。但从任务目标来看，这些动作并没有转化为有效进展。

这就是“执行成功”与“任务完成”之间的鸿沟。

四、为什么会发生这种情况？

要理解这种反直觉的现象，需要从数字任务与物理任务的本质差异入手。

4.1 数字任务有明确的成功信号

在代码生成、文本问答等数字任务中，成功与否通常存在清晰的判断依据。代码能否通过测试用例，回答是否符合语义要求，工具调用是否返回预期结果——这些信号都是确定性的，模型可以基于这些信号进行迭代修正。

更重要的是，数字任务中的“动作”通常是可重试、可回滚、低代价的。生成一段错误代码，重新生成即可；调用一次失败的工具，换个参数再试即可。失败的边际成本很低，模型可以在大量试错中逐步逼近正确答案。

4.2 物理任务中，失败会改变任务状态

物理世界的核心特征是不可逆性。一旦机械臂碰倒瓶子，瓶子的状态就发生了改变，后续所有规划都必须基于这个新状态重新进行。如果模型没有及时更新对场景的理解，而是在旧状态假设下继续执行，就会陷入无效循环。

前面提到的倒水任务就是典型案例。瓶子在第42步已经被碰倒，但模型在后续的大量步骤中仍然试图用为“直立瓶子”设计的抓取策略来操作。它虽然意识到了“瓶子倒下了”这一事实，却没有随之切换到一个适合侧躺瓶子的恢复策略。

4.3 误差会在长周期执行中累积

物理操作中的每一次执行都带有误差。夹爪闭合的位置可能偏差几毫米，机械臂移动的角度可能偏差零点几度。在短周期任务中，这些误差可能不会导致失败；但在需要几十步甚至几百步的长周期任务中，误差会持续累积。

更麻烦的是，这些误差往往不会被模型显式地感知到。模型看到的是关节角度的数值，而不是真实的物理状态。如果它没有主动通过视觉或其他传感器去校准和更新状态估计，就会在错误的假设下继续动作，导致偏差越来越大。

4.4 模型需要建立“物理常识”级的判断力

在数字任务中，模型可以依靠大规模预训练中习得的模式来处理问题。但物理操作需要的不是语言层面的常识，而是对质量、摩擦、接触力、稳定性等物理量的实时判断。

一个瓶子倒下后需要多大的力才能抓起来？夹爪从什么角度接近才不会再次碰倒？这些问题无法从语言模型的预训练数据中获得直接答案。模型需要在实际操作中通过感知-行动的闭环来学习和推断，而这恰恰是当前多模态模型能力的薄弱环节。

五、这意味着什么？

这个实验结果并不是要否定大模型在机器人领域的应用前景，而是揭示了一个重要的工程现实：将语言模型搬到机器人上，不等于机器人就具备了通用操作能力。

一个更有价值的视角是：多模态大模型可以成为机器人系统中的“高层规划器”或“策略协调者”，但物理执行层面仍然需要更精细的感知闭环、更可靠的底层控制和更完善的错误恢复机制。

以云上智能能力为例，当企业构建机器人自动化方案时，通常需要将视觉感知、任务规划、动作控制和状态监控分层设计，而不是期望单一模型承担所有职责。大模型适合做的是理解任务指令、生成候选策略、根据反馈调整计划；而实时控制、力反馈处理和安全性保障，则应由更确定性的控制模块负责。

六、工程实践中的几点启示

从这些实验结果中，可以提炼出一些对机器人智能系统设计有参考价值的原则。

第一，区分“规划层”与“执行层”。 大模型适合放在规划层，负责理解高层目标、拆解子任务、根据感知反馈调整策略。执行层应保留经典控制方法的可靠性，对关键动作进行约束和校验。

第二，建立显式的状态验证机制。 模型每一次动作之后，不应默认“执行成功等于状态正确”，而应通过视觉或其他传感手段验证关键对象的状态是否仍然符合预期。验证逻辑可以独立于模型规划逻辑存在。

第三，将失败恢复作为一等公民来设计。 物理任务中失败是常态，系统需要具备检测失败、调整策略、恢复操作的能力。与其追求一次成功，不如设计能够从异常状态中恢复的鲁棒流程。

第四，控制长周期任务中的误差累积。 可以通过将任务分解为更短的执行单元，在每个单元结束时进行状态校准，降低误差在长链条中的传播效应。

第五，让模型的“观察—判断—行动”闭环更紧凑。 当前许多模型的推理周期较长，从看到画面到给出下一步动作可能需要数秒。对于准实时控制场景，这种延迟会带来新的挑战。优化推理链路、降低端到端延迟，是工程化的关键方向之一。

七、结语

当AI学会写代码、用工具、分析图像之后，它距离“稳定地端稳一杯咖啡”还有多远？这项研究给出的回答是：比人们直觉中要远一些。

拆开来看，模型已经具备了完成任务所需的大量“零件”：视觉感知、代码生成、几何计算、策略规划。但这些零件还缺少一个将它们紧密耦合在物理世界节奏中的“神经系统”。每一次动作都在物理世界中留下不可撤销的痕迹，而系统对状态的实时感知、对误差的及时修正、对失败的有效恢复，才是决定最终成败的能力。

这不是对多模态大模型能力的否定，而是对当前技术边界的清醒认知。大模型可以在机器人系统中扮演越来越重要的角色，但“会操作”与“会稳定地操作”之间，仍需要大量的工程积累与系统性设计来填补。