具身智能下一场竞争是数据还是“具身 o1 时刻”这个问题最近被反复讨论。从产业投入看大家都在卷数据采集车、遥操作平台、仿真环境、标注团队规模一个比一个大。从模型路线看业界又在普遍提推理、规划、慢思考这些词希望复现大模型在语言任务上的 o1 式跃迁。我的判断是这两条线不是二选一数据是燃料推理是引擎。没有高质量数据堆再大的模型也训不出稳定操作能力没有推理能力的跃迁数据再多也只是记住场景不是理解任务。这篇文章不聊泛泛的行业趋势而是把“数据竞争”和“具身 o1 时刻”拆成两条可执行的技术路线来看。数据侧要解决采集、清洗、标注、合成、版本管理这些基础问题模型侧要解决 VLA 架构、推理链路、评估闭环这些工程问题。适合正在做具身智能数据工程、VLA 模型训练、机器人落地评估的工程师和研究者阅读。如果你刚接触具身智能这篇文章也可以帮你建立一张从数据到模型的技术地图。1. 核心能力速览先给一张速览表把“数据竞争”和“具身 o1 时刻”这两条线的核心要素放在一起对比。这样后面展开时你脑子里会有一条清晰的主线。维度数据竞争方向具身 o1 时刻方向主要目标建一套稳定、可复用、可扩展的数据生产线提升模型在开放任务中的推理、规划与纠错能力核心资源真实遥操作数据、仿真数据、人类视频数据、合成数据高质量数据 强化学习 推理架构关键能力数据采集、清洗、标注、增强、版本管理系统 1 快速反应、系统 2 慢思考、任务分解主要瓶颈数据成本高、长尾分布、跨本体迁移难评测闭环缺失、真机试错成本高、安全边界难定工程产物数据管线、数据服务 API、批量标注平台VLA 模型、规划器、仿真评估框架硬件门槛机器人本体、传感器、采集工作站GPU 训练集群、真机或高保真仿真环境典型路径先解决“有没有数据可用”再解决“数据质量”先解决“能不能动”再解决“能不能想”适配场景数据团队、标注团队、仿真平台建设模型团队、算法研究、机器人产品化落地从这张表可以看出来数据侧解决的是“学习素材从哪来”的问题模型侧解决的是“素材怎么变成能力”的问题。两者互相依赖没有绝对的先后顺序但在资源有限时我更建议先补数据管线。因为推理模型的训练和评测最终还是要回到数据上。2. 数据竞争的底层逻辑与适用边界2.1 为什么数据是下一场竞争的焦点具身智能和纯语言模型有一个根本区别语言模型的数据来自互联网天然存在海量文本具身智能的数据来自物理世界的交互获取成本高出一个数量级。一个抓取、倒水、叠衣服的操作轨迹需要遥操作员一遍一遍演示每段轨迹都包含多路传感器、关节角度、力矩、图像流标注和清洗的工作量远超纯文本数据。所以从供给角度看具身智能数据是稀缺资源谁先建立稳定的数据生产线谁就有更大的训练空间。从分布角度看真实物理任务存在明显的长尾现象。常见场景如搬运、抓取数据容易积累但异常恢复、柔性物体操作、复杂装配这些场景数据非常稀疏。模型要泛化到这些长尾任务靠单一数据源基本做不到。因此真实遥操作、仿真批量生成、人类视频学习、合成数据补全需要组合使用。这个组合策略本身就是工程能力不是买几张显卡就能解决的。2.2 数据的边界光靠数据不够但数据不是万能的。现在很多团队把开集操作能力弱归因于数据少实际上还有两个隐藏问题。第一模型架构如果没有推理和规划能力数据再多也只能学到表层关联。比如一个倒水任务模型记住了训练集中杯子的位置换了透明杯、异形杯就开始失控这不是数据不够而是模型没有理解“倒水”的目标状态。第二评测闭环缺失导致数据扩充没有方向。你收集了 10 万条轨迹但不知道模型在哪些场景失败数据越加越偏。所以“数据竞争”和“具身 o1 时刻”在这里交汇。o1 式推理能帮助模型在遇到分布外场景时做任务分解和纠错降低对训练数据密度的依赖而高质量数据又能给推理模型提供足够丰富的先验。正确的关系不是取舍而是互补。数据决定下限推理模型决定上限。2.3 不适合用数据堆砌解决的场景有三类场景不适合靠堆数据硬解。第一安全敏感操作比如人体接触、高价值设备操作真机数据采集风险太高应该在仿真优先验证。第二极端长尾任务如果任务组合空间接近无限数据永远采不完必须依靠任务级推理。第三跨本体迁移机器人的关节数量、夹爪形状、传感器布局不同采集的数据很难直接复用需要做本体对齐或领域自适应。遇到这些情况应该先检查任务定义和模型设计而不是盲目扩充数据。3. 数据管线具身智能的“环境准备”3.1 数据采集数据采集是整个数据管线的起点。常见来源有四种遥操作采集、仿真环境生成、人类视频学习、传感器日志回放。遥操作采集适合精细任务但成本高仿真环境适合批量生成但存在仿真到真实的迁移差距人类视频数据规模大但缺少动作标签传感器日志回放适合真实部署后的持续学习。搭建采集系统时建议先定好三个标准。一是采样频率和传感器时间戳对齐方式否则训练时图像流和关节状态对不上二是轨迹段落的切分规则比如按任务完成点切还是按固定时长切三是采集环境的分级比如从仿真验证到真机小规模采集再到批量采集。先定标准再写代码能省掉后面 80% 的清洗成本。3.2 数据清洗与标注清洗阶段重点检查四类问题传感器缺失、时间戳错位、轨迹中断、动作抖动。我一般会写一个最基础的清洗脚本先过滤明显坏数据再做人工抽检。标注阶段需要区分物体标签、动作标签、语言指令。语言指令的标注质量直接影响 VLA 模型的指令跟随能力建议用多轮审核而不是一次标注直接入库。下面是一个简单的轨迹清洗示例实际项目需要根据自己的数据格式调整import json from pathlib import Path def clean_episode(episode: dict, min_len: int 10) - bool: # 检查轨迹长度和传感器是否对齐 obs episode[observations] acts episode[actions] if len(obs) min_len or len(obs) ! len(acts) 1: return False # 检查关键传感器是否缺失 if rgb not in obs[0] or joint_positions not in obs[0]: return False return True def process(input_dir: str, output_dir: str): for ep_path in Path(input_dir).glob(*.json): ep json.loads(ep_path.read_text()) if clean_episode(ep): out_path Path(output_dir) / ep_path.name out_path.write_text(json.dumps(ep, ensure_asciiFalse))3.3 数据合成与增强当真实数据不足时数据增强和合成数据是补齐长尾的重要方式。视觉层面可以做颜色扰动、光照变化、相机视角扰动动作层面可以做轨迹平滑、速度缩放、夹爪开合时序微调场景层面可以做物体纹理替换、布局随机化。但要注意过度增强也可能破坏物理一致性。比如视觉上改变了物体颜色但动作标签还是原来的抓取位姿模型可能学到错误的关联。更稳妥的做法是在仿真环境里生成同一种任务的多物理版本让颜色、形状、摩擦系数都在合理范围内变化这样数据增强和物理语义是自洽的。仿真数据出来后建议用一个小型评测集验证迁移效果再决定要不要大规模生成。3.4 数据格式与版本管理具身智能数据格式目前没有统一标准。有的团队用 HDF5 存传感器流有的用 JSON 存轨迹元数据有的用 WebDataset 方便分布式训练。格式本身不是最重要的重要的是版本管理。数据一旦入库必须能追溯来源、清洗规则、标注版本和任务定义。我建议至少给每个数据集记录这几个字段任务 ID、采集环境、传感器配置、数据来源、处理脚本版本、标注版本、质量抽检结果。这样训练出问题时你能快速定位是数据问题还是模型问题。下面是一个数据配置文件的示例{ task: grasp_and_place, version: v0.3, sources: [ {type: teleop, path: ./data/teleop, frequency: 10}, {type: simulation, path: ./data/sim, engine: isaac_sim} ], processing: { filtering: [deduplicate, sensor_sync, episode_length_check], annotation: [object_label, action_label, language_instruction] }, output: { format: episode_json, version_dir: ./datasets/v0.3, val_ratio: 0.1 } }4. 具身 o1 时刻从感知控制到推理规划4.1 什么是具身 o1 时刻语言模型领域的 o1 时刻指的是模型从快速直觉反馈进入慢速推理阶段遇到复杂问题时先想清楚步骤再生成答案。具身智能也需要这个能力。当前很多机器人策略是系统 1 式的传感器输入直接映射到动作输出反应快但不会“想”。在障碍物布局变化、任务目标不明确、操作中途出错时系统 1 式策略容易崩溃。具身 o1 时刻的含义是机器人模型能够对任务进行内部推理——把“把杯子放到托盘上”拆解成定位杯子、规划轨迹、接近、抓取、移动、放置、确认成功这几个步骤并且能在某一步失败时重新规划。这不是简单加一层大模型而是要在动作生成回路里嵌入一个可验证的推理闭环。4.2 VLA 模型与推理链路现在主流的具身智能模型范式是 VLA也就是视觉-语言-动作模型。输入是相机图像和自然语言指令输出是动作序列。VLA 模型已经具备一定的语言理解和视觉理解能力但离真正稳定的操作能力还有差距。差距主要在于VLA 模型多数还是端到端地生成动作没有显式的任务状态评估遇到新场景时不能自己判断“现在做完了没有”“下一步该做什么”。要走向具身 o1 时刻需要在 VLA 外面加一个推理层。推理层负责使用语言模型或专用规划器做任务分解VLA 负责把子任务指令转化为具体动作。这样系统有两条通路一条是快速反应通路处理抓取、跟踪这类低层控制一条是慢速推理通路处理失败恢复、任务重规划这类高层决策。两条通路配合才算完整的具身推理链路。4.3 硬件与算力需求推理模型带来的直接问题是算力需求上升。语言模型的推理链路可以在云端完成但机器人操作对时延非常敏感。如果推理层在云端一次任务分解就要几百毫秒到几秒对于动态抓取来说太慢了。更合理的架构是低层控制放在机载边缘设备上推理规划放在远端更强算力的服务上两者通过状态同步和异步任务调度解耦。如果你是在入门设备上验证比如树莓派小车这类轻量平台4G 内存版本更适合跑纯控制任务和轻量感知模型8G 版本可以多塞一个视觉语言小模型或中间件但别指望跑完整推理链路。设备选型时先明确哪部分算力放在端上哪部分放在远程再决定内存和 GPU 配置。4.4 评估闭环具身 o1 时刻不能只靠感觉来评估。需要建立一套任务级评估指标成功率达到多少、平均完成时长、失败后能否自主恢复、需要多少次重规划。更细一点还要区分任务分解能力、动作执行能力和错误恢复能力分别是什么水平。没有评估闭环模型迭代就是盲人摸象。评估闭环需要在仿真和真机两套环境上跑。仿真适合做高频回归测试真机适合做小规模最终验收。建议仿真评测集和真机评测集分开维护仿真里放大量可自动生成的场景真机里放少量但能代表真实痛点的场景。每轮训练后先跑仿真通过后再跑真机可以显著降低测试成本和风险。5. 从数据到模型的验证流程5.1 第一步定义任务和指标在“数据还是 o1 时刻”的争论里最容易忽略的是任务定义。先明确你要解决什么任务、成功标准是什么。比如“抓取并放置”这个任务成功标准是物体放到指定区域、不掉落、不损坏。评测指标建议同时记录成功率和平均任务时长成功率太低说明策略学得不对时延太长说明规划链路有性能瓶颈。指标定义好后写一个简单的评测函数方便后面反复调用def evaluate_policy(policy, env, episodes20): successes 0 total_steps 0 for _ in range(episodes): obs env.reset() done False while not done: action policy(obs) obs, reward, done, info env.step(action) total_steps 1 if info.get(success): successes 1 avg_steps total_steps / episodes return {success_rate: successes / episodes, avg_steps: avg_steps}5.2 第二步准备数据准备数据时先用小规模数据跑通全流程。不要一上来就采集 10 万条轨迹成本太高。我的建议是先采 50 到 100 条高质量演示训练一个最基础的基线策略看能不能在仿真里跑通。这一步的目的是验证数据格式、训练代码和评测接口而不是追求效果。基线能跑通之后再逐步扩充数据观察成功率和泛化能力的边际变化。5.3 第三步训练基线策略基线策略可以先从行为克隆开始。行为克隆就是直接学习专家轨迹的分布输入观测和动作输出匹配专家动作的概率。这个方案简单但有用能快速验证数据质量。如果行为克隆在训练集上都学不好多半是数据问题不是模型问题。训练时要注意分离训练集和评测集避免验证集泄漏。5.4 第四步融合语言指令与视觉输入当行为克隆基线稳定后再让模型支持语言指令。这里建议先固定语言模板比如“把红色杯子放到托盘上”再逐步增加指令复杂度。你会更容易定位错误来自视觉理解还是语言理解。如果视觉正确但动作错误问题在动作分支如果指令理解错误问题在语言-视觉对齐。定位错误来源后再决定是补数据还是调模型结构。5.5 第五步仿真与真机验证最后在真机上验证。真机验证之前务必做一套安全保护限制最大关节力矩、设置操作边界、准备急停方案。真机测试次数不要贪多重点是观察仿真到真实的迁移差距。如果仿真成功率 95%真机只有 50%说明策略依赖了仿真环境的特定纹理、光照或物理参数需要在数据增强阶段补充仿真随机化而不是继续加数据量。6. 数据管线的自动化与批处理6.1 批量标注流水线具身智能数据的标注量很大建议第一时间搭建批量处理流水线。流水线至少包含三个模块数据入库、自动清洗、人工抽检。自动清洗可以过滤时间戳错位和轨迹中断人工抽检负责语言指令质量和语义准确性。抽检比例可以动态调整数据质量稳定时降低抽检比例新增数据源时提高抽检比例。API 服务是流水线的理想入口。你可以把数据入库和标注请求封装成接口方便采集团队和训练团队并行工作curl -X POST http://127.0.0.1:8000/datasets/v0.3/episodes \ -H Content-Type: application/json \ -d {source: ./data/teleop/2025-04-01, tag: clean}6.2 数据服务 API 设计数据服务 API 要考虑两类使用方标注平台和训练框架。标注平台需要查询单条轨迹、提交标注结果训练框架需要按批次下载数据、获取数据集元信息。建议设计成如下结构import requests response requests.post( http://127.0.0.1:8000/annotations/batch, json{task: grasp_and_place, batch_id: b-001} ) print(response.json())如果你的训练框架直接读取本地数据集数据服务也可以只负责元信息管理和版本控制。关键是不要让数据和代码共享同一份目录结构否则模型版本和数据集版本会互相污染。6.3 批量训练与评估队列批量训练和评估往往不是一次跑完而是要连续跑多个实验。建议把训练和评估脚本封装成可复用模块输入数据集版本、模型配置、评测集路径输出成功率和模型权重。再加上简单的队列管理可以一次提交多个参数组合比如对比不同数据增强方式、不同模型大小、不同推理策略。所有实验结果统一记录到一张结果表里方便筛选最优配置。7. 算力与数据规模观察7.1 显存与存储观察训练 VLA 模型需要关注显存占用但显存占用没有固定数字取决于模型大小、batch size、图像分辨率、动作维度、是否使用低秩适配微调。实际操作时先用一个很小的 batch size 起训练比如 4 或 8观察显存曲线再逐步调大。如果显存溢出优先降低图像分辨率再尝试梯度累积或混合精度训练。存储方面具身智能数据往往很大。真机采集的一小时数据如果包含多路高清视频轻松超过几十 GB。磁盘要考虑训练集、原始采集数据、处理脚本和模型权重分开存储方便归档清理。数据存储目录建议按照“原始数据/清洗数据/增强数据/模型权重”分层管理。7.2 数据吞吐与性能指标训练性能不能光看显存还要看数据吞吐。如果 GPU 利用率一直上不去大概率是数据加载太快或者太慢形成了瓶颈。最直接的办法是数据预处理和模型训练解耦使用数据加载器把图像解码、增强、拼接样本放在独立进程里不要把预处理写进训练循环。观察每秒处理多少样本再对比训练步数就知道瓶颈在哪。7.3 成本控制思路具身智能的成本大头往往不是 GPU而是数据采集和数据清洗的人力投入。仿真数据看起来很便宜但仿真到真实的迁移调试成本很高真实数据看起来很贵但数据质量高模型收敛更容易。我的建议是先做小规模真机采集确认策略和任务定义正确后再用仿真大规模扩充数据。这样能把整套流程的试错成本控制在较低水平。8. 常见瓶颈与排查方法下面这个表格汇总了从数据到模型最常见的几类问题你在项目里大概率会遇到问题现象可能原因排查方式解决方案训练集上成功率低数据质量差或轨迹长度不足抽检数据看传感器是否对齐、动作是否抖动清洗坏数据补充专家演示训练集成功率正常评测集成功率低过拟合或评测场景分布差异大对比训练集和评测集场景分布增加场景随机化扩充评测集仿真效果好真机效果差仿真到真实迁移差距大分析真机视觉、物理参数差异增加仿真随机化添加真机数据混合训练语言指令理解错误标注不一致或指令模板单一人工抽检语言标注统一标注规范增加指令改写增强动作抖动或执行不稳定轨迹平滑不足或控制频率低查看动作序列曲线增加动作平滑提高控制频率GPU 利用率低数据加载、预处理阻塞观察数据吞吐时间增加并行加载、图像预解码训练显存溢出batch size 过大或分辨率过高监控显存曲线降低 batch size、分辨率使用混合精度任务分解合理但执行失败VLA 模型动作能力不足单独评测每个子任务为失败子任务补充专门数据批量任务卡住数据服务接口或队列异常查看日志和任务状态增加超时重试和任务状态监控排查时有一个通用原则先排除数据问题再怀疑模型问题。因为数据问题的排查成本低检查一下观测和动作是否对齐比重新设计模型快很多。如果我遇到“模型不收敛”第一反应会先抽几段训练数据可视化确认数据没错再调整超参数。9. 最佳实践与合规提醒9.1 工程规范具身智能项目要从第一天就建立工程规范。第一数据版本和模型版本必须绑定记录训练结果表里要能追溯到数据集版本、代码版本和模型权重路径。第二评测集和训练集物理隔离任何数据清洗脚本都不能碰评测集。第三先小参数跑通再大规模训练。不要一开始就上最大模型先跑一个 5 分钟的实验验证流程再投计算资源。还有一个工程细节仿真和真机的评测脚本要尽量保持接口一致。比如仿真里输出的是 7 自由度关节角度真机也要能读出同样的关节角度。这样模型可以在仿真里反复迭代到最后一次再上真机减少真机调试次数和硬件损耗风险。9.2 合规与安全边界具身智能涉及真实物理操作安全优先级最高。真机验证前必须有急停开关、力矩限制、运动范围限制操作人员要守在安全距离外。数据采集和模型部署阶段要注意隐私保护室内采集会拍到人脸、房间布局等敏感信息建议在采集和存储阶段做匿名化处理涉及人体动作或手势演示的数据要获得当事人明确授权。版权方面人类视频数据和第三方仿真素材也需要确认授权。如果要用别人的开源数据集先检查许可协议是否允许商用、是否允许二次分发。模型训练完发布前最好做一次效果复核确认不会在未授权场景下生成或执行危险动作。这些边界不是事后补救而是项目立项时就应该写进技术方案里的要求。10. 总结与下一步回到标题具身智能下一场竞争是数据还是“具身 o1 时刻”我的结论很明确数据是入场券推理能力是分水岭。短期内先看谁的采集清洗管线更稳、数据版本更清晰中期看谁能在 VLA 模型外面把推理闭环真正跑起来长期看谁能把数据、模型、真机验证三条链路拧成一套自动迭代系统。如果你现在要从零开始我建议第一步不是买机器人、也不是租顶级 GPU而是先定义一个极小的任务用 50 到 100 条高质量演示数据把小规模基线跑通。这个过程中把数据采集、清洗、训练、评测整套工具链建好。工具链通了再谈数据规模和 o1 时刻才有基础。这篇文章涉及的配置示例和验证流程可以按你实际项目环境调整先收藏备用后面对照着做。 具身智能竞争：数据管线与VLA推理模型的双轮驱动
具身智能下一场竞争是数据还是“具身 o1 时刻”这个问题最近被反复讨论。从产业投入看大家都在卷数据采集车、遥操作平台、仿真环境、标注团队规模一个比一个大。从模型路线看业界又在普遍提推理、规划、慢思考这些词希望复现大模型在语言任务上的 o1 式跃迁。我的判断是这两条线不是二选一数据是燃料推理是引擎。没有高质量数据堆再大的模型也训不出稳定操作能力没有推理能力的跃迁数据再多也只是记住场景不是理解任务。这篇文章不聊泛泛的行业趋势而是把“数据竞争”和“具身 o1 时刻”拆成两条可执行的技术路线来看。数据侧要解决采集、清洗、标注、合成、版本管理这些基础问题模型侧要解决 VLA 架构、推理链路、评估闭环这些工程问题。适合正在做具身智能数据工程、VLA 模型训练、机器人落地评估的工程师和研究者阅读。如果你刚接触具身智能这篇文章也可以帮你建立一张从数据到模型的技术地图。1. 核心能力速览先给一张速览表把“数据竞争”和“具身 o1 时刻”这两条线的核心要素放在一起对比。这样后面展开时你脑子里会有一条清晰的主线。维度数据竞争方向具身 o1 时刻方向主要目标建一套稳定、可复用、可扩展的数据生产线提升模型在开放任务中的推理、规划与纠错能力核心资源真实遥操作数据、仿真数据、人类视频数据、合成数据高质量数据 强化学习 推理架构关键能力数据采集、清洗、标注、增强、版本管理系统 1 快速反应、系统 2 慢思考、任务分解主要瓶颈数据成本高、长尾分布、跨本体迁移难评测闭环缺失、真机试错成本高、安全边界难定工程产物数据管线、数据服务 API、批量标注平台VLA 模型、规划器、仿真评估框架硬件门槛机器人本体、传感器、采集工作站GPU 训练集群、真机或高保真仿真环境典型路径先解决“有没有数据可用”再解决“数据质量”先解决“能不能动”再解决“能不能想”适配场景数据团队、标注团队、仿真平台建设模型团队、算法研究、机器人产品化落地从这张表可以看出来数据侧解决的是“学习素材从哪来”的问题模型侧解决的是“素材怎么变成能力”的问题。两者互相依赖没有绝对的先后顺序但在资源有限时我更建议先补数据管线。因为推理模型的训练和评测最终还是要回到数据上。2. 数据竞争的底层逻辑与适用边界2.1 为什么数据是下一场竞争的焦点具身智能和纯语言模型有一个根本区别语言模型的数据来自互联网天然存在海量文本具身智能的数据来自物理世界的交互获取成本高出一个数量级。一个抓取、倒水、叠衣服的操作轨迹需要遥操作员一遍一遍演示每段轨迹都包含多路传感器、关节角度、力矩、图像流标注和清洗的工作量远超纯文本数据。所以从供给角度看具身智能数据是稀缺资源谁先建立稳定的数据生产线谁就有更大的训练空间。从分布角度看真实物理任务存在明显的长尾现象。常见场景如搬运、抓取数据容易积累但异常恢复、柔性物体操作、复杂装配这些场景数据非常稀疏。模型要泛化到这些长尾任务靠单一数据源基本做不到。因此真实遥操作、仿真批量生成、人类视频学习、合成数据补全需要组合使用。这个组合策略本身就是工程能力不是买几张显卡就能解决的。2.2 数据的边界光靠数据不够但数据不是万能的。现在很多团队把开集操作能力弱归因于数据少实际上还有两个隐藏问题。第一模型架构如果没有推理和规划能力数据再多也只能学到表层关联。比如一个倒水任务模型记住了训练集中杯子的位置换了透明杯、异形杯就开始失控这不是数据不够而是模型没有理解“倒水”的目标状态。第二评测闭环缺失导致数据扩充没有方向。你收集了 10 万条轨迹但不知道模型在哪些场景失败数据越加越偏。所以“数据竞争”和“具身 o1 时刻”在这里交汇。o1 式推理能帮助模型在遇到分布外场景时做任务分解和纠错降低对训练数据密度的依赖而高质量数据又能给推理模型提供足够丰富的先验。正确的关系不是取舍而是互补。数据决定下限推理模型决定上限。2.3 不适合用数据堆砌解决的场景有三类场景不适合靠堆数据硬解。第一安全敏感操作比如人体接触、高价值设备操作真机数据采集风险太高应该在仿真优先验证。第二极端长尾任务如果任务组合空间接近无限数据永远采不完必须依靠任务级推理。第三跨本体迁移机器人的关节数量、夹爪形状、传感器布局不同采集的数据很难直接复用需要做本体对齐或领域自适应。遇到这些情况应该先检查任务定义和模型设计而不是盲目扩充数据。3. 数据管线具身智能的“环境准备”3.1 数据采集数据采集是整个数据管线的起点。常见来源有四种遥操作采集、仿真环境生成、人类视频学习、传感器日志回放。遥操作采集适合精细任务但成本高仿真环境适合批量生成但存在仿真到真实的迁移差距人类视频数据规模大但缺少动作标签传感器日志回放适合真实部署后的持续学习。搭建采集系统时建议先定好三个标准。一是采样频率和传感器时间戳对齐方式否则训练时图像流和关节状态对不上二是轨迹段落的切分规则比如按任务完成点切还是按固定时长切三是采集环境的分级比如从仿真验证到真机小规模采集再到批量采集。先定标准再写代码能省掉后面 80% 的清洗成本。3.2 数据清洗与标注清洗阶段重点检查四类问题传感器缺失、时间戳错位、轨迹中断、动作抖动。我一般会写一个最基础的清洗脚本先过滤明显坏数据再做人工抽检。标注阶段需要区分物体标签、动作标签、语言指令。语言指令的标注质量直接影响 VLA 模型的指令跟随能力建议用多轮审核而不是一次标注直接入库。下面是一个简单的轨迹清洗示例实际项目需要根据自己的数据格式调整import json from pathlib import Path def clean_episode(episode: dict, min_len: int 10) - bool: # 检查轨迹长度和传感器是否对齐 obs episode[observations] acts episode[actions] if len(obs) min_len or len(obs) ! len(acts) 1: return False # 检查关键传感器是否缺失 if rgb not in obs[0] or joint_positions not in obs[0]: return False return True def process(input_dir: str, output_dir: str): for ep_path in Path(input_dir).glob(*.json): ep json.loads(ep_path.read_text()) if clean_episode(ep): out_path Path(output_dir) / ep_path.name out_path.write_text(json.dumps(ep, ensure_asciiFalse))3.3 数据合成与增强当真实数据不足时数据增强和合成数据是补齐长尾的重要方式。视觉层面可以做颜色扰动、光照变化、相机视角扰动动作层面可以做轨迹平滑、速度缩放、夹爪开合时序微调场景层面可以做物体纹理替换、布局随机化。但要注意过度增强也可能破坏物理一致性。比如视觉上改变了物体颜色但动作标签还是原来的抓取位姿模型可能学到错误的关联。更稳妥的做法是在仿真环境里生成同一种任务的多物理版本让颜色、形状、摩擦系数都在合理范围内变化这样数据增强和物理语义是自洽的。仿真数据出来后建议用一个小型评测集验证迁移效果再决定要不要大规模生成。3.4 数据格式与版本管理具身智能数据格式目前没有统一标准。有的团队用 HDF5 存传感器流有的用 JSON 存轨迹元数据有的用 WebDataset 方便分布式训练。格式本身不是最重要的重要的是版本管理。数据一旦入库必须能追溯来源、清洗规则、标注版本和任务定义。我建议至少给每个数据集记录这几个字段任务 ID、采集环境、传感器配置、数据来源、处理脚本版本、标注版本、质量抽检结果。这样训练出问题时你能快速定位是数据问题还是模型问题。下面是一个数据配置文件的示例{ task: grasp_and_place, version: v0.3, sources: [ {type: teleop, path: ./data/teleop, frequency: 10}, {type: simulation, path: ./data/sim, engine: isaac_sim} ], processing: { filtering: [deduplicate, sensor_sync, episode_length_check], annotation: [object_label, action_label, language_instruction] }, output: { format: episode_json, version_dir: ./datasets/v0.3, val_ratio: 0.1 } }4. 具身 o1 时刻从感知控制到推理规划4.1 什么是具身 o1 时刻语言模型领域的 o1 时刻指的是模型从快速直觉反馈进入慢速推理阶段遇到复杂问题时先想清楚步骤再生成答案。具身智能也需要这个能力。当前很多机器人策略是系统 1 式的传感器输入直接映射到动作输出反应快但不会“想”。在障碍物布局变化、任务目标不明确、操作中途出错时系统 1 式策略容易崩溃。具身 o1 时刻的含义是机器人模型能够对任务进行内部推理——把“把杯子放到托盘上”拆解成定位杯子、规划轨迹、接近、抓取、移动、放置、确认成功这几个步骤并且能在某一步失败时重新规划。这不是简单加一层大模型而是要在动作生成回路里嵌入一个可验证的推理闭环。4.2 VLA 模型与推理链路现在主流的具身智能模型范式是 VLA也就是视觉-语言-动作模型。输入是相机图像和自然语言指令输出是动作序列。VLA 模型已经具备一定的语言理解和视觉理解能力但离真正稳定的操作能力还有差距。差距主要在于VLA 模型多数还是端到端地生成动作没有显式的任务状态评估遇到新场景时不能自己判断“现在做完了没有”“下一步该做什么”。要走向具身 o1 时刻需要在 VLA 外面加一个推理层。推理层负责使用语言模型或专用规划器做任务分解VLA 负责把子任务指令转化为具体动作。这样系统有两条通路一条是快速反应通路处理抓取、跟踪这类低层控制一条是慢速推理通路处理失败恢复、任务重规划这类高层决策。两条通路配合才算完整的具身推理链路。4.3 硬件与算力需求推理模型带来的直接问题是算力需求上升。语言模型的推理链路可以在云端完成但机器人操作对时延非常敏感。如果推理层在云端一次任务分解就要几百毫秒到几秒对于动态抓取来说太慢了。更合理的架构是低层控制放在机载边缘设备上推理规划放在远端更强算力的服务上两者通过状态同步和异步任务调度解耦。如果你是在入门设备上验证比如树莓派小车这类轻量平台4G 内存版本更适合跑纯控制任务和轻量感知模型8G 版本可以多塞一个视觉语言小模型或中间件但别指望跑完整推理链路。设备选型时先明确哪部分算力放在端上哪部分放在远程再决定内存和 GPU 配置。4.4 评估闭环具身 o1 时刻不能只靠感觉来评估。需要建立一套任务级评估指标成功率达到多少、平均完成时长、失败后能否自主恢复、需要多少次重规划。更细一点还要区分任务分解能力、动作执行能力和错误恢复能力分别是什么水平。没有评估闭环模型迭代就是盲人摸象。评估闭环需要在仿真和真机两套环境上跑。仿真适合做高频回归测试真机适合做小规模最终验收。建议仿真评测集和真机评测集分开维护仿真里放大量可自动生成的场景真机里放少量但能代表真实痛点的场景。每轮训练后先跑仿真通过后再跑真机可以显著降低测试成本和风险。5. 从数据到模型的验证流程5.1 第一步定义任务和指标在“数据还是 o1 时刻”的争论里最容易忽略的是任务定义。先明确你要解决什么任务、成功标准是什么。比如“抓取并放置”这个任务成功标准是物体放到指定区域、不掉落、不损坏。评测指标建议同时记录成功率和平均任务时长成功率太低说明策略学得不对时延太长说明规划链路有性能瓶颈。指标定义好后写一个简单的评测函数方便后面反复调用def evaluate_policy(policy, env, episodes20): successes 0 total_steps 0 for _ in range(episodes): obs env.reset() done False while not done: action policy(obs) obs, reward, done, info env.step(action) total_steps 1 if info.get(success): successes 1 avg_steps total_steps / episodes return {success_rate: successes / episodes, avg_steps: avg_steps}5.2 第二步准备数据准备数据时先用小规模数据跑通全流程。不要一上来就采集 10 万条轨迹成本太高。我的建议是先采 50 到 100 条高质量演示训练一个最基础的基线策略看能不能在仿真里跑通。这一步的目的是验证数据格式、训练代码和评测接口而不是追求效果。基线能跑通之后再逐步扩充数据观察成功率和泛化能力的边际变化。5.3 第三步训练基线策略基线策略可以先从行为克隆开始。行为克隆就是直接学习专家轨迹的分布输入观测和动作输出匹配专家动作的概率。这个方案简单但有用能快速验证数据质量。如果行为克隆在训练集上都学不好多半是数据问题不是模型问题。训练时要注意分离训练集和评测集避免验证集泄漏。5.4 第四步融合语言指令与视觉输入当行为克隆基线稳定后再让模型支持语言指令。这里建议先固定语言模板比如“把红色杯子放到托盘上”再逐步增加指令复杂度。你会更容易定位错误来自视觉理解还是语言理解。如果视觉正确但动作错误问题在动作分支如果指令理解错误问题在语言-视觉对齐。定位错误来源后再决定是补数据还是调模型结构。5.5 第五步仿真与真机验证最后在真机上验证。真机验证之前务必做一套安全保护限制最大关节力矩、设置操作边界、准备急停方案。真机测试次数不要贪多重点是观察仿真到真实的迁移差距。如果仿真成功率 95%真机只有 50%说明策略依赖了仿真环境的特定纹理、光照或物理参数需要在数据增强阶段补充仿真随机化而不是继续加数据量。6. 数据管线的自动化与批处理6.1 批量标注流水线具身智能数据的标注量很大建议第一时间搭建批量处理流水线。流水线至少包含三个模块数据入库、自动清洗、人工抽检。自动清洗可以过滤时间戳错位和轨迹中断人工抽检负责语言指令质量和语义准确性。抽检比例可以动态调整数据质量稳定时降低抽检比例新增数据源时提高抽检比例。API 服务是流水线的理想入口。你可以把数据入库和标注请求封装成接口方便采集团队和训练团队并行工作curl -X POST http://127.0.0.1:8000/datasets/v0.3/episodes \ -H Content-Type: application/json \ -d {source: ./data/teleop/2025-04-01, tag: clean}6.2 数据服务 API 设计数据服务 API 要考虑两类使用方标注平台和训练框架。标注平台需要查询单条轨迹、提交标注结果训练框架需要按批次下载数据、获取数据集元信息。建议设计成如下结构import requests response requests.post( http://127.0.0.1:8000/annotations/batch, json{task: grasp_and_place, batch_id: b-001} ) print(response.json())如果你的训练框架直接读取本地数据集数据服务也可以只负责元信息管理和版本控制。关键是不要让数据和代码共享同一份目录结构否则模型版本和数据集版本会互相污染。6.3 批量训练与评估队列批量训练和评估往往不是一次跑完而是要连续跑多个实验。建议把训练和评估脚本封装成可复用模块输入数据集版本、模型配置、评测集路径输出成功率和模型权重。再加上简单的队列管理可以一次提交多个参数组合比如对比不同数据增强方式、不同模型大小、不同推理策略。所有实验结果统一记录到一张结果表里方便筛选最优配置。7. 算力与数据规模观察7.1 显存与存储观察训练 VLA 模型需要关注显存占用但显存占用没有固定数字取决于模型大小、batch size、图像分辨率、动作维度、是否使用低秩适配微调。实际操作时先用一个很小的 batch size 起训练比如 4 或 8观察显存曲线再逐步调大。如果显存溢出优先降低图像分辨率再尝试梯度累积或混合精度训练。存储方面具身智能数据往往很大。真机采集的一小时数据如果包含多路高清视频轻松超过几十 GB。磁盘要考虑训练集、原始采集数据、处理脚本和模型权重分开存储方便归档清理。数据存储目录建议按照“原始数据/清洗数据/增强数据/模型权重”分层管理。7.2 数据吞吐与性能指标训练性能不能光看显存还要看数据吞吐。如果 GPU 利用率一直上不去大概率是数据加载太快或者太慢形成了瓶颈。最直接的办法是数据预处理和模型训练解耦使用数据加载器把图像解码、增强、拼接样本放在独立进程里不要把预处理写进训练循环。观察每秒处理多少样本再对比训练步数就知道瓶颈在哪。7.3 成本控制思路具身智能的成本大头往往不是 GPU而是数据采集和数据清洗的人力投入。仿真数据看起来很便宜但仿真到真实的迁移调试成本很高真实数据看起来很贵但数据质量高模型收敛更容易。我的建议是先做小规模真机采集确认策略和任务定义正确后再用仿真大规模扩充数据。这样能把整套流程的试错成本控制在较低水平。8. 常见瓶颈与排查方法下面这个表格汇总了从数据到模型最常见的几类问题你在项目里大概率会遇到问题现象可能原因排查方式解决方案训练集上成功率低数据质量差或轨迹长度不足抽检数据看传感器是否对齐、动作是否抖动清洗坏数据补充专家演示训练集成功率正常评测集成功率低过拟合或评测场景分布差异大对比训练集和评测集场景分布增加场景随机化扩充评测集仿真效果好真机效果差仿真到真实迁移差距大分析真机视觉、物理参数差异增加仿真随机化添加真机数据混合训练语言指令理解错误标注不一致或指令模板单一人工抽检语言标注统一标注规范增加指令改写增强动作抖动或执行不稳定轨迹平滑不足或控制频率低查看动作序列曲线增加动作平滑提高控制频率GPU 利用率低数据加载、预处理阻塞观察数据吞吐时间增加并行加载、图像预解码训练显存溢出batch size 过大或分辨率过高监控显存曲线降低 batch size、分辨率使用混合精度任务分解合理但执行失败VLA 模型动作能力不足单独评测每个子任务为失败子任务补充专门数据批量任务卡住数据服务接口或队列异常查看日志和任务状态增加超时重试和任务状态监控排查时有一个通用原则先排除数据问题再怀疑模型问题。因为数据问题的排查成本低检查一下观测和动作是否对齐比重新设计模型快很多。如果我遇到“模型不收敛”第一反应会先抽几段训练数据可视化确认数据没错再调整超参数。9. 最佳实践与合规提醒9.1 工程规范具身智能项目要从第一天就建立工程规范。第一数据版本和模型版本必须绑定记录训练结果表里要能追溯到数据集版本、代码版本和模型权重路径。第二评测集和训练集物理隔离任何数据清洗脚本都不能碰评测集。第三先小参数跑通再大规模训练。不要一开始就上最大模型先跑一个 5 分钟的实验验证流程再投计算资源。还有一个工程细节仿真和真机的评测脚本要尽量保持接口一致。比如仿真里输出的是 7 自由度关节角度真机也要能读出同样的关节角度。这样模型可以在仿真里反复迭代到最后一次再上真机减少真机调试次数和硬件损耗风险。9.2 合规与安全边界具身智能涉及真实物理操作安全优先级最高。真机验证前必须有急停开关、力矩限制、运动范围限制操作人员要守在安全距离外。数据采集和模型部署阶段要注意隐私保护室内采集会拍到人脸、房间布局等敏感信息建议在采集和存储阶段做匿名化处理涉及人体动作或手势演示的数据要获得当事人明确授权。版权方面人类视频数据和第三方仿真素材也需要确认授权。如果要用别人的开源数据集先检查许可协议是否允许商用、是否允许二次分发。模型训练完发布前最好做一次效果复核确认不会在未授权场景下生成或执行危险动作。这些边界不是事后补救而是项目立项时就应该写进技术方案里的要求。10. 总结与下一步回到标题具身智能下一场竞争是数据还是“具身 o1 时刻”我的结论很明确数据是入场券推理能力是分水岭。短期内先看谁的采集清洗管线更稳、数据版本更清晰中期看谁能在 VLA 模型外面把推理闭环真正跑起来长期看谁能把数据、模型、真机验证三条链路拧成一套自动迭代系统。如果你现在要从零开始我建议第一步不是买机器人、也不是租顶级 GPU而是先定义一个极小的任务用 50 到 100 条高质量演示数据把小规模基线跑通。这个过程中把数据采集、清洗、训练、评测整套工具链建好。工具链通了再谈数据规模和 o1 时刻才有基础。这篇文章涉及的配置示例和验证流程可以按你实际项目环境调整先收藏备用后面对照着做。