具身智能 | LingBot-VLA：从开源基座到真机后训练，如何用少量数据教会机器人做复杂操作

转载自公众号：敢敢AUTOHUB

0. 摘要

LingBot-VLA 是蚂蚁灵波科技开源的一类 Vision-Language-Action 基座模型。它的价值不只在于“又一个 VLA 模型”，而在于把 大规模真机预训练、跨机器人本体适配、LeRobot 数据生态、真机后训练代码和部署推理流程 放进了同一个开源工程里。根据官方资料，LingBot-VLA 使用 超过 2 万小时真实机器人操作数据 进行预训练，覆盖 9 种主流双臂机器人构型，并在 GM-100 真机基准与 RoboTwin 2.0 仿真任务中给出了与 WALL-OSS、GR00T N1.6、π0.5 等模型的对比结果。

本文不会把这些结果直接等同于任何硬件上的保证，而是从工程复现角度解释：一个开发者怎样 准备环境、采集数据、写 Robot Config、做归一化、微调模型、评估模型，并最终把策略接入真机。

GitHub链接：https://github.com/robbyant/lingbot-vla

图1 LingBot-VLA 官方项目概览图。

1. 为什么 VLA 会成为机器人学习的关键接口

传统机器人系统通常把感知、规划和控制拆得很开：视觉模型负责识别物体，规划器负责算轨迹，控制器负责把轨迹变成关节指令。这种方法在工业结构化场景里很可靠，但面对家庭桌面、厨房、衣物整理、杂乱物体抓取这类开放环境时，工程维护成本会迅速上升。VLA 模型的切入点，是把视觉、语言和动作放进同一个学习框架中，让模型直接根据多视角图像、任务文本和机器人状态预测一段动作序列。 它不是替代底层伺服和安全控制，而是把“我要做什么”和“下一小段动作怎么走”之间的语义鸿沟缩短。

从 OpenVLA、π0/π0.5 到 LingBot-VLA，可以看到一个明显趋势：机器人模型正在从单机单任务的模仿学习，转向多硬件、多任务、多数据源的基础模型路线。 OpenVLA 强调开源 VLA 与大规模机器人数据训练，Physical Intelligence 的 π 系列强调跨形态机器人和开放世界泛化，而 LingBot-VLA 则更明确地把“真机后训练能否低门槛跑通”作为工程目标。对开发者而言，真正有用的不是论文里某个平均成功率，而是当你换成自己的相机、夹爪、机械臂和任务后，系统是否还给你留出了清晰的数据入口和训练入口。

图2 VLA 基本闭环图：模型不直接替代机器人控制栈，而是在感知、任务和动作之间生成策略输出。

2. LingBot-VLA 的核心：更务实的跨本体 VLA 基座

官方把 LingBot-VLA 定位为 “A Pragmatic VLA Foundation Model”，这里的 Pragmatic 可以理解为工程务实。它没有只在单一本体上给出漂亮 Demo，而是把预训练数据扩展到 9 种双臂机器人构型，包含 Agibot G1、AgileX、Galaxea R1Pro 等平台；同时开源了 安装、数据准备、后训练、开环评测和部署推理脚本。对于真机开发来说，这一点很重要，因为多机器人构型意味着模型在预训练阶段见过不同相机布局、不同关节维度、不同夹爪状态和不同动作尺度，后续迁移到新任务时不必从零学习“机器人动作是什么”。

图3 官方给出的数据规模与成功率趋势图。

从技术报告看，LingBot-VLA 的模型设计大体可以理解为三部分：视觉语言模型用于理解图像和文本，动作专家用于生成机器人动作，深度蒸馏版本则额外引入深度信息来增强空间感知。 官方开源权重包含无深度版 LingBot-VLA-4B 和深度版 LingBot-VLA-4B-Depth。

无深度版更适合先跑通流程和常规桌面任务，深度版则更适合存在明显空间歧义的任务，比如透明物体、低纹理物体、遮挡较多的抓取、需要判断前后关系的双臂操作。实际选型时不必一上来就追求深度版，先用无深度版把数据、归一化、训练和部署链路跑通，往往更稳。

3. 不能只看“成功率”，还要看评测是怎样定义的

LingBot-VLA 官方报告中使用了 GM-100 真机基准和 RoboTwin 2.0 仿真任务进行评测。GM-100 覆盖 100 个真实世界操作任务，并在 3 种机器人平台上比较成功率和过程得分；RoboTwin 2.0 则用于模拟环境下的 clean 和 randomized 设置。这样的设计比只展示单个任务视频更有说服力，因为真实机器人任务常常不是二元成功或失败。例如机器人打开微波炉门之后是否正确接触把手、是否拿稳碗、是否关门到位，这些中间过程都会影响最终可用性，所以过程得分能更细致地反映策略质量。

图4 官方给出的 GM-100 评测结果。

不过，开发者在阅读这类结果时需要保持一个清醒判断：基准结果说明模型在官方硬件、官方数据流程、官方评测协议下表现较强，并不意味着换到任何自制平台后都能立刻达到同等效果。 VLA 的真机迁移高度依赖相机标定、动作空间定义、夹爪控制稳定性、数据质量和任务分布覆盖。也正因为如此，LingBot-VLA 真正值得关注的部分不是“官方说它超过了谁”，而是它把 自定义数据接入、Robot Config 映射、归一化统计、真实场景训练配置和部署脚本 都公开了，开发者可以沿着同一条链路验证自己的任务。

图5 官方给出的 RoboTwin 2.0 评测结果。

4. 环境准备：先让代码和权重干净跑起来

LingBot-VLA 官方仓库给出的基础环境是 Python 3.12.3、PyTorch 2.8.0、CUDA 12.8，并提供 install.sh。这类项目最容易出问题的不是训练脚本，而是 CUDA、PyTorch、flash-attn、编译器和显卡驱动之间的组合。建议第一次复现时不要混用旧环境，也不要把系统里已有的 LeRobot、Transformers、flash-attn 版本强行拼进去。 新建 conda 环境虽然看起来麻烦，但能减少大量隐性冲突，尤其是在后面启用 FSDP2、torch.compile 和分布式 checkpoint 时更明显。

conda create -n lingbotvla python=3.12 -y
conda activate lingbotvla

git clone <https://github.com/Robbyant/lingbot-vla.git>
cd lingbot-vla
bash install.sh

模型权重方面，官方在 HuggingFace 和 ModelScope 都提供了入口，国内开发者可以优先使用 ModelScope 降低下载阻力。除了 LingBot-VLA 本体权重，训练和推理还会用到 Qwen/Qwen2.5-VL-3B-Instruct；如果使用深度版，还需要 MoGe-2-vitb-normal 和 LingBot-Depth 相关权重。官方 README 还特别说明，2026-05-01 之前下载过权重的用户可能遇到 LeRobot v2.1 到 v3.0 迁移后的 config.json 字段不兼容问题，稳妥做法是重新下载最新 checkpoint。

python3 scripts/download_hf_model.py \
  --repo_id robbyant/lingbot-vla-4b \
  --local_dir lingbot-vla-4b

4.1 最小使用路径：先不要急着上真机

如果只是验证 LingBot-VLA 是否适合你的团队，建议按 “先环境、再权重、再样例、再自有数据” 的顺序推进。第一步只确认仓库能安装、模型能加载；第二步跑官方 RoboTwin 或已有后训练 checkpoint，确认推理入口没有问题；第三步再把自有数据转成 LeRobot v3.0；第四步才做真机后训练。这样排查问题时边界更清楚：如果官方样例都跑不起来，问题大概率在环境或权重；如果官方样例正常、自有数据失败，问题大概率在数据格式、Robot Config、归一化统计或动作维度。

# 推荐的最小检查顺序
conda activate lingbotvla
python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

# 确认权重目录、配置文件和 tokenizer 可访问
export QWEN25_PATH=/models/Qwen2.5-VL-3B-Instruct
ls lingbot-vla-4b

实际使用时可以把工程目录分成四类：models/ 放预训练权重和 Qwen 权重，datasets/ 放 LeRobot v3.0 数据，assets/norm_stats/ 放归一化统计，output/ 放训练输出和 checkpoint。不要把原始采集数据、转换后数据、训练输出混在同一个目录里，否则后面重训、删错文件、复现实验都会很麻烦。对于小团队，目录清楚比脚本写得复杂更重要。

5. 数据接入：LeRobot v3.0 与 Robot Config 是关键

做具身智能复现的人都知道，真正消耗时间的常常不是模型结构，而是 数据字段对齐。LingBot-VLA 选择全面接入 LeRobot v3.0 数据生态，这是一个很现实的工程选择。LeRobot 已经把机器人数据中的图像、状态、动作、episode 元信息、任务文本等内容组织成相对标准的格式；LingBot-VLA 在此基础上再用 Robot Config 把不同机器人的原始字段映射到统一特征空间。这样做的好处是模型不需要知道你的原始数据叫 cam_high、top_rgb 还是 observation.images.camera_top，只要映射清楚即可。

states:
  - observation.state.arm.position:
      origin_keys:
        - observation.state:
            start: 0
            end: 6
        - observation.state:
            start: 7
            end: 13

  - observation.state.effector.position:
      origin_keys:
        - observation.state:
            start: 6
            end: 7
        - observation.state:
            start: 13
            end: 14

actions:
  - action.arm.position:
      origin_keys:
        - action:
            start: 0
            end: 6
        - action:
            start: 7
            end: 13
      subtract_state: False

images:
  - observation.images.camera_transform: translateY(
      origin_keys: observation.images.cam_high
  - observation.images.camera_wrist_left:
      origin_keys: observation.images.cam_left_wrist
  - observation.images.camera_wrist_right:
      origin_keys: observation.images.cam_right_wrist

上面这段来自官方 RoboTwin 配置思路，核心是 “切片、拼接、改名”。左臂和右臂关节可能存在于同一个 observation.state 向量里，夹爪开合也可能夹在中间；Robot Config 通过 start 和 end 明确告诉训练管线哪些维度属于手臂，哪些维度属于末端执行器。真实机器人上还要特别注意动作是绝对位置还是相对增量。官方自定义数据指南建议真实数据中 action.arm.position 可以考虑用 subtract_state: True 学相对动作，而 action.effector.position 通常保持绝对值，这与夹爪开合状态的物理意义更匹配。

CUDA_VISIBLE_DEVICES=0 bash train.sh scripts/compute_norm.py \
  ./configs/vla/real_load20000h.yaml \
  --data.data_name my_robot \
  --data.train_path /data/lerobot_v3/my_task \
  --data.norm_stats_file assets/norm_stats/my_task_norm.json

归一化统计不能省略。机器人动作的数值尺度差异很大，有的机械臂关节用弧度，有的控制接口用归一化位置，有的夹爪状态是 0 到 1，有的是脉宽或毫米。模型如果直接吃这些未经处理的数值，很容易把某些维度当成“天然更重要”。 LingBot-VLA 官方配置中真实场景推荐 meanstd，RoboTwin 仿真任务使用 bounds_99，这说明真实数据和仿真数据的噪声分布并不相同，照抄配置前应先理解自己的数据来源。

5.1 如何把自己的机器人接进来

把自有机器人接入 LingBot-VLA 时，最重要的是先写一张“字段对照表”。例如你的原始数据里可能有 joint_pos[0:6] 表示左臂，joint_pos[6:12] 表示右臂，gripper[0:2] 表示左右夹爪；相机可能叫 front_rgb、left_hand_rgb、right_hand_rgb。在进入训练前，应该先明确这些字段分别对应 LingBot-VLA 训练配置中的 arm.position、effector.position、camera_top、camera_wrist_left、camera_wrist_right。字段对照表写不清楚，就不要急着训练，因为模型训练失败时你很难判断是策略没学会，还是输入本身错位了。

一个实用做法是先写一个小的检查脚本，随机抽取 5 条 episode，把图像、关节曲线和夹爪曲线画出来。只要你发现“机器人明明向左动，曲线却像右臂在动”，或者“夹爪闭合时数值反而变成打开”，就先修数据，不要继续训练。数据检查比训练更便宜，越早发现越省时间。

6. 数据采集：一条好数据不是视频，而是一段可学习的控制经验

很多初学者会把数据采集理解成“多录几段成功视频”。这在 VLA 微调里远远不够，因为 模型真正学习的是观察、语言、状态和动作之间的条件关系。一条合格 episode 至少要包含同步的多视角图像、机器人状态、动作指令、任务文本、episode 边界、成功标记和异常标记。相机时间戳、控制频率、夹爪状态、动作空间单位也必须稳定，否则模型看到的世界会被时间错位污染。尤其在双臂任务中，左右腕相机的时序漂移、夹爪闭合延迟、桌面坐标系偏差都会变成训练集里的隐性噪声。

{
  "episode_id": "fold_towel_main_0037",
  "task": "fold the towel in half from a random pose",
  "stage": "main_random",
  "robot": "dual_arm_v1",
  "control_hz": 20,
  "cameras": ["camera_top", "camera_wrist_left", "camera_wrist_right"],
  "success": true,
  "initial_state": {
    "object_pose": "random_rotation_random_wrinkle",
    "cloth_type": "small_towel",
    "lighting": "normal"
  },
  "notes": "right gripper regrasped the far corner once before final fold"
}

我更推荐把每条 episode 当成 “带标签的经验样本”，而不是简单的轨迹文件。采集时可以额外记录 stage、失败原因、是否重抓、是否发生碰撞、是否偏离任务区域、是否人为中断。后面做数据清洗时，这些字段会非常有用。比如一个叠毛巾任务失败了，如果失败原因是夹爪打滑，这条数据仍然可能作为 recovery 数据；如果失败原因是操作者误操作撞到相机支架，那么这条数据应当剔除。VLA 不是魔法，低质量数据越多，模型越容易学会不稳定动作。

6.1 采集时具体怎么做

实际采集时建议采用 “固定脚本 + 人工遥操作 + 自动记录元信息” 的方式。固定脚本负责每条 episode 的开始、结束、保存、编号和相机同步；人工遥操作负责完成任务；元信息记录负责保存任务名称、阶段、成功与否、失败原因和环境变化。这样做的好处是操作者只需要专注于把任务做好，不需要每次手动整理文件名。对于叠衣服这类任务，单条 episode 可以从机器人看到初始布料开始，到完成压平或判定失败结束，避免把一次完整操作切得过碎。

# 示例：采集一条叠毛巾 main task 数据，具体脚本名需要按自己的采集系统实现
python tools/record_episode.py \
  --task "fold the towel in half from a random pose" \
  --stage main_random \
  --robot dual_arm_v1 \
  --control_hz 20 \
  --cameras camera_top,camera_wrist_left,camera_wrist_right \
  --output /data/raw/fold_towel_v1

采集完一批数据后，不要马上训练。更好的流程是先抽样回放：每个阶段随机抽 5 条，检查图像是否同步、左右腕相机是否遮挡、关节曲线是否连续、夹爪开合是否符合操作过程、episode 开始和结束是否干净。如果一条数据开头已经在半路状态，或者结尾还没有完成任务就停止，模型会把这种不完整经验当成正常样本学习。 这类问题在小数据微调里影响很大，因为 200 条数据中只要混入 20 条质量差的样本，就已经占了 10%。

7. 从字母块分拣看四阶段采集法：少量数据为什么可能有效

你给出的字母块案例很适合作为小样本后训练的范式：第一阶段让单个字母块从固定初始位置被夹取，每个字母大约 15 条，用于 cold start；第二阶段让四个字母在桌面随机摆放，机器人一次性按顺序抓取，这是 main task，大约 50 条；第三和第四阶段加入 recovery，例如人为打乱顺序、把字母偏离原位置、制造夹取后的异常摆放，让模型学会从非标准状态恢复，两个阶段合计约 100 条。总量大约 200 条，如果不考虑 recovery，从随机状态分拣方块约 100 条可能已经能做得很好；如果只训练第二阶段 50 条，理论上也可能起效，但鲁棒性需要真机验证。

这个四阶段设计的本质不是“凑够 200 条”，而是把任务分布拆成了 从简单到复杂、从标准到异常的课程学习。cold start 让模型先学会基本视觉定位和夹取动作，main task 让模型学习完整任务链，recovery 让模型见到偏离训练主路径的状态。复杂任务失败常常不是因为模型不会做第一步，而是因为第二步之后物体状态稍微变了，模型就进入了没见过的状态空间。把 recovery 单独采出来，等于是主动把模型可能失败的状态提前放进训练分布。

8. 迁移到叠衣服：难点从“识别物体”变成“控制形变”

叠衣服和字母块分拣的最大差别在于 对象是否可变形。字母块是刚体，抓取后形状不变，模型主要处理位置、朝向和顺序；毛巾、T 恤、布料是柔性物体，同一个动作会因为材质、褶皱、抓点、拉力和摩擦产生不同形变。也就是说，叠衣服任务的关键不是让模型知道“这是毛巾”，而是让它学会 识别角点、拉平布面、建立折线、协调双臂张力，并在某个角点没抓稳时重新调整。因此，叠衣服的数据量不能只按最终成功次数计算，还要按关键状态覆盖来设计。

一个更稳妥的叠毛巾数据方案可以分成四层。第一层是固定姿态 cold start，例如毛巾平铺、四角清晰、折线固定，采 30 到 50 条，让模型先学“抓两个角、抬起、对折、压平”这条主路径。第二层是 main task，例如毛巾在桌面上随机平移、旋转、轻微褶皱，采 80 到 120 条，让模型学会从随机初始状态完成完整折叠。第三层是 recovery，例如单侧角点没抓住、毛巾被拉歪、对折后边缘错位，采 80 到 150 条。第四层是 domain randomization，例如不同颜色、不同厚度、不同光照和桌面摩擦，视目标场景再加 50 到 200 条。这里的数量不是硬性公式，而是一个工程起点：先让模型覆盖关键状态，再用真机失败案例反向补数据。

如果你要用 LingBot-VLA 做叠衣服，建议先从 小方巾或毛巾对折 开始，而不是直接做完整 T 恤折叠。第一版任务只定义一个清晰目标：机器人从随机轻微褶皱状态中找到两个角点，抓起、对齐、放下并压平。这个任务足够体现柔性物体操作难点，又不会像 T 恤那样引入袖子、领口、正反面判断。等毛巾对折稳定后，再扩展到二次折叠、T 恤袖子折叠和分类叠放。

实际执行时可以按下面的顺序推进：第一周只采固定姿态毛巾数据，目标是让模型能稳定完成一次对折；第二周加入随机平移、旋转和轻微褶皱，目标是提升初始状态泛化；第三周专门采失败恢复，包括抓偏、滑落、折线歪斜和角点遮挡；第四周再换颜色、材质和光照。不要在第一轮就把所有变化全部打开，否则模型看到的是一团混乱分布，而不是可以逐步学习的任务结构。

9. 微调训练：先跑通最小闭环，再逐步扩大数据

当数据准备成 LeRobot v3.0，并且 Robot Config 与归一化统计都完成后，就可以进入真机后训练。官方真实场景推荐配置文件是 configs/vla/real_load20000h.yaml 和 configs/vla/real_load20000h_depth.yaml。默认参数里包含 FSDP2、torch.compile、micro_batch_size、gradient_accumulation_steps、max_steps、checkpoint 管理和 fp32 action expert 等设置。第一次训练不要急着调太多参数，建议只改数据路径、data_name、归一化文件和输出目录，先确认 loss 能正常下降、checkpoint 能正常保存、开环评测能读取模型。

bash train.sh tasks/vla/train_lingbotvla.py \
  ./configs/vla/real_load20000h.yaml \
  --data.data_name my_robot \
  --data.train_path /data/lerobot_v3/fold_towel_v1 \
  --data.norm_stats_file assets/norm_stats/fold_towel_v1_norm.json \
  --train.output_dir output/fold_towel_v1

如果显存不足，优先降低 micro_batch_size，再通过 gradient_accumulation_steps 把 global batch size 补回来。官方 Training Config 中给过一个 4 张 A6000 的例子：micro_batch_size=4、gradient_accumulation_steps=16 时，global batch size 仍然可以达到 256，但显存占用接近 48GB。对小团队来说，训练效率不是单纯追求最大 batch，而是要在显存、训练时长、过拟合风险和数据量之间折中。只有 100 到 200 条真机数据时，过长训练可能让模型记住采集者习惯，而不是学会任务本身。

train:
  output_dir: "output/fold_towel_v1"
  data_parallel_mode: fsdp2
  use_compile: true
  lr: 5.0e-5
  micro_batch_size: 4
  gradient_accumulation_steps: 16
  max_steps: 20000
  save_steps: 5000
  enable_fp32: true
  enable_resume: true

真实微调时我建议采用 “三轮训练法”。第一轮只用 cold start 和 main task，训练较短步数，验证模型是否能完成基本动作；第二轮加入 recovery 数据，观察失败状态是否减少；第三轮加入鲁棒性数据，并减少重复成功样本的比例。这样做的好处是每次模型变化都能解释。如果一开始把所有数据混在一起训练，模型表现不好时很难判断问题来自数据标注、动作空间、归一化、训练步数，还是 recovery 数据比例过高。

9.1 一次完整微调应该怎么安排

对于一个新任务，可以把训练安排成三次实验，而不是一次训练到底。run_01_base 使用 cold start 和 main task，目标是验证模型是否学会主路径；run_02_recovery 在第一版基础上加入 recovery，目标是减少中途卡死和抓偏后的失败；run_03_robust 加入颜色、光照、材质和轻微布局变化，目标是让模型从“能演示”变成“能在现场反复跑”。每一轮都要保留独立输出目录和评估记录，方便回退到表现最好的版本。

# 第一轮：主路径训练
bash train.sh tasks/vla/train_lingbotvla.py ./configs/vla/real_load20000h.yaml \
  --data.data_name my_robot \
  --data.train_path /data/lerobot_v3/fold_towel_base \
  --data.norm_stats_file assets/norm_stats/fold_towel_base_norm.json \
  --train.output_dir output/fold_towel/run_01_base

# 第二轮：加入 recovery 数据
bash train.sh tasks/vla/train_lingbotvla.py ./configs/vla/real_load20000h.yaml \
  --data.data_name my_robot \
  --data.train_path /data/lerobot_v3/fold_towel_recovery \
  --data.norm_stats_file assets/norm_stats/fold_towel_recovery_norm.json \
  --train.output_dir output/fold_towel/run_02_recovery

判断训练是否值得继续，不要只看 loss。更应该看三件事：第一，开环评测中动作方向是否符合常识；第二，真机低速测试时是否能稳定进入正确阶段；第三，失败案例是否集中在少数状态。如果失败分布很集中，例如总是在抓第二个角点时滑落，那就补采这个状态的 recovery 数据；如果失败非常随机，优先检查相机同步、动作维度和归一化，而不是盲目增加训练步数。

10. 开环评测与真机部署：不要跳过中间检查

训练完成后，先用开环评测而不是直接上真机。开环评测不能证明机器人一定成功，但可以快速发现明显问题，例如模型输出动作维度不对、夹爪维度异常、动作幅度过大、语言指令没有被正确读取、checkpoint 缺少 lingbotvla_cli.yaml 等。官方提供的 scripts/open_loop_eval.py 可以指定后训练 checkpoint 和验证数据路径。建议把验证集单独留出 10% 到 20%，并确保其中包含不同初始状态和少量 recovery 场景。

export QWEN25_PATH=/models/Qwen2.5-VL-3B-Instruct

python scripts/open_loop_eval.py \
  --model_path output/fold_towel_v1/checkpoints/step_20000/hf_ckpt \
  --data_path /data/lerobot_v3/fold_towel_val \
  --use_length 50

真机部署时，LingBot-VLA 提供 deploy.lingbot_vla_policy 作为推理服务入口。部署层通常只负责模型推理和动作序列输出，真正发给机械臂的控制还需要你自己的机器人桥接层，例如 ROS2 节点、厂商 SDK 或实时控制进程。这里必须加安全阈值：动作限幅、速度限幅、夹爪力限制、工作空间边界、急停通道和人工接管。VLA 的输出是一段预测动作，不是经过形式化验证的安全轨迹，因此部署时应把它放在受控执行框架里，而不是直接放开给底层执行器。

export QWEN25_PATH=/models/Qwen2.5-VL-3B-Instruct

python -m deploy.lingbot_vla_policy \
  --model_path output/fold_towel_v1/checkpoints/step_20000/hf_ckpt \
  --use_compile \
  --use_length 25

# 伪代码：把 VLA 推理服务输出接入机器人控制层时，必须保留安全过滤。
def execute_action_chunk(action_chunk, robot):
    for action in action_chunk:
        action = clip_joint_delta(action, max_delta=0.05)
        action = enforce_workspace_limit(action, robot.workspace)
        if robot.estop_pressed() or robot.force_too_large():
            robot.stop()
            return "aborted"
        robot.send_action(action)
    return "ok"

10.1 真机第一次使用的安全流程

第一次真机部署时，建议把机器人放在空桌面上，先不放目标物体，只观察模型输出是否会让机械臂朝危险方向运动。第二步放入目标物体，但把速度限制到正常速度的 20% 到 30%，并把动作幅度限制到很小的关节增量。第三步只执行前 3 到 5 个 action chunk，确认模型能稳定靠近目标后，再逐步放开执行长度。不要第一次就让模型完整执行长任务，尤其不要在夹爪、桌沿、相机支架和人手附近直接全速运行。

真机评估建议记录四类指标：任务是否最终成功、失败发生在哪个阶段、失败是否可恢复、是否出现安全过滤触发。对于叠衣服，最终成功率并不能完全说明问题，因为“找到角点、抓起、对齐、放下、压平”每一步都有独立价值。可以把一次运行拆成 5 个阶段打分，这样你会更快知道该补哪类数据。如果模型总能找到角点但放下时对不齐，应该补对齐和压平数据；如果模型经常找错角点，应该补初始视觉状态和角点遮挡数据。

11. 一套可落地的实现流程

如果把整套流程压缩成工程路线，它并不复杂：先确定任务和硬件动作空间，再采集少量高质量 cold start 数据，接着采集 main task 和 recovery 数据，然后转换到 LeRobot v3.0，写 Robot Config，计算归一化统计，启动后训练，做开环评测，最后在真机上小步试运行。真正容易失败的是两个地方：一是数据采集阶段没有控制变量，导致模型学不到稳定规律；二是部署阶段缺少安全过滤，导致模型偶发输出被放大成真实风险。 只要这两点守住，小样本迁移就有实际操作空间。

图6 建议用 Gemini 生成的完整实现流程图。复杂任务不是一次训练结束，而是“部署、观察、补采、再训练”的循环。

12. 结论

LingBot-VLA 最值得肯定的地方，不是某张表里的单项成绩，而是它把 VLA 从“看论文和视频”推进到“开发者可以按流程接自己的数据”。它把大规模真机预训练、LeRobot 标准格式、Robot Config 映射、后训练配置、开环评测和部署推理连接起来，让小团队有机会用 100 到 300 条高质量演示去验证一个真实任务。

对复杂任务来说，真正的核心不是盲目增加数据，而是像字母块分拣那样设计阶段：先 cold start，后 main task，再 recovery，最后做鲁棒性覆盖。只要数据分布设计得足够清楚，VLA 微调就不是玄学，而是一套可以迭代的机器人系统工程。