最近和一个做机械臂项目的朋友聊天他说团队其实不缺模型方案缺的是真正能让模型学会操作的“轨迹数据”。这个问题我在不少具身智能团队里都听过。所以当看到“黎曼动力携手光轮智能与诺亦腾机器人剑指2026年百万小时具身智能数据建设”这条合作信息时我第一反应不是“又一轮数据军备竞赛”而是具身智能行业终于要把数据当工程来做了。为什么这么说百万小时听起来只是一个数字但背后是真实数据采集、动作捕捉、仿真合成、清洗标注、质量评估、版本管理还有整套存储和调度基础设施。如果只是让机器人开着跑很多小时那大概率会得到一堆无法被模型使用的噪音。百万小时的目标真正的价值不在“多”而在于它逼着行业把数据链路建起来。1. 具身智能的瓶颈不在模型而在“可学习的动作数据”1.1 为什么互联网数据救不了机器人大语言模型有海量文本视觉模型有海量图片这些数据并不稀缺。但机器人需要在物理世界中执行动作它学习的不只是“认出杯子”还包括“伸手、抓握、施加多大的力、物体滑动怎么办、抓起来之后往哪放”。这种数据无法从互联网上随便一个大视频里完整得到因为缺少机器人的本体感受、关节力矩、力反馈、触觉以及和动作序列严格对齐的时间信息。语言模型的数据是静态的具身智能的数据是动态且交互的。一个机器人观察到画面之后必须输出一个具体的动作向量这个动作会改变世界然后新状态再进入模型。整个循环里状态转移数据必须是连续、同步、可复现的。1.2 一条可学习样本到底长什么样不少人以为采集数据就是录视频。实际上一条能被模型使用的样本通常包含多个维度的信息。下面是一个简化的元数据示例不代表任何厂商的真实格式但可以说明问题{ sample_id: task_grasp_cup_00001, task: grasp_cup, scene: { object: white_mug, category: cup, pose: [0.35, 0.12, 0.02, 0, 0, 1.57] }, sensors: { rgb_camera: {topic: /camera/color, fps: 30}, depth_camera: {topic: /camera/depth, fps: 30}, joint_states: {topic: /robot/joint_states, fps: 100}, force_torque: {topic: /robot/ft_sensor, fps: 500} }, action: { type: joint_position, dim: 7, controller: positionimpedance }, time_stamp_range: [1700000001.00, 1700000003.42], success: true, source: teleoperation, annotations: {grasp_start: 1700000002.15, lift_start: 1700000002.60} }这条样本至少包含任务语义机器人要干什么场景状态物体在哪、属于什么类别、初始位姿多模态传感器流视觉、深度、关节状态、力/力矩动作序列机械臂、灵巧手或移动底盘的控制指令全局时间戳所有信息流必须能对齐结果标签成功还是失败来源信息真实遥操作、真实自动运行、仿真生成等。实际生产环境里还会更复杂。多个相机、两只机械臂、移动底盘、操作员的人体姿态都可能要同时记录。这时候“百万小时”背后的真实含义是把这么多内容以稳定、可检索、可训练的方式保存下来而不是录一段视频丢进网盘。1.3 “小时数”不是目的数据质量才是上限“百万小时”听起来像对标语言模型的海量数据。但机器人数据不是 token小时数代表的是多模态交互经验信息密度极不均匀。一分钟里可能只有最后一秒成功抓住物体其余都是失败尝试。失败数据也有价值但不加筛选和标注模型就无法区分哪些是有效探索哪些是无效混杂。所以我的判断是百万小时是资源投入目标不是模型效果保证。决定模型效果上限的是有效数据小时、样本多样性、标注质量、传感器同步和任务覆盖度。只有在数据管线稳定之后小时数才有意义。2. 三方合作背后的数据生产矩阵从这条合作信息看黎曼动力、光轮智能、诺亦腾机器人三方组合几乎覆盖了具身智能数据生产的主要方式真机采集、动作捕捉、仿真与合成数据。三者不是替代关系而是互补关系。2.1 真机采集贵但不可替代真实机器人数据最接近部署环境但它也是最贵的。一台机械臂加视觉系统采购、维护、调试都要投入人力。为了让机器人稳定完成同一个任务很多次还需要处理环境变化、物体摆放误差、夹具磨损等各种问题。我经常看到的一个误区是以为真机采集只要有机器人就行。实际落地时一个反复出现的坑是“任务脚本能跑通但数据没法用”。比如只保存了图像和关节角度却没有保存夹爪开合状态或者相机标定变了但元数据里没有记录后续训练时视觉坐标和机器人坐标系对不上。真机数据真正不可替代的部分是真实物理接触。力反馈、滑移、物体形变、柔性材料操作这些很难在仿真里完全还原。所以精细操作任务的最终验证通常仍要落到真机上。2.2 遥操作与动作捕捉把人的操作能力转译成机器人经验很多复杂的精细操作靠程序自动生成轨迹很难。这时候需要人参与。最常见的做法是遥操作操作员通过手柄、主手或 VR 设备控制机器人系统把人的操作过程完整记录下来。遥操作的瓶颈也很明显一位熟练操作员连续工作一小时也很难保证全程高质量疲劳、手抖、认知负荷都会影响数据质量。于是动作捕捉方案被引入把人体手臂、手指的姿态高速记录下来再通过运动学重定向映射到机器人构型。这里要注意动作捕捉数据不能直接扔给机器人。机器人关节数、连杆长度、速度限制、力矩限制跟人体不一样必须做重定向。比如人手五个手指自由度很多但映射到两指夹爪时要重新设计抓取策略否则轨迹根本执行不了。重定向之后还要检查关节限位、碰撞、安全速度和力矩。动作捕捉的价值在于它能捕捉人操作时的自然动作细节。这些细节往往是遥操作里被手柄“过滤”掉的部分。如果一家公司有动作捕捉技术积累它提供的就不只是数据采集设备更是一套“人体操作技能数字化”的方法。2.3 仿真与合成数据批量生产场景但要小心 sim-to-real真实数据贵仿真数据便宜。借助机器人仿真平台和合成数据管线可以批量生成不同物体、不同位置、不同光照、不同纹理的场景。这对扩充长尾场景特别重要。如果合作中的光轮智能承担合成数据方向那它要解决的核心问题就不是“能不能生成场景”而是“生成的场景和真实分布差多远”。行业中常说 sim-to-real 差距最常见的是两种视觉差异仿真图像的材质、光照、传感器噪声和真实相机不一致物理差异仿真里的摩擦、质量、接触力与实际物体不一致。缓解方法也有常规套路域随机化、真实感渲染、仿真与真实混合训练、真实数据微调。但无论怎么做仿真数据都更适合预训练和覆盖场景真机数据更适合校准和最终验证。一个合理的判断是百万小时里很大比例可能来自仿真合成因为真机采集成本太不现实。这不是坏事前提是仿真数据按任务和场景打标签并且和真实数据做分布对齐而不是简单堆数量。下面这张表可以快速理解几种数据来源的差异数据来源成本规模真实性最大问题适合阶段真机自动采集高小最高场景覆盖不足、动作模式单一验证、微调、最终评估遥操作中高中高依赖操作员、稳定性波动精细操作、基础轨迹采集动作捕捉重定向中中高运动学映射和延迟问题人体操作技能迁移仿真合成低很大较低sim-to-real 差距预训练、长尾场景、负样本3. 从“采集小时数”到“可训练数据集”的数据工程链路很多团队一开始都会问“我要不要先买几十台机器人把数据量提上去”我的建议正好相反先定义任务边界再考虑设备和数据规模。3.1 先定义任务边界再开始采集数据采集最怕没有边界。今天采物体抓取明天采倒水后天采叠衣服每个任务的传感器布局、动作空间、评价标准都不一样最后很容易得到一块“什么都有但什么都不可用”的数据堆。更稳妥的做法是在采集前画一张任务定义表任务名称操作物体和场景机器人构型传感器列表和话题名动作空间类型成功判据最小数据量和最大数据量允许的任务变量范围。以“倒水”任务为例必须记录杯子初始水量、倾斜角速度、出水位置、是否洒出。如果成功完成任务后忘了记录“水位”标签模型就学不到关键条件。所以任务定义不是流程文档它本质上是在设计数据模式。3.2 数据管线的四个阶段一个可复用的数据处理链路可以拆成四段数据生成/采集数据清洗与预处理标注与质量验证入库与版本管理。每个阶段都要有明确产出物和检查点。采集阶段产出原始记录比如 bag 包、图像目录、状态日志检查所有话题是否都有数据时间戳是否持续增长。清洗阶段产出“干净序列”去掉异常段、统一采样率、修复可修复的时间戳、剔除传感器漂移段。标注阶段产出任务标签和关键事件比如抓取开始、成功或失败有动作捕捉数据时还要检查重定向后的轨迹质量。入库阶段产出数据集版本原始数据只读每个训练集有明确 schema、采样策略和统计报告。这不是唯一标准但可以作为起步框架。3.3 数据清洗不是做保洁而是保护模型数据清洗时最常遇到的问题有四个时间戳不同步相机 30Hz关节 100Hz力传感器 500Hz不插值对齐模型读到的就是“错位的动作”关节角跳变编码器丢包或异常值直接训练会让模型学到奇怪的抖动操作失败段未标注模型无法区分有效和无效训练结果容易变成平均行为视觉自遮挡严重机械臂挡住相机导致关键物体不可见需要提前设计相机位置。一个参考目录结构可以是data/ raw/ task_grasp_cup_20260101/ ros2.bag sensor_config.yaml task_meta.json clean/ task_grasp_cup_20260101/ images/ joint_states.csv force_torque.csv actions.npz sample_meta.json annotated/ task_grasp_cup_20260101/ labels.json datasets/ grasp_cup_v1/ train/ val/关键原则是原始数据、派生数据、元数据分开永远不要直接修改原始采集文件。3.4 质量门禁先跑通小闭环再放大不要等攒完一万小时再验证。更实际的做法是先采集 1 小时清洗后放进一个小模型或行为克隆基线里跑通训练、评估、失败分析。这样能尽早暴露数据链路的问题。我自己见过的情况是数据采集了三天跑模型之后才发现动作序列和观测差了 200ms。如果等到一万小时以后才发现返工成本会高到难以承受。所以质量门禁的核心是数据不是采集完就结束必须和模型训练形成一个可验证的循环。在这个小规模闭环里真正要回答的问题只有一个给定这段观测模型能不能复现出人类或遥操作产生的动作如果连 1 小时数据都无法学到稳定策略那说明问题不在数据量而在数据质量、同步或标注。4. ROS2、同步与自动化百万小时数据建设的工程底座百万小时不是靠人拿 U 盘考文件存出来的必须有工程底座。这个底座里最容易被忽略的是同步。4.1 同步是命门在 ROS2 机器人系统里采集通常用 ros2 bag record 或多个节点分别记录。最容易踩坑的是时间戳同步。ROS2 话题时间戳由节点在发布时打上如果传感器没有共用时钟或硬件触发多路数据之间的相对延迟可能非常大。更稳妥的方案是使用硬件同步信号触发相机和力传感器并在元数据里记录每个话题的时基。一个常见的记录命令是ros2 bag record \ /camera/color/image_raw \ /camera/depth/image_raw \ /robot/joint_states \ /robot/ft_sensor \ /task/success \ -o data/raw/task_grasp_cup_20260101之后处理时先检查时间戳范围再按目标采样率重采样。不要默认所有话题天然同步。4.2 数据版本管理与自动化百万小时的数据不可能靠人肉管理。原始数据包必须只读。训练数据的筛选、增强、剪裁应该通过脚本生成新版本类似代码分支。可以用 DVC、Git LFS 或自建存储服务但核心是给你一个数据集版本你能知道它是由哪些原始序列、清洗脚本、参数配置生成的。自动化脚本至少要有三类check_raw.py检查原始数据完整性、时间戳增长、文件大小preprocess.py完成重采样、裁剪、格式转换build_dataset.py按任务、场景、成功/失败采样生成训练集。这些脚本不用一开始写得完美但要在第一批数据进来之前写好因为人工处理第一批数据时留下的临时操作往往就是后续所有脏数据的来源。4.3 一条可复用的排查链路如果模型训练效果差不要急着调超参。先按这个顺序排查数据看现象是收敛慢、震荡还是验证集上动作不连贯看样本可视化几条训练样本观察视觉流和动作序列是否存在错位看时间戳同一时刻的关节角、力反馈和相机帧是否在语义上对应同一个物理状态看标注同一任务不同标注员的 success 标签是否稳定看分布训练集和验证集来源是否相同有没有引入分布泄露看仿真和真实差异模型在仿真里表现好、真机差先做 sim-to-real 差距分析。这套链路本质上回答一个问题模型学不好到底是谁的问题很多时候答案不在模型结构而在数据管线。5. 百万小时对从业者和个人开发者意味着什么5.1 数据建设会成为新的行业基础设施随着具身智能公司把数据建设提到 2026 年目标行业会出现更专业的分工数据采集服务商、数据标注团队、数据质检工程师、仿真平台开发者、数据版本管理系统。具身智能的数据工程师不是简单录数据而是同时懂机器人控制、机器视觉、数据工程和模型训练的人。这个角色的价值会越来越明显。因为“能跑通一个模型”和“能稳定生产高质量数据”是完全不同的能力。后者需要理解传感器、控制器、时间同步、文件格式、异常处理、版本管理和模型评估这是一套复合工程能力。5.2 个人开发者不需要焦虑“百万小时”对个人或小团队来说最大的启发不是去模仿大厂建数据中心而是培养“数据工程意识”。在学习阶段从 ROS2 机器人开发、机器人导航、机械臂控制到仿真平台选择都可以把数据质量考虑进去。比如每跑一次仿真都保存场景配置、传感器配置、任务描述和轨迹数据。哪怕只有几小时数据也可以做出有价值的小项目。一个很实际的建议是不要先学一大堆工具链先选一个固定任务把“采集—清洗—训练—评估”跑通。这个流程跑通之后再扩展数据量会容易很多。5.3 三个可以立刻开始的动作选定一个固定任务比如“单臂抓取桌面立方体”搭好传感器记录结构设计一个最小元数据模板包含任务、场景、传感器、时间戳、动作、成功标志用真实机器人或仿真环境采集一小批数据完成一次完整的小规模训练评估。这三步做完比收藏再多学习路线都有用。因为你会亲身体会到数据不是越多越好而是越能被模型使用越好。回到那条合作新闻。百万小时真正考验的不是把机器人开多久而是能不能把原始传感器流变成高质量、可检索、可训练的数据资产。谁能先打通数据从采集到模型反馈的完整流程谁才真正拥有具身智能的长期竞争力。与其关心“百万小时什么时候建成”不如先把自己手上的那一个任务数据做干净。数据质量的边界最终就是模型能力的边界。