做具身智能的团队，问到“真机评测基准有哪些”这个问题，往往是被同一个尴尬逼出来的：仿真里刷到九成以上的成功率，一上真机就原形毕露。我见过不少组在模拟环境里跑得风生水起，真机测试一开，一半失败来自机械层面的意外，另一半来自光照、遮挡、接触力这些仿真里根本没认真建模的物理量。真机评测因此不是仿真评测的补充，而是另一套逻辑——它衡量的是整条感知-规划-控制链路在真实物理世界里的综合表现。这篇文章我会把目前具身领域能拿来当参照系的真机评测基准，按构型、任务形态、评测协议拆开讲清楚，并给出选型建议和踩坑经验，适合正在搭评测流程、或者准备复现别人真机结果的工程师和研究者。
1. 仿真刷分和真机翻车之间，隔着的到底是什么
1.1 仿真基准的优势，同时也是它的局限
“具身智能”这个方向之所以过去几年大量依赖仿真评测，是因为仿真基准确实好用。以 Meta-World、RLBench、CALVIN、LIBERO、ManiSkill 为代表的模拟环境，把物体模型、相机内外参、机器人运动学都参数化了，跑一次实验只要几张显卡，还能并行几十个随机种子，天然适合算法预筛。论文里漂亮的成功率曲线，绝大多数是在这种“简化世界”里跑出来的。
问题在于，这些基准对物理交互的抽象程度太高了。真机上随机的桌面光照、相机的畸变和曝光波动、机械臂关节回差、物体从指尖滑落时的摩擦突变、软体物体被我抓变形的那一下，仿真里要么不存在，要么用一个简化物理模型糊弄过去。久而久之，排行榜的比拼就变成了“谁的策略更会在简化动力学里钻空子”，而不是“谁的机器人真的更会干活”。
必须说一句公道话：仿真基准不是错了，它是在特定抽象层级上做了取舍。真正错的是把仿真分数直接当成真机能力的证明。很多团队把“仿真成功率高”当作模型发布的核心论据，结果部署后翻车，本质上就是评测边界没划清楚。
1.2 真机评测到底在考什么
真机评测本质上把三个东西同时放上考场。
第一是感知的迁移能力。模型在仿真里见过的纹理、光影和物体分布，和真实相机采集到的画面差异极大，感知网络会不会过拟合到仿真渲染风格，只有真机能检验。第二是控制对物理接触的鲁棒性。仿真里的接触往往是刚体近似，真机上手指/夹爪的轻微倾斜、力矩过冲、柔性形变都会被放大。第三是整机系统的容错能力。机械臂连续跑四五个小时会不会漂移，控制器遇到通信中断会不会安全停机，策略遇到从未见过的物体位姿时能不能闭环恢复，这些都不是一个离线指标能涵盖的。
所以真机评测衡量的是系统级别的表现，不是单点能力。也正因为如此，它天然贵、慢、需要人工监督和安全冗余。这也是为什么大家一边嫌仿真不真实，一边又不愿意高频做真机评测的根因。
顺便提一句，中间路线也有人走，比如用与真实硬件高度对齐的仿真环境做“校准评测”，类似 SIMPLER 这类思路——先把仿真环境调到和真机分布接近，再做评测对比。但这类方法最终也逃不过真机抽检，只能算降低真机迭代频率的辅助手段。
2. 真机评测基准的分类地图：先搞清楚在聊哪一层
聊真机评测基准之前，得先分清楚两件事：你说的“基准”到底是任务集合，是数据集合，还是硬件平台加评测协议的组合。很多人把公开真机数据集直接当成基准，这个误解会让后续选型走不少弯路。
2.1 按机器人构型分四大类
| 构型类别 | 代表基准/平台 | 评测重点 |
|---|---|---|
| 单臂桌面操作 | RoboMimic、Language-Table、BridgeData V2 的大多数任务 | 抓取、放置、基础工具使用，强调策略学习 |
| 双臂协同操作 | ALOHA / ALOHA 2 / Mobile ALOHA 的典型任务 | 双手配合、长程精细作业，强调遥操作和模仿学习 |
| 移动操作 | Mobile ALOHA 扩展任务、各类车组平台自建任务 | 导航与操作联合，强调长时间跨区域任务 |
| 多构型数据生态 | DROID、Open X-Embodiment、国内公开真机集 | 跨本体迁移，强调预训练模型通用性 |
选择的时候要清楚，单臂桌面任务和双臂长程任务面对的是完全不同的失败模式。单臂桌面任务的难点集中在夹取策略和物体位姿泛化，双臂任务还会叠加协同运动学和动作空间冲突，评测复杂度完全不是一个量级。
2.2 按交付形态分三类：任务型、数据型、平台型
任务型基准是最接近传统评测定义的，它提供固定的任务集合、成功判定规则、评测协议和公开基线，典型代表是 RoboMimic。这种基准的好处是横向对比门槛低，任何人都能用同一套规则跑自己的算法。
数据型基准只提供大规模真机演示数据，评测方式由使用者自己定义，典型代表是 DROID 和 Open X-Embodiment。它们解决的是“数据从哪里来”的问题，但如果你只是下载了数据而没有自己设计任务协议，你拿到的其实不是基准，只是原料。
平台型基准则是硬件、采集方法、训练代码一起开源，比如 ALOHA 系列。它没有官方排行榜，它给的是一个被社区广泛验证过的“标准实验环境”。团队之间可以基于同一套硬件平台自建任务，再互相比较。
把这三层分开后你会发现，很多团队说“我们评测了什么”，其实只是“我们采集了什么”。数据量再大，缺少协议和指标，就无法形成可信的对比结论。
3. 绕不开的几个真机评测基准，逐个拆开看
3.1 RoboMimic：入门级单臂操作基准，协议最干净
RoboMimic 目前依然是单臂真机评测里最容易被复现、最常被引用的起点。它定义了四种典型单臂任务：把物体抬离桌面、抓取罐子、把转接头插入方形口、把工具挂到特定位置。官方为每个任务提供了固定的离线演示数据集，并给出了统一评测流程：固定相机位姿、统一成功判定、用同一组基线算法（行为克隆、BC-RNN、保守 Q 学习等）做对照。
它对刚入门的团队非常友好，原因有三：一是任务定义明确，成功与否有客观判断；二是离线数据规模不大，机器配置要求低；三是社区里跑过的人很多，遇到问题容易找人交流。
但它的局限也明显：任务类型少，物体位姿和场景分布比较固定，不容易测出策略的泛化能力。而且真机版本的复现性比仿真差不少，成功率和机械臂标定质量强相关。我见过不少团队直接下载官方检查点跑自己机器人，结果成功率砍半，最后发现是相机外参没重标。首次用 RoboMimic 之前，建议先花半天时间做一次相机-机械臂标定，并用一个最小测试集验证成功判定逻辑，再开始正式实验。
3.2 BridgeData V2 与 Language-Table：低成本语言条件化评测
如果你的研究重心在“视觉语言模型 + 机器人操作”，那 BridgeData V2 和 Language-Table 有独特的价值。BridgeData V2 提供的是数万条在真实家庭、厨房、桌面等场景中采集的单臂演示轨迹，用语言指令做条件化标注，强调“杂乱环境 + 语言指令 + 多相机”的评测难度。它不只是一个数据集，还配套了对应的评测环境和任务定义，很多离线强化学习论文就是用它的真实机器人任务作为最终验证。
Language-Table 则把复杂度降到极低：机械臂很小，任务就是推动、摆放桌面上的色块，指令像“把红色方块推到绿色角落”这样直白。它的好处是迭代速度极快，半天就能完成一轮“改模型-采集-真机评测”的循环，非常适合先验证策略的语义理解和动作 grounding 能力，再去挑战更复杂的任务。
这两套下来，基本可以形成一个低成本的语言条件化真机评测组合：用 Language-Table 快速验证模型能不能听懂指令，再用 BridgeData V2 的任务验证在更杂乱场景里的表现。它们的短板是机械结构和任务形态离工业应用有距离，不能作为最终产品能力的证明。
3.3 ALOHA 家族：双臂精细操作的事实平台
提到真机双臂操作，绕不开 ALOHA。它最初解决的是“低成本双臂精细遥操作”的工程问题，让实验室用远低于工业平台的预算实现高保真双手控制。后来的 ALOHA 2 在机械结构、工作空间、深度相机配置上做了大量改进，Mobile ALOHA 又给平台装了移动底座，把评测范围扩展到了做饭、开门、收拾物品这类长程移动操作任务。
ALOHA 家族没有官方排行榜，它更像一个被社区默认的硬件平台和演示采集协议。实际操作中，给定一个真实任务（比如挂衣架、拉拉链、转齿轮），团队用遥操作采集一批演示，训练模仿学习策略，再在固定初始条件下跑成功率。Mobile ALOHA 的论文里还特别强调“静态双臂数据和移动数据联合训练”，把静态 ALOHA 的数据作为提升移动操纵稳定性的关键。
对做双臂操作或者人形机器人上身控制的团队来说，ALOHA 是目前成本最低、讨论度最高的起点。工程上的坑主要是遥操作采集的一致性：演示过程中末端位姿和夹爪开合要稳定，否则策略会学到奇怪的偏好。
3.4 DROID 和 Open X-Embodiment：跨本体迁移的评测生态
这两个代表的是另一个思路：拒绝把小任务集当作评测终点，而是用大规模、多场景、多构型数据来检验通用性。
DROID 提供了七万余条真实轨迹，覆盖数百种真实场景和大量任务类型，强调“真实世界的多样性”。它适合回答“一个策略在训练分布之外能不能做对”的问题，很多具身基础模型论文都会用它做外部验证。
Open X-Embodiment（简写 OXE）则把多套公开真机数据集统一成跨本体格式，汇总了几十万条演示片段，覆盖二十多种机器人构型，并配套了 RT 系列的策略模型。OXE 的评测逻辑已经不是“单任务成功率”，而是“一套策略换一种机械臂、换一种相机，成功率能保留多少”。这个问题恰好对应具身大模型真实部署时的核心诉求——不能每个机器人从头训一遍。
使用这类数据生态的代价是数据清洗和后处理成本很高。不同数据集的动作空间、控制频率、相机位姿定义都有差异，归一化脚本如果处理得不彻底，训练出的策略在真机上会出现“换了坐标系就废”的问题。
3.5 国内公开真机数据集与评测体系
近几年国内团队也开源了几套有代表性的真机数据/评测体系，比如 RH20T、AgiBot World、RoboMIND 等。它们的特点比较明显：任务覆盖更贴近国内日常场景，不少包含双臂或复合机器人构型，部分体系配套了中文指令评估和基线模型。
我的建议是挑选时重点看三件事：数据授权是否允许商用、传感器配置是否匹配你的机器人、评测代码和协议是否完整开放。有些数据集规模很可观，但后处理脚本和成功判定代码缺了一大半，实际用起来要花不少时间自行补全。这类工作还在快速迭代中，关注官方更新往往比等二手整理更靠谱。
把这一节汇总成一张表，方便直接对照选型：
| 基准/平台 | 构型 | 评测定位 | 上手成本 | 适用场景 |
|---|---|---|---|---|
| RoboMimic | 单臂 | 固定任务+离线数据+统一协议 | 低 | 算法对比、模仿学习入门 |
| Language-Table | 单臂 | 语言指令桌面任务 | 低 | 视觉语言策略快速验证 |
| BridgeData V2 | 单臂 | 真实家庭场景语言条件化任务 | 中 | 离线强化学习、语言控制 |
| ALOHA 家族 | 双臂/移动 | 长程精细双臂任务 | 中 | 双臂操作、移动操作研究 |
| DROID | 单臂 | 大规模真实世界多样性任务 | 高 | 通用策略外部验证 |
| Open X-Embodiment | 多构型 | 跨本体迁移评测 | 高 | 具身基础模型 |
| 国内真机体系们 | 单臂/双臂/复合 | 中文场景与多构型数据 | 中高 | 国内场景落地预研 |
4. 评测指标与评测协议：真正拉开差距的地方
4.1 成功率之外，还要盯哪些指标
真机评测里最常见的错误是“只报成功率”。成功率当然重要，但它远不足以支撑结论，尤其对具身智能这种系统性问题多的领域。
我建议至少再关注四类指标。一是部分完成率或分阶段成功率，对应长程任务执行到哪一步才失败的；二是鲁棒性，比如在评测中加入轻微推搡、遮挡和光照变化，看成功率掉多少；三是泛化性，把物体换成训练时没见过的形状或颜色，把指令换成同义换说法，看策略能不能扛住；四是安全指标，比如碰撞次数、急停距离、超行程报警，这对产品化尤其重要。
可以这样理解：成功率回答的是“能不能做完”，鲁棒性回答的是“稳不稳”，泛化性回答的是“有没有背题”，安全指标回答的是“出问题会不会伤人”。四个维度合在一起，才是一份能负责的真机评测报告。
4.2 一份可信评测协议的最小配置
基于我实际踩坑的经验，一套可信度足够高的真机评测协议至少包含这些要素：固定随机种子和物体位姿扰动范围、每项任务不少于 10 次有效测试（条件允许最好 20 次）、明确定义成功判定的客观规则、全程录屏并保存机械臂控制日志、记录相机标定文件和机械臂标定文件。下面这个字段列表是我做评测时都会保留的最小集，直接抄作业就行：
# 一个最简单的真机评测记录结构，建议每次实验固定保存 eval_run = { "task": "put_apple_in_bowl", "robot_urdf_version": "ur5_v3", "camera_calib": "20250106_cam2base.yaml", "n_trials": 20, "object_pose_seed_list": [1, 2, 3, 4, 5], "lighting": "lab_default", "success": [1, 1, 0, 1, 1, ...], "partial_success": [0.5, 1, 0.2, ...], "completion_time": [8.2, 6.1, ...], "human_intervention_count": 2, "video_path": "run_20250106_a/", "log_path": "run_20250106_a/logs/", }评测协议里最容易被人钻空子的是“成功判定”。如果成功标准是人工肉眼看的，那不同操作员会给出完全不同的结论。可行做法是把成功判定拆成可检测的子步骤，比如“夹爪闭合”“物体离开桌面”“物体进入目标区域”分别打标签，而不是给一个总体的“成功/失败”二值。人工复核可以保留，但要有统一的操作手册。
5. 真机评测的隐形坑：复现性、成本与公平性
5.1 硬件不一致和标定漂移，是复现性低的第一原因
同一份代码，在 A 实验室跑得漂亮，到 B 实验室直接崩，最可能的原因不是算法玄学，而是硬件状态不一致。相机高度差两公分、基座标定用了一个月前的参数、夹爪磨损导致开合宽度变化，这些都会显著影响成功率。
解决办法是建立评测前的“体检清单”：每次评测日开始前重标相机外参，检查机械臂末端实际位姿和理论位姿的误差，记录夹爪开合的真实宽度，确认桌面和物体的位置分布符合协议。这套检查看起来琐碎，但省掉它，后续所有对比都不可信。
5.2 基准过拟合和数据泄漏
开源真机数据集的流行带来了一个隐蔽问题：你的训练数据可能已经包含了将来评测时用的“新任务”。很多论文用公开数据集既训练又评测，评测任务的物体、场景、指令和训练集高度重叠，最终给出的泛化结论其实是“内存外推”。
做评测设计时，至少要留出训练时完全未见过的场景子集，比如换三种物体、换一个房间、换一套光照条件。哪怕这会让成功率数字变难看，也比自欺欺人强。另外，遥操作演示的数据分布和策略自主执行时的分布天然不同，评测时不要重复使用演示时的初始条件和路径，否则会过高估计模仿学习的真实能力。
5.3 成本、时间和安全预算要提前算
真机评测的隐性成本往往被严重低估。一次像样的双臂任务评测，从遥操作采数据、训练、部署、调成功判定，到正式跑 20 个 trail，可能要一整天。过程中还会遇到机械臂保护性停机、物体被推出容器外、网络通信抖动这些突发状况，每个都要有人盯着处理。
所以真机评测不是越频繁越好，而是应该和仿真评测错开：仿真负责快速迭代算法假设，真机负责抽样验证关键结论。对安全也要有底线设置，评测脚本里必须带超时保护、力矩限制、远程急停。跑无人值守实验前，我建议先做一轮“干跑”，确认所有异常分支都会被安全处理，再放策略长时间运行。
5.4 让评测结果站得住脚的四个存档习惯
现在很多人发真机结果只放一段精选视频，这是最不可信的证据形式。想让自己结果能对他人负责，至少做到四点：原始 log 全量存档、录屏不剪接地保留连续片段、固定种子和初始条件列表随结果一起发布、评测脚本开源到仓库。这样做之后，别人拿到手就能复现，你的结论才真正有辩护能力。
6. 给自家团队选基准：按照目标反推选型
6.1 先想清楚要回答什么问题
选基准之前，先问自己这次的评测结论给谁看、要支撑什么判断。
如果只是验证一个新算法相比既有基线有没有提升，首选协议固定、成本低的任务型基准，RoboMimic 和 Language-Table 是很好的组合。如果目标是验证视觉语言大模型在真机上的底座能力，应该走 BridgeData V2 加跨本体迁移评测的路线。如果目标不是发论文而是产品验收，那任何公开基准都替代不了自建任务套件——产品场景里的门槛和开放基准里的任务分布往往差得很远。
6.2 参考决策表
| 团队情况 | 首选评测组合 | 理由 |
|---|---|---|
| 小型实验室，单臂机械臂 | RoboMimic + Language-Table | 成本低、协议清晰、社区基线多 |
| 已有双臂平台 | ALOHA 2 | 硬件开源、演示采集成熟、经验可参考 |
| 做具身基础模型/跨本体迁移 | OXE + DROID | 数据多样性高，能测跨构型泛化 |
| 做家用服务/移动操作 | Mobile ALOHA + 自建任务 | 长程移动任务能暴露导航与操作协同短板 |
| 准备产品落地验收 | 自建 5-10 个任务的最小任务套件 | 直接映射真实产品场景和失败率红线 |
6.3 自建最小评测套件的建议
自建套件不需要贪多。我的经验是控制在 5 到 10 个任务，覆盖抓取、放置、工具使用、干扰恢复这四类基础能力就够用了。每个任务固定 20 次试跑，统一记录成功率、中位完成时间和人工干预次数。评测输出不要只给一张汇总表，还要附一份失败模式清单——失败发生在哪个阶段、是感知问题还是控制问题、是持续性故障还是偶发扰动，这些信息才是下一轮迭代真正需要的。
我也建议新模型进真机前，先在公开基准上跑一遍，把评测脚本原样沿用下来，不要自己私下做“友好化”改动。改协议不是不可以，但每改一处都要在方法部分写清楚，否则你的结果无法和别人的数字横向比较。
真机评测基准解决的从来不只是“能不能跑通”的问题，而是“跑通的结果能不能对别人负责”的问题。选准基准、守住协议、留好记录，这三件事做到位，你在具身领域的评测结论才经得起同行推敲。
