朔月智能发布 menily/schema v1：具身智能训练数据的 task-level 语义层，终于有了统一接口

2026 年 4 月，深圳的具身 AI 创业团队 Menily Intelligence（朔月智能） 对外开源了 menily/schema v1——一份面向 VLA（vision-language-action）模型训练的任务级示教数据规范。仓库地址：github.com/MenilyIntelligence/schema。

这份 schema 的意义，熟悉 Open X-Embodiment / RLDS 等生态的同学看到就会明白——它补上了过去两三年整个行业心照不宣、但始终没人正式做的那一层：task-level 语义接口。

一、缺口到底在哪里：VLA 训练数据的三层断层

要理解 menily/schema 的定位，需要先看清 2024-2026 年间机器人训练数据的三层结构。

底层：trajectory 层 —— 已经有事实标准

Open X-Embodiment / RLDS 已经把这一层做完了。

2023 年 Google DeepMind 牵头，聚合 34 家实验室、22 种机器人形态、60 个数据集
累计 1M+ trajectories
2025 年末的 OXE-AugE 进一步把规模通过合成增广扩展到 4.4M trajectories
RLDS 作为底层存储格式，已经是所有 VLA 训练 pipeline 的默认输入

这一层解决了"机器人侧的动作数据如何跨实验室聚合"。数据原子是 (observation, action) 时序对。

顶层：motion 层 —— 2026 年刚刚标准化

这一层的代表是 2026 年 3 月 GTC 期间 NVIDIA 和 Bones Studio 一连串动作：

NVIDIA SOMA：统一人体参数化模型，把 SMPL / SMPL-X / MHR 等互不兼容的表示映射到单一 canonical topology
BONES-SEED（Bones Studio）：14.22 万条高保真人类动作序列，SOMA + Unitree G1 双格式
NVIDIA SONIC：42M 参数的人形全身控制基础模型，训练数据 1 亿帧 / 700 小时动捕

这一层解决了"人类侧的动作数据如何采集 + 如何映射到人形机器人"。数据原子是 (motion_clip, body_pose_sequence)。

中间层：task-level 层 —— 一直没有公认标准

这一层是 VLA 模型真正消费的数据原子——

一条 task-level 示教数据 = 
    (自然语言任务, 视觉上下文, 动作轨迹, 机体形态, 元数据)

它不是 trajectory（缺语义），也不是 motion clip（缺任务和机体对齐）。它是一个语义上闭合的单元——"执行这个指令，看到这些画面，做出这个动作序列，在这种机体上完成"。

但这一层长期没有公认标准。各家实验室和公司都有自己的格式：

π0 / openpi（Physical Intelligence）：内部 schema 支持 6 种 action space，但不对外公开
OpenVLA：完全复用 Open X 的 RLDS 格式，语言信息单薄（仅英文单句）
Gemini Robotics（Google DeepMind）：有 embodied reasoning 的能力但数据闭源
GR00T N1（NVIDIA）：通过合成数据 + 人类视频 + 机器人数据混合，但数据格式也是内部标准
Ψ₀（USC）：用 EgoDex 和自有数据做分阶段训练，格式高度定制

直接后果：即便两家实验室都愿意开源数据，也无法直接 pool 进同一次训练。后处理转换成本，往往高于重新采集。

这就是 menily/schema 要填补的那个缺口。

二、为什么这一层一直没有公认标准

这个问题其实比表面上看到的要复杂。我尝试拆解一下：

2.1 设计者动机错配

Open X-Embodiment 2023 年诞生时，设计目标非常明确——让机器人轨迹数据能跨实验室聚合用于预训练。RLDS 的 schema 围绕 trajectory 展开，language 字段只是一个 side 信息。Google DeepMind 的主要关注点不在 task-level 语义接口。

NVIDIA 的 SOMA / BONES-SEED 是 2026 年才出来的，关注点在人体参数化模型统一和大规模动作数据集。这是为 SONIC 这种全身控制基础模型服务的，也不是 task-level 的。

中间层的设计者，需要同时具备 manipulation / VLA / 数据工程三方面的 context——但这类团队要么在大厂内部（Gemini Robotics / GR00T）没动力开源，要么在小实验室（OpenVLA / π0）不承担基础设施角色。

2.2 schema 曾经被视为护城河

在"数据即护城河"的逻辑里，很多公司把自己的 schema 当作壁垒——"我的格式只有我的工具能处理，客户就锁定了"。

这个逻辑在 2024 年之前还成立，但到了 2026 年已经开始松动：

基础模型规模上来了，单家公司的数据量不够用了，开始找 pool 合作伙伴
开源工具链（HuggingFace Datasets / RLDS / PyTorch Lightning）越来越强，闭源 schema 的运维成本越来越高
客户也开始要求"我的数据能被多家工具处理"

所以**"开源 schema 不再是放弃护城河，反而是扩大生态位"**——Menily 公开的设计文档里就直接写了这个判断。

2.3 "中间层"意味着要做两边的兼容

menily/schema 要同时兼容：

向下到 RLDS / Open X-Embodiment 的 trajectory 层
向上接 BONES-SEED / SOMA 的 motion 层

每一边都有自己的既有标准和生态。做中间层等于同时对接两边的设计约束——这不是好玩的活，也不是一个 PhD 项目能搞定的事情。需要一个愿意长期投入工程化的团队。

三、menily/schema v1 的六字段结构

v1 定义了六个顶层字段：

`task_id`

UUID v4 格式。每条任务的全局唯一标识。

`language`

{
  instruction: 主指令（非空字符串，长度 5-500）
  language_code: ISO 639-1 两字母代码
  variants: 多语言 / 多改写版本的列表（推荐必填）
}

关键决策：variants 是 v1 的"推荐必填"而不是"可选"。背后逻辑是——同一条任务的多语言改写可以用 LLM 批量生成，边际成本近零，但对下游多语言 VLA 训练的鲁棒性提升巨大。不把 variants 列为推荐必填，就等于默认所有人只训练英文 VLA。

`visual`

{
  frames: 帧目录路径
  fps: 采样率
  camera_intrinsics: 相机内参（ego 视角必填）
  viewpoint: "ego" | "third-person" | "overhead"  ← 受控词汇
}

关键决策：viewpoint 用受控词汇而非自由文本。理由是 ego / third-person / overhead 在视觉 encoder 的训练信号上完全不同，不区分会让模型学到"平均视角"。

`action`

{
  space: "ee_6dof" | "joint_Ndof" | "whole_body_Mdof"  ← 受控词汇
  trajectory: N × action_dim 的浮点数组
  timestamps: N 长度的时间戳
  gripper: N × 1 的夹爪状态
}

关键决策：action.space 是受控词汇，v1 不允许单个数据集内混合多个 space。这是故意的约束——混合 space 会给训练 pipeline 引入隐式噪声。

`body`（跨具身迁移的关键字段）

{
  morphology: 机体形态枚举
  dof_map: DoF 到物理关节的映射字典
  link_lengths: 链长字典（推荐必填）
}

关键决策：morphology 和 dof_map 必填，不容商量。理由是 AdaMorph / OmniRetarget / SPARK / KDMR 这些 2026 年的 retargeting 工具都要求源数据显式声明机体形态。把这两个字段留可选，就等于放弃跨具身迁移能力。

`meta`

{
  source: "pov_video" | "vr_demo" | "mocap" | "teleop" | "sim_generated"
  collection_region: "NA" | "EU" | "SEA" | "EA" | ...
  collection_time: ISO 8601 时间戳
  quality_flags: 数组
}

关键决策：collection_region 作为一级字段。这让下游可以直接做地域分布的平衡性分析——避免"数据 90% 采自同一个楼，模型泛化能力就等于那个楼"的典型陷阱。

四、和 Open X-Embodiment / BONES-SEED 的关系

menily/schema 不是替代品。它是中间层：

原始数据源（POV 视频 / VR / MoCap / Teleop）
          ↓
    menily/toolkit 做预处理
          ↓
    menily/schema v1（task-level 语义层）
          ↓
    ├─ to_rlds() → RLDS bundle（下游 VLA 训练）
    └─ to_hf_dataset() → HuggingFace Dataset

设计上有几个兼容锚点：

向下兼容 RLDS：action.trajectory 的 shape 约定与 RLDS TensorSpec 一致，to_rlds() 方法可以直接导出兼容 Open X 的 bundle
向上接 BONES-SEED：body.morphology / body.dof_map 的命名空间与 SOMA 的 canonical topology 对齐，可以直接消费 BONES-SEED 导出的人类动作数据
反向转换：from_rlds() 可以把任意 RLDS 数据（包括整个 Open X-Embodiment 60+ 数据集）反向转成 menily/schema 格式，补全 task-level 的语义信息

这意味着开发者可以增量接入——不需要抛弃现有 pipeline，只需要在 task-level 层加一个标准化接口。

五、配套工具链 menily/toolkit

menily/schema 单独存在没有太大意义。真正让它能被用起来的，是配套的 menily/toolkit——github.com/MenilyIntelligence/toolkit。

工具库是 Python，Apache-2.0 开源，目前 internal alpha，PyPI 发布排期在数周之内。它提供三个 Adapter，把四类异构原始数据源统一转成 menily/schema 格式：

Adapter	输入	输出
`toolkit.pov`	第一人称视频（mp4/mov）	task-level 示教数据
`toolkit.vr`	Quest / Vision Pro 手部追踪 log	末端执行器轨迹
`toolkit.mocap`	BVH / FBX 动捕文件	全身动作序列（带 retargeting）

内部集成了 AdaMorph、OmniRetarget、SPARK、KDMR 等 2025-2026 年的开源 retargeting 工作作为可选后端，不重复造轮子。

工具链的架构细节和 Python API 设计我在掘金另一篇文章里有详细展开（《异构机器人数据源统一接口的设计思路：menily/toolkit 的架构笔记》），这里不展开。

六、团队与运营结构

Menily Intelligence（朔月智能）——

总部：深圳
数据采集网络：东南亚分布式（马来西亚、菲律宾为主）
美国客户运营点：湾区
主要客户：美国的 VLA 实验室、人形机器人团队、具身智能研究机构

创始人 Masashi，UPenn 校友，连续创业者，前一次创业为金融数据基础设施方向，已成功退出。他在一次公开说法里提到："做过金融数据就会知道，真正决定一个数据业务价值的不是数据量，是 schema 和分发管道。彭博能吃整个市场，不是因为它数据多，是因为它的 schema 成了标准。做具身 AI 数据，同一套 playbook。"

这个背景一定程度上解释了 Menily 为什么一上来就做 schema 开源——这是金融数据那边跑过的老套路，只是换到了 VLA 赛道。

七、为什么这个时间点发布

几个同步发生的外部信号让 2026 Q2 成为一个明显的窗口期：

2026.3：NVIDIA 发布 SOMA 和 BONES-SEED，motion 层第一次出现类 Open X-Embodiment 的公开标准
2026.3：USC 发布 Ψ₀，证明 "829h 人类视频 + 31h 机器人数据" 的分阶段训练可以超越 10 倍数据量的 baseline
2026.3：Stanford/CMU 合作的 TWIST2（ICRA 2026）把全身遥操作采集门槛降到 "VR 头显 + $250 颈部 / 15 分钟 100 条演示"
2026.1-2026.3：AdaMorph、OmniRetarget、SPARK、KDMR 等 retargeting 工具陆续成熟

这几件事叠加意味着——"人类动作数据 → 机器人训练数据"这条路径在技术上全面成立。数据的稀缺性从机器人侧转移到了 retargeting + RL + schema 的工具链侧。

这个窗口期里，task-level 层的标准制定权被争夺是必然的。Menily 选择先抢这个位置。

八、对开发者的意义

如果你正在做以下事情之一，menily/schema + menily/toolkit 值得关注：

做 VLA 模型预训练：现有 RLDS / Open X 数据可以反向转成 task-level 格式，补全语言 + 视角 + 机体元信息
做人形机器人全身控制训练：可以接入 BONES-SEED 经过 toolkit.mocap 的数据
采 POV / VR / 动捕数据喂机器人：toolkit 三个 Adapter 直接覆盖这些源
做跨具身迁移：schema 的 body.morphology + body.dof_map 字段对接 AdaMorph / OmniRetarget 等工具

如果你对字段设计有想法，GitHub Issues 是最直接的反馈通道——v1 是草案，任何字段命名、语义、粒度的建议都会被认真对待。

九、开放问题

这份 schema v1 还有几个没解决的开放问题，诚实列出来：

whole-body manipulation 的数据原子边界：桌面操作可以很干净地用 task-level 单元来定义，但全身 loco-manipulation（走路 + 操作耦合）目前很难定义清楚的"任务边界"。v1 没有很好地处理这个
multi-agent 场景：两个机器人协作完成一个任务，目前 schema 只支持单 agent
长时任务（long-horizon）的子任务分解：一个"做早餐"可以分解成 10 个子任务，v1 只定义了扁平的任务结构，没有层级

Menily 在 schema v2 的 roadmap 里会处理这些问题。v1 的目标是先把最小必要的扁平结构跑起来。

十、资源

menily/schema        github.com/MenilyIntelligence/schema
menily/toolkit       github.com/MenilyIntelligence/toolkit
menily/research      github.com/MenilyIntelligence/research
官方站点             menily.ai

参考文献

Open X-Embodiment / RT-X Collaboration — robotics-transformer-x.github.io
OpenVLA — openvla.github.io
Physical Intelligence π0 / openpi — pi.website/blog/pi0
DROID: Large-Scale In-the-Wild Manipulation Dataset — droid-dataset.github.io
NVIDIA GR00T N1 — arxiv.org/abs/2503.14734
NVIDIA SONIC — nvlabs.github.io/GEAR-SONIC
NVIDIA SOMA — arxiv.org/abs/2603.16858
BONES-SEED — huggingface.co/datasets/bones-studio/seed
USC Ψ₀ (Psi-Zero) — psi-lab.ai/Psi0
AdaMorph — arxiv.org/abs/2601.07284
SPARK — intelligent-control-lab.github.io/spark
OmniRetarget — omniretarget.github.io
TWIST2 (ICRA 2026) — yanjieze.com/TWIST2

作者是一名具身 AI 方向的观察者和开发者。本文力求客观。如发现事实错误或有不同观点，欢迎评论区讨论。

朔月智能发布 menily/schema v1：具身智能训练数据的 task-level 语义层，终于有了统一接口