HFlow：让机器人数据流水线从"内部机密"变成开源利器

在哥伦比亚大学和新加坡国立大学的一间实验室里，几个曾在 Google DeepMind、OpenAI、Jane Street 工作过的年轻工程师，被一个共同的问题困扰着：当一个机器人团队收集了成百上千小时的视频、关节状态、机械臂动作数据之后，如何判断这些数据真的能用来训练出一个好模型？

他们看到的现实是：每支机器人团队都在重复发明轮子——写一堆 Python 脚本处理数据，靠人工检查摄像头是否冻住、传感器数据是否同步、某些关节是否异常。最终，数据处理的脚本散落在各处，既没有人知道哪个版本跑了什么结果，也没有办法把一条有问题的数据追踪回它最初产生的那一刻。

Hebbian Robotics 团队决定把这个问题做成一个开源 SDK——这就是 HFlow。

被YC S26选中的数据质量基础设施

HFlow 于 2026 年 Y Combinator 夏季批次（YC S26）正式亮相，是一个专注于机器人与 Physical AI 领域的多模态数据流水线开源 SDK。它的核心目标很明确：让数据处理和质量验证不再是大团队的专利，任何规模的机器人团队都能用上生产级别的数据工具。

HFlow 脱胎于团队在真实机器人数据处理中积累的工程经验，部分灵感来自 Dyna Robotics 2026 年公开的百万小时级数据基础设施实践，但 HFlow 是完全独立的项目，有自己的公开格式、接口和实现。

用类比理解：数据流水线的"质检流水线"

可以把 HFlow 想象成制造业的质检流水线。原材料（原始传感器数据）进入工厂后，经过一道道质检关卡：检查尺寸是否合格、材料是否有缺陷、组装是否精准——只有通过全部关卡的产品才会被打上合格证，进入下一环节。

HFlow 做的事情类似：机器人数据（视频、状态、动作等）进入流水线后，先被标准化成 MCAP 格式（ROS 2 原生使用的容器格式），然后依次经过你写的质量检查、转换处理、数据增强，最后以可查询的 Parquet 编目 + DuckDB SQL 的方式输出，同时附带完整的数据血缘记录（provenance）——你随时可以知道：这条数据的来源是什么？经过了哪几步处理？每个步骤用了什么版本的工具？

四阶段生命周期：数据如何流过 HFlow

HFlow 定义了一个清晰的数据生命周期：

1. Collection（采集）：传感器数据着陆到存储桶，格式不限。HFlow 支持直接消费标准 MCAP 格式的录像，同时提供了 LeRobot Dataset v3 的导入器，可以把其他格式的数据转为 MCAP 边界格式。

2. Ingestion（摄取）：这是 HFlow 的核心环节。数据经过 Transform（转换）→ Check（质检门）→ Enrich（增强）三个子阶段。每个阶段都是你写的 Python 函数，放在自己的环境中，HFlow 负责编排、存储和版本管理。开发阶段可以用进程内执行（in-process），生产阶段会自动生成 Airflow 3 DAG 来调度。

3. Curation（编目）：通过 DuckDB SQL 对整个数据集进行查询，不需要打开原始 MCAP 文件。质量检查的结果以可查询的测量值（而非硬编码的通过/失败）写入 Parquet 编目，方便不同数据集应用不同阈值。

4. Delivery（交付）：输出标准的 MCAP 文件 + 版本锁定的清单（manifest），可以直接喂给训练框架。

HFlow 流水线演示：collection → ingestion → curation → delivery

技术栈解剖：Python + MCAP + DuckDB + Airflow 3

HFlow 的技术选型非常务实，围绕"可落地"而非"最前沿"展开：

输入边界：MCAP。MCAP 是 ROS 2 原生使用的容器格式，能高效存储同步的视频、状态、动作等时序数据。HFlow 对 MCAP 有明确的规范约定：GOP 长度与读取模式匹配、topic 分组 chunking（摄像头流和状态流不会共享同一个 chunk），从而保证训练时一次读取只花一次 IO。

核心依赖：Python >= 3.11，DuckDB（编目查询），mcap 系列库（foxglove-schemas-protobuf、mcap-protobuf-support、mcap-ros2-support），numpy，httpx2。

编排层：开发阶段用进程内执行，生产阶段输出 Airflow 3 DAG。Airflow DAG 可以通过 Docker Compose 运行时本地执行，也可以部署到你已有的 Airflow 3 环境中。

扩展接口：内置质量检查（摄像头冻结检测、传感器漂移检测、手部检测等），也支持接入自己的模型做语义质量评估（如 OpenAI VLM）。

可选扩展：mediapipe（手部检测）、opencv-python-headless（光流相机抖动测量）、pyarrow（Arrow 格式支持）、obstore（云对象存储 S3/GCS/Azure）。

六行代码上手：极低的实验门槛

HFlow 刻意压低了使用门槛。如果手头没有现成的 MCAP 录像，quickstart 会自动合成一个小型的多模态 episode，让你跑完整个流程：

uv add hflow
uv run python examples/quickstart.py

跑完之后，你会在 data/ 目录下看到输出的 MCAP 文件和 Parquet 编目。然后：

uv run hflow catalog ui

会启动一个本地 DuckDB Web UI，你可以在浏览器里直接用 SQL 查询数据集的质量元数据，完全不需要打开原始录像文件。

如果你有真实的机器人数据，可以直接：

uv run python examples/quickstart.py path/to/your/episode.mcap

或者用 LeRobot 导入器，把 LeRobot Dataset v3 格式的数据转成 HFlow 的 MCAP 格式：

uv run hflow import lerobot --repo lerobot/pusht --revision main --episode-index 0

数据血缘：每个 episode 都知道自己从哪来

HFlow 最具工程价值的特性是数据血缘（provenance）追踪。每个经过流水线处理的文件本身都记录了它的 schema、流水线配置和工具版本号。如果训练出来的模型效果不好，你可以从结果一直回溯到原始数据，精确到哪一步处理引入了异常。

质量检查的结果也不是简单的"通过/不通过"——它们被作为可查询的测量值写入编目，你可以针对不同的数据集应用不同的阈值，而不需要重新处理原始媒体。

争议与局限：pre-v1 阶段的现实

HFlow 团队在 README 中明确标注：当前处于 pre-v1 状态，核心生命周期已经端到端跑通，但还有大量功能处于"简化实现"或"待实现"状态。

几个需要关注的事实：

• 无 Docker 一键部署：仓库内没有提供 Dockerfile 或 docker-compose.yml（除了可选的 Airflow 运行时）。生产部署需要你自行编写 Docker 配置。对于希望开箱即用的团队来说，这增加了落地成本。
• MCAP 是强制的输入边界：如果你的数据不是 MCAP 格式，也不是 LeRobot Dataset v3，就需要自己写导入器。HFlow 的愿景是支持更多输入格式，但目前除了 MCAP 和 LeRobot v3，还没有其他官方导入器。
• 无分布式缓存和 GPU 编排：Per-step compute、Corpus caching、Fleet orchestration 这些生产级功能都在 deferred 列表中。对于有大规模数据处理需求的团队（HFlow 的核心用户群），这意味着你可能需要自己补充这部分能力。
• DuckDB 编目 ≠ 数据库：DuckDB 擅长分析型查询，但没有 CDC、实时写入或传统数据库的事务能力。如果需要实时数据质量监控，可能需要额外的工程投入。

行业意义：Physical AI 数据质量的"缺失一环"

2026 年，Physical AI（物理世界 AI）成为继 LLM 之后最热门的 AI 细分方向。Figure、1X、Physical Intelligence 等公司先后发布突破性成果，但整个行业在数据基础设施层面其实非常原始——每家都在重复造轮子，没有一个像 Git 之于代码那样的"数据版本控制与质量追踪"的事实标准。

HFlow 试图填补这个空白：它不替代现有的训练框架或数据收集系统，而是专注于"采集之后、训练之前"这一段：把原始的多模态传感器数据，变成经过质量验证、带有完整血缘记录、可查询可复现的标准数据集。

从 GitHub 237 颗星、135 个 forks 的数据来看，HFlow 仍然处于早期采用阶段。但考虑到它背后是 YC S26 孵化的团队、核心技术栈成熟（MCAP+DuckDB+Airflow 都是经过生产验证的工具），以及 Physical AI 赛道的持续火热，HFlow 有潜力成为机器人数据流水线的"事实标准"之一。

对于 AI 爱好者来说，HFlow 展示了一个重要趋势：数据质量正在成为与模型架构同等重要、甚至更重要的工程问题。对于开发者来说，如果你正在构建机器人或 Physical AI 系统，HFlow 值得试用——它能让你从第一天起就建立数据质量意识，而不需要在数据爆炸之后才回过头来做"数据考古"。