HuggingFace博客 6小时前 · 2026-08-29 15:06:53 · 3 阅读

借助 Strands Agents、LeRobot 与 Hugging Face Storage Buckets，一站式完成记录、训练与部署

本文将带你了解 Strands Robots 中的流式数据闭环：由一个 agent loop 记录机器人示范，直接从 Hub 读取数据进行训练，再将策略部署回硬件；整个流程始终使用同一种磁盘上的 LeRobot 数据格式。

现在，你已经有一个 agent，能够记录示范并将其上传到 Hugging Face Hub。接下来，你可能希望让这个流程持续运行：白天不断采集 episode，在不断增长的数据集上训练策略，将策略部署到设备，再拉取下一批数据进行改进。运行一次时，每个环节都能正常工作；但如果每天运行，就会反复为相同的数据传输付费。上传的录制数据不断膨胀，每次训练开始前都要把整个数据集复制到 GPU，而新的 checkpoint 发出去的同时，下一批录制数据又传了回来。

本系列的上一篇文章介绍了 Strands Robots：这是 AWS 基于 Apache 2.0 协议开源的 SDK，将机器人抽象、仿真环境和 LeRobot 技术栈封装为 AgentTools，方便组合成一个 Strands agent。文中介绍了 Robot() 工厂、在仿真环境中记录示范、运行策略，以及将同一套 agent 代码部署到实体 SO-101 上。该工厂会根据名称，从包含机械臂、人形机器人、移动底盘和机械手的注册表中解析对应设备，因此本文一直使用的 SO-100 只是众多受支持机器人形态之一。你可以在机器人目录中查看工厂支持的全部机器人。目前，Hub 上已有来自 8,000 多个发布者的 90,000 多个数据集和模型使用 LeRobot 数据格式（LeRobot Project Pulse）。Strands Robots 记录的数据也是其中之一，因此所有能够读取 LeRobot 数据的工具都可以直接读取，无需格式转换。如果你还不熟悉 Strands Robots，建议先阅读上一篇文章；本文默认你已经完成相关设置。

上一篇文章沿着 agent loop 的一个方向展开：从 Hub 数据集走向实体机器人。本文则反向追踪数据，从首次录制的帧开始，经由 Hugging Face Storage Buckets，一路回到部署好的策略。Storage Bucket 是一种基于 Xet 的可变、无版本对象存储仓库类型，于 2026 年 3 月发布。Bucket 与数据集仓库位于同一个 hf:// 命名空间中，并沿用你已有的 hf CLI，因此可以作为工作层，在数据录制完成后、训练开始前暂存数据。

在采集过程中，总有人需要决定保留哪些片段、场景变化到什么程度就该重新录制、当天的数据是否足够用于训练，以及哪个 checkpoint 应替换机器人上的版本。这些决定会在一次采集活动中反复出现几十次，而每次执行下一条命令前，都要先查看刚刚返回的数据。这正是 agent 发挥作用的地方。本文将带你走完一个 agent 内部的数据闭环：将一段示范录制到 Storage Bucket 中，以便每次同步只上传发生变化的字节；直接从 Hub 流式读取数据集进行训练，无需下载到本地；最后只修改一个关键字参数，就能将 checkpoint 部署回硬件。本文配套的可运行示例位于 examples/notebooks/05_streaming_data_loop.ipynb。

你将构建的内容

上一篇文章录制数据集并将其推送到 Hub，而本文构建的 agent 则可以根据自然语言提示录制 LeRobotDataset，将其同步到 Storage Bucket，再逐帧从同一个 Bucket 流式读取数据，并在读取过程中即时解码摄像头视频，全程无需本地副本。数据的写入和读取在同一个进程中完成：负责录制数据集的 Strands Robots Robot()，也负责将其流式读回。训练好的 checkpoint 只需修改一个关键字参数，就能部署到同一个 Robot() 上；机器人在硬件上录制的新示范，也会回到同一个 Bucket。

Strands Robots 数据循环的四个阶段依次循环运行：record 将数据写入 LeRobotDataset，store 将其同步到 Hugging Face Bucket，train 将数据流式传回 GPU，deploy 则把 checkpoint 运行在硬件上；每个阶段都会点亮指向下一阶段的箭头，整个循环围绕同一个共享的 Robot() 展开

图 1。 四个阶段共享同一个后端。 Robot("so100") 通过共享的 DatasetRecorder 记录 LeRobotDataset；sync_dataset_to_bucket(...) 将数据同步到 Storage Bucket；stream_dataset(...) 通过 Hub 读取数据，无需完整下载；训练好的 checkpoint 则通过 mode="real" 部署到同一个 Robot 上。磁盘上的数据格式始终保持 LeRobot 写入时的原样。

同一个 Robot() 既能记录数据集，也能将其读回，因此数据采集和训练本质上是同一个对象基于同一后端提供的两种方法。Agent 决定执行一个 episode 后，只需调用一个工具；随后，rollout 会以机器人的控制频率持续运行，直到 episode 结束，其间每个动作都由训练好的策略生成。整个流程只需几行代码：

from strands import Agent
from strands_robots import Robot

sim = Robot("so100")                 # mode="sim"（默认：安全运行，不连接硬件）
agent = Agent(tools=[sim])

# 记录一次演示，并将其同步到 Bucket。
agent("记录一次抓取方块的演示，并将其同步到 my-org/robot-fave。")

# 从 Bucket 流式读取数据进行训练，无需先下载。
for batch in sim.stream_dataset("my-org/robot-fave/cube_pick", repo_type="bucket").dataloader(batch_size=64):
    ...

下面将逐步介绍这个循环内部实际发生的事情。

前置条件

最低要求（默认仿真路径）

Python 3.12 及以上，运行于 Linux 或 macOS（MuJoCo 后端支持 Apple Silicon）。
为 Agent 提供推理能力的 Strands 兼容模型提供商。可选方案包括配置 AWS 凭证的 Amazon Bedrock、Anthropic API、OpenAI，或在本地运行的 Ollama。
安装带数据集扩展的 Strands Robots：uv pip install -U "strands-robots[sim-mujoco,lerobot]>=0.5.1"。其中，lerobot 扩展会同时安装 LeRobot（>=0.6.1）、datasets、av 和 torchcodec，无需额外配置即可完成录制和视频解码。详见安装指南。

准备好这三项就够了。本文中的每个步骤都能在笔记本电脑上运行。不过，真正运行的是整套流程，而不是一个可用的策略：默认使用 mock policy，只能生成格式有效的数据集，无法产生有实际价值的数据。

进阶：Storage Buckets、硬件与真实策略

准备一个 Hugging Face 账户，以及具有写入权限的 token；此外还需要用于创建 bucket 和同步数据集的 hf CLI：先执行 pip install -U "huggingface-hub>=1.6.0,<2.0.0"，再执行 hf auth login。
如果使用硬件流程，需要一对 SO-101 follower 和 leader，或其他 LeRobot 支持的机器人，并将校准文件放在 ~/.cache/huggingface/lerobot/calibration/ 下。
如果要在本地运行 vision-language-action（VLA）推理，需要 NVIDIA GPU。要进行大规模训练，则需要能够从 Hub 读取数据的 GPU 集群。
要运行训练步骤，请执行 uv pip install "lerobot[training]"。录制和流式传输不需要该依赖。如果跳过安装，trainer.train() 返回的会是错误结果，而不是 checkpoint。故障排查指南列出了该错误及对应的修复安装命令。

第 1 步：将演示录制到 Storage Bucket

你可以在一天中持续录制新的 episode，每个 episode 都是一段连续运行的数据，包含摄像头画面以及关节状态和动作遥测信息。LeRobot 会将这些数据写入少量大文件，录制过程中文件会不断增长。将文件推送到版本化数据集仓库后，每次追加都会生成一个 commit，同时保留所有历史版本。但数据采集需要的是另一种存储方式：能够写入字节数据，并直接覆盖原有内容。这正是Storage Bucket的用途。它位于你的 Hugging Face 工作区中，沿用现有权限，无需配置身份与访问管理（IAM）角色、跨源资源共享（CORS）规则，也不必维护上传服务。

你的 agent 会以 LeRobot 在硬件上写入的相同格式记录 LeRobotDataset。完成一个 episode 后，再将数据集同步到 bucket。下面的 prompt 使用 mock policy——一种无需训练模型、只生成关节动作的替代策略，这样在拿到 checkpoint 之前，也能先跑通完整流程：

from strands import Agent
from strands_robots import Robot, sync_dataset_to_bucket

sim = Robot("so100")                 # 默认使用 mode="sim"
agent = Agent(tools=[sim])
# 一个 prompt 即可完成场景设置、相机配置、策略运行和录制。
agent(
    "创建一个包含 so100 机器人的场景，添加一个红色方块和一个前置相机，"
    "开始录制（repo_id='local/cube_pick', root='/tmp/cube_pick', fps=30, "
    "overwrite=True, task='捡起红色方块'），运行 mock policy 60 步，"
    "然后停止录制。"
)
# 将已完成的磁盘数据集同步到 bucket（无需保持实时录制会话）。
sync_dataset_to_bucket("/tmp/cube_pick", "my-org/robot-fave")
# -> {"status": "success", "bucket_uri": "hf://buckets/my-org/robot-fave/cube_pick"}

同步后的路径格式为 hf://buckets/{bucket}/{run_id}，其中 run_id 默认为数据集目录名。第 3 步进行流式读取时也要指定 run：ID 的前两段表示 bucket，后面的部分则是 bucket 内的路径。

sync_dataset_to_bucket(root, bucket, run_id=...) 会先校验数据集，再通过 hf CLI 完成同步，与录制生命周期相互独立。如果直接操作已打开的 recorder，也可以使用 DatasetRecorder.sync_to_bucket(bucket, run_id=...)；而 stop_recording(bucket=...) 会在停止活动录制的同时完成同步。bucket 是日常写入的工作层；如果要生成带版本、可发布的 artifact，仍需调用 push_to_hub()。两者使用相同的数据格式。

这个 episode 在结构上已经完整，但其中的动作只是占位数据，因此还不能作为理想的训练数据。将 create_policy("<hf_repo>") 换成真正的策略即可执行实际抓取；prompt、数据格式和 bucket 同步流程都无需改变。

在硬件上录制

如果要在实体 SO-101 上录制，LeRobot 的录制 CLI 会负责完成 leader-follower 的启动配置：

lerobot-record \
  --robot.type=so101_follower --robot.id=my_follower \
  --teleop.type=so101_leader  --teleop.id=my_leader \
  --dataset.repo_id=my_user/cube_picking \
  --dataset.single_task='Pick up the red cube'

数据集会以与仿真记录相同的格式落盘，因此可以用同一个同步调用将其上传到存储桶：sync_dataset_to_bucket("./recordings", "my-org/robot-fave", run_id="run-021")（或者使用它所封装的 hf sync ./recordings hf://buckets/my-org/robot-fave/run-021 CLI 命令）。多次采集的结果会追加到同一个位置，而发布到仓库的只会是你选择发布的版本。

第 2 步：通过字节级去重存储

数据集进入存储桶后，下一个问题就是：再次同步需要付出多少代价？假设用两台固定摄像头记录机械臂连续 8 小时清理同一张桌面，那么采集到的大部分内容其实都是已有数据的重复——相同的光照、相同的机身、相同的背景，分布在数千个片段中。对于带版本控制的仓库，情况还会更糟：如果多 GB 的视频分片中只改动了一帧，整个文件都必须重新上传。

存储桶基于 Xet 构建，使用内容定义分块在字节级别对上传内容进行去重。分块边界由内容决定，因此插入几个字节时，只会改变这些字节所在的分块，不会导致后续所有边界发生偏移。根据 Hugging Face 自己的测量结果（HF Storage），在整个 Hub 中，内容定义分块可以将每次上传的数据传输量减少约四倍；Enterprise 计划的计费也基于去重后的存储占用。其存储桶基准测试展示了单个文件的实际效果：从上传一个 500 MB 文件开始，修改其中 1% 的字节后重新上传，实际传输了 5.5 MB；修改 5% 时传输 27.5 MB；修改 10% 时传输 55 MB。如果没有分块级去重，覆盖对象就意味着必须再次发送全部字节，无论其中有多少内容并未发生变化。

具体能节省多少取决于文件布局，而 Strands Robots 录制器采用的是 LeRobot 的布局：每个 episode 会写入 Parquet 分片（data/chunk-000/file-000.parquet）以及按摄像头划分的 MP4 分片（videos/observation.images.front/chunk-000/file-000.mp4）。只有当前文件写满后，才会滚动生成新文件；LeRobot 的默认大小分别是数据 Parquet 100 MB、视频 MP4 200 MB。因此，录制一天后执行同步时，只需上传新增的末尾分片，以及那个刚刚继续增长的未写满分片，而不是整个数据集。第二天再次同步同一个 bucket 时，Xet 会负责去重。

图 2。 同步时只会上传发生变化的内容。首次同步全新数据集时，需要上传所有分片；继续录制更多 episode 后，Xet 基于内容的分块机制会让下一次同步只上传新增分块，跳过已经存储的部分。

第 3 步：从 Hub 流式训练

训练时，需要让 GPU 直接访问数据集。如果先把数据集完整下载下来，数百 GB 的文件复制完成前，GPU 只能闲等。这里可以直接从 Hub 流式读取，这得益于第 2 步采用的分片布局：一个 batch 只需对大型分片执行几次字节范围读取，无需发起成千上万次小文件请求。LeRobot 的 StreamingLeRobotDataset 会将这一过程封装成可直接使用的 torch iterable，Strands Robots 则通过 stream_dataset() 提供这一能力：

Two paths from a Hugging Face Bucket to a training GPU, shown one at a time: the download path moves the dataset to local disk and then to a GPU that waits, while the stream path sends it straight to a GPU that is already busy, with 100 KB on local disk

图 3。 应该流式读取，而不是先下载。下载路径会先将整个数据集复制到本地磁盘，因此 GPU 必须等待； stream_dataset() 则直接从 bucket 读取 batch，本地磁盘无需存储数据，GPU 从第一个 batch 开始就能训练。

reader = sim.stream_dataset("my-org/robot-fave/cube_pick", repo_type="bucket",
    shuffle=False, max_num_shards=1, buffer_size=1,  # 单个 episode，按采集顺序读取
)

print(reader.num_episodes, reader.num_frames, reader.fps)
for frame in reader:
    frame["observation.images.front"]   # (3, H, W) 张量，从 MP4 分片实时解码
    frame["observation.state"]           # 关节向量，来自 Parquet 分片
    frame["action"]
    break

除了存放 schema、统计信息和 episode 索引的小型 meta/ 文件夹，不会有其他内容写入本地磁盘。遍历数据时，相机会从远程 MP4 分片中实时解码画面；状态和动作则来自 Parquet 分片。上述循环一次读取一帧，适合检查单个 episode。训练时，可以把 reader 传给 DataLoader，改为按 batch 遍历。流式数据集会通过有界 reservoir buffer 在内部打乱数据，因此视频解码可以跨多个 worker 进程并行执行，而训练步骤本身仍是标准的 PyTorch 写法：

# policy 是你构造的 LeRobot policy，例如 ACTPolicy。
for batch in reader.dataloader(batch_size=64, num_workers=4):
    loss, _ = policy(batch)   # LeRobot 的 ACTPolicy.forward 返回 (loss, loss_dict)
    loss.backward()

如果不想自己编写循环，LeRobot 自带的 trainer 也会使用同一套引擎读取数据，因此 agent 采集的数据无需新增代码即可用于训练。它接收 bucket 时，使用的也是进程内 reader 相同的关键字参数：

lerobot-train --policy.type=act \
  --dataset.repo_id=my-org/robot-fave/cube_pick \
  --dataset.repo_type=bucket \
  --dataset.streaming=true \
  --num_workers=4

Bucket 仅支持流式读取，因此 --dataset.repo_type=bucket 必须同时设置 --dataset.streaming=true，否则配置校验会拒绝这组参数。如果希望在自己的进程中控制读取循环，可以使用 stream_dataset()：例如验证 episode、在仿真环境中回放，或接入自定义评估循环。对于只包含本体感知数据的流式读取，设置 drop_videos=True 可以完全跳过视频解码，因此即使边缘设备没有 torchcodec wheel，也能正常运行。录制与数据集指南详细说明了这个参数，以及它所需的 delta_timestamps 映射。

策略运行和训练使用的是同一套 provider 名称。create_trainer("lerobot_local") 会返回一个用法类似 create_policy() 的 Trainer，而 TrainSpec 用来描述训练任务。这样一来，记录、训练到部署的完整流程只需几行代码：

import os
os.environ["STRANDS_TRUST_REMOTE_CODE"] = "1"   # create_policy 会以 trust_remote_code=True 加载模型

from strands_robots import create_policy
from strands_robots.training import TrainSpec, create_trainer

trainer = create_trainer("lerobot_local", device="cuda")
spec = TrainSpec(dataset_root="/tmp/cube_pick", output_dir="/tmp/cube_pick_ft",
                 base_model="", steps=500, extra={"policy_type": "act"})
result = trainer.train(spec)                    # 在流式数据集上训练 ACT
policy = create_policy(result.checkpoint_dir)   # 直接重新加载训练好的 checkpoint

在单块 NVIDIA L4（g6.4xlarge）上，对一个包含 120 帧的 episode 训练 ACT 500 个优化器步数（模型参数量为 51.6M，有效 batch size 为 8），耗时 133 秒，并生成了一个可通过 create_policy() 重新加载的 checkpoint；加载入口与运行其他策略时完全相同。训练耗时会随数据集大小、batch size 和步数变化，因此这里只代表这一组实测配置，不能视为基准测试结果。"groot" 和 "cosmos3" provider 也采用同一套 TrainSpec 与 Trainer 生命周期，外围流程无需改动。不过，每个 provider 都会先校验自身必需的字段：GR00T 任务需要提供 base_model 和 embodiment 标签，Cosmos 3 任务则需要 base_model 和 SFT recipe。在调用 train() 前先执行 trainer.validate(spec)，即可获得当前后端缺少的字段清单。

Hugging Face 的预热机制会将 bucket 数据缓存到靠近云端和任务运行区域的边缘节点，让集群可以就近读取，确保 dataloader 始终领先于 GPU。在 Hugging Face 自己的 bucket 基准测试中，针对 10 GB 数据，在 m5dn.24xlarge（位于 us-east-1）上，预热后的内容分发网络（CDN）读取速度约为 1,086 MB/s，冷读取则为 780 MB/s；数据量达到 100 GB 时，预热读取速度约为 1,124 MB/s。该仪表板还提供了与普通对象存储的完整对比，包括上传和下载性能。数据存储位置可通过 Team 和 Enterprise 计划中的 Storage Regions 设置。目前支持美国和欧盟，亚太地区及海湾合作委员会（GCC）区域也已宣布即将推出；不属于这些计划的用户，其仓库默认存储在美国。

在 macOS 上，import strands_robots 会自动将 Homebrew 的 ffmpeg 加入加载路径，因此 torchcodec 无需额外配置即可解码流式视频。

第 4 步——部署策略并将数据送回循环

这一步要使用刚训练好的 checkpoint，在实体机器人上运行策略，并用它记录下一轮演示数据。代码与上一篇文章中的 agent 完全相同，只需将一个关键字参数改为 mode="real"：

robot = Robot("so100", mode="real", port="/dev/ttyACM0",
              cameras={"front": {"type": "opencv", "index_or_path": "/dev/video0", "fps": 30}})
agent = Agent(tools=[robot])
agent("Pick up the red cube.")

该 checkpoint 会驱动物理机械臂运行，机械臂记录的演示数据则以与最初相同的 LeRobot 格式保存到磁盘，随后即可同步回 bucket，开始下一轮训练。

如果数据已经存放在 Amazon Simple Storage Service（Amazon S3），本文介绍的格式流程无需任何改动。LeRobotDataset 由 Parquet 和 MP4 分片组成，是一种目录结构，因此存储在 Amazon S3 上与存储在其他位置并无区别；无论数据位于何处，记录、训练和部署步骤都读取同一种格式。Bucket 提供的是 Hub 原生路径：sync_dataset_to_bucket 和 stream_dataset(repo_type="bucket") 可直接指向 hf://，无需额外配置存储路径，即可完成同步并以流式方式读取数据。两种路径遵循同一套流程：数据已有存储位置时使用 Amazon S3；如果希望无需提前配置存储就完成同步和流式读取，则使用 bucket。

第二天再次运行这套流程时，你可以直接将数据记录到 bucket，只同步发生变化的字节，并将这些数据流式传输到 GPU，无需等待完整下载。数据始终保持 LeRobot 格式，也始终留在 Hub 中。

使用示例应用试试看

完整的 Strands Robots 示例位于 GitHub 的 strands-labs/robots 仓库中，具体路径是 examples/notebooks/05_streaming_data_loop.ipynb。该示例按单元格逐步演示完整流程：记录、渲染、同步到 bucket、流式读取、训练，以及加载 checkpoint。每个单元格都使用 mock policy 在模拟环境中运行，因此无需 GPU、Docker 或 Hugging Face 凭据。

git clone https://github.com/strands-labs/robots.git
cd robots
uv pip install -U "strands-robots[sim-mujoco,lerobot]>=0.5.1"
jupyter notebook examples/notebooks/05_streaming_data_loop.ipynb

按从上到下的顺序运行各个单元格。录制的数据集会保存到 /tmp/nb5_dataset。如果要将其同步到存储桶，请先执行 hf auth login，然后在第一个单元格中设置 BUCKET = "my-org/robot-fave"；旁边的 RUN_ID 用于指定存储桶内的文件夹名称，Notebook 会从 f"{BUCKET}/{RUN_ID}" 读取数据流。要在 GPU 上训练，请将 steps 调高到 500，并设置 device="cuda"。采用 agent 驱动的同一套流程见 examples/06_agent_collect_and_stream.py。

安全注意事项

这里的代码只是 Strands Robots 数据流程的“Hello World”。一旦用于真实数据，以下五点就需要特别注意。

提示注入。向 agent 提供不可信数据可能导致提示注入：不可信的上下文会被当作 LLM 指令执行。这些 agent 不仅会控制机器人，还会读写共享存储，因此这是必须关注的重要风险。只向 agent 提供来自可信来源的数据。如果无法确保所有输入都可信，请限制 agent 可用的工具，避免它执行涉及安全的关键操作或覆盖存储桶内容。
训练数据是信任边界。能够写入采集存储桶的 agent，也可能写入供策略训练的 episode，而训练出的策略最终会驱动实体机械臂。请将用于写入采集数据的凭证，与训练任务读取数据时使用的凭证分开；每次运行都使用独立的 run_id 进行同步，以便将 episode 追溯到生成它的运行，并单独删除；同时，应把版本化的数据集仓库视为经过审核的正式产物，因为存储桶不会保留可供审计的版本记录。
存储桶凭证与权限范围。sync_dataset_to_bucket(...)、stop_recording(bucket=...) 和 sync_to_bucket 都会通过 hf CLI 上传数据，并使用 hf auth login 登录时获得的 token。请使用仅限于目标命名空间的 token；采集数据最好存放在使用 --private 创建的存储桶中；此外，还应将该存储桶与通过 push_to_hub 推送并共享的版本化数据集仓库分开。
原地覆盖不会保留历史版本。Bucket 会直接覆盖原有内容，不保留任何修订记录，因此适合作为工作层；这也意味着，重复使用同一个 run_id 会替换其中已经存储的运行记录。每次采集都应显式传入不同的 run_id，例如 sync_dataset_to_bucket("./recordings", "my-org/robot-fave", run_id="run-021")。如果需要随时回退到之前的版本，请使用 push_to_hub() 推送到带版本管理的数据集仓库，那里会保留每次修订。
只使用可信的 Hugging Face 组织。本地推理路径会通过 trust_remote_code=True 加载 Hugging Face 模型。设置 STRANDS_TRUST_REMOTE_CODE=1 即表示同意启用该功能，因此只能加载来自可信组织的 checkpoint。通过 Hub 加载预训练权重时（例如使用 pretrained_name_or_path），请先确认所属组织可信。模型权重可能包含任意代码（基于 pickle 的 checkpoint），因此在可用时应优先选择 safetensors 格式的 checkpoint。

清理

运行循环会留下一个 bucket、/tmp 下的数据集，以及磁盘上的 checkpoint。Bucket 中的内容会计入存储空间，因此请删除不再需要的文件：

hf buckets rm my-org/robot-fave/cube_pick/ --recursive --dry-run  # 仅列出，不删除任何内容
hf buckets rm my-org/robot-fave/cube_pick/ --recursive            # --yes 跳过确认提示
hf buckets delete my-org/robot-fave                               # 删除其中的全部内容
rm -rf /tmp/cube_pick /tmp/cube_pick_ft /tmp/nb5_dataset /tmp/nb5_ft

停止 GPU 实例上仍在运行的训练进程，并关闭该实例。如果运行过 notebook，请将其中的 RUN_ID（默认为 nb5_demo）替换为 cube_pick。通过 push_to_hub() 发布的内容位于带版本管理的仓库中，不会受到影响。

接下来

Strands Robots 文档详细介绍了机器人目录、仿真、策略提供方、记录流程以及 mesh。记录与数据集指南则完整说明了 DatasetRecorder API、sync_dataset_to_bucket / sync_to_bucket 和 stream_dataset 的用法。

如果要同时从多台机器人采集数据，请为每台机器人分配独立的 run_id，让它们并行写入同一个 bucket。多机器人 mesh 会将一个 agent 分发到这些机器人上，使同一套循环能够驱动整个机器人集群，在一天内持续将数据写入共享存储。流式读取器每次读取一个运行记录。记录与数据集指南介绍了如何使用多台机器人采集的数据进行训练。

如果需要比 ACT 更大的策略模型，Step 3 中的 TrainSpec 和 Trainer 生命周期已经通过各自的 provider 名称支持 GR00T 和 Cosmos 3。因此，只需更换 provider 字符串和基础模型，就能使用刚刚流式采集的数据对 VLA 进行微调，调用方式保持不变。真正运行模型时，流程会有所不同：VLA checkpoint 最终要部署到硬件上，而不是你训练时使用的模拟器中。如果需要更重型的模拟环境来生成数据，Newton（sim-newton）和 Isaac Sim（isaac）后端都通过同一个 Robot() 工厂接入，因此即使扩大模拟规模，agent 代码也无需修改。

Bucket 流式读取功能由 Strands Robots 和 LeRobot 团队共同贡献，并已合并到 LeRobot 上游项目中。因此，agent 采集的数据集可以被整个生态中的工具读取。反过来也一样：Step 3 中的读取器可以打开 Hub 上已经发布的任意 LeRobot 数据集，让 agent 在记录自己的演示数据之前，先重放并评估现有演示。

本项目基于 Apache 2.0 协议，欢迎贡献。如果你用这套流程构建了项目，欢迎提交 issue，分享哪些地方运行顺利、哪些地方遇到了问题。

资源

Strands Robots

SDK、AgentTools 和 Robot() 工厂：github.com/strands-labs/robots，Apache 2.0
文档：strands-labs.github.io/robots
记录与数据集指南：strands-labs.github.io/robots/recording
本文配套 Notebook：examples/notebooks/05_streaming_data_loop.ipynb——逐个运行单元格，完整走通整个流程
Strands Agents SDK：github.com/strands-agents/harness-sdk

LeRobot 与 Hub

LeRobot：github.com/huggingface/lerobot——提供数据集、策略和硬件驱动
Hugging Face Storage Buckets：Storage Buckets 文档
Xet 去重：从文件到数据块
采用本文记录格式的抓取放置数据集：lerobot/svla_so101_pickplace

策略模型

SmolVLA：lerobot/smolvla_base
Pi0：lerobot/pi0_base
NVIDIA Isaac-GR00T N1.7：nvidia/GR00T-N1.7-3B
NVIDIA Cosmos 3 Nano：nvidia/Cosmos3-Nano
针对 SO-100/101 训练的 MolmoAct2：allenai/MolmoAct2-SO100_101——通过 lerobot_local 加载，并需要安装 molmoact2 extra

背景资料

本系列第一篇文章：借助 Strands Agents 和 LeRobot，从 Hugging Face Hub 连接到机器人硬件
本文工作流所遵循的Physical AI 数据闭环：The Physical AI Data Loop，Steven Palma，Hugging Face，2026
Bucket 吞吐量与去重测量结果：hf-buckets-benchmark

本文提及的模型：5 个

本文提及的数据集：1 个

本文提及的 Spaces：3 个

原始来源： HuggingFace博客