Research Box 与机器人数据探索
补天石 · 2025 · 设计原则存续
这是个什么项目
客户 Demo 交付之后，销售给出了下一个目标：把已经验证过的一次性能力，做成一个可以本地化部署、面向小型具身团队的完整研发平台。目标用户是十人以下的具身研发团队，他们要的是一个能一次部署、把自己的机器人接进来、跑通从采集到训练整条闭环的东西。
Research Box 就是为这件事搭起来的先锋版本。它覆盖设备接入、机器人对接、数据采集、数据集与血缘、标注、训练 SDK、存储、K8s 集群资源整条链路，机械臂和机器人接进来，能真正跑通"注册 → 唤醒 → 数据生产 → 标注 → 入库 → 训练"这条主路径。
它不是一个可以直接复用的成熟产品。要让一台机器人跑通采集到训练的完整闭环，系统层面有一系列没有现成答案的问题——怎么组织异构数据、怎么划分边云算力、怎么让陌生用户能用起来。这一版里，这些判断是第一次被建立起来。
系统长什么样
Research Box 覆盖范围（面向 <10 人团队，刻意简化） ┌─────────────────────────────────────┐ │ 设备管理（GPU / 机器人 / 机械臂） │ │ 数据采集（遥操 / 录制 / 标注） │ │ 数据集（Episode / 派生 / 血缘 / 检索）│ │ Pipeline（Pod 挂载数据 + 自定义处理） │ │ Training SDK + 训练任务 │ │ 存储管理 │ │ K3s 集群 │ │ ────────────────────────── │ │ 刻意砍掉： │ │ × 多供应商 / 配额 / 多级质检 / 结算 │ │ × 复杂存储挂载 / 数据版本控制 │ │ × 用户已有数据/模型导入入口 │ └─────────────────────────────────────┘
项目规模
- 时间：3 个月
- 团队：4 人
- 投入：约 100 万
- 覆盖范围：整条具身研发链路，从设备接入到训练
- 闭环完成度：核心技术闭环 90%+
- 目标用户：十人以下的具身研发小团队
核心问题清单
① 第一版产品边界应该在哪里？
→ 面向 <10 人研发团队，优先跑通机器人接入 → 数据 → 训练完整闭环，而不是建设复杂生产平台。
② 怎么把机器人、数据和训练组织成一套系统？
→ 建立统一的数据组织方式和边云分工，让不同机器人产生的数据能够进入同一套研发链路。
③ 怎么让研究人员真正用起来？
→ 用户不应该理解底层基础设施，而应该围绕项目、数据集、训练任务和结果完成工作。
我的职责
担任核心研发与整体技术方案负责人。除 Kubernetes/底层 Infra 与训练任务资源调度外，从产品层到应用层的主体建设基本由我完成，涵盖设备管理、机器人对接、数据集、采集、标注与训练 SDK。3 个月里约一半时间写代码，其余投入架构方案设计与带人。
沉淀与转移
代码没有被后续系统继承，真正延续下去的是设计原则。它们在后来的项目里反复出现：
- MVP 边界意识：以"简化的代价在规模变化时是否可控"为判断标准。→ 数据生产系统（Case 3）
- 数据按性质分流 + 时间索引关联：视频与 ROS 解耦、Parquet 时间索引在这里第一次成型。→ 设备基础设施（Case 4，Manifest、Chunk、生产与交付格式分离）
- 边缘算力是硬约束：重计算搬到云端，设备端只留实时必须的计算。→ 设备基础设施（Case 4，MP4 云端重算）、训练系统（Case 5，异构算力）
- 用户入口与主路径同等重要：入口要先于主路径想清楚。→ 设备基础设施（Case 4，二维码入口、Manifest 历史数据）
- 跑通 ≠ 可用：技术链路在自己环境跑通，不代表陌生用户能独立使用。→ 后续每个项目的入口设计