VLA 已经能输出动作，为什么机器人仍需要多时间尺度闭环

VLA 已经能输出动作，为什么机器人仍需要多时间尺度闭环

先说几个核心判断。端到端 VLA 可以共享视觉、语言与动作表示，减少人工设计的中间接口，听起来很美好。但它不能取消传感器时钟、机械动力学、关节限位、网络故障、控制稳定性和事故责任——这些物理世界的硬约束，不会因为语义模型能说话就自动消失。VLA 输出动作，说明系统获得了一个

；而生产级闭环仍要明确：谁建立可信状态，谁解释任务，谁验证几何与动力学，谁拥有安全否决权，谁在高频控制电机，谁判断失败并恢复。

可靠性不来自把 VLA、世界模型、规划器和控制器全部画进一个大模型方框，也不来自强制每个项目都部署全部模块。正确做法是：按任务风险、环境开放度和硬件能力选择最小闭环、混合闭环或高阶闭环，并为每个时间尺度建立可测试的输入、输出、截止时间、失效行为和责任人。

公开 VLA 已经说明了什么

[I-O01] RT-2 的做法是把机器人动作表示成文本 Token，跟互联网视觉语言数据一起训练，推理时再将动作 Token 反解为机器人动作。这个方案说明，语义知识和动作输出确实可以共享模型接口，但并不意味着动作 Token 自带连续动力学、避碰和硬件安全能力。

[I-P01] OpenVLA 是 7B 开源 VLA，论文报告其在 97 万条机器人示范上训练，并支持适配多种机器人。[I-P02] π0 使用建立在预训练 VLM 上的 Flow Matching 动作架构。[I-P03] GR00T N1 采用双系统：视觉语言模块解释环境和指令，后续 Diffusion Transformer 生成连续动作。[I-P04] Gemini Robotics 报告一种可直接控制机器人的 VLA，同时另设 Gemini Robotics-ER 提供空间与具身推理能力。

这些路线的动作表示、生成方式、模型拆分与部署目标各有不同。共同结论不是“传统模块已经消失”，而是 VLA 可以承担从观察与语言到动作候选的更大范围。具体系统仍要回答：动作是单步还是 Action Chunk？是关节位置、速度还是末端目标？是否带有效期？输出频率和最坏延迟是多少？对哪个机器人、工具与坐标系有效？

多时间尺度不是架构偏好，而是物理事实

下面时间仅为示意，假设一台带 30 fps 相机、关节编码器、力传感器和约 1 kHz 伺服环的移动操作机器人。它不是所有机器人的性能指标；高速无人机、慢速仓储臂和柔性执行器会使用不同预算。

秒—分钟：任务管理／人机交互／恢复策略
↓ 任务、约束、成功条件

100 ms—数秒：VLA、技能选择、可选世界模型与任务规划
↓ 动作块、技能、子目标、候选后果

10—100 ms：运动规划、轨迹优化、MPC、局部避障
↓ 带时间参数的可行参考轨迹

1—20 ms：状态估计更新、安全监督、轨迹跟踪
↓ 位置／速度／力矩参考与否决信号

0.5—2 ms：驱动器、电流环、硬件联锁与急停
↓ 电机与机械系统连续反馈：相机、编码器、IMU、力／力矩、触觉、网络状态

一个低频语义模型可以决定“拿起红杯子”，却无法每毫秒处理电机电流；高频驱动器能稳定跟踪，却不知道“红杯子”是哪个物体。多速率设计的目的，不是维护传统模块，而是让不同信息在其有效时间尺度上闭环，并在上层迟到或失效时，保留下层可预测行为。

责任图：模块可以合并，门禁不能消失

能力	主要责任	可由学习模型承担吗	生产门禁
传感器同步与状态估计	对齐时间，融合视觉、本体、力觉，给出状态与有效性	可以部分学习	必须输出时间戳、坐标系、协方差／质量和失效标志
任务规划	把目标拆成技能、顺序、前置条件和完成条件	可以由 VLM／VLA 承担	必须可取消、可重试、有预算与成功判据
VLA／策略	根据观察和指令提出动作、动作块、技能或子目标	是	动作合同、适用机体、有效期与延迟必须明确
世界模型	预测状态或候选动作后果	可选	只有在反事实排序或规划收益通过验证后才进入门控
运动规划	在几何、碰撞和运动学约束下寻找路径	可学习、可经典、可混合	必须给出可行性与碰撞检查结果
MPC／轨迹优化	在有限时域内按动力学与约束滚动优化	可学习模型辅助	求解超时、不可行和模型失配必须有退化策略
低层控制	高频跟踪位置、速度、力矩或阻抗参考	可学习或经典	稳定性、限幅、看门狗和驱动器状态
硬件安全	急停、限位、功率与驱动保护	不应只依赖大模型	独立链路、故障安全、人工复位
监控与恢复	判断进度、失败、异常接触和重试	可学习加规则	状态机、重试上限、升级与审计日志

责任可以共享，但门禁不能删除，这是两回事。VLA 可以同时学习感知、任务语义和动作，但系统仍需验证输入是否新鲜、动作是否属于该机体、执行是否超时、硬件是否允许。即使所有功能由一个网络内部实现，对外仍要暴露可测试合同，否则无法定位和隔离失效。

三档闭环架构，而不是一个万能架构

一、最小闭环

同步状态 → VLA／学习策略 → 动作适配器 → 独立安全门禁 → 低层控制器 → 监控

适用于环境受控、动作范围小、速度低、碰撞后果有限、示教覆盖充分的任务。比如固定工位上的短时抓取，让策略直接输出末端增量或关节目标。此架构不强制世界模型或通用规划器，但最低限度仍包括状态新鲜度、动作单位与坐标转换、关节／速度／工作区限制、看门狗、停止条件和失败检测。

最小不等于“只有一个模型”。若 VLA 超时，控制器必须知道保持、减速还是停止；若视觉丢失，监控器必须阻止继续消费旧动作；若安全门禁拒绝动作，任务管理必须进入可解释状态，而不是无限重试。

二、混合闭环

状态估计 → VLA 输出技能／子目标／稀疏轨迹
↓
运动规划／局部 MPC → 安全门禁 → 控制器 → 执行监控

适用于有障碍、精确接触、较高速度或机器人动力学不可忽略的任务。VLA 负责语义和泛化，经典或学习规划器负责几何与有限时域约束。VLA 可以说“抓取杯柄并放入托盘”，运动层负责可达性、避碰、速度与接触路径。

混合架构不是对端到端学习的否定，而是把不适合由低频生成模型独自承担的硬约束放到可验证路径。若 VLA 直接输出密集动作，也可在执行前转换成参考轨迹交给 MPC 或安全过滤；若规划器不可行，应把原因反馈给上层重新选择姿态、抓取点或技能，而不是硬投影到一条未知轨迹。

三、高阶闭环

任务管理／VLM
↓
目标与候选技能
VLA 候选 ←→ 可选世界模型／反事实评估
↓
选定子目标或动作块
运动规划／MPC → 独立安全监督 → 实时控制
↑ ↓
状态估计 ← 结果验证／异常检测／恢复状态机

适用于开放环境、长时任务、多个可行动作、失败代价高或需要预测其他 Agent 的系统。世界模型只在它能可靠比较候选后果时加入；任务规划器只在任务确有多阶段依赖时加入。高阶架构的代价是延迟、接口、模型不一致和恢复复杂度，不能为了“完整”而堆模块。

选择原则很清晰：若策略直接输出在约束内且任务短，先从最小闭环开始；若几何、接触或动力学风险主导，加入运动规划或 MPC；若候选动作的未来后果和长期任务状态主导，再加入经验证的世界模型与任务规划。每次增加模块都必须带来可测收益，并同时增加故障注入与回退测试。

任务规划、运动规划、MPC、控制和硬件安全的区别

[I-P06] LaValle 的《Planning Algorithms》把离散规划、运动规划、传感不确定性、轨迹与微分约束等作为不同问题族处理。这种区分在 VLA 系统中仍然有用。

任务规划处理“先做什么后做什么”，包括前置条件、资源和成功状态。运动规划在配置空间或状态空间中寻找无碰撞、可达路径。MPC 根据当前估计状态，在有限预测时域中反复优化控制并执行第一段；它关心模型、代价、约束、求解时间和不可行处理。低层控制在更高频率跟踪参考并抑制扰动。硬件安全在软件失效时仍能断能、限位或急停。

模块可以共享模型和优化器：学习策略可提出轨迹，MPC 可使用学习动力学，VLA 可输出技能序列。但任务成功、几何可行、动态可行、跟踪稳定和硬件保护是不同验收项，不能用一个端到端成功率掩盖。

接口合同：示例字段，不是真实模型输出

以下 JSON 仅为接口示意，不代表任何公开 VLA 的原生格式或真实置信度。

状态估计到策略

{
  "state_id": "uuid",
  "captured_at_ns": 0,
  "published_at_ns": 0,
  "frame_id": "robot_base",
  "robot_model": "example-v1",
  "joint_position_rad": [],
  "joint_velocity_rad_s": [],
  "tool_pose": {"xyz_m": [], "quat_xyzw": []},
  "contact": {"valid": true, "wrench": []},
  "objects": [],
  "quality": {"valid": true, "max_age_ms": 0, "reason": null}
}

必要语义是状态来源、采样时刻、坐标系、单位、机器人版本和有效性。objects 可为空；不能因为视觉检测器没输出对象，就伪造“场景为空”。

策略到执行层

{
  "proposal_id": "uuid",
  "based_on_state_id": "uuid",
  "created_at_ns": 0,
  "expires_at_ns": 0,
  "action_mode": "ee_delta_pose",
  "frame_id": "robot_base",
  "dt_ms": 0,
  "actions": [],
  "assumptions": [],
  "model_score": null,
  "fallback": "hold"
}

model_score 只是可选模型字段，不应自动解释为成功概率。执行层必须核对 based_on_state_id、动作模式、有效期、维度和机器人版本，过期动作直接拒绝。

执行反馈到任务管理

{
  "proposal_id": "uuid",
  "status": "executing|completed|rejected|aborted",
  "reason": "",
  "progress": {},
  "tracking_error": {},
  "safety_events": [],
  "last_feedback_at_ns": 0
}

拒绝原因要机器可读，例如 STALE_STATE、JOINT_LIMIT、COLLISION_RISK、DEADLINE_MISS、CONTACT_ANOMALY。只有这样，上层才能选择重新感知、换抓取点、降速、撤退或请求人工，而不是把所有失败都变成“模型再试一次”。

失败与恢复状态机

一个最小状态机可写为：

BOOT → SELF_CHECK → READY → EXECUTING → VERIFY → READY
                          │              │
                          ├→ DEGRADED ─→ RECOVER ─→ READY
                          ├→ HOLD ─────→ RECOVER
                          └→ E_STOP ───→ MANUAL_RESET
                          └────────────→ FAULT ──→ MANUAL_RESET

DEGRADED 表示仍可安全运行但能力下降，如只剩本体状态、网络退化或某相机失效；HOLD 表示停止推进任务并保持安全姿态；RECOVER 执行有限次数的重新感知、撤退、重新抓取或回到已知安全位；E_STOP 与 FAULT 不允许模型自动解除。

触发条件至少包括：状态超龄、传感器不同步、动作过期、策略或规划截止时间错过、约束不可行、跟踪误差超限、异常接触、无进展、对象丢失、网络中断、驱动器报警。每种恢复都有预算：最大次数、最大时间、最大位移和允许风险。超过预算必须升级到 Hold、人工接管或硬件安全，而不是无限循环。

任务成功也必须验证。例如“杯子放入托盘”不能只以夹爪张开作为成功；应检查对象位置、夹爪状态、接触解除和稳定持续时间。否则 VLA 可能执行完整动作序列，却没有完成物理任务。

云、边、端怎样分工

云边选择不能只比较平均推理速度。要同时看最坏延迟、断网行为、数据体量、隐私、安全责任和本地替代能力。

问题	适合端侧／机器人	可考虑边缘服务器	可考虑云端
硬件急停、驱动限位、看门狗	必须	不可替代	不可替代
高频控制与状态新鲜度检查	通常必须	仅专网且有本地回退	不应处于硬实时链路
局部规划、MPC、安全过滤	风险高时优先本地	受控网络可行	只有中断后仍可安全时
VLA 推理	本地算力允许时	常见折中	适合低频、可等待、可降级任务
大模型任务规划、知识检索	可缓存基础能力	可选	对延迟不敏感时适合
日志分析、训练、离线回放	可采集	可聚合	适合，但需隐私与合规控制

一个直接门槛是：若远端链路在 p99 延迟或断网期间会耗尽安全动作缓冲，而机器人不能自动进入无风险 Hold，则该远端服务不能位于硬控制闭环。即使平均延迟很低，也必须注入丢包、抖动、DNS／认证失败、服务限流和长时间离线，验证本地行为。

云端模型还需要版本固定、回滚、请求幂等、动作过期和数据最小化。网络恢复后不能立即执行断网前返回的旧动作；必须重新采样状态并重建计划。

端到端指标账本

模型准确率只能覆盖一部分。生产评估至少分六组：

1. 任务结果
   ：成功率、完成时间、步骤完成率、对象／环境损坏；

2. 安全
   ：碰撞、近失、限位触发、异常力、急停、人工干预、危险动作漏放；

3. 实时性
   ：状态年龄、策略／规划／门禁 p50/p95/p99、截止时间错过、缓冲欠载；

4. 控制质量
   ：跟踪误差、超调、振荡、Jerk、接触稳定性、能耗；

5. 恢复能力
   ：故障检测延迟、恢复成功率、恢复时间、重试次数、升级比例；

6. 泛化与运维
   ：新对象／光照／布局成功率、分布外拒绝、模型版本回归、网络中断表现。

每个总成功率都应附失败分类。若成功率下降来自感知丢失，继续训练动作头可能无效；若来自规划超时，扩大 VLA 数据也不解决；若安全门禁拒绝率突然升高，可能是模型漂移、坐标转换或限位版本变化。多速率账本的价值就在于把“机器人失败”还原成可归责、可重放的事件链。

验证顺序：不要直接从离线分数跳到开放场景

建议按四个门逐步放行：

• 日志回放
  ：固定状态输入，验证动作维度、单位、有效期、确定性和版本回归；

• 仿真与故障注入
  ：加入观测延迟、丢帧、网络中断、对象移动、接触异常和规划不可行；

• Hardware-in-the-loop／Shadow Mode
  ：控制器与真机状态运行，但策略先不拥有执行权，比较候选与现有系统；

• 分级真机
  ：低速、软物体、受限工作区、人工在环，再逐步扩大速度、对象和环境。

每一级都要验证拒绝与恢复，而不只是成功轨迹。一个不会失败的测试集无法证明恢复状态机有效。

结语

VLA 的进步正在扩大端到端策略可以承担的范围：从离散动作 Token，到连续 Action Chunk，再到双系统和具身推理。但“模型能输出动作”仍只是闭环入口，不是生产系统终点。

最小闭环可以没有世界模型和通用规划器，复杂系统也可以把多个能力合并进同一网络；不可省略的是责任合同：状态是否可信，动作是否新鲜且属于该机体，几何和动力学是否可行，谁能否决危险命令，控制器如何在高频执行，上层失败后系统如何 Hold、恢复或急停。把这些责任放在正确时间尺度，并用延迟、约束、跟踪、恢复和任务结果共同验收，才是端到端学习真正进入物理世界的条件。

FAQ

端到端 VLA 是否意味着不需要运动规划？

取决于任务和风险；模块可以融合，但几何、动力学、碰撞与执行约束仍需由可验证路径承担。

控制频率应该是多少？

没有通用固定值；不同传感器、机构和控制目标需要实测，文中频率只表示时间尺度量级。

云端能不能直接控制机器人？

高时效和安全路径不应依赖不稳定网络；云端更适合训练、回放和非实时任务，端侧保留停止权。

错误速查卡

症状	根因	定位	修复
“VLA 输出动作就宣布机器人已可控”	策略候选获得表达能力 ≠ 获得执行授权；缺少安全门禁、低层控制、监控	检查感知/VLA/安全/控制四件套是否齐备	部署最小闭环：同步状态→VLA→动作适配→独立安全门禁→低层控制→监控
VLA 超时时一直重试	控制器没有保持/减速/停止的回退；任务管理未进入可解释状态	检查 VLA timeout → 控制器回退行为；任务管理是否进入 HOLD/RECOVER	显式定义 DEGRADED / HOLD / RECOVER 状态机；超时进入降级策略
安全门禁拒绝率突然升高	模型漂移 / 坐标转换变化 / 限位版本变化	核对 frame_id / unit / control_mode / embodiment 字段	坐标系/单位/版本作为版本化工件；触发下游 Gate 复验
离线分数高但真机失败	只评估任务结果，未评估安全 / 实时性 / 控制质量 / 恢复 / 泛化	端到端指标账本 6 类是否都跑了	加安全 / 实时性 / 控制质量 / 恢复能力 / 泛化与运维 5 类；每类配失败分类
任务成功判定只看夹爪张开	“杯子放入托盘”未做对象位置、夹爪状态、接触解除、稳定持续时间检查	任务成功验证字段是否完整	加入对象位置 + 夹爪状态 + 接触解除 + 稳定持续时间 4 项
“module_count 越多 = 系统越安全”	为“完整”堆模块反而增加接口、延迟、模型不一致、恢复复杂度	三档闭环架构选择是否匹配任务风险	按任务短且在约束内→最小；几何/接触/动力学风险主导→混合；候选后果与长期任务主导→高阶
网络恢复后立即执行断网前返回的旧动作	远端链路 p99 延迟或断网期间会耗尽安全动作缓冲；机器人不能自动进入无风险 Hold	云边分工表硬件急停 / 高频控制 / VLA 推理三行的“必须端侧”是否被满足	远端服务不进入硬控制闭环；网络恢复后必须重新采样状态并重建计划
拒绝原因都用“模型再试一次”	拒绝原因未机器可读	检查 STALE_STATE / JOINT_LIMIT / COLLISION_RISK / DEADLINE_MISS / CONTACT_ANOMALY 等枚举	拒绝原因机器可读；上层才能选择重感知 / 换抓取点 / 降速 / 撤退 / 请求人工
一个端到端成功率掩盖多类问题	任务成功、几何可行、动态可行、跟踪稳定、硬件保护是不同验收项	端到端指标账本是否拆分类	6 类指标 + 失败分类；不要用一个数字掩盖多类问题
仿真通过、真机失败	只跑了日志回放或仿真，跳过 Hardware-in-the-loop / Shadow Mode / 分级真机	验证顺序 4 步是否完整	日志回放→仿真与故障注入→HIL/Shadow Mode→分级真机；每级验证拒绝与恢复
故障注入只测功能正确	一个不会失败的测试集无法证明恢复状态机有效	是否注入观测延迟、丢帧、网络中断、对象移动、接触异常、规划不可行	每级都要验证拒绝与恢复；恢复预算（最大次数 / 时间 / 位移 / 风险）必须存在
VLA 直接输出密集动作未做几何 / 接触检查	缺运动规划 / MPC 阶段的几何 / 接触路径	混合闭环是否部署	加入运动规划 / MPC；不可行时把原因反馈上层重新选择姿态 / 抓取点 / 技能
Action Tensor 没有基于状态版本 / 时间戳	接口合同未带 based_on_state_id / expires_at_ns / action_mode / frame_id	状态估计→策略、策略→执行层 JSON 字段是否齐备	必带 state_id / proposal_id / based_on_state_id / created_at_ns / expires_at_ns / frame_id / dt_ms
“VLA 通用模型 = 取消所有传统模块”	端到端 ≠ 取消责任合同	责任矩阵 9 类能力是否每类都有生产门禁	9 类能力 × 4 列（主要责任 / 可学习 / 生产门禁）；门禁不消失
E_STOP / FAULT 由模型自动解除	状态机未限制“不可由模型自动解除”	状态机图：E_STOP → MANUAL_RESET；FAULT → MANUAL_RESET	强化状态机约束；E_STOP 与 FAULT 不允许模型自动解除
任务成功验证只看对象存在	物理任务可能“动作序列完整但物理任务未完成”	任务成功验证是否含物理完成证据	加入对象位置 + 接触解除 + 稳定持续时间 + 视觉确认等多模态证据