最近圈内有一条消息值得关注一家做具身智能数据的团队在 40 天内连续完成两轮融资。这个节奏放在大模型时代不算稀奇但放在机器人赛道信号意义完全不同——资本正在从“抢模型”转向“抢数据”。更准确地说是在抢那些能把数据真正工程化、产品化、可交付的团队。过去很多人对“具身数据”的理解还停留在“给机器人拍视频、打标注”的阶段。但 40 天融两轮的节奏说明这个领域已经不再是学术试验田而是一条正在快速工业化的赛道。真正被资本看重的不是数据本身而是把数据变成可训练资产的全套工程能力采集、清洗、标注、合成、评测、回流。这套能力恰恰是“实战派”团队的长项。这篇文章想讲清楚三件事具身数据和传统 AI 数据到底有什么区别为什么资本会在这个时间点密集押注数据公司以及作为开发者如果你想切入这条赛道应该从哪几项技术能力入手。1. 为什么“具身数据”突然值得关注先看一个背景。具身智能Embodied Intelligence指的是让 AI 拥有身体能够在真实物理环境中感知、决策、行动。机器人、自动驾驶、机械臂、人形机器人都属于具身智能的范畴。过去一年大模型在语言和图像上取得了巨大突破但机器人领域的进展明显滞后。原因不是模型不够强而是数据不够用。语言模型有互联网文本图像模型有海量图片但机器人模型缺的是“动作数据”——也就是“在什么状态下执行什么动作得到什么结果”这种三元组数据。这类数据获取成本极高需要真实设备、真实场景、真实操作远不是爬虫能解决的。40 天融两轮表面上说明资本对具身智能赛道热情不减更底层的原因是上游模型和硬件都在快速成熟数据成了卡脖子的环节。人形机器人本体已经能稳定行走机械臂精度也足够高但训练一个可泛化的操作模型仍然需要成千上万条高质量轨迹数据。谁能把数据供给跑通谁就能占据产业链的关键位置。需要强调的是这篇文章不想夸大融资本身。融资快不代表技术一定领先但它传递了一个行业信号具身数据已经从“学术研究中的辅助工具”变成了“产业竞争中的核心资产”。在这个转折点了解数据的采集、加工、评测、回流全流程比追逐某个模型架构更有现实价值。2. 具身智能与具身数据先搞清楚这几个概念2.1 什么是具身智能具身智能直白说就是“有身体的 AI”。它不只是会聊天、会画图还要能在物理世界里行动。比如机械臂根据视觉信息抓取物体人形机器人端茶倒水、整理桌面四足机器人爬楼梯、跨越障碍自动驾驶汽车识别路况并作出驾驶决策。具身智能的三个核心能力是感知、决策、执行。感知负责理解环境决策负责规划动作执行负责控制身体。这三个能力中前两个可以部分依赖预训练模型但执行——也就是真实物理世界的动作控制——必须依赖真实或仿真数据来训练。2.2 什么是具身数据具身数据是用于训练具身智能模型的数据核心形式是“感知-动作-反馈”序列。典型的具身数据包括机器人关节角度、力矩、速度等状态数据视觉、触觉、力觉等多模态感知数据人类操作示范的轨迹数据仿真环境中生成的合成数据任务完成后的结果反馈数据。2.3 具身数据与传统 AI 数据的核心区别这是理解整个赛道的关键用一张表来对比对比维度传统 AI 数据NLP/CV具身数据数据类型文本、图片、音视频多模态时序数据感知动作反馈获取方式爬虫、公开数据集、人工标注真机采集、遥操作、仿真合成标注成本相对较低高需要专业设备和人员数据规模海量TB 到 PB 级稀缺高质量数据尤其少通用性较强一个模型可处理多种任务较弱高度依赖具体环境和本体质量评估相对明确有公认指标困难需要结合任务效果评估从表中可以看到具身数据的最大特征是“稀缺”和“高成本”。这也是为什么数据公司能独立成赛道不是随便拉几个人就能批量产出高质量具身数据。2.4 为什么“数据 Scaling Law”在机器人上失效了大模型领域有一个共识更多数据、更大参数就能带来更好效果。但在机器人领域这个规律遇到了两个挑战。第一机器人的数据分布极端不均匀。一个抓取任务可能在特定光照、特定桌面、特定物体上表现很好但换一个环境就失效。数据的“域偏移”domain shift比语言模型严重得多。第二机器人数据的“浓度”比“数量”更重要。1000 条高质量、多样化、任务明确的轨迹数据训练效果可能远超 10 万条重复、低质的演示数据。单纯堆量对机器人训练的帮助非常有限。这意味着具身数据公司不能只做“数据生产商”还必须做“数据精炼商”。谁能设计出更高效的数据采集方案、更严格的质量筛选机制、更聪明的数据增强策略谁就能建立起真正的壁垒。3. 具身数据产业的三层结构与玩家分化具身数据虽然听起来很新但产业链已经初步成型。从产业分工来看大致可以分为三层。3.1 数据采集层硬件和场景密集型这一层解决“数据从哪来”的问题。主要玩家包括拥有机器人本体的公司利用自有设备采集数据专业数据服务公司搭建数据采集场雇佣操作员进行遥操作采集仿真平台公司提供高保真虚拟环境批量生成合成数据。这一层的核心竞争力是设备数量、场景覆盖度、采集效率。举例来说同一个抓取任务有的团队一次只能采一条轨迹有的团队通过多机并行和自动化采集一天能产出数百条有效轨迹。这种效率差异长期会演变成数据规模差异。3.2 数据处理层质量和标准密集型这一层解决“数据怎么变成训练可用资产”的问题。包括数据清洗去除无效帧、异常传感器读数数据标注语义分割、物体框、动作意图标注数据增强仿真转真Sim-to-Real迁移、场景随机化数据格式标准化统一为模型训练所需的结构化格式。这一层是最容易被低估的也是“实战派”优势最明显的地方。很多算法团队能写好模型但面对脏乱差的真机数据往往束手无策。而真正做过数据工程的人知道一套严谨的数据质量评估体系往往比模型调参更能提升最终效果。3.3 数据应用层场景和模型密集型这一层解决“数据怎么用起来”的问题。典型的工作包括构建机器人基础模型的预训练数据集针对特定任务的微调数据集数据飞轮设计模型在实际使用中持续收集新数据回流到训练集数据评测基准定义什么样算“好数据”。这一层离模型最近也最容易产生学术和商业价值。融资消息中提到的“实战派”通常就是能同时打通三层、形成完整数据闭环的团队。从目前行业格局来看纯做采集的团队面临同质化竞争压力纯做合成数据的团队要解决仿真到真实的迁移问题而具备“采、处、用”一体化能力的团队更容易形成壁垒。这也是 40 天连融两轮的逻辑所在——资本在投的不是一个数据仓库而是一条可运转的数据生产线。4. 一条具身数据管线的完整技术拆解理解了产业背景我们回到技术本身。一条完整的具身数据管线通常包含五个环节。4.1 任务定义与场景设计任何一条具身数据的第一步不是开机采集而是定义清楚任务。要明确机器人要完成什么任务抓取、搬运、插拔、折叠等在什么环境下完成家庭、工厂、实验室、户外使用什么本体单臂、双臂、人形、四足数据要训练什么模型视觉抓取模型、操作策略模型、导航模型。这些决策直接影响采集方案设计。比如训练一个家庭场景的抓取模型可能需要多样化的桌面背景、光照条件和物体组合训练一个工业插拔任务则需要严格控制机械臂的力控参数和夹具开合行程。4.2 数据采集采集方式通常有三种真机采集、遥操作和仿真生成。真机采集是指让机器人按照预设程序执行动作同时记录传感器数据。这种方式数据真实度高但成本高、效率低。遥操作是指人类操作员通过示教器、力反馈设备或动作捕捉服远程控制机器人完成操作同时记录操作轨迹。这种方式适合采集复杂操作任务是目前主流方案。仿真生成是指在物理引擎中构建虚拟环境和机器人模型批量生成数据。这种方式成本低、规模大但存在 Sim-to-Real 迁移问题。三种方式各有优劣实际项目中通常是组合使用仿真数据做预训练真机和遥操作数据做微调。4.3 数据处理与标注采集完成后原始数据需要经过多道工序时序对齐同步对齐相机帧和关节状态异常剔除去除传感器断线、遮挡严重的片段动作分段把连续操作切分为有语义的原子动作语义标注为每个片段标注任务描述、物体信息、成功/失败标签轨迹后处理平滑噪声、修复缺失帧、统一坐标系。这一步是整个数据管线中最花人力的环节。一个成熟的数据团队通常会开发半自动化的标注工具让人工只处理算法无法判断的部分。4.4 数据版本管理与数据评测数据资产和代码一样必须有版本管理。同一个模型用 v1 数据和 v2 数据训练效果可能天差地别。如果没有数据版本管理就无法定位模型效果变化的原因。数据评测也是一个容易被忽略但极其重要的环节。常用的评测指标包括数据完整性缺失帧比例、传感器异常比例动作多样性关节角度分布、轨迹差异度任务成功率按此数据训练的模型在真实环境中的成功率数据偏差场景、物体、动作的分布是否均衡。4.5 数据回流与飞轮构建数据管线最后一步是把模型在真实使用中产生的数据筛选、清洗后重新加入训练集形成“数据飞轮”。这一步做得好数据资产会随着时间指数级增值做得不好数据集只是静态的“死水”。数据飞轮的实现需要一个重要前提可追溯。每条数据都要能回溯到采集时间、设备、场景、操作员和模型版本。否则当模型效果出现问题时整个数据链条会变成一团乱麻。5. 最小可运行的具身数据流水线示例理论讲完了接下来用一个最小示例演示如何构建一个简化版的具身数据流水线。这个示例不依赖真实机器人重点展示数据管线的工程组织方式。5.1 项目目录结构embodied-data-pipeline/ ├── config/ │ └── task.yaml ├── data/ │ ├── raw/ │ └── processed/ ├── scripts/ │ ├── collect_demo.py │ ├── validate_data.py │ └── split_dataset.py ├── annotations/ │ └── episode_001.json └── requirements.txt5.2 任务配置文件文件路径config/task.yamltask: name: grasp_coke_can instruction: 抓取桌面上的可乐罐放到右侧托盘 robot: type: single_arm joint_count: 7 camera_count: 2 environment: scene: tabletop lighting: [bright, normal, dim] background: [white, wood, mixed] objects: - name: coke_can weight: 350g size: standard_330ml - name: tray location: right_side data_format: obs: [rgb_left, rgb_right, depth_left, depth_right, joint_pos, joint_vel] action: [joint_target, gripper_command] reward: task_success sampling_rate: 30这个配置的核心作用是“标准化采集元信息”。所有采集任务都必须引用一个 task.yaml这样后续处理时每个数据文件都知道自己在做什么任务、用什么设备、记录什么信息。5.3 数据标注文件示例文件路径annotations/episode_001.json{ episode_id: episode_001, task: grasp_coke_can, robot: { type: single_arm, joint_count: 7 }, sensor_count: 2, duration_sec: 12.5, frame_count: 375, result: { task_success: true, place_position_ok: true }, segments: [ { segment_id: 1, action_type: reach, start_frame: 0, end_frame: 88, description: 机械臂移动到可乐罐上方 }, { segment_id: 2, action_type: grasp, start_frame: 89, end_frame: 156, description: 闭合夹爪抓住可乐罐 }, { segment_id: 3, action_type: place, start_frame: 157, end_frame: 374, description: 移动到托盘上方并放下 } ] }5.4 数据质检脚本文件路径scripts/validate_data.pyimport json from pathlib import Path def validate_episode(annotation_path: Path, min_frames: int 100) - dict: 校验单条数据是否符合基本质量要求。 report {episode_id: None, passed: False, issues: []} with open(annotation_path, r, encodingutf-8) as f: data json.load(f) report[episode_id] data.get(episode_id) frame_count data.get(frame_count, 0) if frame_count min_frames: report[issues].append( fframe_count{frame_count} {min_frames} ) segments data.get(segments, []) if not segments: report[issues].append(no segments found) else: for seg in segments: if seg[end_frame] seg[start_frame]: report[issues].append( fsegment {seg[segment_id]} has invalid frame range ) # 检查关键字段 required_fields [task, robot, sensor_count, result] for field in required_fields: if field not in data: report[issues].append(fmissing field: {field}) report[passed] len(report[issues]) 0 return report if __name__ __main__: annotation_dir Path(annotations) for json_file in sorted(annotation_dir.glob(*.json)): result validate_episode(json_file) status PASS if result[passed] else FAIL print(f[{status}] {result[episode_id]}) for issue in result[issues]: print(f - {issue})这个脚本只做最简单的校验帧数是否达标、动作分段是否合法、关键字段是否缺失。真实项目中还需要检查传感器数据的时间戳对齐、关节值的取值范围、图像是否有大面积遮挡等。5.5 数据集划分脚本文件路径scripts/split_dataset.pyimport json import random from pathlib import Path def split_annotations(annotation_dir: Path, train_ratio: float 0.7, val_ratio: float 0.15, seed: int 42): 将标注数据按 episode 为粒度划分为 train/val/test 三份。 具身数据必须按 episode 切分不能按帧随机切分 否则同一段轨迹会同时出现在训练集和测试集中。 random.seed(seed) episodes sorted(annotation_dir.glob(*.json)) random.shuffle(episodes) train_end int(len(episodes) * train_ratio) val_end int(len(episodes) * (train_ratio val_ratio)) train_set episodes[:train_end] val_set episodes[train_end:val_end] test_set episodes[val_end:] split_info { train: [p.name for p in train_set], val: [p.name for p in val_set], test: [p.name for p in test_set], } output_path Path(data/split_info.json) with open(output_path, w, encodingutf-8) as f: json.dump(split_info, f, ensure_asciiFalse, indent2) print(ftrain: {len(train_set)} episodes) print(fval: {len(val_set)} episodes) print(ftest: {len(test_set)} episodes) print(fsplit info saved to {output_path}) if __name__ __main__: split_annotations(Path(annotations))这里有一个非常重要的工程细节数据集划分必须按 episode完整轨迹为粒度进行千万不能把同一段轨迹的帧拆开放进训练集和测试集。否则模型在测试时相当于“见过”了训练数据评估结果会虚高。这个问题在具身数据中比常规 CV 数据更隐蔽因为一段轨迹可能包含几百帧肉眼很难发现交叉。5.6 运行整个流水线# 1. 创建环境并安装依赖这里仅假设需要 json, pyyaml, pathlib pip install pyyaml # 2. 校验注释文件 python scripts/validate_data.py # 3. 划分数据集 python scripts/split_dataset.py预期输出[PASS] episode_001 [PASS] episode_002 ... train: 70 episodes val: 15 episodes test: 15 episodes split info saved to data/split_info.json如果所有文件都通过校验就可以把data/split_info.json交给模型训练团队。这个流程保证了任何人拿到数据都能知道数据来自什么任务、包含什么内容、经过什么校验不会出现“黑盒数据”问题。6. 运行结果与效果验证6.1 如何判断数据质量合格运行完脚本只是一个开始。真正判断数据是否合格需要从三个层面验证。第一工程层面。确认所有数据都能被正确读取格式统一字段完整。这一步由 validate_data.py 完成。第二分布层面。可视化关节角度分布、任务成功/失败比例、场景覆盖度确认数据没有明显的单边分布。比如如果 95% 的数据都是任务成功样本模型可能学到的是“不管怎样都算成功”的偷懒策略。第三模型层面。用一批数据训练一个小模型在真实环境或高保真仿真环境中测试任务成功率。这是最终标准。如果模型用这批数据训练后任务成功率明显高于随机策略说明数据确实包含了有效信息。6.2 失败排查第一步看哪里如果模型训练效果不佳不要立刻调模型结构先回头检查数据标注是否准确分段边界是否合理成功/失败标签是否可靠数据是否均衡场景、物体、动作类型是否覆盖全面数据是否交叉训练集和测试集是否数据泄漏传感器是否对齐多相机帧和关节状态时间戳是否一致策略是否可复现同一个数据被多次训练效果是否稳定。7. 常见问题与排查方法问题现象可能原因排查方式解决方案模型训练损失不下降数据中存在大量噪声帧检查传感器数据和标注一致性增加异常数据清洗环节剔除坏帧仿真效果好真机效果差Sim-to-Real 迁移不足对比仿真和真机的传感器分布加入域随机化引入更多真机微调数据模型频繁重复动作轨迹分段不准确可视化每段轨迹的动作变化优化分段算法人工校正难例训练集和测试集指标差异大数据泄漏或分布不均检查 episode 是否被重复划分按 episode 粒度重新划分数据集同一任务多次运行效果不稳定场景覆盖度不足统计光照、背景、物体姿态分布补充边缘场景数据数据采集成本过高遥操作效率低分析平均采集时长和成功率引入自动化采集辅助优化操作界面数据格式不统一缺少标准化流程检查各批次数据字段统一 task.yaml 和标注 schema8. 具身数据工程的实践建议8.1 从任务定义开始而不是从设备开始很多团队做数据采集第一反应是“买更好的机器人”“搭更大的采集场地”。但更稳的做法是先定义清楚要训练什么模型、任务边界在哪里、成功标准是什么。任务定义清晰设备选型、采集方案、标注规范都会自然明确。举个例子如果是为“桌面物体抓取”模型采集数据用单臂机械臂加两台 RGB-D 相机就够了。如果目标是“双臂协同整理桌面”那就需要双臂平台、更精细的力觉传感器以及更复杂的标注规范。设备不是越贵越好匹配任务才关键。8.2 数据版本管理必须提前建立代码有 Git数据同样需要版本管理。推荐的做法是每个数据集目录对应一个版本号记录数据集的采集时间、设备配置、任务配置训练模型时锁定数据集版本模型发布时记录对应的数据版本。推荐使用 DVCData Version Control或类似的工具来管理数据版本。DVC 的好处是数据和代码可以关联管理模型的每次实验都能追溯到具体的数据版本。8.3 数据安全与合规不能跳过具身数据的采集场景往往涉及真实环境和真实操作。如果采集场地涉及人员的图像、语音或行为信息必须提前做好合规审查。具体需要注意采集前获得相关人员的知情同意对涉及个人隐私的图像进行匿名化处理数据存储和传输使用加密通道重要数据建立访问权限控制遵循最小权限原则与外部团队共享数据时签订数据使用协议。这些不是“流程负担”而是数据资产长期可用的基础。一旦出现合规问题数据资产可能被整体废弃损失远大于前期的合规投入。8.4 数据质量评估要建立“人机结合”机制完全依赖人工评估数据成本太高完全依赖自动评估又容易漏掉语义层面的问题。更合理的方式是分级处理第一级自动化规则拦截格式错误、字段缺失、时间戳异常第二级算法辅助筛选用预训练模型判断任务是否成功、动作是否自然第三级人工抽检重点审查自动筛选无法判断的边界样本。三级机制的好处是既控制了成本又保证了质量底线。8.5 团队配置要有“跨域”思维具身数据不是一个纯算法问题也不是一个纯硬件问题。一个高效的数据团队至少需要四种角色任务设计师定义任务边界、采集场景、评估标准算法工程师负责数据清洗、质量评估、数据增强机器人工程师负责采集设备调试、遥操作系统维护数据工程师负责数据管线、版本管理、数据平台建设。四种角色缺一不可。如果团队只有算法工程师和机器人工程师数据管线通常会变得混乱如果只有数据工程师又可能脱离模型训练的实际需求。9. 总结与下一步建议回到开头的问题40 天融两轮具身数据实战派入局对技术人来说意味着什么我的判断是具身数据正在经历从“项目制”到“工业化”的转变。早期做具身数据大多是围绕某个机器人项目定制采集少量演示数据属于项目制运作。而这一轮资本关注的重点是把数据采集、处理、评估、回流做成可复用的标准化流程——这本质上是一个工程问题而不是算法问题。对开发者来说这是一个值得关注的切入方向。具身数据赛道不像大模型那样需要庞大的算力和研究资源它的核心竞争力来自工程经验、场景理解和管理体系。如果你在机器人、数据工程、自动化测试、后端系统方面有积累转做具身数据工程的适配度并不低。建议的下一步实践路径是先在自己的项目里跑通一个最小数据闭环——比如用仿真环境生成 100 条抓取轨迹配上标注、质检、版本管理然后用这批数据训练一个小模型。不用追求规模先建立“数据也是一种需要精心管理的工程资产”这个意识。这个意识可能是具身智能时代最重要的基本功。如果你已经在做具身数据的相关工作可以回头审视一下自己的数据管线任务定义是否清晰数据质量是否有量化指标数据版本是否能完整追溯数据集划分是否符合规范先把这四件事做好再去追求更大的数据规模会稳妥得多。