从一机一模型到一脑多体：机器人通用操作模型技术拆解

过去一个月机器人圈子里最热闹的话题不再单是“谁家机器人又翻了个跟头”而是“一个通用大脑能不能同时驱动不同厂家的机器人本体”。宇树和智元放在一起讨论本身就很有意思因为这两家代表了两种不同的产品路径一边是硬件本体能力极强的人形机器人另一边是通用智能体方向的持续布局。外界更关注的是那个“10分钟一镜到底”的模型Demo视频里机器人没有频繁切换场景、没有剪辑连续完成了一串任务这让很多人第一次感受到“模型能力”和“本体能力”正在合流。但如果只看“机器人好厉害”会错过这件事里真正值得技术人关注的部分。这次Demo的含金量不在某个动作有多丝滑而在它验证了一条链路真实数据采集、模型训练、真机部署、长时程闭环执行这条路已经可以跑通而且跑的是一套跨本体的通用模型不是为某一台机器人单独训练的专用策略。换句话说行业正在从“一机一模型”走向“一脑多体”。这篇文章想从技术角度拆一下所谓“共用一个大脑”在架构上到底是什么含义10分钟一镜到底为什么难数据从哪来硬件和部署层面会卡在哪里以及如果我们要复现类似能力需要准备哪些关键组件、会踩到哪些坑。内容不会只停留在“看热闹”而是尽量落到工程可实现的范围里。1. “共用一个大脑”到底是什么含义“共用一个大脑”这个说法听起来很像营销话术但从技术架构看它描述的是一个真实发生的转变过去机器人公司普遍的做法是为每一台机器人训练一套独立的运动策略或操作策略换一台本体算法基本要重来。现在头部团队在尝试的是一个通用操作模型同一个模型可以被不同自由度、不同关节配置、不同传感器组合的人形机器人使用。这个“通用”是怎么实现的关键在于把模型拆成明显的层级结构而不是让模型直接去读电机控制指令。一个通用机器人操作模型通常分为四层感知层负责把相机图像、深度信息、点云等原始输入变成统一的空间表示。决策层根据人类指令和场景理解决定要完成什么任务、按什么顺序执行。动作层在通用动作空间里生成操作意图比如“把手移动到杯子位置抓取”。执行层把通用动作意图映射到具体机器人本体的关节电机上涉及运动学、动力学和底层控制。这样分层之后前几层可以做到与具体本体无关只有最底层的执行层需要针对每一台机器人做适配。所谓“共用一个大脑”本质上是前几层共用不同的机器人只需要换一个“执行适配器”。用一个类比来解释通用大脑相当于一个经验丰富的司机他理解交通规则、知道怎么打方向盘、踩油门刹车。不同品牌的车方向盘手感、刹车灵敏度不同但司机不需要重新学开车只需要适应一下这台车的操作细节。专用策略相当于给每台车配一个只能开这台车的专用司机。对开发者来说这个架构带来的实际好处很直接新的机器人本体可以复用已有模型的大部分能力不需要从零采集数据重新训练。同一个模型在多个场景、多个本体上得到验证泛化能力会更强。开发资源和训练算力可以集中投到模型本身而不是反复做重复的底层适配。不过也要清醒一点跨本体复用的前提是底层执行层做得足够好能把不同机器人的运动学差异、控制频率差异、硬件响应差异都消化掉。这一层如果没有做好上层模型再通用到真机上也会变成“脑子会了手不会”。2. 10分钟一镜到底为什么这么难外行看Demo看到的是机器人连续完成任务似乎很轻松。但做机器人技术的人都知道最难的恰恰是“一镜到底”和“10分钟”这两个词。2.1 长时程任务累积误差人形机器人是一个高度非线性的系统关节之间存在耦合重心不断变化哪怕单个动作的精度是95%10个连续性动作累积下来成功率会快速衰减。如果模型只是“看起来能做单个动作”在实际连续执行时任何一个微小偏移都可能被放大器传导到后面的步骤。“一镜到底”的意义在于它强制要求每个中间环节都不能出错而且必须能实时修正前面留下的误差。比如机器人去拿杯子第一下没对准模型不能重新规划整个任务而要在当前状态下做局部调整这种“连续失败后的恢复能力”才是长时程执行的关键。2.2 规划、控制、感知的毫秒级配合10分钟一镜到底背后是感知到决策到控制的循环在持续高速运转。摄像头采集图像模型理解当前状态规划下一步动作控制层下发指令传感器反馈执行结果再进入下一轮感知判断。任何一个环节延迟过高系统就会变得“迟钝”动作会看起来一顿一顿的。这也是为什么很多Demo只能做短视频剪辑因为可以在每个片段之间重新初始化状态、重新规划。一镜到底等于放弃了所有“作弊”空间只能用真本事跑完。2.3 时间压力下的容错设计10分钟这个时长在机器人任务里其实相当长。它要求系统具备时间维度上的动态调整能力如果某个动作花了比预期更长的时间后续任务要能自动压缩或者调整顺序而不是死板地按照预设脚本执行。这也意味着模型里面不仅要理解空间关系还要有一定的时间规划能力。从这些角度理解10分钟一镜到底已经不只是“控制算法好”而是整个系统在感知、规划、控制、硬件可靠性上都没有明显短板。3. 数据是大脑的“燃料”遥操作与真机数据闭环一个通用操作模型真正稀缺的不是模型结构本身而是高质量的真机操作数据。对于“共用一个大脑”这种架构训练数据需要覆盖不同的本体、不同的场景、不同的任务类型数据规模和数据质量直接决定模型的上限。3.1 数据从哪里来目前业界获取真机操作数据的主流方式有三种各有优劣数据来源优点缺点适用阶段人工遥操作采集数据质量高动作自然采集成本高速度慢小规模精标数据模型冷启动仿真环境生成数据量大成本低存在仿真到真实的差距预训练覆盖长尾场景自动化脚本/规则数据一致性好容易陷入固定套路特定场景补充数据从公开讨论看当前很多机器人团队采用的是“遥操作为主、仿真为辅”的组合策略。操作员通过VR设备或专用控制设备像操控自己的手一样操控机器人采集一组高质量示范数据。这种数据包含图像、关节角度、力矩反馈、任务指令等多种信息是训练操作模型的主要燃料。3.2 遥操作数据的标准化遥操作采集的数据往往存在姿态抖动、任务分段不清晰、传感器时间戳不一致等问题。要用于大模型训练需要先做统一标准化处理。下面是一个典型的数据清洗与标准化流程的示意代码演示如何把多个采集来源的数据统一成训练集可用的格式。# 文件路径tools/data_standardize.py import json import numpy as np from pathlib import Path def load_raw_episode(episode_dir): 读取遥操作采集的原始数据。 原始数据通常包括多视角图像帧、关节角度、指令文本。 images sorted((Path(episode_dir) / images).glob(*.jpg)) joint_angles np.load(Path(episode_dir) / joint_angles.npy) instruction json.loads( (Path(episode_dir) / instruction.json).read_text() )[text] return images, joint_angles, instruction def align_timestamps(images, joint_angles, fps30): 对齐图像与关节角度的时间戳。 遥操作设备与相机可能使用不同的采集频率 需要将两者插值到统一频率。 angle_len joint_angles.shape[0] frame_idxs np.linspace(0, angle_len - 1, numlen(images)).astype(int) aligned_angles joint_angles[frame_idxs] return aligned_angles, frame_idxs def save_episode(episode_dir, output_dir, images, angles, instruction): 把标准化后的数据写入训练集目录。 out_path Path(output_dir) / episode_dir.name out_path.mkdir(parentsTrue, exist_okTrue) # 图像重命名为统一序号 for idx, img in enumerate(images): new_name out_path / fframe_{idx:05d}.jpg if not new_name.exists(): new_name.write_bytes(Path(img).read_bytes()) np.save(out_path / joint_angles_aligned.npy, angles) with (out_path / instruction.json).open(w, encodingutf-8) as f: json.dump({text: instruction}, f, ensure_asciiFalse, indent2) print(f已保存标准化数据: {out_path}) if __name__ __main__: RAW_DIR Path(data/raw) OUT_DIR Path(data/standardized) for episode_dir in RAW_DIR.iterdir(): if not episode_dir.is_dir(): continue images, angles, instruction load_raw_episode(episode_dir) aligned_angles, _ align_timestamps(images, angles) save_episode(episode_dir, OUT_DIR, images, aligned_angles, instruction)这个脚本的核心思路是把原始采集数据转换成“图像按序号排列 关节角度与图像对齐 指令文本JSON”的统一格式。格式一旦统一后续无论是训练VLA模型还是传统模仿学习算法都可以直接加载。3.3 仿真数据的价值与局限仿真数据可以极大扩充数据量。像Isaac Sim、MuJoCo这样的物理仿真环境可以批量生成大量虚拟场景下的操作数据覆盖真实环境难以复现的长尾情况比如物体掉落、抓取失败后的重试等。但仿真数据有天然的域差距问题仿真里的材质物理特性、相机噪声、光照环境都比真实世界干净得多。如果模型只用仿真训练部署到真机上通常会出现性能下降。业界更推荐的做法是“仿真预训练 真实数据微调”先用仿真数据教给模型基本操作能力再用遥操作的真实数据把策略微调到可用状态。4. 从Demo到产品硬件与调试层面的现实挑战模型能力是机器人的“大脑”但大脑要通过一个可靠的“身体”去干活。很多团队在Demo阶段模型效果很好一到产品化就卡住问题往往出在硬件工程和部署环境上。4.1 电路与总线的稳定性机器人全身有十几个甚至几十个关节电机每个电机都要供电、通信、反馈状态。电机工作时的电流波动、通信总线上的数据冲突、线束在运动过程中的磨损都会直接影响模型输出的执行效果。如果底层通信超过20毫秒延迟上层的模型再怎么优化真机响应也会显得“慢半拍”。从公开拆解和分析材料来看行业里对机器人主控电路、伺服驱动、电源管理的要求已经接近工业设备而非消费电子标准。这也是为什么很多机器人项目在Demo阶段用实验室样机到了量产阶段要重新设计整机电路。4.2 调试模式G1这类本体的开发体验很多开发者最早接触人形机器人都是从调试一台具体本体开始的。以宇树G1这样的产品为例它提供了调试模式开发者可以读取每个关节的实时角度、力矩、温度也可以下发控制指令。这类调试能力对算法工程师来说几乎是必需品因为模型在真机上的表现很大程度上依赖能否快速定位“是算法问题还是硬件问题”。这里想强调一个经验遇到模型在仿真里表现很好、真机上失败的情况优先查底层调试数据看关节是否出现异常抖动、是否在接近物理极限位置、是否有过流报警。大部分“模型下线后变笨”的问题最后都能追溯到硬件反馈异常或者控制频率不匹配。4.3 边缘算力约束一套完整的操作模型运行时包含视觉编码器、语言理解模块、动作解码器等组件。在实验室里可以用高性能GPU跑但产品化的机器人通常只能携带边缘计算设备算力、功耗、散热都有严格限制。模型必须经过量化、剪枝、算子融合等手段压缩推理延迟要达到“肉眼无感知”的水平。这带来一个优先级排序不可能把所有模块都做到最好必须权衡视觉精度、决策速度、动作平滑度三者之间的关系。实际项目中通常优先保证动作控制频率因为底层控制一旦卡顿整个系统都会变得不可用。4.4 研发投入的长期性机器人软件栈相比传统互联网软件周期要长得多。模型要迭代数据要积累硬件要改版三者必须同步推进。行业头部企业在研发上的持续高投入核心就是在同时建三个壁垒模型能力、数据闭环、硬件工程能力。这三条腿缺一条都很难走到真正的产品化。5. 想复现类似能力你需要准备哪些关键组件如果我们不把注意力放在“买一台机器人”上而是从技术复现的角度看一个“共用一个大脑”的机器人操作模型需要以下关键组件组件作用常见选择机器人本体提供物理执行能力人形机器人或带机械臂的移动平台中间件统一通信与硬件抽象ROS 2、自定义控制框架感知模块物体识别、空间定位多视角相机、深度相机、点云模型语言/任务理解模块把人类指令转为任务意图大语言模型、VLM操作模型把任务意图转为动作序列VLA模型、模仿学习策略数据管理平台采集、清洗、版本化管理数据自定义工具链仿真环境预训练与安全测试Isaac Sim、MuJoCo边缘算力设备承载模型推理Jetson系列、定制NPU设备如果只是想做技术验证不一定要上人形机器人。先用一个带机械臂的移动底盘平台甚至是一个固定基座的机械臂就能验证“视觉感知 任务理解 动作生成”这条主链路。再逐步过渡到更复杂的双足或人形平台。一个最小可行的技术栈可以这样组织# 文件路径config/pipeline.yaml # 用于描述一条最小数据-训练-部署流水线 data: raw_dir: data/raw standardized_dir: data/standardized episode_length: 120 # 每条示范数据的最大帧数 fps: 30 model: type: vla # vision-language-action 模型 vision_encoder: siglip language_backbone: qwen2 # 或任意可用的语言模型 action_dim: 12 # 关节数按实际本体调整 horizon: 8 # 每次预测多少步动作 training: batch_size: 64 epochs: 300 learning_rate: 1e-4 simulation_ratio: 0.4 # 训练数据中仿真数据占比 real_ratio: 0.6 # 训练数据中真机遥操作数据占比 deploy: inference_device: edge # 可选: gpu / edge quantization: fp16 max_inference_ms: 50 # 单次推理延迟上限单位毫秒这份配置的核心逻辑有两点一是明确数据混合比例仿真数据和真机数据的比例不能拍脑袋要按任务复杂度和仿真逼真度动态调整二是把推理延迟放到部署配置的第一优先级避免模型精度很高但上线根本跑不动。6. 核心流程拆解从数据采集到模型部署的一次完整闭环在实践中建议不要一开始就追求“共用一个大脑”那样的大目标而是先把一条最小闭环跑通。流程可以拆成六个阶段。6.1 最小闭环的六个阶段硬件准备选择一台可控的本体确认可以提供实时关节状态读取和指令下发能力。数据采集通过遥操作录制10组左右的目标任务示范数据比如“拿起红色杯子放到托盘”。数据清洗统一图像帧率、对齐时间戳、剔除质量差的片段。模型训练用现有开源VLA模型或模仿学习框架在小数据集上做微调。仿真验证先在仿真环境里跑同样的任务排除代码逻辑错误。真机部署把模型部署到真机逐步从单任务过渡到连续多任务。这个过程不需要一次做到完美核心是建立一套“数据-训练-部署-反馈”的迭代机制。每一轮真机测试发现的问题反哺回数据采集环节再补数据、再训练这才是机器人智能系统真正的开发节奏。6.2 真机数据采集脚本示例下面给一个遥控操作数据采集的简化示例主要演示原始数据如何记录。# 文件路径tools/capture_episode.py import cv2 import numpy as np import json import time from pathlib import Path class EpisodeRecorder: def __init__(self, output_dir, camera_id0): self.output_dir Path(output_dir) self.output_dir.mkdir(parentsTrue, exist_okTrue) self.cap cv2.VideoCapture(camera_id) self.frames [] self.angles [] def record_frame(self, joint_angles): ret, frame self.cap.read() if not ret: return False self.frames.append(frame) self.angles.append(joint_angles.copy()) return True def save(self, instruction): image_dir self.output_dir / images image_dir.mkdir(exist_okTrue) for idx, frame in enumerate(self.frames): cv2.imwrite(str(image_dir / fframe_{idx:05d}.jpg), frame) np.save(self.output_dir / joint_angles.npy, np.array(self.angles)) with (self.output_dir / instruction.json).open(w, encodingutf-8) as f: json.dump({text: instruction}, f, ensure_asciiFalse, indent2) print(f采集完成共 {len(self.frames)} 帧) def get_current_joint_angles(): 实际开发中这里会从机器人SDK读取当前关节角度。 下面返回的数据仅为演示格式。 return np.random.rand(12) * 3.14 if __name__ __main__: recorder EpisodeRecorder(data/raw/episode_001) while True: joints get_current_joint_angles() if not recorder.record_frame(joints): break time.sleep(1 / 30) # 实际项目中按下空格键停止采集 if cv2.waitKey(1) 0xFF ord(q): break recorder.save(拿起红色杯子放到托盘)这个脚本演示了三个关键点图像帧与关节角度同步记录、按指令文本归组、输出统一的原始数据目录。实际项目中遥操作的数据采集会比这个复杂得多但核心逻辑是一致的多模态数据必须带时间戳、对齐、可回放。6.3 VLA模型输入输出的示意结构为了帮助理解通用操作模型“吃什么、出什么”下面给一个简化版的VLA模型输入输出结构示意。这里不绑定具体框架只展示数据流。# 文件路径model/vla_interface.py from dataclasses import dataclass from typing import List, Optional dataclass class VLAModelInput: instruction: str # 人类指令文本 images: List[object] # 当前多视角图像帧 joint_angles: List[float] # 当前关节角度 prev_actions: Optional[List[List[float]]] None # 历史动作序列 dataclass class VLAModelOutput: actions: List[List[float]] # 未来N步的动作序列 confidence: float # 模型对预测动作的置信度 task_state: str # 当前任务执行状态如 RUNNING / DONE def predict(model, user_input: VLAModelInput) - VLAModelOutput: 在实际项目中这里会调用训练好的模型权重进行推理。 模型内部会经历图像编码 - 文本编码 - 多模态融合 - 动作解码。 actions model.generate( instructionuser_input.instruction, imagesuser_input.images, joint_anglesuser_input.joint_angles, prev_actionsuser_input.prev_actions, ) return VLAModelOutput( actionsactions, confidence0.9, task_stateRUNNING, )可以看到模型的输入并不是原始的电机指令而是“人类可理解的指令 图像 当前关节状态”输出也不是单个关节的目标位置而是一段动作序列。这中间经历了从“语言空间”到“视觉空间”再到“动作空间”的转换这就是VLA模型与传统控制系统最大的不同。7. 常见问题与排查思路在实际开发和部署过程中下面这些问题是出现频率最高的。做机器人模型开发和做传统软件不同问题往往跨多个层面排查时要按“数据-模型-部署-硬件”的顺序来。问题现象可能原因排查方式解决方案模型在仿真里表现很好真机上完全失效仿真与真实环境差距过大视觉域差异明显对比仿真和真机采集的图像特征分布增加真实数据比例引入域随机化技术机器人执行到一半停顿像在“发呆”推理延迟超时控制循环等待模型输出查看单次推理耗时和CPU/GPU占用率模型量化、减小输入图像分辨率、升级边缘算力动作方向正确但位置偏差越来越大训练数据里缺少误差恢复样本检查遥操作数据中是否包含失败和重试片段在训练数据中加入纠错、重试类示范关节出现明显抖动控制频率与模型预测频率不匹配查看关节角度曲线是否高频振荡对动作序列做平滑滤波调整控制频率换一台机器人后模型效果大幅下降执行层适配不足只训练了单一本体的运动特征检查基础动作空间是否统一重新标定运动学参数增加不同本体的微调数据采集的数据无法用于训练时间戳未对齐样本格式不统一检查图像的帧号与关节角度长度是否一致先跑数据标准化脚本再做数据可视化检查最容易被忽视的一条经验是不要直接拿原始采集数据训练模型。遥操作人员的手抖、任务开始和结束时的多余动作、传感器频率不一致都会污染模型学习。先清洗再训练听起来很基础但能解决大量“模型好像学不会”的诡异问题。8. 最佳实践与工程建议结合当前行业主流做法和工程经验下面几条建议对做机器人模型开发的团队会比较有价值。8.1 先建数据闭环再追求模型精度很多团队一开始就把精力放在调模型结构上这是方向性错误。真机操作模型的上限不是由模型结构决定的而是由训练数据的质量和覆盖度决定的。更稳妥的顺序是先建立一套能持续采集、清洗、标注、版本化管理数据的系统再在稳定的数据流水线上去迭代模型。8.2 做一个“最小可信Demo”不要一上来就复现“10分钟一镜到底”那需要大量工程资源。先选一个具体的任务比如“从桌面抓取物体到指定位置”把数据采集、训练、部署全流程跑通。这个最小可信Demo的价值在于它会让团队真正理解机器人开发的工作量和难点分布而不是在PPT上讨论通用大模型。8.3 数据版本化管理机器人训练数据是资产数据变更必须有记录。建议为每条数据记录以下元信息采集本体型号、采集环境、操作员ID、传感器配置、任务指令、采集时间。当模型表现回退时能够快速定位是数据变化还是代码变化导致的。8.4 仿真与真实数据混合训练仿真数据负责让模型见多识广真实数据负责让模型贴近实际。比例不建议固定可以先从73仿真真实开始如果真机表现不好逐步增加真实数据占比。同时要注意仿真环境里的域随机化设置要贴近真实分布比如光照变化、物体纹理变化、相机噪声。8.5 安全边界优先设计任何真机部署都必须有硬性的安全保护机制。包括关节限位保护、力矩阈值保护、急停按钮、物理隔离围栏。模型预测的动作在发送到电机之前应当经过安全校验模块。下面是一个简化示例# 文件路径deploy/safety_check.py def safety_check(actions, joint_limits): 动作下发前做安全校验防止模型输出越界动作。 for action in actions: for joint_id, target in enumerate(action): lower, upper joint_limits[joint_id] if target lower or target upper: return False, joint_id return True, None # 使用方式如果校验失败应当立即停止动作下发并进入安全状态 # ok, failed_joint safety_check(predicted_actions, LIMITS) # if not ok: # robot.stop()8.6 日志与复盘机制机器人Demo看起来是“一镜到底”但背后一定是大量的失败日志和问题复盘。每次真机运行都要记录完整的传感器数据、模型输出、控制指令、异常事件。出现问题时通过回放日志定位是视觉误判、规划错误还是执行偏差。9. 总结与后续学习方向回到最开始的问题宇树和智元放在一起讨论真正值得关注的是什么不是某台机器人有多酷而是行业正在验证“一个通用操作模型可以驱动不同机器人本体”这条技术路径。10分钟一镜到底的Demo表面看是一次成功的现场展示实质上是对数据闭环、模型泛化、部署工程三者协同能力的一次压力测试。如果这篇文章对你有启发可以按下面的顺序继续深入先研究VLAVision-Language-Action模型的网络结构和训练方式这类模型是“共用一个大脑”的技术底座。再学习ROS 2或类似的机器人中间件理解底层通信和硬件抽象这是所有上层智能落地的前提。如果条件允许找一台带机械臂的移动平台做最小闭环实验把遥操作数据采集、模型微调、真机部署完整跑一遍。这条路线走一遍你对“机器人通用大脑”的理解会比只看Demo视频深得多。建议先收藏本文等真正开始动手做项目时再对照着关键组件和排查清单来用。