很多团队把 humanoid 做到能拍 demo 就以为离落地不远了，但真正难的是把它做成一台可维护、可回放、可交接、可持续跑班次的工业样机。本文要解决的就是这个问题：如果你希望机器人不是“偶尔成功一次”，而是能在工厂或仓内被工程团队接住、维护、复盘和迭代，你该先补哪些底座。最关键的工程判断是：先把“可维护性、控制边界、日志回放、现场运维”做成产品约束，再去追求更炫的动作能力。
这篇适合谁
- 正在把 humanoid 原型往工厂、仓储或半结构化场景推进的团队
- 已经能做出抓取、搬运、上下料 demo，但一进现场就暴露稳定性和维护问题的项目
- 需要给机器人建立值班、排障、回放、升级和回退机制的系统工程师
先纠正几个很常见的误区
- 误区 1：动作越强，产品越成熟。 现场更先问的是一班能跑多久、坏了几分钟能恢复、日志能不能复盘，而不是视频里动作有多惊艳。
- 误区 2：可维护性是后面再补的事。 线束、接插件、电池更换路径、检修窗口如果一开始没留好，后面会直接拖垮节拍和 MTTR。
- 误区 3：只要模型够强，现场问题会自己消失。 现场失败很多都来自状态切换、接口契约、延迟抖动、权限边界和回退流程，不是模型分数不够。
- 误区 4：有遥操作就算有兜底。 如果没有明确的模式切换、日志标记和人工接管责任链，遥操作只是在把问题藏起来。
关键实现判断
把 humanoid 从 demo 做成工业样机，建议优先按下面四条主线收敛，而不是平均发力：
- 先收敛任务边界，别先收敛“通用性”。 先锁定 1 到 2 个高频工步，把起点、终点、允许偏差、人工接管点写清楚。
- 把实时控制层和任务/运维层硬切开。 高层规划、调度、视觉理解可以慢一点，但不能直接穿透到底层执行。
- 所有上线动作都必须可回放。 没有统一日志时间线，就没有稳定排障，也没有可靠回归。
- 把维护动作当成一等公民。 换电、重启、传感器校验、控制器重置、版本回退，都要像任务执行一样有标准流程。
分步实践指南
第 1 步，先把“工业样机”的验收口径写出来
不要只写“能搬箱子”“能上下料”。要把能否上线拆成几类具体指标：
- 单班次连续运行时长
- 单任务成功率和异常升级率
- 人工介入频次
- 故障恢复时间，也就是 MTTR
- 版本升级后回归通过率
Boston Dynamics 在介绍新版 Atlas 时，反复强调的不是单个动作片段，而是 manufacturability、reliability、serviceability。这个取向很值得借鉴。对工业样机来说，先定义“怎样才算一台能交给现场团队的机器”，比先讨论“还能再做什么能力”更重要。
第 2 步，把软件架构拆成三层，不让高层逻辑直接碰底层执行
我更推荐下面这个分层：
- 实时执行层：关节控制、状态估计、接触逻辑、硬件保护、急停联锁
- 技能与任务层：抓取、搬运、放置、对位、失败重试、局部恢复
- 运维与站点层：任务下发、版本管理、设备注册、日志聚合、值班告警、人工接管
这层边界不只是为了写代码更整洁，而是为了把风险关在低层。参考 ros2_control 的做法，控制器生命周期、硬件接口访问和控制环路更新都应该有明确状态机，至少要能区分未激活、激活、故障和重置中的状态。这样你在现场停一个控制器、切换一个硬件接口或重载一套参数时，才不会把整机直接带进未知状态。
第 3 步，按“维修工的视角”重新看一遍硬件
很多 humanoid 原型是按 demo 视角搭的，不是按维护视角搭的，所以一到现场就出现这些问题：
- 要拆半个躯干才能换一根线
- 电池能装进去，但换不出来
- 传感器重标定要连开发机手工跑脚本
- 出问题时看不到关键电源、总线和温度状态
更稳的做法是把每个高故障频次模块都做成“可快速确认、可快速替换、可快速复位”的单元。最低限度建议有：
- 清晰的电源域划分和保险策略
- 传感器、执行器、计算板的独立健康检查
- 现场可达的调试口和维护窗口
- 电池或供电切换流程的防误操作设计
- 关键线束、接插件和散热路径的可视检查点
如果这些东西没有，机器人再聪明，现场也只会觉得它“难养”。
第 4 步，把日志回放做成升级前提，不是事故后补救
一台工业样机，至少要能回答三个问题：它刚才看到了什么、做了什么、为什么这么做。如果做不到，就很难判断问题是视觉错了、控制抖了、任务逻辑写坏了，还是人机交接出错了。
MCAP 这类面向机器人多通道日志的格式很适合做统一时间线，因为它能同时记录传感器、状态机、任务事件、错误码和操作员动作，而且带 schema，后面换代码版本也更容易读回旧数据。真正有用的不是“存了很多包”，而是你能把一次失败切成下面这些片段复盘：
- 异常前 10 秒的状态估计、控制器模式和任务阶段
- 异常发生时的目标对象、位姿、抓取参数和安全限幅
- 异常后系统走了哪条恢复路径，是自动重试还是人工接管
- 同类失败过去一周出现了几次，是否和某次版本变更相关
没有这条回放链路，所谓“回归测试”通常都会退化成看视频拍脑袋。
第 5 步，把站点集成当成产品的一部分
只要你不是做一台永远单机演示的机器人，最终都会碰到设备注册、任务下发、区域权限、人工升级和调度系统。
这时可以借鉴 Open-RMF 这类多机器人系统的思路，把机器人适配器当成站点系统与本体之间的边界层。适配器至少要负责：
- 上报位置、健康状态、当前任务和电量
- 接收外部任务并转换成机器人内部可执行的技能序列
- 在异常时把失败分类为可自动恢复、需人工确认、必须停机三类
- 确保调度层永远拿到的是“可解释的状态”，而不是一堆机器人内部黑话
这一步做得好，后面多机协同、跨班次值守、远程值班和灰度放量才有基础。
第 6 步，把现场运维流程写成 runbook
真正能落地的团队，不会只交付一台机器人，还会交付一套值班手册。至少应该包括：
- 开机自检顺序
- 每日首班标定检查项
- 常见报警的分级处理
- 控制器重启、传感器复位和换电流程
- 什么时候允许继续跑，什么时候必须停机并保留日志
- 升级、回退和版本冻结窗口
我很建议把“人工接管后必须补哪些记录”也写进去，否则团队只会越来越依赖口头经验，系统质量会慢慢失真。
最容易翻车的地方
- 过早追求开放场景。 任务边界还没压稳就放进复杂环境，最后你根本不知道是哪一层在出错。
- 控制器和任务层耦合过紧。 上层逻辑一改，低层行为就漂，回归成本会暴涨。
- 没有统一日志 ID。 任务记录、报警记录、操作员介入记录互相对不上，事故复盘会变成猜谜。
- 把维护窗口留给“以后”。 早期样机最常见的不是算法死，而是接线松、温度高、接口脆、供电抖。
- 没有明确的停机条件。 现场最危险的不是失败，而是系统已经失真却还在继续执行。
怎么验证你真的搭对了
- 连续运行测试： 让系统按真实班次负载跑，记录任务成功率、人工介入率和恢复时间。
- 冷启动与热重启测试： 随机打断控制器、网络或上层任务进程，检查系统是否能回到已知状态。
- 维护动作演练： 按正式流程做换电、模块替换、传感器复位、日志导出，确认不依赖核心开发者在场。
- 版本回归测试： 每次参数、控制器或任务逻辑变更，都要回放一组固定失败样例和一组正常样例。
- 人工接管演练： 在不同任务阶段触发接管，验证系统能否正确冻结状态、记录原因并安全交还控制权。
如果这五类测试过不了，说明你现在拥有的还不是“工业样机”，而是“可重复演示的实验系统”。两者差别非常大。
下一步怎么做
如果你准备继续往前推进，我建议下一篇内部设计文档就写这三件事：
- 一页纸任务边界表，写清起点、终点、节拍、异常和人工接管点
- 一张控制层/任务层/运维层接口图，标出谁能发什么命令，谁只能读状态
- 一份最小 runbook，覆盖开机、自检、换电、报警、日志导出和版本回退
先把这三样写实，再去追求更强能力，项目会稳很多。