同一个模型，怎样控制五种机器人？Being-H0.5 论文详解（下）

在上篇里，我们把 Being-H0.5 的核心出发点讲清楚了：跨本体学习不是把不同机器人数据补齐维度后倒进同一个训练池，而是要先给它们一门共享的“身体语言”。

人类手腕、机械臂末端、夹爪、灵巧手、腰部和移动底盘，被放入一套物理语义明确的统一状态-动作空间。人类演示、机器人轨迹和视觉语言数据，又被序列化进同一个多模态训练框架。

但“统一”只解决了能不能一起学的问题，没有自动解决学得好不好。

一个低自由度夹爪和一只高自由度灵巧手，虽然可以填进同一个 200 维向量，背后的动力学复杂度仍然天差地别。更何况模型从服务器算出一段动作时，真实机器人不会停下来等：它仍在执行上一段轨迹，摄像头仍在移动，网络延迟也在变化。

因此，Being-H0.5 的下半场实际上围绕三个冲突展开：

1. 共享知识与本体专门化之间的冲突；

2. 理想视觉语义与真实感知噪声之间的冲突；

3. 模型推理节奏与机器人控制节奏之间的冲突。

对应的解法分别是 Mixture-of-Flow、Manifold-Preserving Gating 和 Universal Async Chunking。它们共同决定了 Being-H0.5 是一篇停留在“数据预训练”层面的论文，还是一套能够走进真实控制环路的系统。论文｜项目主页

一、连续动作要精确，离散动作要稳定

先从预训练里的一个巧妙设计讲起。

人类手部运动很丰富，但从公开视频中恢复出的轨迹不可避免地带有抖动、遮挡误差和个体差异。如果只用连续坐标监督，模型可能把这些噪声也当成要认真拟合的细节；如果只把动作离散成 token，又可能丢失机器人控制所需的精度。

Being-H0.5 没有在两者之间二选一，而是让同一段人类动作同时拥有两种表示：

• 连续动作块：保留位置、旋转和关节变化，用 Flow Matching 学习高精度动作分布；

• 离散动作 token：通过动作 tokenizer 对片段量化，再用 Masked Motion Token Prediction 学习更抽象、更抗噪的动作模式。

总动作损失可以写成：

L_act = lambda_1 * L_FM + lambda_2 * L_MASK

Flow Matching 从高斯噪声 x0 出发，沿着时间 t 逐步走向真实动作 a：

x_t = (1 - t) * x0 + t * a
目标速度 = a - x0

连续分支回答的是“每一个数值应该多精确”，离散分支回答的是“这段动作整体上属于什么行为”。可以把它们理解成动作的笔画与词义：只有笔画，容易被噪声带偏；只有词义，又无法控制机械臂落到毫米级位置。

论文还特意阻止两个目标分支互相偷看答案。连续动作段和离散 token 段都能看见共享上下文，却不能彼此注意；它们使用相同的相对位置起点，让模型知道这是同一时刻的两种表达，而不是让一个分支复制另一个分支。

这是一个结构上很完整的设计。不过论文自己的消融表 8 出现了值得警惕的矛盾：表中标为越高越好的 MWDS 指标，Hybrid (Ours) 在 Lab/Wild 上分别为 0.33/0.20，而去掉 L_MASK 后反而是 0.35/0.28；正文却写“去掉 masked prediction 会明显下降”。按表中数字，结论恰好相反。除非表格行名或数值排反，否则这组结果目前不能直接支持作者的文字结论。阅读这部分时，应等待作者勘误或后续版本，而不宜把它当成已经坐实的证据。

二、Mixture-of-Flow：共享动作原语，但不要让所有身体挤在一个专家里

统一动作空间让跨本体共享成为可能，却也制造了新的容量竞争。

想象让同一个动作专家同时学习 SO-101 的 6 自由度单臂夹爪、Franka 加灵巧手，以及 31 自由度的 Adam-U。它既要掌握普遍的接近、抓取和避障，又要理解某只灵巧手独特的关节耦合。如果所有参数都被所有数据更新，复杂本体很容易拖着简单本体一起抖，简单本体的大量数据又可能淹没稀缺的高自由度动作。

Mixture-of-Flow（MoF）的思路，是把动作专家分成两层：

• Foundation Experts 位于前部，学习跨本体共享的动作原语，例如接近、抓取、搬运和碰撞规避；

• Specialized Experts 位于后部，由可学习路由器按本体和任务稀疏激活，学习特定硬件或技能的动力学细节。

这和普通 MoE 的精神相似，但服务的对象不再只是语言 token，而是 Flow Matching 的动作生成。共享层负责“大家都要会的”，路由专家负责“这副身体才需要的”。只有少量专家在一次推理中被激活，因此总容量可以增长，而活跃计算量不必线性增长。

论文把它描述为解决负迁移的关键架构：既不能退回“每个机器人一个完全独立动作头”，也不能假设一套小动作专家能吃下所有形态。

这里需要区分论文方案和当前公开代码。仓库已经清晰实现了 Mixture-of-Transformers（MoT）：理解分支与动作生成分支使用各自的 Q/K/V、归一化和 MLP，同时通过同一层共享注意力进行信息交换。beingvla.py 也把文本/视觉 token 放入理解序列，把状态/动作 token 放入生成序列。模型主文件

但截至 2026 年 8 月 4 日，在公开的 qwen3_navit.py 中可以直接看到的是单个 mlp_mot_gen 动作分支，没有论文图中完整的 Top-K 专家路由实现；仓库 README 也仍把完整预训练脚本和文档列在 TODO。因此，目前开源代码足以理解 MoT 主干和动作流，却不应被描述成已经完整公开了论文中所有 MoF 训练细节。公开仓库

三、ESA：不是每来一台机器人，就再造一个头

预训练完成后，模型还要适应目标硬件的关节限制、自碰撞和接触约束。这时最容易出现“可塑性—稳定性”矛盾：全量微调能快速适应一台机器人，却可能覆盖掉预训练得到的跨本体知识；完全冻结又无法学会新身体的细节。

Embodiment-Specific Adaptation（ESA）利用了统一动作空间的槽位结构。

假设统一空间共有 K 个语义槽位，机器人 e 只激活其中的索引集合 I_e。ESA 为各槽位维护轻量适配参数，只更新当前本体真正使用的部分：

当前本体只更新 k 属于 I_e 的 adapter
k 不属于 I_e 时，Delta W[k] = 0

如果两台机器人共享同款机械臂、只更换末端执行器，那么机械臂槽位对应的适配参数可以共享，手部槽位则各自更新。这样既保留重合结构上的正迁移，也把不相干的自由度隔离开。

这一步看似只是参数高效微调，实际上再次利用了“物理语义槽位”这个地基：因为槽位有明确含义，模型才知道哪些参数应该共享，哪些不应互相干扰。

四、MPG：当视觉不可靠时，别让模型越修越偏

Flow Matching 的动作生成不是一步完成，而是从噪声出发多次更新。一次更新可写成：

a_next = a_now + Delta_t * v_theta(a_now | H)

H 是视觉、语言、状态和当前动作 token 形成的上下文特征。如果现场光照变化、摄像头抖动、物体被遮挡，H 就可能偏离训练分布。普通策略依然会把它当成可靠条件，迭代更新还会把一次小误差逐步放大，最终表现为机械臂抖动、反复修正甚至离开可行动作流形。

Manifold-Preserving Gating（MPG）做了一件很像“先判断自己看得准不准”的事。

它把当前上下文特征与一个参考动作 embedding 投影到共同空间，用 Sliced Wasserstein Distance 衡量两者分布差异 D，再把差异变成可靠性门：

g = exp(-D / tau)

差异小，g 接近 1，模型可以大胆使用当前上下文进行修正；差异大，g 变小，模型就压低依赖当前特征的残差，退回一个稳定的已学习先验偏置。

H_tilde = H + lambda * g * W * E_obs(H) + lambda * b

这里最细致的一点，是偏置 b 不受门控。当视觉变得不可信时，特征相关的修正会被压低，但稳定的默认修正仍然存在。代码中的 MPGEnhancement 使用 32 个随机投影近似 Sliced Wasserstein Distance，经过 LayerNorm 后计算 g，并默认对 gate 做 stop-gradient，避免模型通过操纵 gate 本身走捷径。MPG 实现

推理时，MPG 采用两阶段策略：

1. 先不用 MPG 生成一版基准动作；

2. 把上一版预测编码成无噪声动作锚点，再进行 1-3 轮 MPG refinement。

于是形成一个闭环：动作越合理，参考锚点越可靠；锚点越可靠，门控越准确；门控越准确，下一轮动作越稳定。论文称在少于 10 个去噪步时，通常 2-3 轮 refinement 就会趋于饱和。

五、UAC：模型算下一段动作时，机器人并没有暂停

动作分块是现代 VLA 常用的提速方式。模型一次预测未来 T 步动作，机器人逐步执行，不必每个控制周期都重新推理。

问题是，模型计算下一块动作需要时间。假设机器人在推理期间已经执行了旧动作块的前 d 步，新动作块如果仍从“推理开始时的状态”接着生成，就会与真实时间线错位。两个动作块在交界处容易出现跳变。

Training-Time RTC 的基本方法，是在训练时模拟这种延迟：把动作块切成已经承诺执行的前缀和仍需预测的后缀，前缀保持干净，损失只计算后缀。

Being-H0.5 的 Universal Async Chunking（UAC）把这一机制推广到不同控制频率和延迟预算的机器人。延迟步数由本体决定：

d >= ceil(t_inference / t_control) + epsilon_safety

高频机器人在同样推理时间里会多执行几步，因此 d 更大；低频机器人 d 更小。作者强调一个很实用的原则：高估 d 是安全的，低估 d 会破坏连续性。

训练时，对每个本体采样自己的延迟分布；动作块前 d 步被视为已承诺前缀，剩余后缀从噪声中学习生成，损失也只落在后缀上。

部署时则采用两个硬约束：

• Hard Prefix Locking：每一个 Flow 去噪步都把前 d 步覆盖回执行缓冲区中的旧动作，禁止模型“修改已经来不及修改的过去”；

• Hard Stitching：推理结束后丢掉新动作块的前缀，只把后缀写回缓冲区。

代码中的对应开关仍沿用 RTC 命名，例如 use_training_time_rtc、simulated_delay、prev_chunk 和 inference_delay。训练时它把前缀 timestep 设为 1，只对 postfix 计算 MSE；推理时每个 Euler step 都用 torch.where 把旧动作前缀锁回去。Flow Matching 与 RTC 代码

论文进一步给出双线程环形缓冲区：控制线程按固定频率消费动作，推理线程异步生产后缀动作，缓冲区至少设为两个 chunk 长度。这样，模型偶尔慢一拍时，控制线程仍有动作可用；真的欠载时，再保持最后动作或触发机器人自己的安全策略。

这部分创新的价值不在公式有多复杂，而在于它承认了一个常被论文忽略的事实：推理延迟不是部署时再修的工程瑕疵，而应该进入训练分布。

六、实验真正证明了什么

1. 五种真实机器人，一个 generalist checkpoint

论文把同一模型部署到五种形态差异明显的机器人：

十项任务覆盖空间操作、长程任务、双手协作和泛化。每项真实机器人任务只采集约 30-60 分钟演示，并采用随机策略选择、操作者不知道当前模型身份的盲测流程。

从论文图 10 读取的类别成功率如下：

结果最有意思的不是 specialist 最强——这本来就在预期之中——而是单一 generalist checkpoint 在空间和长程任务上只小幅落后，在泛化类别甚至高于 specialist。与此同时，去掉 UniHand-2.0 预训练后，generalist 下降尤其明显，说明人类中心预训练的作用不只是提高单机性能，更像是在异构数据混训时提供一个稳定的共同起点。

2. MPG 与 UAC 最先救的是长程和双手任务

论文图 13 的消融很符合系统直觉：

UAC 对长程和双手任务影响尤其大，因为延迟造成的微小错位会在多阶段执行和双臂配合中不断累积。MPG 则对感知变化与泛化更重要。二者一个处理“什么时候接上”，一个处理“当前信息值不值得信”。

3. 仿真成绩强，但 specialist 和 generalist 要分开看

Being-H0.5 使用 224×224 RGB 输入和 2B backbone，在 LIBERO 上取得 98.9% specialist 平均成功率；联合训练 LIBERO 与 RoboCasa 的单一 generalist checkpoint 为 97.6%。在 RoboCasa Human-50 设置中，specialist 为 53.9%，generalist 为 53.3%。官方结果页

这说明 generalist 没有因为同时覆盖两个 benchmark 而发生严重负迁移。但比较时也要注意：generalist 使用约两倍训练步数，以保证每个 benchmark 获得相近更新预算；98.9% 是 benchmark-specific specialist 的结果，不能直接等同于“一个模型在所有场景都达到 98.9%”。

4. 零样本跨本体是信号，不是已经解决的问题

作者报告了一个很吸引人的现象：generalist checkpoint 在 Adam-U 上面对从未出现过的“任务—本体组合”时，能够以非零成功率尝试翻转并扫码、开抽屉再放物、堆叠等结构化行为。

论文自己也承认成功率较低、动作精度不够稳定。更重要的是，正文没有给出一张完整的零样本任务成功率表。因此更稳妥的表述是：Being-H0.5 观察到了跨本体组合泛化的早期信号，而不是已经实现可靠的零样本换机部署。

七、代码应该从哪里读

公开仓库将 Being-H0.5 放在统一的 Being-H 项目中，核心目录是 Being-H05。最有效的阅读顺序不是从一千行模型文件硬啃，而是沿着一条动作数据的生命周期走。

第一步：先看 200 维槽位

阅读：docs/unified_action_space.md

先弄清各语义槽位的位置，再看 configs/data_config.py 中每个数据集的 UNIFIED_MAPPING。否则后面看到大量 mask、padding 和 metadata 时，很难判断它们到底在保护什么。

第二步：看数据怎样进入共同空间

公开文档使用三层配置：

YAML 数据集列表
    ↓
DataConfig：解析相机、状态、动作和语言
    ↓
Dataset Registry：把数据集名字映射到实际路径

一个新机器人至少要定义 VIDEO_KEYS、STATE_KEYS、ACTION_KEYS、LANGUAGE_KEYS 和 UNIFIED_MAPPING。跨本体训练还必须保存合并后的层级 metadata，否则推理阶段无法选择正确的归一化统计和有效槽位。数据配置指南

第三步：看 MoT、Flow Matching、MPG 和 RTC

阅读：

• BeingH/model/beingvla.py：200 维 state/action encoder、Flow Matching 训练与推理、MPG 两阶段 refinement、RTC 前缀锁定；

• BeingH/model/layers.py：ActionEncoder、Sliced Wasserstein Distance、MPGEnhancement；

• BeingH/model/llm/qwen3_navit.py：理解分支与动作分支如何通过 MoT 共享注意力。

公开模型默认配置中可以看到 action_chunk_length=16、num_inference_timesteps=4，统一状态/动作维度均为 200。真正训练时这些值仍应以 checkpoint 和配置文件为准。

第四步：最后看推理包装

BeingHPolicy 负责加载 checkpoint、数据配置、机器人 tag、指令模板和 metadata。最小调用形式是：

from BeingH.inference.beingh_policy import BeingHPolicy

policy = BeingHPolicy(
    model_path="<path-to-checkpoint>",
    data_config_name="<config-name>",
    dataset_name="<dataset-name>",
    embodiment_tag="<robot-tag>",
    instruction_template="<prompt>",
)

actions = policy.get_action(observations)

跨本体 checkpoint 还要指定 metadata_variant 和 stats_selection_mode。文档给出 task、embodiment 和 auto 三种统计选择模式；选错 metadata，状态归一化、动作反归一化和有效槽位都可能出错。推理指南

八、怎样开始跑公开代码

官方给出的基础流程是：

git clone https://github.com/BeingBeyond/Being-H.git
cd Being-H/Being-H05

conda create -n beingh python=3.10
conda activate beingh
pip install -r requirements.txt
pip install flash-attn --no-build-isolation

训练入口分为单本体和跨本体示例：

# 单本体，例如 LIBERO
bash scripts/train/train_libero_example.sh

# 跨本体训练
bash scripts/train/train_cross_emb_example.sh

训练使用 torchrun 与 FSDP。关键参数包括 InternVL backbone 路径、Qwen action expert 路径、恢复 checkpoint、数据集 YAML 和输出目录；文档默认动作 chunk 长度为 16，图像尺寸为 224，DataLoader worker 为 12。训练指南

不过，复现时有四个边界必须提前知道。

1. 当前开箱配置主要面向 LIBERO 和 RoboCasa，真实机器人预训练 checkpoint 仍在 TODO；

2. 完整预训练脚本、全部 benchmark 的 post-training 和评测脚本仍在 TODO；

3. README 强调跨本体训练要启用 --save_merged_metadata True，否则推理缺少层级统计；

4. 论文写统一动作空间尽量保留原始物理量，而代码文档又要求加载 mean/std/min/max/q01/q99 等 metadata 做归一化与反归一化。两者可能对应不同处理边界，但当前公开文档没有把关系解释完整，移植新机器人时应以实际 DataConfig 和 checkpoint metadata 为准。

所以，当前仓库适合做三件事：理解模型主干、复现实验 benchmark、基于示例接入新数据。若目标是完全复刻论文的 35,000 小时预训练、五种真实机器人和完整 MoF/UAC 系统，公开材料还不足以做到逐项等价复现。

九、这篇论文最重要的创新，到底是哪一个

如果只看名词，Being-H0.5 有太多可以被列为“贡献”的模块：UniHand-2.0、UniCraftor、Unified Action Space、Unified Sequence Modeling、Hybrid Motion、MoF、ESA、MPG、UAC。

但它真正有价值的地方，不是模块数量，而是一条从问题出发、层层闭合的路线：

机器人数据太少
→ 用人类交互补充物理先验

人类与机器人、机器人与机器人动作不一致
→ 用统一物理语义槽位完成翻译

共享动作专家容量不足、容易负迁移
→ 用 MoF 分离共享原语与专门动力学

新本体微调会破坏共同知识
→ 用 ESA 只更新被激活的槽位

真实视觉发生分布偏移
→ 用 MPG 判断上下文是否可靠

不同机器人控制频率和延迟不同
→ 用 UAC 把推理延迟纳入训练和缓冲区协议

因此，这篇论文最核心的创新不是某个孤立公式，而是把跨本体泛化从一个“多数据集训练问题”，重新定义成“共享物理语言 + 专门化容量 + 实时控制协议”的系统问题。

也正因为如此，Being-H0.5 最值得后续工作验证的，不只是 LIBERO 能否再提高零点几个百分点，而是两个更大的问题：随着训练本体和任务继续增加，统一动作空间是否仍能保持语义清晰；当新机器人几乎没有演示数据时，这套“身体翻译”能否从非零信号走向稳定成功。

如果答案是肯定的，未来部署一台新机器人也许不再意味着从头教它每个动作，而更像是为一个已经懂得物理交互的模型，接入一种新的身体方言。

Being-H0.5 项目入口
项目主页 ｜ 论文 ｜ 开源代码 ｜ 模型集合