具身智能LingBot-VLA：少量数据训练复杂操作新方案

转载自公众号：敢敢AUTOHUB

0. 摘要

LingBot-VLA 由蚂蚁灵波科技推出，是一类 视觉-语言-动作（VLA）基座模型。它的意义并非仅仅“又一款 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 
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_a vailable())"
# 确认权重目录、配置文件和 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
  sa ve_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 微调就不是玄学，而是一套可以迭代的机器人系统工程。