1. 从“引力琥珀”这个比喻说起大模型与物理世界之间隔了什么第一次听到“引力琥珀”这个说法我愣了几秒然后觉得这个比喻精准得让人后背发凉。琥珀是什么是树脂滴落之后把一只活生生的虫子包裹进去经过千万年石化虫子还在里面形态完好但它再也动不了了。大模型现在就是那只虫子——它在数字世界里能写诗、能编程、能推理、能通过一堆考试但一旦你想让它去控制一个真实的机械臂、一辆小车、一个无人机它就像被琥珀裹住了一样动弹不得。这个“引力”不是物理课本里的万有引力而是真实世界的约束重力、摩擦力、惯性、延迟、噪声、磨损、温度漂移。这些东西在文本世界里完全不存在。你在对话框里让模型“把杯子拿起来”它给你输出一段看起来完美的动作序列但真机一跑杯子要么被捏碎要么根本没碰到。问题出在哪出在大模型的训练目标和机器人的控制目标之间存在一道根本性的鸿沟。我做了几年机器人相关的项目也深度参与过几个大模型落地的尝试踩过的坑可以说能写一本书。这篇文章想聊的就是为什么大模型不能直接控制机器人这背后的核心矛盾是什么有没有绕过去的路如果你正在做具身智能、机器人控制、或者只是对大模型的能力边界感兴趣这篇内容应该能帮你省下不少试错的时间。先给一个最直观的结论大模型擅长的是“语义空间”里的映射而机器人控制需要的是“物理空间”里的映射。这两个空间之间的翻译不是加一个适配层就能解决的它涉及到训练数据、推理频率、误差累积、安全约束等一整套系统性问题。下面我拆开来讲。2. 语义空间与物理空间的翻译鸿沟2.1 大模型到底在做什么下一个token的概率预测要理解为什么大模型不能直接控制机器人得先搞清楚大模型本质上在干什么。不管你用的是哪种架构自回归语言模型的核心任务只有一个给定前面的token序列预测下一个token的概率分布。它做的事情是在一个离散的、符号化的空间里做概率建模。你输入“把红色方块放到蓝色方块上面”模型输出的是一串token比如“首先机械臂移动到红色方块上方然后下降闭合夹爪……”这串token在语义上是合理的因为它见过大量类似的文本描述。但注意这串token描述的是“应该怎么做”而不是“具体每个关节在每一毫秒应该输出什么力矩”。这两者之间的差距就像菜谱和炒菜之间的差距——菜谱告诉你“大火翻炒三分钟”但真正炒菜的时候火候、油温、食材含水量、锅的材质每一个变量都在影响最终结果。更关键的是大模型的输出是离散的token而机器人控制需要的是连续的、高频的、带反馈的指令流。一个典型的机械臂控制循环跑在100Hz到1000Hz也就是说每1到10毫秒就要输出一次新的指令。大模型推理一次的时间哪怕是最优化的部署也在几十毫秒到几百毫秒级别。这个频率差距是数量级的不是靠优化能填平的。2.2 物理世界的“引力琥珀”不可忽略的约束条件物理世界有一堆在文本世界里完全不需要考虑的约束。我列几个最要命的重力与动力学。你让模型输出“抬起机械臂”它不知道这个臂有多重、电机扭矩够不够、关节在什么角度下力矩最大。这些信息不在文本里在物理模型里。一个2公斤的负载和一个200克的负载控制策略完全不同但文本描述可能一模一样。摩擦与间隙。真实机械系统的关节有间隙、导轨有摩擦、皮带会打滑。你给一个位置指令实际到达的位置可能差几毫米。这几毫米在文本里无所谓在装配任务里就是成功和失败的差别。延迟与抖动。从发出指令到执行器响应中间有通信延迟、计算延迟、机械响应延迟。这些延迟在文本生成里不存在但在控制里会导致振荡甚至失稳。传感器噪声。摄像头有噪点、力传感器有漂移、编码器有量化误差。模型如果直接吃原始传感器数据很容易被噪声带偏。磨损与温漂。今天调好的参数跑了一周之后因为磨损和温度变化可能就不准了。文本模型不需要考虑“自己用久了会不会变笨”但机器人会。这些约束加在一起就是那层“引力琥珀”。大模型在琥珀里面能看到外面能描述外面但它的“身体”动不了。2.3 一个具体的失败案例让模型输出关节角度我做过一个实验让一个当时比较流行的大模型直接输出六轴机械臂的关节角度序列任务是“把桌上的方块推到指定位置”。模型输出的角度看起来挺合理数值范围也在关节限位内。但真机一跑问题全出来了。第一模型不知道方块的初始位置。它输出的角度序列是“通用”的但方块在桌子左边和右边需要的角度完全不同。第二模型输出的角度之间没有考虑运动学约束相邻两个角度之间的变化可能导致关节速度超限。第三模型没有考虑末端执行器的姿态推方块需要特定的接触角度模型输出的姿态让夹爪侧面撞上了方块。这个实验让我彻底放弃“让大模型直接输出控制指令”这条路。不是说模型不够强而是它的输出空间和机器人的控制空间根本不匹配。你让一个诗人去开挖掘机他可能写出很美的操作手册但真让他上手大概率把墙拆了。3. 频率、延迟与闭环控制理论视角下的硬伤3.1 控制循环为什么需要高频机器人控制本质上是一个闭环反馈系统。你给一个目标位置控制器根据当前实际位置和目标位置的偏差计算出一个控制量驱动电机运动然后再次测量、再次计算。这个循环的频率决定了系统的稳定性和精度。举个简单的例子一个移动机器人以1米/秒的速度前进控制频率是10Hz那么每次控制周期之间机器人移动了10厘米。如果前方突然出现障碍物从传感器检测到到控制器响应机器人已经多走了10厘米。如果控制频率是100Hz这个距离就降到1厘米。对于高速运动或者高精度任务10Hz的控制频率根本不够用。大模型的推理频率是多少以目前主流的部署方案一个7B参数的模型在消费级显卡上推理一次大概需要50到200毫秒也就是5到20Hz。这还是在batch size为1、序列长度较短的情况下。如果模型更大、输入更复杂频率会更低。这个频率对于文本生成够用对于机器人控制就是灾难。3.2 大模型推理的延迟构成大模型推理的延迟不是单一来源它由好几部分组成预处理延迟把输入文本tokenize、把图像编码成特征向量这部分通常几毫秒到几十毫秒。模型前向传播延迟这是大头取决于模型大小、硬件算力、并行策略。7B模型在A100上大概20到50毫秒在消费级显卡上可能100毫秒以上。采样与后处理延迟从概率分布中采样、解码成token、再后处理成控制指令这部分几毫秒到几十毫秒。通信延迟如果模型部署在云端或者边缘服务器网络传输还会增加几十到几百毫秒。把这些加起来端到端的延迟很容易超过200毫秒。对于需要快速响应的任务比如抓取移动物体、避障、平衡控制这个延迟是致命的。3.3 闭环控制中的误差累积更麻烦的是误差累积。开环控制下模型输出一串指令机器人执行完就完了误差不会累积。但闭环控制下每一步的误差都会影响下一步的输入如果控制器设计不当误差会指数级放大。大模型输出的指令往往带有“语义模糊性”。比如它说“稍微向左移动”这个“稍微”是多少在文本里无所谓在控制里就是几厘米的偏差。如果每一帧都有这种模糊性闭环系统很快就会发散。我见过一个团队尝试用大模型做移动机器人的路径规划模型输出“向前走一段然后右转”。机器人执行后因为轮子打滑实际位置偏了。下一帧模型看到新的传感器数据又输出“向前走一段然后右转”。结果机器人走出了一个弧线完全偏离了目标。问题不在于模型不聪明而在于它的输出粒度太粗无法满足闭环控制对精度的要求。3.4 控制理论对大模型说“不”的几个理由从控制理论的角度看大模型直接做控制器有几个硬伤没有稳定性保证。经典控制理论有一套完整的稳定性分析方法比如李雅普诺夫稳定性、根轨迹、频域分析。大模型是一个黑箱你无法用这些工具分析它的稳定性。它可能在99%的情况下表现正常但在1%的情况下输出一个离谱的指令导致系统崩溃。没有可解释性。当机器人出现异常行为时你需要快速定位原因。如果控制器是大模型你很难说清楚它为什么输出了那个指令。是训练数据的问题是提示词的问题还是模型本身的不确定性排查起来非常困难。没有实时性保证。控制系统的硬实时要求意味着你必须在严格的时间窗口内完成计算。大模型的推理时间受输入长度、硬件负载、内存带宽等多种因素影响很难给出硬实时保证。没有安全边界。机器人控制需要明确的安全边界比如关节力矩上限、速度上限、工作空间限制。大模型的输出是概率性的它可能输出超出安全边界的指令而且你很难在模型层面加硬约束。4. 分层架构目前最务实的解法4.1 大模型做“大脑”传统控制器做“小脑”既然大模型不能直接控制机器人那怎么用目前业界比较务实的做法是分层大模型负责高层任务理解和规划传统控制器负责低层运动控制。具体来说大模型接收自然语言指令和场景信息输出一个中间表示比如“抓取红色方块并放到蓝色方块上”。这个中间表示可以是任务序列、目标点、或者子目标。然后一个传统的运动规划器或者控制器接收这个中间表示生成具体的关节轨迹或者力矩指令。这个架构的好处是大模型发挥它擅长的语义理解和任务分解能力传统控制器发挥它擅长的实时控制和稳定性保证。两者各司其职互不干扰。我参与过的一个项目就是这种架构大模型负责把“把桌上的零件按大小排序”分解成“抓取零件A放到位置1抓取零件B放到位置2……”这样的子任务序列然后每个子任务交给一个基于视觉伺服的控制模块执行。整个系统跑下来成功率比纯大模型方案高了不止一个数量级。4.2 中间表示的设计从语言到动作的桥梁分层架构的关键在于中间表示的设计。这个中间表示需要满足几个条件大模型能生成。它必须是文本或者类文本的形式大模型可以通过提示词或者微调来输出。控制器能理解。它必须有明确的语义控制器可以把它翻译成具体的控制指令。粒度合适。太粗了控制器没法执行太细了大模型生成不了。常见的中间表示包括任务序列比如“移动到A抓取移动到B放置”。这是最粗的粒度适合任务级规划。目标点序列比如“末端执行器移动到(x1, y1, z1)然后到(x2, y2, z2)”。这是中等粒度适合运动规划。技能调用比如“调用抓取技能参数是方块ID和抓取力度”。这是比较结构化的方式适合技能库已经比较成熟的场景。代码生成让大模型生成一段调用机器人API的代码。这种方式灵活度高但安全性和可靠性需要额外保证。我个人比较推荐“技能调用”这种方式。它把大模型的输出限制在一个预定义的技能库里每个技能都有明确的输入输出和安全边界。大模型只需要选择合适的技能并填充参数不需要生成底层的控制指令。这样既利用了大模型的语义理解能力又保证了控制的安全性和实时性。4.3 技能库的构建与维护技能库是分层架构的核心资产。一个设计良好的技能库应该包含原子技能比如“移动到指定位置”、“抓取”、“释放”、“旋转”。这些技能对应底层的控制原语有明确的参数和安全约束。组合技能比如“抓取并放置”、“插入”、“拧螺丝”。这些技能由原子技能组合而成对应更复杂的操作。技能参数每个技能需要哪些参数参数的取值范围参数的默认值。这些信息需要以结构化的形式提供给大模型。前置条件与后置条件每个技能在什么条件下可以执行执行后会产生什么效果。这些信息帮助大模型做任务规划。构建技能库不是一劳永逸的事情。随着任务复杂度的增加你需要不断添加新的技能调整现有技能的参数优化技能之间的组合方式。这是一个持续迭代的过程。我踩过的一个坑是技能库设计得太细导致大模型需要输出很长的技能序列推理时间变长而且容易出错。后来我们把一些常用的技能组合封装成高层技能大模型的输出长度缩短了成功率也上去了。4.4 分层架构的局限与应对分层架构不是银弹它也有自己的问题。信息损失。大模型在生成中间表示时会丢失一些底层信息。比如它说“抓取方块”但没有指定抓取的位置和姿态。控制器需要自己决定这些细节如果决策不当任务就会失败。接口脆弱。大模型和控制器之间的接口是人为定义的如果任务超出了接口的覆盖范围系统就无法处理。比如技能库里没有“推”这个技能大模型就无法完成推的任务。错误传播。如果大模型的任务分解错了控制器再精确也救不回来。比如大模型把“把方块放到盒子里”分解成“把方块放到盒子旁边”控制器执行得再好也没用。应对这些问题的方法包括给大模型提供更丰富的场景信息让它做出更准确的决策设计更灵活的接口允许大模型在必要时生成新的技能组合在控制器层面加入异常检测和恢复机制当任务执行失败时能够回退或者重试。5. 端到端方案的可能性与当前瓶颈5.1 端到端机器人学习在做什么端到端方案的想法很直接既然分层架构有信息损失和接口脆弱的问题那能不能用一个模型直接从传感器输入映射到控制输出这就是端到端机器人学习。具体来说输入是摄像头的图像、关节编码器的读数、力传感器的数据输出是关节力矩或者位置增量。模型通常是一个神经网络用模仿学习或者强化学习来训练。这个方向在学术界很热也有一些令人印象深刻的demo。比如让机器人从演示中学习叠衣服、组装零件、开抽屉。但这些demo大多在受控环境下运行泛化能力有限。5.2 端到端方案为什么还没成为主流端到端方案面临几个核心瓶颈数据效率。训练一个端到端的机器人控制模型需要大量的真实世界交互数据。收集这些数据的成本极高而且很难覆盖所有可能的场景。相比之下大模型可以用互联网上的文本数据训练数据获取成本低得多。泛化能力。端到端模型在训练分布内表现不错但一旦遇到新的物体、新的光照条件、新的任务性能就会大幅下降。大模型之所以强是因为它在海量数据上训练见过足够多的多样性。机器人数据没有这种规模。安全性。端到端模型是一个黑箱你无法保证它在所有情况下都输出安全的控制指令。在真实世界里一个错误的指令可能导致机器人损坏或者人员受伤。可解释性。当端到端模型失败时你很难定位原因。是视觉编码器的问题是策略网络的问题还是训练数据的问题排查起来非常困难。实时性。端到端模型通常比大模型小但推理频率仍然受限于网络规模和硬件。对于高动态任务实时性仍然是一个挑战。5.3 大模型端到端小模型的混合方案目前比较有前景的方向是混合方案大模型负责高层推理和任务规划端到端小模型负责低层控制。大模型提供语义理解和常识推理小模型提供快速反应和精细控制。比如大模型看到“把桌上的垃圾扔进垃圾桶”这个指令输出“抓取纸巾移动到垃圾桶上方释放”。然后一个端到端的抓取模型接收“抓取纸巾”这个子任务输出具体的抓取动作。这个抓取模型可能是在大量抓取数据上训练的小网络推理频率可以做到100Hz以上。这种混合方案结合了两者的优势大模型的泛化能力和语义理解小模型的实时性和精细控制。但它也带来了新的挑战如何设计大模型和小模型之间的接口如何保证两者的一致性如何处理小模型失败的情况5.4 从仿真到现实的迁移难题端到端方案还有一个绕不开的问题仿真到现实的迁移。在仿真环境里训练模型成本低、速度快、安全性高但仿真环境和真实世界之间存在差距。物理参数不准确、传感器噪声模型不真实、接触力学简化这些都会导致模型在真机上表现下降。常见的应对方法包括域随机化在仿真中随机化物理参数、光照、纹理让模型学会适应变化域适应用少量真实数据微调仿真中训练的模型系统辨识用真实数据校准仿真参数。但这些方法都有局限。域随机化可能导致模型过于保守域适应需要真实数据系统辨识无法覆盖所有动态变化。从仿真到现实的迁移仍然是端到端方案落地的最大障碍之一。6. 实操中的经验与避坑指南6.1 不要试图让大模型输出底层控制指令这是我踩过的最大的坑。一开始我觉得大模型这么强直接让它输出关节角度或者力矩不就行了结果浪费了好几周时间。大模型的输出空间和底层控制空间根本不匹配无论怎么调提示词、怎么微调都达不到可用的精度和频率。正确的做法是把大模型的输出限制在任务级或者技能级让传统控制器去处理底层细节。大模型说“抓取方块”控制器决定怎么抓、用多大力、从哪个角度抓。6.2 中间表示要结构化不要用自然语言另一个坑是让大模型输出自然语言描述的动作序列然后用另一个模型去解析。这种方式看起来灵活实际上非常脆弱。自然语言有歧义解析模型可能理解错而且解析本身也需要时间。更好的做法是定义一套结构化的中间表示比如JSON格式的任务描述或者预定义的技能调用格式。大模型只需要填充字段不需要生成自由文本。这样解析速度快、歧义少、可靠性高。6.3 安全边界要在控制器层面加不要在模型层面加你可能会想在提示词里告诉大模型“不要输出超出关节限位的角度”或者在微调时加入安全约束。但这些方法都不可靠。大模型是概率性的它可能在某些情况下忽略这些约束。正确的做法是在控制器层面加硬约束。无论大模型输出什么控制器都会检查是否超出安全边界如果超出就拒绝执行或者裁剪到安全范围内。这样即使大模型出错系统也不会崩溃。6.4 从简单任务开始逐步增加复杂度我见过一些团队一上来就想做“通用机器人”让大模型控制机器人完成各种家务。结果每个任务都做不好因为复杂度太高问题太多根本不知道从哪里开始修。我的建议是从一个非常简单的任务开始比如“把方块从A点搬到B点”。把这个任务做到90%以上的成功率然后再增加难度比如加入障碍物、改变物体形状、增加任务步骤。每一步都确保系统稳定后再往前走。6.5 日志和回放系统是排查问题的关键机器人系统出问题的时候你需要知道当时发生了什么。大模型输出了什么控制器接收到了什么执行器实际做了什么传感器读数是什么如果没有完整的日志排查起来就是盲人摸象。我建议在系统里加入详细的日志记录包括每一帧的输入、输出、中间状态。同时做一个回放系统能够重现问题场景方便调试。这个投入在后期会节省大量时间。6.6 不要忽视传统控制的价值大模型很热但传统控制理论经过几十年的发展有一套成熟的方法论。PID控制、模型预测控制、阻抗控制这些方法在特定场景下比神经网络更可靠、更可解释、更容易调试。我的经验是能用传统方法解决的问题就不要用大模型。大模型应该用在传统方法解决不了的地方比如语义理解、任务规划、异常处理。把大模型和传统方法结合起来而不是用大模型替代传统方法。7. 一些关于未来的个人判断“引力琥珀”这个比喻之所以让我印象深刻是因为它点出了一个本质问题智能不等于控制。一个系统可以非常智能能理解语言、能推理、能规划但它不一定能控制好一个物理身体。控制需要的是实时性、稳定性、精度、安全性这些和智能是两回事。大模型在语义空间里的能力还在快速提升但物理空间的约束不会因为模型变大而消失。重力还是那个重力延迟还是那个延迟噪声还是那个噪声。要突破“引力琥珀”需要的不是更大的模型而是更好的架构、更好的接口、更好的控制方法。我个人比较看好的方向是大模型负责它擅长的部分传统控制负责它擅长的部分两者通过一个设计良好的中间层连接。这个中间层需要足够结构化让大模型的输出可以被可靠地解析和执行同时需要足够灵活能够覆盖多样化的任务。另一个值得关注的方向是让大模型学会“知道自己不知道”。当任务超出它的能力范围时它应该能够识别出来并请求人类帮助或者回退到安全状态。这种元认知能力可能比单纯提升模型规模更重要。最后说一个我自己的体会做机器人系统最怕的不是技术难而是不知道难点在哪。大模型控制机器人这件事难点不在模型本身而在模型和物理世界之间的那层“翻译”。把这层翻译做好了系统就能跑起来做不好再大的模型也没用。希望这篇内容能帮你少走一些弯路。
