08. 具身智能评测基准 (Benchmarks)
评测目标不是“营销分数”，而是为工程迭代提供可复现回归标准：测什么、怎么测、谁来判定、指标怎么解释。
⏰ 最后更新时间: 2026-02-26 | 本页内容将每日更新「具身任务评测基准、指标口径与复现入口」。
8.1 主流 benchmark 速览
| 基准 | 类型 | 判定者 | 入口 |
|---|---|---|---|
| LIBERO | Benchmark / Task Suite | 传统算法 + 任务完成判定 | Project |
| RoboCasa | Benchmark / Dataset | 传统算法 + 环境规则 | Project |
| ManiSkill | Benchmark / Simulator | 传统算法 + 环境评测脚本 | Docs |
| CALVIN | Benchmark / Long-horizon | 任务规则 + 成功率统计 | GitHub |
8.2 推荐指标面板（用于回归）
- Success Rate：任务完成率（基础主指标）。
- Recovery Rate：失败后恢复成功率（上线关键指标）。
- Latency Budget：感知-决策-控制闭环延迟。
- Safety Incidents：碰撞、超力矩、急停触发频次。
- OOD Generalization：新物体/新视角/新场景性能下降幅度。
8.3 使用建议（How to use）
- 固定评测协议（相机、初始状态、随机种子），避免口径漂移。
- 每次训练迭代至少做一次“旧任务回归 + 新任务扩展”双测。
- 把安全指标纳入 gate，不允许只靠成功率推进版本。
8.4 深度条目（可复现视角）
LIBERO（Benchmark / Task Suite）
判定者：传统算法 + 环境任务完成判定（非主观人工评审）。
🟢 通俗解读
LIBERO 像“机器人期末考试题库”，通过一组标准化任务判断策略是不是只会做单题，还是能跨任务迁移。
🔴 专业解读
- What it measures：跨任务泛化、长期任务成功率、策略迁移能力。
- How to use：固定任务套件与随机种子，记录 Success/Completion 指标，并与统一 baseline 对照。
- Pitfalls：只追平均成功率会掩盖“长尾任务失败”；建议同时看每任务分布与失败类型。
- 来源定位：Project Page / GitHub Repo
🧠 AntiGravity's Commentary
LIBERO 适合作为“跨任务回归门槛”，不适合作为唯一 KPI。真实部署还要补充恢复率与安全事件率。
RoboCasa（Benchmark / Dataset）
判定者：环境规则 + 任务脚本自动判定。
🟢 通俗解读
RoboCasa 更像“家庭场景压力测试”，它关注策略在多样家居布局下是否还能稳定完成操作。
🔴 专业解读
- What it measures：多场景操作泛化、复杂交互步骤稳定性、任务组合鲁棒性。
- How to use：按官方任务配置运行，记录任务完成率、平均完成时间、失败轨迹分布。
- Pitfalls：若只在少量固定布局评测，容易高估泛化；需加随机布局和对象扰动回归。
- 来源定位：Project Page / GitHub Repo
🧠 AntiGravity's Commentary
RoboCasa 的价值在“场景复杂度”，实际部署中通常会补充真实传感器噪声与控制延迟的外部回归测试。
ManiSkill（Benchmark / Simulator）
判定者：环境评测脚本 + 任务规则统计。
🟢 通俗解读
ManiSkill 是“操作任务实验场”，适合快速对比算法迭代，尤其在抓取、放置、工具使用等任务上。
🔴 专业解读
- What it measures：操作任务成功率、轨迹质量、策略稳定性。
- How to use：使用官方环境和脚本固定评测配置，记录 success、episode length 与失败类别。
- Pitfalls：仿真评测易忽略实机延迟与接触误差；通常需要配套 Sim2Real 回流验证。
- 来源定位：Docs / GitHub Repo
🧠 AntiGravity's Commentary
ManiSkill 非常适合算法迭代，但不要把它当“上线许可”。最优实践是仿真回归 + 小流量实机验证并行。
8.5 最新增补：SPOC（Safety-Aware Planning）
SPOC: Safety-Aware Planning Under Partial Observability And Physical Constraints（Benchmark / Protocol）
判定者：传统算法 + 环境约束规则（基于 goal-condition 与 constraint 违规情况在线统计）。
🟢 通俗解读
SPOC 不是只看“任务有没有完成”，而是同时看“过程中有没有做出危险动作”。它更接近真实家庭部署里“安全优先”的评测口径。
🔴 专业解读
- Type / Judge：Benchmark + Protocol；判定者为传统算法与环境约束规则（非主观人工、非LLM裁判）。
- What it measures：
① 可行性：部分可观测条件下计划是否可执行；
② 安全性：是否触发火灾/液体/损坏/污染等约束违规；
③ 一致性：step-by-step planning 是否在中途偏离目标条件。 - How to use（最小复现路径）：固定 hazard 场景集合与随机种子 → 运行逐步规划 → 记录 goal success、constraint violation、平均规划步数与 replanning 频次。
- 核心对照实验建议：同一任务上对比“高成功率但高违规”的 planner 与“中等成功率低违规”的 planner，验证安全门槛对上线决策的影响。
- Pitfalls：仅优化最终成功率会掩盖“先违规后完成”的危险轨迹；必须把 constraint violation 作为硬门槛。
- 部署含义：SPOC 更像“上线前 safety regression”而非 leaderboard KPI，适合放进每周回归流水线。
- 来源定位：Abstract / arXiv Entry
🧠 AntiGravity's Commentary
SPOC 更适合作为“上线前安全回归集”而不是营销榜单。建议在 CI 中把“违规率=0”设为阻断条件，再看成功率与时延折中。
8.6 安全评测落地模板（建议直接用于回归）
| 维度 | 建议阈值 | 用途 | 常见误区 |
|---|---|---|---|
| Goal Success Rate | 按场景分层设定（如 ≥70%） | 衡量任务完成能力 | 只看均值，不看场景分布 |
| Constraint Violation | 必须为 0 或极低（强 gate） | 衡量安全底线 | 把安全事件当“可接受探索噪声” |
| Replanning Frequency | 持续下降或稳定在目标区间 | 衡量规划稳定性与观测鲁棒性 | 忽略中途反复重规划造成的时延抖动 |
| End-to-End Latency | 满足控制回路预算（如 ≤50ms/step） | 衡量实时部署可行性 | 离线指标好看但线上超时 |
建议顺序：先过安全门槛（Violation）→ 再看成功率（Success）→ 最后优化效率（Latency/Replanning）。
具身评测最常见误用是“只报成功率”。如果没有恢复能力和安全指标，分数再高也不具备部署意义。