昨天晚上实验室组会，大家都在刷 Figure 01 进工厂的视频。说实话，我盯着屏幕看了三遍，不是因为它有多好看，而是因为它太“反直觉”了。以前我们做机器人，那是把控制算法写在 C++ 里，像修钟表一样精细地调 PID 参数，每一步都要算好力矩、加速度、动力学模型。现在倒好，直接喂给一个大模型一句话：“帮我拿那个红色的杯子。” 然后机器人自己就动起来了。这让我想起 Google DeepMind 上个月发的那篇 RT-2 论文里提到的愿景，但说实话，论文里的数学公式跑通了，真要把 Figure 01 放进流水线里干活，工程上遇到的坑比我想象的要深得多。
30秒速览
- - Figure 01 使用 VLA 模型，而非传统控制，GPT-4o 提供高层语义，MPC 提供底层执行。
- - Sim2Real 差距巨大，仿真器的刚体假设无法匹配现实世界的长尾物理现象。
- - 实时性是硬伤，LLM 延迟必须通过分层架构（规划-执行分离）解决。
- - 开发者需掌握 ROS2、动力学和 MPC，而不仅仅是调大模型参数。
Figure 01 视频背后的技术揭秘：自然语言如何转化为机械动作
很多开发者看完视频第一反应是：“这不就是多模态大模型嘛？” 错，大错特错。Figure 01 用的不是那种聊天的 LLM，它是一个 **VLA（Vision-Language-Action）模型**。简单说，就是把 GPT-4o 的“理解能力”和机器人的“动手能力”强行缝合在了一起。
VLA 模型的核心：从像素到 Action Token
Figure 01 的摄像头不是用来“看”的，是用来“读”的。它的视觉编码器把摄像头拍到的画面压缩成向量，然后这个向量被扔进 GPT-4o 的处理流程里。但最关键的地方在于，GPT-4o 的输出不是文本，而是 **Action Token（动作 Token）**。
这中间有个巨大的工程转换。你想想，GPT-4o 是一个通用的语言模型，它的输出空间是无限的词汇表。Figure 必须在这个输出层加一个“投影头”，把语言空间映射到机器人的动作空间。这个动作空间不是简单的“移动 5 厘米”，而是一个高维的向量，包含了抓取位置、抓取力度、手腕姿态、甚至手指的张开角度。（延伸阅读：仿真跑了100%通过，实测Lunar Lake仅80%——我的轻薄本异构计算踩坑记）
我看过他们的技术博客，他们并没有直接让 GPT-4o 去控制每一个关节。那样太慢了，而且 GPT-4o 的生成速度根本达不到机器人 1000Hz 的控制频率。他们的架构是“分层”的：GPT-4o 负责高层决策（比如“我要拿杯子”），然后一个轻量级的运动规划器（MPC）负责把这些决策翻译成具体的关节指令。这就好比 GPT-4o 是“大脑”想吃饭，而底层的控制栈是“小脑”负责咀嚼和吞咽。
# 伪代码：模拟 Figure 01 的 Action Token 生成逻辑
# 注意：这是为了理解架构，并非直接复现其内部模型
class VLA_Model:
def __init__(self, vision_encoder, llm, action_head):
self.vision_encoder = vision_encoder # 比如基于 ViT 的视觉编码器
self.llm = llm # GPT-4o 或类似的高性能 LLM
self.action_head = action_head # 将 LLM 输出映射到动作空间的线性层
def forward(self, visual_observation, text_prompt):
# 1. 视觉编码：将图像转为向量
# 假设输入是 (B, 3, 224, 224) 的图像
visual_embedding = self.vision_encoder(visual_observation)
# 2. 文本编码：将指令转为向量
# 假设输入是 "Pick up the red cup"
text_embedding = self.llm.encode_text(text_prompt)
# 3. 融合与推理：VLM 的核心
# 在 RT-2 论文里，他们用的是对比学习或者简单的拼接
combined_input = self.concat_embeddings(visual_embedding, text_embedding)
# 4. 生成动作 Token：关键步骤
# LLM 输出的是一个巨大的 token 序列，我们只取最后几个作为动作
logits = self.llm.forward(combined_input)
# 这里的 action_head 作用是把 logits 映射到具体的关节控制参数
# 比如：[x, y, z, roll, pitch, yaw, gripper_open, gripper_force]
action_vector = self.action_head(logits[:, -1, :])
# 5. 后处理：确保动作在安全范围内
# 物理世界不允许关节超过 360 度，或者力矩超过电机极限
safe_action = self.clamp_action(action_vector)
return safe_action
# 实际工程中，这不仅仅是前向传播，还要考虑 KV Cache 的复用
# 为了降低延迟，Figure 01 可能会使用 KV Cache，即把历史帧的
# 视觉特征缓存起来，而不是每帧都重新跑一遍 Encoder
从仿真到现实的差距：具身智能落地难点
这也是我最焦虑的地方。Google DeepMind 那篇 RT-2 论文里提到，只要在仿真中把环境随机化做得足够好，模型就能泛化到现实。但我最近在复现他们的实验时发现，**仿真里的“完美物理引擎”和现实里的“混沌物理世界”之间，隔着一道天堑。**
论文里的理想 vs 现实的长尾问题
在论文的实验里，机器人拿杯子通常成功率在 80% 以上。但 Figure 01 在真实工厂里，面对的是什么？是滑溜溜的不锈钢表面，是传送带的不规则震动，是光照突然变化导致的视觉漂移。（延伸阅读：仿真跑通了Lunar Lake的NPU，实测延迟却比M3 Pro慢了40ms——我的轻薄本异构计算踩坑记）
最让我头疼的是“长尾分布”。仿真器里的物体通常都是刚体，碰撞反馈是完美的。但在现实里，你抓起一个塑料瓶，它的受力变形是不规则的。Figure 01 必须具备“力觉反馈”的感知能力，但这在纯视觉的 VLA 模型里很难体现。如果模型没见过“瓶子滑脱”这种极端情况，它就会死机——比如它死死抓住滑落的瓶子不放，或者试图把瓶子“推”回传送带，结果把自己摔了。
Figure 团队肯定做了大量的**域随机化**。他们在训练时故意把仿真环境的摩擦系数、质量分布、光照角度打乱。但工程上有个悖论：随机化做得太狠，模型泛化能力变强了，但收敛速度变慢了。在算力有限的大厂实验室，这往往是个两难选择。
# 伪代码：模拟 Sim2Real 中的 Domain Randomization
# 这是为了防止模型“死记硬背”仿真器的参数
import numpy as np
class SimulationEnvironment:
def __init__(self):
# 仿真器的基础参数（例如 MuJoCo 或 Isaac Gym）
self.base_gravity = np.array([0, 0, -9.81])
self.base_friction = 0.5
def randomize_domain(self):
# 1. 随机化物理参数：摩擦系数是关键
# 实际上机器人抓取成功率很大程度上取决于摩擦
friction_coeff = np.random.uniform(0.1, 1.5)
# 2. 随机化质量分布：让物体有时候很轻，有时候很重
object_mass = np.random.uniform(0.1, 5.0)
# 3. 随机化环境干扰：模拟传送带的震动
conveyor_speed = np.random.uniform(-0.5, 0.5)
vibration_noise = np.random.normal(0, 0.05)
return {
"friction": friction_coeff,
"mass": object_mass,
"conveyor": conveyor_speed,
"vibration": vibration_noise
}
# 在训练循环中
sim = SimulationEnvironment()
for episode in range(num_episodes):
# 每一帧都给仿真器注入随机参数
domain_params = sim.randomize_domain()
# 重置环境，但保持任务目标不变
state = env.reset()
while not done:
action = policy(state)
next_state, reward, done, info = env.step(action)
# 关键点：如果仿真环境参数和真实环境差异过大，
# reward 函数需要设计成“鼓励鲁棒性”而不是“完美执行”
# 比如，如果物体滑落了，给予一个巨大的负反馈
if info['object_slipped']:
reward -= 10.0 # 这种惩罚必须够狠，否则模型学不会
为什么仿真跑通的动作，真机上一碰就飞
我在实验室也遇到过这种情况。我们在 PyBullet 里训练了一个抓取模型，成功率 99%。但把代码移植到 Jetson Orin NX 上跑真机时，成功率直接掉到了 20%。为什么？（延伸阅读：HBM3e 短缺正在杀死 80% 的 AI 初创公司：Blackwell B200 的 FP4 与 Transformer 引擎如何重新定义 ROI）
除了传感器噪声，最大的问题是**视觉延迟**。仿真器里计算一帧可能只要 1ms，但 Orin NX 上跑视觉编码器可能要 30ms。这个时间差会导致模型看到的画面是“滞后”的。Figure 01 必须在软件栈里做时间同步和补偿，否则机器人看着杯子在左边，手已经打到了右边。
具身智能的“小脑”工程：实时性与控制栈的博弈
很多非机器人专业的 AI 工程师有个误区，觉得只要把 LLM 跑通就行了。错。机器人是实时系统，你的 LLM 延迟如果是 2 秒，机器人早就摔碎了。
控制回路延迟：LLM 不能等，机器人更不能等
Figure 01 的架构里，GPT-4o 并不是每 20ms 调用一次。那是不可能的。他们的做法是**“规划-执行”分离**。（延伸阅读：为什么 HBM3e 的价格战正在淘汰 90% 的 AI 芯片初创企业：Blackwell B200 的 FP4 是真突破还是营销噱头？）
每隔几百毫秒（比如 100ms），系统才会把当前的视觉画面和任务指令喂给 GPT-4o。GPT-4o 返回一个“动作意图”。然后，一个基于 Model Predictive Control (MPC) 的控制栈会利用这个意图，在接下来的 100ms 内规划出一系列关节指令。这就好比一个象棋大师（GPT-4o）看一眼棋盘，给出一步妙手，然后底下的棋手（MPC）负责把这步棋走好，不走歪。
工程上最难的是**状态估计**。机器人不知道自己手在哪里，除非它看得见。Figure 01 用的是视觉 SLAM（Simultaneous Localization and Mapping）来追踪自己的手部位置。但视觉 SLAM 在工厂这种光照复杂的环境下很容易丢帧。一旦丢帧，控制栈就会进入“盲开”模式，这时候必须启动冗余的 IMU（惯性测量单元）数据作为补充。
安全约束：硬编码的保命符
大模型是概率性的，它可能会说“把杯子扔进垃圾桶”。在代码里，我们得加一层硬编码的安全过滤器。
# 伪代码：安全约束层
# 这层代码是必须的，哪怕 GPT-4o 再聪明
class SafetyMonitor:
def __init__(self):
self.max_joint_velocity = 2.0 # rad/s
self.max_torque = 50.0 # Nm
self.gripper_force_limit = 20.0 # Newton
def check_and_clip_action(self, raw_action):
# raw_action 来自 LLM 的输出 [x, y, z, qx, qy, qz, qw, gripper]
# 1. 关节速度限制
# 假设 raw_action 包含速度指令
if raw_action.velocity > self.max_joint_velocity:
raw_action.velocity = self.max_joint_velocity
print("Warning: Joint velocity clamped!")
# 2. 力矩限制
# 如果是力控模式
if raw_action.force > self.max_torque:
raw_action.force = self.max_torque
print("Warning: Torque clamped!")
# 3. 空间边界检查
# 不能让机器人把手伸到传送带底下（有风险）
if raw_action.position.z < 0.05:
raw_action.position.z = 0.05
print("Warning: Z-axis limit reached!")
# 4. 逻辑安全检查
# 禁止出现会导致自碰撞的动作序列
if self.check_self_collision(raw_action):
raw_action = self.retract_action() # 执行撤退动作
return raw_action
给机器人开发者的建议：从传统控制转向 AI 驱动
如果你现在正准备入局具身智能，别光盯着 LLM 的参数调优了。那只是冰山一角。
学习路径：ROS2 已经过时了吗？
别把 ROS/ROS2 抛弃了。虽然现在的趋势是用 PyTorch 直接写控制栈，但 ROS2 在节点通信和设备驱动管理上依然有优势。我建议你的技术栈是这样的：**ROS2 负责底层的传感器数据和硬件控制，Python/PyTorch 负责中间层的感知和决策，大模型（GPT-4o 或开源的 LLaMA-3-70B）负责高层语义理解。**（延伸阅读：仿真跑了100%通过，实测76%——我的Tesla Optimus具身智能踩坑记）
你需要掌握的不仅仅是深度学习，还有**机器人动力学**。不懂动力学，你就没法调那个 MPC 控制器。不懂 MPC，你就没法把大模型的“意图”转化为物理上可行的“动作”。
评估指标：不要只看成功率
在实验室里，我们喜欢看成功率。但在工厂里，我们看的是 **MTBF（平均故障间隔时间）** 和 **恢复时间**。如果一个机器人能 99% 地完成抓取任务，但一旦失败就需要人工介入修复 10 分钟，那它对工厂来说就是累赘。
Figure 01 最厉害的地方不是它能拿杯子，而是它**能从失败中恢复**。这是目前所有基于模仿学习（Imitation Learning）的模型都做不到的。未来的研究方向，应该是让大模型具备“自我反思”能力——比如当它抓不住物体时，它能意识到“摩擦力不够”，然后自动调整抓握力度。
总的来说，Figure 01 进工厂是一个里程碑，但它离真正的“通用机器人”还有很长的路要走。那条路，就是从“仿真跑通”到“真机稳定”的工程化之路。别被 GPT-4o 的光环骗了，底层的控制算法才是决定生死的根本。
