具身智能“共用大脑”技术解析：从概念到工程实践

具身智能、GPT时刻、宇树、智元这四个关键词放在一起时已经不只是一个新闻标题。具身智能指的是让机器人在真实物理环境中感知、理解并执行任务的智能系统GPT时刻则借用了大语言模型出现后能力突然泛化的比喻。近期行业受关注的信号之一是宇树、智元等本体厂商开始探索让不同型号的机器人共用同一套大模型“大脑”让机器人不再是“每台设备一套程序”而是共享一套任务决策能力。一个看起来粗糙、没有经过精细剪辑的连续演示视频反而引发大量讨论因为它展示了连续10分钟不中断执行任务的可能性。这篇文章不预测哪家公司会成功而是回答一个问题如果“共用大脑”真的成为方向开发者需要理解哪些技术环节才能从新闻走向可验证的工程实践。1. 先把概念对齐具身智能大脑、本体与“共用大脑”1.1 具身智能解决什么问题具身智能的核心目标是让机器人具备“感知、决策、行动”的闭环能力。传统工业机器人靠预设轨迹和规则执行任务适合固定产线、稳定光照、标准工件。一旦环境变化比如物体位置偏移、桌面出现反光、夹爪没有抓到物体规则系统就很容易失效。具身智能的思路是让机器人从数据中学习策略用视觉、语言、本体状态作为输入直接生成物理动作。这个方向与纯语言模型最大的区别是输出空间不同。纯语言模型输出文本具身智能模型输出动作。动作要在真实物理世界中执行所以必须考虑关节限位、力反馈、碰撞、控制频率和安全约束。比如“倒水”这个任务模型不仅要识别杯子和水壶还要估计水壶的倾斜角度、倒水速度并根据水流情况做实时修正。这种连续闭环能力是单纯的视觉识别或语言理解模型无法直接提供的。所谓“GPT时刻”用于具身智能领域是一种比喻当模型规模、数据规模和训练范式达到某个临界点之后策略的泛化能力会明显提升单台机器人上训练的决策能力可以迁移到另一台机器人。这个临界点是否已经到来目前还不能给出确定结论但它带来的工程范式变化已经清楚机器人开发正在从“手写规则”走向“数据驱动的大模型训练”。1.2 “共用大脑”在工程上意味着什么“共用大脑”并不是让机器人简单调用一个云端API而是要在工程上定义一套分层架构。通常可以分成三层第一层是感知和决策模型它接收多模态输入包括图像、文本指令、关节角度、夹爪状态等输出统一的任务决策结果第二层是统一动作表示模型不直接产生某个马达的PWM值而是输出例如“末端执行器在目标坐标系下的增量位移”或“关节目标位置”这类抽象动作第三层是硬件适配层负责把统一动作转换成具体机器人的关节指令。这种分层的价值在于决策模型学习的是任务理解能力比如“把红色方块推到A点”在语义上意味着什么、视觉上需要关注哪些关键点、末端应该往哪个方向移动。硬件差异被隔离在适配层因此不同型号的机械臂、四足机器人、人形机器人可以共享同一套模型的大部分参数。更换本体时只需要替换适配层并补充少量该本体的数据做微调。这与大语言模型的使用方式很像。不同应用共享同一个文本生成能力只是通过输入输出格式做适配。具身智能领域如果要复制这种路径就必须先解决“统一接口”的问题否则即使模型能力足够强也无法低成本迁移到不同机器人上。1.3 为什么粗糙视频反而有说服力一个没有经过剪辑的演示视频尤其是连续运行10分钟不中断的视频在工程评测中的价值很高。它不只是展示“某个任务成功了一次”而是展示了一系列任务连续执行时系统仍然能保持稳定。这种连续运行会暴露出很多单任务评测看不到的问题目标切换后的指令混淆、长时间运行后的累积误差、抓取失败后的恢复逻辑、视觉遮挡后的重新规划。粗糙反而是一种可信度信号。经过后期剪辑的视频可以把失败的尝试全部剪掉只保留最顺利的一条轨迹。未剪辑视频保留了失败、重试、停顿让观看者能判断系统在异常情况下是否具备恢复能力。如果展示的是连续10分钟零打断那么它至少说明系统在任务调度、策略推理、故障恢复几个模块之间配合得足够稳定。当然看这类视频也要注意边界。任务复杂度、是否有人工遥控接管、场景是否提前布置、物体是否固定初始位置这些信息往往不会在视频里完整展示。因此理性做法是把这类演示当成“行业方向信号”而不是“某家公司已经解决所有问题的证据”。本文后面讨论的技术点正是为了帮助开发者自己搭建一套可以验证连续稳定性的实验环境。2. 连续10分钟零打断背后拆开看是三个工程难题2.1 任务切换与目标歧义连续运行和单任务运行最大的区别是模型必须持续维护“当前任务目标”。假设第一条指令是“把红色方块推到A点”第二条指令是“把蓝色方块放到B点”模型在第二条指令下发后必须快速切换目标不能继续按照旧目标执行。如果模型结构里没有任务状态管理机制两条指令对应的动作会在语言编码和视觉编码上产生歧义最终策略可能输出一个折中的、不合理的动作。工程上可以引入任务状态管理器。管理器维护当前任务ID、任务子步骤、已完成标志并且在每次切换任务时清空临时状态。模型输入中除了常规的视觉和文本指令还会加入一个任务上下文向量用来让模型知道当前应该响应哪个目标。这样连续执行多任务时目标歧义会明显减少。在模型层面语言指令本身就是一种上下文。Transformer模型会把指令文本编码成token与视觉token一起送入序列。只要训练数据中包含“连续不同指令”的样本模型可以学到切换语义。但这类数据在采集时成本较高因为真机连续操作比单任务操作更难录制这也是为什么仿真环境在早期验证中很有价值。2.2 物理世界不确定性与容错单任务演示中一次失败可以重来。连续运行中一次失败如果没有恢复机制整个序列就会中断。真实物理世界的不确定性包括物体抓取后滑落、夹爪位置偏移、光照变化导致视觉检测抖动、桌面摩擦力不一致。这些情况无法通过“扩大训练集”完全消除需要从系统层面设计容错。容错机制通常分成三层。第一层是动作级重试比如夹爪闭合后检测到没有抓住物体就松开夹爪重新调整末端位置再抓第二层是任务级重规划当某个动作重复失败后模型可以改变策略比如先推开障碍物再抓目标物体第三层是全局级接管当连续失败超过阈值或者传感器数据异常时系统自动暂停等待人工接管。模型输出的动作本身也需要经过安全校验。末端位置是否超出工作空间、关节角度是否接近限位、轨迹速度是否过快这些校验不应完全依赖模型学习而应该由控制层的校验逻辑兜底。这也解释了为什么“共用大脑”不能只训练一个模型还需要配套稳定的控制、校验和恢复框架。2.3 连续运行评测指标如果要用指标描述“10分钟零打断”常见指标包括单任务成功率、多任务链完成率、平均无中断运行时长、失败恢复率和任务切换耗时。单任务成功率只能反映模型在固定条件下的基础能力无法体现系统连续运行时的稳定性。指标含义计算方式连续运行中的意义单任务成功率单个任务在固定次数内完成的概率成功次数 / 总测试次数反映基础策略能力多任务链完成率一串任务全部按顺序完成的概率成功执行的任务链数 / 总任务链数反映目标切换和长期规划能力平均无中断运行时长连续运行到中断或失败的平均时间总运行时间 / 中断次数反映系统稳定性和漂移程度失败恢复率失败后自动恢复到正常流程的比例成功恢复次数 / 总失败次数反映容错机制是否有效任务切换耗时上一个任务结束到下一个任务开始的时间平均切换时间反映调度和上下文切换效率这些指标之间是配套关系。一个系统可能单任务成功率很高但多任务链完成率很低问题往往出在目标切换和失败恢复。建立连续运行评测环境比单纯刷单任务榜更能暴露真实工程问题。3. 拆开“大脑”看结构从多模态输入到动作输出3.1 感知编码把相机图、指令和本体状态变成向量具身智能“大脑”的输入通常是多模态的包括摄像头图像、文本指令、关节角度、夹爪状态等。首先要做的是把这些不同尺度的输入统一编码到同一个特征空间。图像部分常见做法是使用 ViT 或 SigLIP 这类预训练视觉编码器把图像拆成 patch 后编码成 token。文本部分使用分词器和文本编码器得到语言特征。本体状态属于低维数值例如关节角、三维坐标、夹爪开合度通常先做归一化再通过一层 MLP 映射成向量。最后把图像特征、文本特征、状态特征拼接起来作为后续决策网络的输入。import torch import torch.nn as nn from transformers import AutoModel, AutoTokenizer class PerceptionEncoder(nn.Module): def __init__(self, image_model_namemicrosoft/siglip-base-patch16-224, state_dim16): super().__init__() self.image_encoder AutoModel.from_pretrained(image_model_name) self.tokenizer AutoTokenizer.from_pretrained(image_model_name) self.state_mlp nn.Sequential( nn.Linear(state_dim, 256), nn.ReLU(), nn.Linear(256, 256), ) self.image_proj nn.Linear(self.image_encoder.config.hidden_size, 256) self.text_proj nn.Linear(self.image_encoder.config.hidden_size, 256) def forward(self, images, instructions, states): img_feat self.image_encoder(pixel_valuesimages).last_hidden_state.mean(dim1) img_feat self.image_proj(img_feat) text_feat self.tokenizer(instructions, return_tensorspt, paddingTrue) text_feat self.image_encoder.text_model(**text_feat).pooler_output text_feat self.text_proj(text_feat) state_feat self.state_mlp(states) return torch.cat([img_feat, text_feat, state_feat], dim-1)这段代码是理解思路用的简化实现。真实 VLA 模型一般不会对图像特征做全局平均池化而是保留 patch token 序列让 Transformer 在更深层捕捉物体位置关系。但理解“图像、文本、状态都被映射成向量并拼接”这个核心过程是后续看任何模型论文的前提。3.2 决策网络Transformer 是如何预测动作的编码之后问题变成“给定特征序列如何得到动作”。主流做法是让模型像语言模型预测下一个 token 那样自回归地预测动作 token。动作可以是连续值也可以被量化成离散 bin模型输出离散动作 token 后再映射回连续动作。一个简化的决策网络结构如下class ActionHead(nn.Module): def __init__(self, hidden_size256, action_dim7, num_bins256): super().__init__() self.num_bins num_bins self.action_dim action_dim self.action_embedding nn.Embedding(action_dim * num_bins, hidden_size) self.transformer nn.TransformerEncoder( nn.TransformerEncoderLayer(d_modelhidden_size, nhead8), num_layers6, ) self.head nn.Linear(hidden_size, action_dim * num_bins) def forward(self, seq, action_so_far): action_emb self.action_embedding(action_so_far) features torch.cat([seq, action_emb], dim1) encoded self.transformer(features) logits self.head(encoded[:, -1]) return logits把连续动作离散化的好处是训练目标变得更稳定模型只需要预测“下一个动作属于哪个区间”而不是直接回归一个精确数值。推理时再选择概率最高的 bin并把它映射回真实动作值。这个映射表必须在训练和推理时保持一致否则会出现“训练能收敛推理却很抖”的问题。3.3 统一动作接口不同机器人如何复用同一个头部要让多个机器人共用同一个大脑必须定义统一动作接口。最合适的抽象不是某个马达的 PPM 或 PWM而是“末端执行器在目标坐标系下的位置增量”或“关节目标位置”这类与具体硬件解耦的表示。本体类型常见动作维度控制接口示例注意事项机械臂6/7 自由度关节位置joint_position_cmd、gripper_cmd检查奇异点、关节限位四足机器人12 个关节角度pd_ctrl、velocity_cmd注意足端力约束和中心质心轮式底盘线速度 角速度cmd_vel限制最大速度和加速度灵巧手多指关节角度hand_joint_cmd传感器少需要状态估计统一动作接口的意义在于模型只需要学会“末端向桌子右侧移动 2 厘米”这样的语义化动作而不用知道具体是哪个电机旋转了多少度。不同机器人在执行时的运动学差异由适配层负责计算。这样做之后同一套模型权重才有可能在不同硬件上运行。4. 用最小仿真环境复现一个可运行的具身智能原型4.1 实验环境准备不要一开始就上真机理解“共用大脑”不需要先买机器人。更稳妥的学习路径是在仿真环境里跑通一个最小闭环机械臂推动桌面上的方块到目标位置。仿真环境可以避免真机上的安全问题也能快速生成大量初始状态。推荐使用 PyBullet 这类轻量物理仿真引擎。环境准备命令如下conda create -n embodied python3.10 -y conda activate embodied pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install pybullet opencv-python pillow transformers numpy scikit-learn示例安装命令需要根据本机 CUDA 版本调整为对应 PyTorch 版本。学习阶段一张显存不低于 4GB 的显卡即可运行但训练速度和 batch 大小会受限。生产训练通常需要多卡或者更高显存的设备同时还需要搭建数据版本管理、训练日志和监控系统。4.2 数据准备统一 JSONL 数据集格式VLA 训练数据至少要包含四类信息指令文本、当前图像、本体状态、期望动作。为了便于清洗和版本管理建议把每个样本保存成 JSONL 格式每行一个 JSON 对象。这样无论是人工标注还是仿真自动生成都能落到同一个数据结构。{instruction: 把红色方块推到A点, image_path: data/episode_00001/frame_00012.png, joint_state: [0.1, -0.2, 0.3, 0.4, 0.5, -0.1], action: [0.02, -0.01, 0.0, 0.0, 0.0, 0.0, 0.8]}上面样本中action 可以理解为末端执行器在当前时刻的增量位移和夹爪开合命令。不同机器人可以选择不同的动作空间但一旦开始训练训练数据和推理时的动作空间必须一致。仿真环境下可以用规划器自动生成轨迹虽然数据样式不如人工遥操作丰富但足以验证模型结构和训练流程。def generate_episode(task_goal, num_frames20): episode [] for i in range(num_frames): obs capture_camera() joint get_joint_state() action interpolate_to_goal(i, num_frames) episode.append({ image_path: save_image(obs), joint_state: joint, action: action, }) return episode这段代码只是生成“看起来合理的演示数据”。如果希望模型真正学出鲁棒的策略还需要在多个随机初始位置、随机颜色、随机光照下采集数据并且加入失败恢复的轨迹片段。4.3 定义数据集加载器与策略模型训练前需要把 JSONL 数据加载成 PyTorch Dataset。每个样本需要完成图像预处理、指令 tokenize、状态转浮点张量、动作转浮点张量。这里最容易出的问题是训练和推理时预处理不一致例如训练时图像做了随机裁剪推理时却只缩放导致特征分布偏移。class PushDataset(torch.utils.data.Dataset): def __init__(self, jsonl_path, img_dir, tokenizer): self.samples read_jsonl(jsonl_path) self.img_dir img_dir self.tokenizer tokenizer def __getitem__(self, idx): sample self.samples[idx] image load_and_preprocess_image(self.img_dir, sample[image_path]) state torch.as_tensor(sample[joint_state], dtypetorch.float32) action torch.as_tensor(sample[action], dtypetorch.float32) text self.tokenizer(sample[instruction], return_tensorspt, paddingTrue) return { image: image, text: text.input_ids.squeeze(0), state: state, action: action, }策略模型可以先用一个轻量的多模态编码器加 MLP 或 Transformer 完成。目标是让数据从文件进入显存、经过模型、得到损失函数再反向传播。先不要追求精度先保证流程跑通。4.4 训练循环最小闭环比模型精度更重要import torch import torch.nn.functional as F model EmbodiedPolicy() optimizer torch.optim.AdamW(model.parameters(), lr1e-4) dataloader torch.utils.data.DataLoader(dataset, batch_size32, shuffleTrue) for epoch in range(30): for batch in dataloader: pred model(batch[image], batch[text], batch[state]) loss F.mse_loss(pred, batch[action]) optimizer.zero_grad() loss.backward() optimizer.step() print(epoch, float(loss.item()))这段训练代码非常简单只适用于从零理解训练链路。实际 VLA 训练通常需要更大模型、更大 batch、动作 token 化、混合精度训练和数据增强。但在学习阶段先跑通最小闭环再逐步加复杂度比直接复现完整论文更有效。5. 运行验证如何量化“10分钟零打断”式的稳定性5.1 搭建连续任务队列仿真环境跑通单任务后可以进一步搭建连续任务队列。所谓连续是指整个评测过程中不重置物体位置、不重开仿真让机器人连续执行多个指令。这样能观察目标切换、任务状态累积和物理接触带来的影响。tasks [ 把红色方块推到A点, 把蓝色方块推到B点, 把绿色方块放到C区, ] for task in tasks: send_instruction(task) while not task_done(task) and time_since_start 60: obs capture_image() action policy.predict(obs, task) execute(action) if detect_stuck(obs): replan_or_recover() if not task_done(task): break连续评测里任务切换时的策略很重要。上一任务结束后桌面上的物体位置是上一任务留下的结果而不是重新摆放的初始状态。模型必须能够基于当前画面判断“这个任务从哪里开始”而不是依赖固定初始位置。5.2 计算稳定性指标评测结束后可以统计连续运行相关的指标。下面是一段简单的指标计算脚本def compute_stability(records): total_time sum(r[duration] for r in records) interrupts sum(1 for r in records if not r[success] and r[fatal]) recoveries sum(1 for r in records if r[recovered]) mbtif total_time / max(interrupts, 1) recovery_rate recoveries / max(recoveries, interrupts) return { total_time_min: total_time / 60, interrupt_count: interrupts, mean_time_between_interrupt: round(mbtif, 2), recovery_rate: round(recovery_rate, 3), }如果一次连续评测中 interrupt_count 为 0总运行时间达到 600 秒以上那么“平均无中断运行时长”就是 600 秒以上对应“10分钟零打断”。这种指标比单任务成功率更能反映系统在真实任务队列中的可用性。5.3 从仿真到真机的距离仿真环境通过后不代表真机可以直接可靠运行。真机会引入相机畸变、电机延迟、关节柔性、摩擦力差异、安全限制等问题。建议在仿真里验证算法在真机上重点验证系统集成和容错。环境重点验证内容示例要求仿真连续任务多任务切换、累积误差、恢复策略5 条任务链中至少 4 条零中断真实桌面任务视觉光照变化、物体材质差异连续 10 分钟零打断失败可恢复生产现场长时间运行、安全、运维需要人工巡检、急停、回滚方案真机部署时最容易被低估的是日志和回放能力。如果系统没有记录每一步的观测、动作、任务状态和底层控制反馈出现问题时很难定位是模型输出错误还是控制执行错误。建议从一开始就把“可回放”作为上线条件。6. 常见坑与排查链路从数据集到真机部署6.1 数据集里的四个坑数据质量直接决定模型上限。具身智能数据采集成本高清洗和格式统一更加重要。问题现象常见原因检查方式处理建议同类任务表现波动大指令表述不统一统计指令文本分布统一指令模板或做同义改写图像推理效果差训练和推理分辨率不一致检查 resize 和 normalize 参数固定预处理流程并写入配置模型收敛慢动作空间不统一查看 action 统计量统一坐标参考系并归一化长任务效果差演示片段被切碎或长短悬殊统计轨迹长度分布按任务长度平衡采样数据清洗比模型结构对结果的影响更大。一个常见误区是“先训练再说数据”实际应该先抽样检查数据确认图像能看清、指令与动作对得上、动作值没有明显跳变再进入训练流程。6.2 训练和推理不一致的坑训练时经常做数据增强比如随机亮度、随机裁剪。但推理时如果仍然保留随机增强模型输出会不稳定。建议训练和推理使用同一套预处理参数尤其是图像尺寸、归一化均值方差和动作归一化的统计量。另一个坑是 BatchNorm。多数视觉模型使用 BatchNorm 习惯但动作预测任务中推理时 batch 很小统计量波动会带来动作抖动。推荐使用 LayerNorm 或固定 BatchNorm 的 running stats或者在训练结束后冻结统计量再导出模型。动作归一化也必须一致。训练时如果对 action 做了标准化模型的输出是标准化后的值推理时就必须用同一组均值和方差反标准化。如果直接在推理脚本里重新计算统计数据结果会有偏差。6.3 真机部署的排查顺序真机运行一段时间后动作抖动、任务停滞先不要急着调模型。按下面顺序排查检查输入相机是否标定、图像是否模糊、关节状态是否反馈正常。检查模型输出打印模型推理结果确认没有 NaN 或异常跳变。检查控制层关节指令是否触发限位、速度是否饱和、力矩是否超限。检查任务状态当前任务是否正确、是否有残留旧任务状态。检查安全逻辑是否被人为暂停、急停标志是否复位。这个排查顺序的核心原则是先确认输入和链路再怀疑模型。很多“模型不收敛”的问题最终定位到的是图像加载顺序错误、状态维度写错、动作单位不一致这类低级问题。7. 从行业事件到落地路线开发者可以按这几条路径推进7.1 先把数据闭环搭建起来再谈模型规模“共用大脑”无论最终采用哪种模型结构都离不开高质量数据。具身智能数据不像文本数据那样容易获取它需要机器人本体、传感器、操作环境和异常恢复样本。适合开发者的起步方式是先把数据格式、采集流程、清洗脚本、版本管理搭好再逐步扩大数据规模。可以使用 JSONL 保存样本用独立的 data 目录保存图片用版本号管理数据集。模型每次迭代都记录“用什么数据、什么代码、什么超参数”训练出来的。这个数据闭环建立得越早后面模型升级和问题定位越容易。7.2 用统一评测集保护每一次模型更新模型结构更新、数据扩充、超参数调整之后都必须用同一套连续任务评测集验证。评测集应该是固定的任务集合、固定的随机种子、固定的评测逻辑。如果任务或初始状态每次都不一样就无法比较两个版本之间的性能差异。建议把评测脚本写入 CI 或发布流程。每次更新模型前先跑一轮短评测再对比新老版本的稳定性指标。只有评测通过模型才能进入下一阶段测试。这里的核心原则是评测先行而不是训练完再临时想验证方法。7.3 生产环境必须有安全缓冲和回滚具身智能系统进入生产环境时安全机制不能只依赖模型判断。需要设置软限位