2026-09-04 人形机器人运动会结束，赛场外的另一场比赛已经开始了

作者：Yuanxq     出品：具身智能研究室

过去两年，我看了不少具身模型。论文一茬接一茬，对实验室里做项目的同学，最费时间的事情却没怎么改变。

机器人换了一台，ROS Topic 要重新对；关节顺序变了，数据脚本要重新写；模型在离线数据上跑通以后，还得再想办法接到控制器上。项目交接、系统升级，前面踩过的坑经常又踩一遍。

最近看了乐聚的 LeTools 新资料，里面谈到数据、文档问答、算法部署。功能本身不难罗列，我读完后想到的却是另一个问题：

一次实验做完，实验室究竟留下了什么？

如果只剩某台电脑上的环境，以及某位同学记得住的操作步骤，下一次大概率还得重来。

LeTools 想解决的，不是再增加几个模型入口，而是把数据、训练、部署和机器人开发串成一套可以反复使用的流程。换了开发者、策略甚至机器人之后，原有的数据、接口和测试方法还能继续使用，一次实际实验结果的意义才算真正留了下来。

机器人到了，实验该开始了

人形机器人能够运行官方 Demo，通常只能初步确认基本功能和配套软件环境可用。进入自定义任务后，开发者还要继续处理传感器、控制接口、软件版本和配置问题。

以一个假设性的任务为例：把 LeTools 已经开放的 AprilTag、移动和手臂控制能力组合起来，让机器人识别标签、转向目标，再抬起手臂。这个看似简单的流程，实际需要接通相机数据、坐标关系、底盘和手臂接口，还要安排动作顺序，处理识别失败、超时和停止。

学习算法又会带来另一组接口问题。LeTools-Learning 会把 Rosbag 转成 LeRobot Dataset v3，训练数据中的 observation 和 action 还需要与具体 Kuavo 型号的观测空间、动作空间和控制接口对应。即使离线评测正常，部署时也要核对时间对齐、推理与控制频率、关节索引、动作限幅和停止机制。

LeTools 目前主要通过 Skills 和 Learning 两套开源仓库展开。Skills 侧重硬件接口、原子技能和任务编排；Learning 侧重数据转换、策略训练，以及仿真和真机部署评测。

从公开仓库的结构看，它试图把接口、配置、数据转换和测试入口整理到一套流程中。至于换人、换策略甚至换平台之后，这些工作还能复用多少，仍然需要外部项目来验证。

数据能读、模型能跑，还不等于真机能动

我看这类机器人系统时，更关注的是仓库之间的接口。模型、数据转换和控制代码各自能够运行，不代表它们接在一起以后仍然是同一个实验。

一段 Rosbag 交给训练代码之前，需要固定相机参数、多路数据的时间基准，以及状态量和动作量的字段与顺序。模型训完以后，还要分清它输出的是关节空间动作还是末端空间动作，是单步预测还是一段动作块；部署端是否启用了动作插值或低通滤波，也会改变最终表现。机器人型号、关节映射、相机配置和控制频率，同样需要与训练端对应起来。

这些内容如果没有进入配置和版本记录，即使使用同一个模型，换个人重新部署时，也可能已经改变了实验条件。

LeTools-Learning 文档中的 Rosbag 数据转换页面

从 Rosbag 到训练格式，变的不只是文件后缀，还包括数据字段、排列顺序和时间基准。

LeTools-Learning 官方仓库明确提供了 Rosbag 到 LeRobot Dataset v3 的转换流程，也让多种策略通过相近的入口完成训练和部署。不过，统一入口不等于自动获得公平比较。换策略时，如果数据划分、观测定义、动作处理和评测条件也一起发生变化，最后看到的性能差异就很难只归因于模型。

乐聚提供的资料还提出了“模型能跨本体迁移”，但目前公开材料没有给出迁移定义和量化结果。同系列机器人之间经过少量微调，与更换自由度、末端执行器和相机布局后的迁移，难度并不相同。要判断这项能力做到哪一步，还需要知道源本体和目标本体、目标端数据量、改动模块、评测次数和成功率。

数据规模也存在两套口径。LET 官方数据卡写的是 31 个子任务场景、117 类原子技能和超过 1000 小时；本次提供的资料写的是 6 个场景、55 个任务、每任务 500 条。它们可能对应不同的分类层级，现有公开材料还不足以建立一一对应关系，因此不能直接加总或互相替代。

公共数据可以帮助团队更快起步，但不会自动覆盖目标工位、相机安装、末端执行器和现场失败分布。进入具体项目后，通常仍需补充目标场景数据，至少也要重新完成标定、适配和真机评测。

开源算法太多了，现在难点往往不是模型

做机器人实验时，代码能够重新运行，并不等于实验可以复现。数据用的是哪个版本、哪些轨迹被删掉、观测和动作怎样定义、部署端是否启用了插值或滤波，只要有一项没有记录，后来的人就可能跑出另一套结果。

LeTools-Skills 的分层结构。

LeTools-Skills 的公开仓库把接口与数据模型、硬件适配、原子技能、行为树和测试入口分开。换本体时，改动应尽量留在适配层；调整任务流程时，则主要修改技能组合和行为树。仓库还提供统一的错误返回、执行日志、超时与异常处理，以及从底层接口到行为树的分层测试，这些机制为排查问题提供了条件。

不过，分层不等于换台机器人就能直接运行。新适配器需要完整实现同一套接口，原有技能也不能依赖旧本体的专有能力。故障发生后，日志能否把问题缩小到硬件适配、单项技能或任务流程，仍然要看实际项目中的接口覆盖和测试质量。

对实验室来说，这类工具最实际的价值，是让新人先复现一条已经跑通的链路，再只改其中一个变量。但统一入口不能把细节全部藏起来：原始数据怎样进入模型、模型输出怎样变成控制命令、失败发生在哪一步，研究者仍然应该能够逐层检查。否则，“一键运行”只会让问题晚一点暴露。

AI 助手先帮人找到正确的那页文档

LeTools 官网还放了一个“基于文档的智能问答”助手。当前界面写明它回答 LeTools-Learning 问题，示例集中在环境安装、Rosbag 数据转换和策略支持。对刚接触 LeTools 的人来说，这至少多了一个查询文档的入口。

LeTools AI 助手当前主要面向 LeTools-Learning 文档。

不过，机器人开发中的问题经常与代码版本、机器人型号和具体配置有关。这个助手能不能真正减少排错时间，还要看回答能否标出原文出处和适用版本，遇到具体报错时能否对应当前代码与配置。公开界面目前没有说明这些信息。

涉及控制命令、动作限位和真机安全时，它更适合帮人找到相关文档和检查项，最终配置仍应由使用者核对。毕竟按下运行键之前，人需要知道机器人接下来会做什么。

LeTools 离通用研发底座还有多远

目前看，LeTools 已经把二次开发、数据转换、训练和部署放进同一个工具体系。对使用 Kuavo 的团队，这至少可以少写一部分外围代码。

它能不能从产品配套再往前走，要等外部使用者给答案。别人能否按指定版本复现基线？换模型以后，是否只改模型相关部分？真机失败时，日志和回放能不能留下足够的信息，让工程师知道应该先查数据、策略、控制器还是硬件？这些问题比支持列表又增加了几个模型更有说服力。

所以可以把 LeTools 看成一套正在成形的 Kuavo 研发底座，还不会急着给它下“行业基础设施”的结论。等到外部团队能用它复现实验、替换策略、回放真机故障，并把这次项目的配置和测试带到下一次项目里，这个称呼才站得住。