项目清单 / Peihong
闭环验证完成 Embodied AIDockerDistributed DeploymentDual-machine DeploymentData CollectionTraining PipelineInference ServiceTakeover / Intervention

项目定位

MINSOP 的核心目标不是单点完成“训练”或“推理”，而是把一个真实可运行的具身操作系统闭成环：

  • 前端能够稳定数采
  • 中间能够组织训练数据和模型版本
  • 在线能够完成推理和执行
  • 现场允许 takeover / intervention
  • 结果、动作、状态和人工介入都能落盘回流

这样系统才不是一次性 demo，而是可以持续迭代的数据引擎。

架构设计

双机部署是这个项目的最小验证形态，但不是它的能力边界。MINSOP 从一开始就按 多 Docker 分布式部署 的思路拆分服务，因此可以从双机平滑扩展到多机，甚至更大规模的部署形态。

整体架构可以理解为两层：

  • 部署层：以容器为基本单元，把采集、推理、训练、存储、回放、编排等职责拆开。
  • 闭环层：在线执行、离线训练、人工介入和结果落盘通过统一的数据流串起来。

最小双机形态里，通常表现为：

  • Robot / Edge 主机：连接传感器、执行器和在线推理容器，负责低时延控制。
  • Operator / Backend 主机：运行任务编排、数据汇聚、训练、评估和回放相关容器。

但在更大规模部署中，这些职责可以继续横向展开：

  • 多台 Edge 主机并行接入多个机器人或工作站。
  • 多个 Inference Worker 容器独立扩缩容。
  • Data / Storage 与 Training Worker 可以迁移到专用算力节点。
  • Orchestrator 负责统一调度配置、策略版本和任务执行状态。
%%{init: {"themeVariables":{"fontSize":"14.5px"}}}%%
flowchart TB
  subgraph B["Control / Backend 层"]
    ORCH["调度与实验管理"]
    DATA["数据接入 /
Episode Store"]
    TRAIN["训练 Worker"]
    EVAL["评估 / 版本管理"]
    STORE["对象存储 / 回放数据"]
    ORCH --> DATA --> TRAIN --> EVAL
    DATA --> STORE
  end

  subgraph E["Edge / Robot 层"]
    CAM["观测采集容器"]
    INF["推理服务容器"]
    CTRL["控制执行容器"]
    EVT["事件 / 人工介入"]
    CAM --> INF --> CTRL --> EVT
  end

  E -- "观测 / 动作 / 状态" --> DATA
  EVT -- "人工介入记录" --> DATA
  ORCH -- "策略版本 / 配置" --> INF
  EVAL -- "新模型回灌" --> INF
  STORE -. "回放 / 分析" .-> ORCH

双机部署验证

双机部署是当前项目里最重要的“第一性验证”，因为它证明了这套系统在真实主机边界上可以跑通，而不是只在单机开发环境里拼接成功。

双机部署验证关注的不只是“服务能否启动”，而是职责边界是否清晰、链路是否稳定：

  • 机器人侧保留本地控制闭环，避免把实时控制依赖在远端调度上。
  • 后端侧承担更重的样本管理、实验管理和训练任务，避免和在线控制抢资源。
  • 两机之间验证了观测同步、动作回传、任务状态上报和模型版本回灌的完整路径。
  • 实际部署时，能够独立替换某一侧的实现，而不需要推翻整套系统。

这一步的价值在于把“实验环境能跑”变成“现场形态可以复制”。

多 Docker 分布式部署

MINSOP 的核心设计不是“双机绑定”，而是“容器职责拆分 + 跨主机调度”。双机只是最小可行形态，背后的部署方式天然支持多机和更大规模扩展。

为什么采用多 Docker 部署

  • 把实时链路和重计算链路拆开，避免相互争抢资源。
  • 不同模块可以独立发布、回滚和扩缩容。
  • 多个机器人或任务站点可以复用同一套后端能力。
  • 训练、存储、推理不再强绑定到固定两台机器。

适合拆成独立容器的模块

  • 观测采集与设备接入
  • 在线推理服务
  • 控制执行与任务状态机
  • 数据接入与 episode 落盘
  • 回放、分析和样本筛选
  • 训练 worker 与评估 worker
  • 配置、模型版本与任务编排

从双机到多机的扩展方式

从双机升级到多机时，不需要重写主流程，只需要把容器按职责迁移到更合适的节点：

  • 把 Inference 留在靠近机器人侧的 Edge 主机上，保证时延。
  • 把 Training Worker 放到有 GPU 的训练节点上。
  • 把 Storage / Replay 放到更稳定的大容量主机上。
  • 把 Orchestrator 放到中心节点，统一下发配置和模型版本。

这意味着：

  • 一台后端主机可以服务多台机器人侧主机。
  • 多台机器人可以并行产出数据并共享训练基础设施。
  • 推理服务也可以按任务量独立扩展，而不影响控制与存储链路。

大规模部署下的层次划分

当节点继续增多时，MINSOP 更适合按 控制面 / 数据面 / 模型面 三层理解，而不是按“两台机器”理解：

  • 控制面：负责任务编排、配置下发、实验管理、版本切换和运行状态汇总。
  • 数据面：负责观测接入、episode 落盘、对象存储、回放分析和样本筛选。
  • 模型面：负责训练、评估、模型注册、推理服务发布和版本回灌。

这样拆的好处是：

  • 机器人和工作站数量增加时，主要扩的是 数据面 和 推理实例，而不是整套系统一起放大。
  • 训练资源可以独立建设，不会影响在线控制链路。
  • 模型升级可以先在一部分推理实例灰度，再逐步扩大范围。

典型多机拓扑

更接近真实场景的部署方式通常不是“2 台机器复制 N 份”，而是形成一个职责更清晰的小型集群：

  • 多台 Edge 主机分别挂接机器人、相机、夹爪或其他执行单元。
  • 一组 Backend 节点承载数据接入、回放、样本筛选和对象存储。
  • 一组 GPU 节点承载训练 worker、评估 worker 和批量推理验证。
  • 中央 Orchestrator 统一维护任务配置、策略版本、实验状态和发布记录。

在这种形态下，新增机器人并不需要重新设计系统，只是新增一组 Edge 侧容器接入现有后端；新增训练负载时，也只是把训练 worker 调度到更多 GPU 节点。

大规模部署时的意义

当系统进入多机器人、多任务或长时间运行场景时，容器化和分布式部署的价值会变得非常明显：

  • 出问题时可以快速定位到具体服务，而不是整机排查。
  • 资源可以按链路类型分配，不再用一台机器硬扛所有负载。
  • 不同版本的策略和服务可以更安全地灰度验证。
  • 现场数采、离线训练、在线推理之间能够形成真正持续运转的数据闭环。

数采链路

数采不是简单录像，而是把后续训练和回放真正需要的最小闭环要素统一记录下来：

  • 多模态观测：图像、状态量、任务上下文
  • 模型输出：策略动作、置信信息、推理时刻
  • 执行结果：控制回执、阶段状态、终态标签
  • 人工操作：takeover / intervention 的触发时刻与接管区间

关键点在于所有记录共享统一时间线和 episode 语义，而不是各自单独写日志。

训练链路

训练侧围绕“可追溯”和“可复现”设计：

  • 从落盘数据中构造可训练样本
  • 以 episode、任务类型和介入情况做筛选
  • 训练阶段绑定数据版本、配置版本和模型版本
  • 评估结果能够反向关联到对应训练批次

这样每次上线的新策略都能回答三个问题：

  • 它用了什么数据训练
  • 它相对上一版提升了什么
  • 它失败时该回到哪一批样本继续修正

推理链路

在线推理链路的核心是让模型输出真正进入可控执行，而不是停在离线指标：

  • 观测在机器人侧整理成推理输入
  • 推理服务输出动作或子任务决策
  • 控制层执行并上报状态
  • 结果继续进入日志和回放系统

这里最重要的不是单次成功率，而是推理结果可以被持续审计、回放和修正。

Takeover / Intervention

人工介入是这个系统非常关键的一环，因为真实现场永远存在模型不确定区间。

MINSOP 里这部分不是临时补丁，而是被显式建模：

  • takeover：人直接接管当前控制权，保障任务不中断
  • intervention：人局部修正某一步动作或状态，再交还系统继续执行

这两类事件都会被记录进 episode，并和观测、动作、结果一起落盘。这样人工经验不会只停留在现场，而会变成下一轮训练的数据来源。

落盘闭环

真正把系统闭起来的是落盘，而不是模型上线本身。

%%{init: {"themeVariables":{"fontSize":"14px"}}}%%
flowchart TD
  RUN["在线执行"] --> LOG["观测 / 动作 /
事件落盘"]
  LOG --> FILTER["筛选 Episode /
失败案例 / 人工介入片段"]
  FILTER --> TRAIN["训练新策略"]
  TRAIN --> EVAL["评估 / 对比 / 版本管理"]
  EVAL --> DEPLOY["双机部署回灌"]
  DEPLOY --> RUN
  TAKE["Takeover / Intervention"] --> LOG

完整闭环包括：

  • 在线执行过程自动落盘
  • 人工接管和干预也进入同一套数据结构
  • 训练与评估结果能够反向追溯
  • 新策略再回到在线部署环境完成下一轮验证

这使系统能够持续演化，而不是每次都从零重新做实验。

项目价值

对具身操作系统来说，MINSOP 的价值主要在三个层面：

  • 把部署、数采、训练、推理和人工介入纳入同一条工程链路
  • 让双机部署形态提前暴露真实环境中的系统边界
  • 形成可反复迭代的数据飞轮，而不是一次性的策略验证

如果只看某个单点模块，这个项目并不复杂；真正困难的是把这些模块以可验证、可回放、可回灌的方式连成完整闭环。