具身开源生态的"最后一公里"，终于有人认真做了：北航开源 EVA-Client

你能相信一个未加载预训练权重的QwenOFT加上ARX R5机械臂能够流畅精准的进行乒乓球对打，回合稳定推进吗？第一次看到这段视频的人，很容易在心里先预设一个失败结局——一个无预训练和强化学习后训练的模型，动作应该会颤、会卡、会失手。

可视频里的场景是：球被稳稳接住、稳稳打回，然后再接、再打，回合能连续推进。

这段视频来自北航 CoLab 最新开源的EVA-Client：一套覆盖真机数据采集、部署与评测的一体化软件框架。

在具身开发的流程中，决定策略能不能在真机上真正跑起来的，不只是模型性能本身，但把模型接到机器人身上的那一层"真机部署方案"同样起到了至关重要的作用——而它，恰恰是当前具身智能开源生态里被长期忽略的一环。

近两年具身模型的研究领域越来越火热，闭环迭代范式也越来越清晰：先在真实机器人上通过遥操作采集一批数据，把数据输入训练框架得到对应的权重，接着部署回真机上进行调试，再按既定任务做评测，得到模型的性能指标，然后把认知回流到下一轮数据采集里去。

这条闭环里，OpenPI、StarVLA、GR00T、DreamZero、VLA Foundry、Cosmos把VLA/WAM等各条技术路线的训练栈都覆盖得相当全面，LeRobot 又把具身数据的存储格式统一成了事实标准；跑通一次模型训练已经不再是难事，甚至可以说，具身模型的训练已经从过去的"神秘手艺"变成了今天的"配置菜单"。

但真正卡住具身模型跨团队复现的，是训练完之后从模型权重走到真机上、"动得对、动得稳、能被评"的这最后一段路，这段路上的情况远没有训练侧干净。

采集侧，不同实验室的机位摆放、遥操作节奏、对齐口径各不相同，同型号机器人的数据放到一起用，都常常引入新的偏置；部署侧，把一个训练好的策略变成机械臂上稳定的动作流，涉及观测同步、动作调度、延迟补偿、动作空间转换等一整套工程细节，可这些细节往往作为方法特化的小脚本，深藏在某个训练栈的角落，换一台机器就得从头写一遍，也不容易做公平的横向对比；评测侧更朴素——现在业内的主流做法还是操作员盯着机器人跑几十次、留下一行"成功 18 / 失败 12"就结束了，过程录像、策略当时看到了什么、为什么输出了那个动作，几乎全丢。

真机结果因此既不可复现，也无法归因；社区目前只好绕道去仿真里比公平。可具身模型终究是要从真机数据中来、再回到真机部署中去的，真机的端到端表现才是衡量它的唯一标准。EVA-Client 要补的正是这一块拼图。

01.

数据采集：让每一次落盘的数据都"够格"进入下一轮训练

具身闭环的起点是数据。而数据质量往往在采集的那一刻就已经被决定：一条时间戳跳过一帧、一路相机偶尔丢帧、一次维度错位……这些问题在采集当下也许看不出来，但会在下游训练里被放大成一整批"学歪"的模型。EVA-Client 的数据采集模式因此不只是"录制"，还包括"质检"——两个阶段合起来构成一套双层保障，让每一条被写入硬盘的数据，都已经被验证过可以在真机上 replay 无误。

录制阶段，EVA-Client 用leader-follower遥操作模式驱动 follower 机械臂，操作员移动 leader，客户端就把每一帧的实测状态和下发动作作为一对同步样本存下来，关节角和末端位姿两种表示同时保留，配合相机流一起对齐时间戳。写盘由后台线程接手，采集主循环永远不会因为I/O阻塞——这一点在低性能机器上尤其关键，长时间录制不至于因为磁盘写慢而出现数据采集过程低效情况。

质检阶段，客户端在录制结束的那一刻会自动对整条 episode 逐帧扫描，覆盖时间戳非单调、缺帧、维度错、非有限值、视频帧数与数据表行数不匹配、相机缺帧或形状不对等常见故障，问题项被明确标记出来。自动检测之外，EVA-Client 还提供人工抽检通道：操作员可以在同一个 web 控制台里对这条 episode 做重放，全程不需要连机器人、也不需要连策略服务器，pass/fail 与自由文本备注就地写回。所有输出直接落成 LeRobot 格式，下游训练框架读取零转换。

这样一来，从采集到写盘的整个链路里，数据质量被两道关口守住，跨团队复用时也少了很多"我们的数据放在你们这里为什么行为不一样"的追问。

02.

真机部署：让高动态任务的控制回路不被推理阻塞

回到开头那个乒乓球场景。之所以一个没加载预训练权重的 QwenOFT 也能把回合打起来，关键在部署栈让高动态任务的控制回路始终没有被推理阻塞。同步执行下，机械臂每一次前向传播都要停顿，等模型算完再执行下一 chunk 的动作——这套节奏遇上快球，机械臂根本追不上球的落点，回合打不起来。异步调度让控制回路在推理进行时继续跑，机械臂沿着当前动作块平滑执行，下一动作块平到达时无缝拼接上去，回合才成立。这不是模型的胜利，是部署栈让模型"能被用起来"的胜利。

EVA-Client 把模型部署沿着传输后端 × 机器人描述（URDF）× 推理策略这三层做了正交拆分：三层之间只有窄接口相互通信，加一台新机器人只需要写一个配置文件，换一个训练框架只需要换一个信号源，换一种推理策略只需要在配置里勾选。传输后端上，EVA-Client 支持 ROS1/2、ZMQ 等主流机器人中间件；训练框架侧对接了包括 WebSocket 与 ZMQ 在内的多种通信协议，覆盖 StarVLA、OpenPI、GR00T、DreamZero 等热门开源框架的部署路径。

基于机器人描述，EVA-Client 利用 PyRoki 统一实现了实时正逆运动学求解，一个 solver 服务全部机型。推理策略上，EVA-Client 一次性实现了包括 RTC、Temporal Ensemble 在内的 5 种开源同步/异步策略，并统一到同一配置面上——同一台机器上换策略只是配置项的切换，可以在同一根时间轴上直接横比。除此之外，机器人硬件覆盖了 UR、Franka、松灵、方舟、智元、新海图等主流品牌，配一台新机器上手基本就是"填一份描述"和一份硬件自带的sdk。

为了让部署过程不是"一把梭，跑到底"、造成机器损坏或人员受伤，EVA-Client 的 Debug 模式还开放了三种执行粒度：开环仿真、仿真-实机分段步进、连续实机执行。从零风险到全实时逐级放开，控制台里 机器人3D渲染、相机数据流全程可见——用户可以先在仿真里确认策略输出合理，再一段端动作一段端动作地放到真机上跑，直到最后进入连续执行模式。配一台新机器人从"能跑"到"跑顺"的调试成本被大幅压低，也让部署阶段真正变成了一个"可观测的工程活动"，而不再是黑盒式的一键启动。

03.

评测：让每一次真机试验都留下可以被复用的痕迹

评测环节，EVA-Client 构建了一套结构化、可归因、可回流的真机评测流程。评测按"场景 + 多次测试 + 里程碑"三段组织：每个场景绑定一组物体配置和 prompt，试验按配置数量重复，每一次试验都对着预定义的里程碑列表打分——比如"抓取、移动、放置"这样一条动作序列，每一个环节都会被独立评分，最终得到的是一条过程分，而不仅仅是一个 0/1 成功。

用户对每个任务进行详细配置后，可以得到远比单一成功率丰富的评测结果：这个模型到底是"抓不稳"还是"放偏了"，从数字上一眼就能看出来

评测过程中，客户端会同步记录机器人真实执行时的相机画面和轨迹信息，并把结果统一落盘。评测完成后，这份 log 既可以作为下一次指标分析的依据，也可以直接作为下一轮的训练数据回流到训练侧去。

EVA-Client 让真机评测变成生产性环节，每一次评测都在积累训练可用的数据，失败的轨迹暴露了当前策略的能力边界，成功的 trial 如果过程分不高，也能作为"需要改进轨迹平滑度"的样本被回流。

模型每迭代一轮，数据集就在自己长大；评测不再只是验收，而是持续的数据生产过程。这也让"评测"这个词，在真机语境里终于有了和仿真评测同样的分量：一份可以被审计、可以被复现、可以被跨团队引用的实验证据。

04.

走向下一段路

具身模型的迭代闭环远没有走到终局。目前 EVA-Client 覆盖了机械臂形态下的采集、部署、评测三块，往后还会有几条明确的路会走：机器人形态上，会从当前的串联机械臂扩展到人形和带轮式底盘的移动机器人，让同一套客户端承担更广的具身形态；数据采集上，将支持 Human-in-the-Loop 采集模式——操作员在 rollout 中途接管或纠正的动作会被作为定向训练信号记录下来，为真机强化学习铺路；策略方案上，会向分层策略延伸，让一个高层规划器可以在同一个客户端里指挥低层控制器；数据标注上，会在采集模式里加入细粒度的任务与子任务标注，让同一份 LeRobot 数据集在子操作阶段的粒度上也能被复用。

CoLab 团队期望和具身社区共同推进具身闭环迭代的软件基础设施建设。项目已在 GitHub 全面开源，文档、示例数据、机器人适配指南都已齐备，并欢迎更多研究者和团队接入自己的机器人平台、贡献推理策略、分享评测协议，一起把真机侧这最后一公里跑通。