这周刚跑完 Mira Agent Core Benchmark，再看 OpenArm 2.0，会有一种很强的既视感。
我们这边刚因为 scorer、证据记录和测试环境折腾了三天；机器人那边则在认真解决另一个看起来更琐碎的问题：
灯光是不是一样，相机是不是放在同一个位置，机械臂是不是装在同一个姿态。
乍看之下，这些都不像“人工智能”。
但如果目标是比较两个机器人模型到底谁更好，它们恰恰可能比模型名字更重要。
它升级的不是一只机械臂，而是一整套评测环境#
OpenArm 1.0 更容易被理解成一只开源机器人手臂。
到了 2.0，项目自己给出的定位已经变了：不再只是 arm，而是一个面向 physical AI，也就是“真正进入物理世界的 AI”的完整研究栈。除了 7 自由度机械臂本身，还加入了 OpenArm Cell，以及计划中的 OpenArm KER。
这里的“7 自由度”可以简单理解成：机械臂有 7 个可以独立控制的运动关节，因此能比较接近人类手臂那种灵活的空间动作。
真正值得注意的是 OpenArm Cell。
它不是新模型，也不是新算法，而是一间标准化的机器人“考场”。项目把背景、灯光、相机位置、机械臂安装位置和校准流程都固定下来，希望不同实验室在评测同一类模型时，至少先站在相同的物理条件里。
OpenArm 对这件事说得很直接：
如果“模型 A 胜过模型 B”要有意义，两者就必须在相同条件下被评估。
OpenArm 2.0：What's New ↗ · OpenArm Cell ↗
具身智能的麻烦，是现实世界会一起参加考试#
纯软件 Benchmark 当然也有环境差异。
操作系统版本、依赖包、CPU、网络条件、测试数据，都可能影响结果。
但机器人把这件事推到了更极端的位置，因为现实世界本身就是输入。
灯光稍微偏一点，视觉模型看到的颜色和阴影会变；相机高几厘米，物体在画面中的透视和遮挡关系会变；机械臂装配位置略有不同，末端执行器到同一个杯子的路径就不再完全一样。
甚至同一套机械臂，重新拆装以后产生的机械误差，也可能让两次测试并不真正等价。
如果这些变量没有被控制，“模型更强”很容易和“这次环境更友好”混在一起。
这也是 OpenArm Cell 最值得看的地方：它不是试图把所有现实世界变量消灭掉，而是先把那些本来不应该成为竞争变量的东西固定下来。
背景不该偷偷帮某个视觉模型。
相机位置不该决定谁赢。
装配误差更不应该被误读成模型能力。
最有意思的，可能是那个看起来最笨的校准夹具#
OpenArm 2.0 里有一个很不“AI”的东西：零位校准夹具。
机械臂放进 Cell 以后，夹具会把末端执行器和关节约束到 CAD 定义的固定姿态，再执行零位校准。它的目标很直接：尽量把装配公差从后续数据和评测中拿掉。
OpenArm 的安装文档甚至把这件事写成了明确步骤：安装夹具，把末端放进固定凹槽，确认关节不能移动，然后再设置零位。
OpenArm Calibration Workflow ↗ · OpenArm Setup ↗
它看起来只是一个机械结构。
但从 Benchmark 的角度看，它其实在做一件很重要的事情：
把“大家差不多都装好了”变成“大家从同一个机械参考点开始”。
软件工程里，我们会把环境装进容器，把依赖版本锁死，把测试数据冻结。
机器人做的是同一件事，只不过它没法把现实世界塞进 Docker，于是只能真的造一套物理夹具出来。
这大概是具身智能最有意思的地方之一：很多抽象的软件工程概念，最后都得长成螺丝、铝型材、相机和传感器。
相机也不能只说“有一个就行”#
OpenArm 2.0 的 Setup 文档里还有一个很工程、但很说明问题的细节。
相机需要被赋予稳定的设备标识，并通过 udev 规则映射到固定名称，例如 wrist right、wrist left、ceiling camera。这样程序拿到的不是“系统今天枚举出来的 video2”，而是语义稳定的“右腕相机”。
这看起来像普通设备配置，实际上仍然是在减少评测里的偶然性。
如果今天右腕相机是 video2，明天重启以后变成 video4，而上层软件又偷偷读错了设备，那么最终 Benchmark 测到的可能根本不是模型能力。
所以真正可复现的机器人评测，并不是“把任务脚本公开”就结束了。
它还包括设备身份、物理位置、校准流程和启动条件。
开源在这里，也不只是公开代码#
OpenArm Cell 还有一个很重要的设计选择：大量使用全球相对容易获得的标准件，并公开 CAD 和 BOM，也就是物料清单。
这意味着它想开放的不只是一个结果，而是让其他实验室有机会重建同样的评测环境。
这和过去“我把代码放 GitHub，你自己想办法跑起来”的开源逻辑不太一样。
如果 Benchmark 依赖一个只有原团队拥有的特殊实验室，那它再标准，也很难真正成为公共标准。
一个能被复制的考场，才有机会让不同团队的结果进入同一张表。
但“标准考场”并没有解决所有问题#
这里也不能把 OpenArm 2.0 写成“机器人 Benchmark 已经被解决”。
OpenArm 自己的 FAQ 目前仍然写着：关于机械臂的 accuracy 和 repeatability，也就是“精度和重复性”，完整文档还在准备中。KER——用于长时间遥操作和数据采集的无电机 leader arm——也还没有正式发布。
OpenArm FAQ ↗ · OpenArm 2.0 Overview ↗
而且，就算所有实验室都买了一样的 Cell，仍然有很多问题不会自动消失。
任务本身怎么定义？物体摆放允许多少误差？同一个任务跑几次？模型失败以后能不能重试？机械磨损如何处理？软件和控制器版本怎么冻结？最后到底按成功率、耗时、动作稳定性，还是别的指标评分？
这些仍然需要一套完整的 Benchmark contract，也就是大家事先认可的考试规则。
所以 OpenArm Cell 更准确的意义不是“解决了机器人评测”，而是把其中长期被忽视的一层正式摆到了台面上：
物理环境本身，也是评测协议的一部分。
这和 Mira 刚踩过的坑，其实是一回事#
Mira 这周的 Benchmark 最后有一道题没有完整出分。
不是因为任务没有执行，而是因为冻结证据里缺少一个足以让 deterministic scorer，也就是确定性判分程序，判断失败类型的字段。
我们最后没有让 Judge 或人类“理解一下”，而是把结果保留为 incomplete。
那次教训是：你没有记录到的事实，就不应该事后假装自己知道。
OpenArm Cell 处理的是另一个维度的同类问题。
你没有固定下来的环境变量，也不应该事后假装它们没有影响结果。
一个是信息世界里的 observability，也就是“关键事实有没有被可靠记录”。
另一个是物理世界里的 reproducibility，也就是“同样的实验条件能不能被重新建立”。
两边最后都落到同一句话上：
Benchmark 的尺子，本身也是系统的一部分。
真正成熟的 Benchmark，不只是排行榜#
我们很容易把 Benchmark 想成一张排行榜。
谁 72 分。
谁 85 分。
谁超过了谁。
但排行榜其实只是最后一层。
真正成熟的评测，前面还有大量很不性感的基础工作：冻结版本、统一环境、定义失败、记录证据、控制变量、重复执行、校准设备。
这些东西做得越认真，最后那个数字反而越值得相信。
OpenArm 2.0 最有价值的地方，也许就在这里。
它没有只告诉大家：
“我们又做了一只更好的机械臂。”
而是在问一个更麻烦的问题：
如果以后所有人都想证明自己的机器人模型更好，我们能不能先让大家站进同一间考场？
这比又一个漂亮 Demo，有意思得多。
