学习型机器人策略部署：基础设施实战指南

先看控制闭环，再看检查点

学习型机器人策略是闭环里的一个组件。运行时读取一次观测——通常是相机图像加上机器人状态——把它映射成模型要求的输入格式，让策略给出一个或多个未来动作，执行其中一部分预测，然后再观测。

很多现代策略预测的是一个动作块（action chunk）：一小段未来的关节、位姿或夹爪指令。控制回路以固定频率逐条执行。部署基础设施负责神经网络之外的一切：同步、队列、动作选择、安全检查、硬件下发，以及能够回答“机器人究竟执行了什么”的记录。

部署的本质是重建训练时的契约

模型是在一组特定假设下学出来的。两个策略可能都接收三张图像和一个状态向量，却在相机角色、RGB 还是 BGR、字段顺序、单位、提示词措辞、时间戳、动作是绝对还是相对这些问题上完全不同。输出形状正确、而且没有 NaN 或无穷值，只能证明这条代码路径跑通了，别的什么都证明不了。

把这些假设写成一份机器可读的运行时契约（runtime contract）。它应该声明观测键名和形状、单位、相机角色、控制频率、动作预测长度和语义、任务词表、预处理方式以及归一化参数。数据集和训练变换通常是这份契约最可靠的证据来源。

先让朴素策略跑通，再让它变顺滑

第一步是证明最短路径可行：一次新鲜观测进入适配器，服务返回有限的动作，动作含义正确，一条受监督的指令到达预期的执行器。方向正确但动作抖动的基线是有用的。相机接错了、或者指令发到了错误的关节上，就算动作再顺滑也没用。

不要一上来就搞异步调度、滤波器、样条、自动重试或放宽限位。每加一个机制都会改变证据。等未经修改的策略路径跑通之后，再一个一个加。

1. 确认相机身份、颜色、方向、分辨率和帧率。
2. 对照一次物理运动，确认状态顺序和单位。
3. 确认动作顺序、单位，以及绝对/增量语义。
4. 测量原始动作幅度和推理延迟。
5. 做一次有人监督、范围受限的小规模真机验证。

把可替换的计算和硬件控制权分开

适配器把机器人观测转换成策略要求的输入格式。这样一来，策略服务可以替换、重启，甚至迁移到另一台机器，而不需要改动机器人驱动。模型输出仍然只是候选动作：路由器在模型、专家和 HOLD 指令之间做选择；最后一道安全边界校验所选动作；整个系统只能有一个进程持有硬件 SDK 并发送命令。

这种拆分让每类故障都有明确归属：格式错误查适配器，模型延迟查服务边界，动作仲裁查路由器，设备状态查硬件控制进程。

异步推理首先是时序问题，其次才是融合问题

同步执行时，机器人可能把当前动作块耗尽后停下来，等下一个动作块生成。异步推理通过提前请求下一个动作块、让控制从现有队列继续运行来避免这种停顿。

模型可能一次预测 H 行，控制端却只把前 E ≤ H 行放进可执行队列。请求时机和队列余量必须按 E 计算，而不是按完整预测长度 H 计算：没有真正进入执行队列的尾部动作，不能算作延迟余量。

但回复基于更早的观测。如果推理花了几个控制周期，回复最前面的几行动作对应的时间已经过去。运行时需要在提交请求时记录执行计数器，统计请求在途期间消耗了多少行动作，再加上观测本身的年龄，最后从回复前面删掉这段已经失效的预测。

何时提前请求也应该由测量决定。把最近端到端延迟的高分位数换算成控制步数，再加一小段调度余量，在队列至少还剩这么多可执行动作时发出下一次请求。模型、加速器、图像传输、编译器或网络发生变化后，都要重新测量。

Preserve 和 transition 不是延迟估计。Preserve 表示新回复到达后，仍有意保留几行有效的旧计划；transition 表示随后用多少行融合新旧目标。在 no-blend 模式下，系统仍然会提前推理并丢弃过期动作，只是不再平均两条未来轨迹，而是直接切换。

先看抖动发生在哪里，再决定用什么平滑方法

“机器人很抖”是一个观察，不是一个诊断。把原始指令流和反馈流画出来。判断不连续是发生在动作块内部、只发生在动作块边界，还是因为请求的运动超出了控制器能跟踪的范围。然后拿同样的统计量和演示数据做对比。

低通滤波处理动作块内部的高频噪声

普通的动作块切换不能重置滤波器，否则刚想消掉的接缝又会回来。episode 开始、人工接管、HOLD 或反馈中断之后，则应该用最新实测状态重新初始化。只过滤能容忍滞后的字段；夹爪开合通常应绕过低通，否则可能错过抓取时机。

固定目标不会永远被“削小”：连续更新会逐渐收敛到它。真正的问题是动作块有限，而且目标一直在变化；滤波过强时，控制指令可能始终落后于策略。α 不该靠肉眼选，而应测量指令与反馈之间的滞后。

样条插值解决的是另一类问题

当控制器拿到的是稀疏路点，而且移动时间明确时，可以使用三次、五次或最小加加速度（minimum-jerk）插值，例如准备位姿、回零动作，或者不同数据集起始位姿之间的过渡。样条会在已知端点之间生成稠密的位置和速度轨迹。它通常不适合快速重规划的模型输出，因为上一条曲线还没走完，新动作块就已经换了终点。

速度、加速度和单步变化限制仍然是最终安全边界，不是平滑器。如果它们频繁裁剪动作，就应该记录裁剪量并修正上游的动作尺度、频率或契约，而不是把长期被裁剪的轨迹当成正常运行。

经过时间对齐 → 可选接缝融合 → 因果低通 → 速率/安全检查 → 唯一硬件写入者

从数据集里采样部署条件

第一次观测已经在影响整段执行。一个在人看来对称或方便的位姿，可能偏离训练时见过的起始状态。相机安装、图像频率、任务措辞、夹爪范围和动作节奏也是一样：它们都属于模型学到的输入分布，不是部署现场可以随意调整的布景。

选择完整记录下来的状态

从成功训练 episode 构建起始状态库。候选帧应位于 episode 早期、持续运动开始之前；排除任务已经推进后的停顿和终止状态；然后对完整状态向量聚类，选取数据里真实存在的代表点（medoid）。不要分别计算每个关节的均值或中位数再拼成一个姿态——每个坐标都可能很常见，但它们的组合可能从未出现在任何示范里。

每个起始状态都应保留来源 episode、帧时间戳、完整状态、单位、相机快照、任务标签和可达性检查。用单独受约束的运动过程抵达它。如果某个采样状态无法安全到达，应修正过渡流程或补采覆盖，而不是凭感觉发明一个模型没见过的起点。

用数据确定动作应有多大

在增加滤波器或修改速率限制之前，先从训练 episode 计算每个关节的单步变化、速度、加速度和夹爪运动分布。用同一套统计量、在同一控制频率下比较原始策略输出和人工纠正。动作明显小于训练分布时，机器人会显得胆怯；明显大于训练分布时，大部分 rollout 都会撞在安全限制上。

DAgger 应该修正策略，而不是改变任务

在基于干预的 DAgger 里，策略会访问由它自己的错误产生的状态，人类在需要时接管，这些修正成为新的训练数据。重点是把有用的标签加到部署策略真正失败的地方——而不是造出第二个互不兼容的控制域。

修正数据只有在时序和动作含义与原始训练契约一致时才有用。更慢的遥操作、不同的控制频率，或者更小的指令增量，即使每一行都合法，也可能让微调后的策略动作偏小、反应迟疑。训练之前，应对比专家数据和原数据在单步变化量、速度、夹爪行程、指令节奏和观测延迟上的分布。

接管发生时，应把专家设备和机器人当下的实测构型对齐，再从这个参考点传递相对运动。直接发送专家设备毫不相干的绝对位姿会造成跳变；未经数据对比就修改专家设备的增益或速度，则会改变下一轮训练标签的分布。

先记录动作来源，再派生训练视图

保留完整且不可变的原始 episode，并在每个控制步记录模型提议、对齐后的专家提议、选中来源、安全处理后的命令、实际执行动作、控制模式和接管事件。训练时就可以只选专家窗口、加入模型失败前的上下文，或者构建混合视图，而不必猜测当时发生了什么。

条件允许时，用下发链路分配的控制步 ID 关联各条数据流。最近时间戳关联可能跨过接管边界，也可能把有效性信号贴到错误动作上。动作来源缺失或互相冲突的区间应该隔离，不能猜成有效标签。

描述一次部署，而不是硬编码一次部署

模型包包含权重，以及正确解释这些权重所需的配套文件。部署描述文件（deployment descriptor）是一份很小的配置：它把不可变的模型包绑定到运行时契约，说明由哪个服务加载、由哪张运行图接入控制链路、使用哪套相机配置，以及上线前必须通过哪些检查。启动器只读取描述文件，不应该为每个 checkpoint 再增加一条专属分支。

schema: deployment/v1
name: example-policy

bundle:
  path: models/<family>/<version>
  required: [checkpoint, contract.json]
  verifier: verify_bundle.py

policy:
  frequency_hz: 30
  action_horizon: 32
  execute_prefix: 16

observation:
  camera_profile: camera-1280x720-30.yml

runtime:
  server: managed
  graph: dual-arm-policy.yml

qualification:
  tests: [contract, adapter, service, no_write_launch]

对于已经支持的后端，接入新模型就变成了“填写配置、产出验证证据”，而不是再写一个 if model == ... 分支。同一份描述文件驱动下载校验、运行时准备、部署前验证、启动和回滚。

校验发布的是什么，到达的又是什么

• 发布方清单：随包发布的文件列表、大小和哈希。
• 本地清单：下载器生成的结构化回执，包含对象路径、大小、来源元数据和计算出的哈希。
• 本地哈希：重新计算的内容指纹，通常也写成一个扁平的 SHA256SUMS 文件。

加载模型之前，三者交叉核对。下载完整也可能是错误的 checkpoint；目录名正确也可能里面有一个损坏的文件。

找到最先出错的那一层

不要从最终的视觉症状开始查。给一次观测和一个动作加上追踪标识，跟着它们穿过系统，找到第一个值、时间戳或归属不再满足契约的边界。

1. 模型实际收到的是什么观测？
2. 它返回的原始动作块是什么？
3. 时序和运动处理之后产出了什么？
4. 路由器和最终安全边界接受了什么？
5. 硬件收到了什么，又上报了什么？

大多数部署争论之所以发生，是因为排查从“模型应该看到什么”直接跳到了“机器人看起来做了什么”。