如果你正在评估一台人形机器人到底能不能从“会做 demo”走到“可以进现场连续跑”，这篇文章想解决的不是谁家发布会更强，而是一个更硬的工程问题：部署就绪度到底该怎么判断、怎么搭、怎么验。最关键的判断是，真正决定项目能不能进入下一阶段的，通常不是某一次精彩动作，而是 uptime、异常分层、日志回放、人工接管和版本回滚这几条链路能不能闭起来。
这篇适合谁
- 准备把 humanoid 从实验室 demo 推到工厂、仓储、园区或半结构化工位的人。
- 已经能做抓取、搬运、巡检或上下料，但一进入连续运行就频繁中断的团队。
- 需要给项目设定阶段门槛，决定“该继续扩场景，还是先补基础设施”的技术负责人。
- 想建立 uptime、告警、回放、恢复、上线验收口径的系统工程师和运维负责人。
先纠正几个很常见的误区
- 误区 1：只要演示视频够顺，部署 readiness 就差不多了。
不是。demo 解决的是“能不能做出来”，部署 readiness 解决的是“能不能重复做、出了问题能不能恢复、改了版本会不会把现场拖死”。 - 误区 2：连续运行不稳，说明先去换更强模型就行。
很多现场中断根本不是模型上限，而是健康监测太粗、告警太吵、日志不完整、恢复路径不清楚。 - 误区 3：有人工盯着，系统就算可落地。
如果一名操作员一天被打断几十次，或者一次异常后要靠工程师远程 SSH 才能恢复，这不叫可运营，只叫勉强撑住。 - 误区 4：部署前验收就是多跑几次任务成功率。
任务成功率只是其中一个指标。真正的 readiness 还要看 MTTR、误报率、模式切换、版本回退、证据留存和失败可解释性。
关键实现判断：先做“可恢复系统”，再谈“可扩场景系统”
我更建议把人形机器人的部署就绪度拆成 5 个必须同时过线的门槛，而不是只看动作本身：
- 健康状态能被看懂。 不是只看 CPU、内存，而是执行器温升、总线电压、状态估计质量、感知掉帧、抓取失败率、人工接管频率这些能不能上墙。
- 异常能被正确分级。 哪些只需要记录，哪些需要降级，哪些必须停机或叫人，必须提前定规则。
- 失败能被回放。 没有统一日志，你会一直在“现场说好像是视觉卡了一下”和“控制说像是估计飘了”之间空转。
- 恢复路径足够短。 一次失败后，是自动重试、人工确认后恢复、远程接管恢复，还是必须整机重启，要事先设计清楚。
- 版本升级可回滚。 现场系统不能只会更新，不会撤回。任何会影响控制、感知、任务编排的版本变更，都应该有明确回退路径。
这也是为什么很多团队看似“算法不错”，却迟迟过不了试点门槛。问题不在于它不会动，而在于它还不是一个可控的运行系统。
分步实践指南
第 1 步，先把部署 readiness 评分表定下来
不要等到客户或现场经理问你“什么时候能扩大范围”时才临时想标准。更稳的做法，是提前给每个版本设一张评分表，至少包含下面几组指标：
- 任务层： 单任务成功率、连续任务完成率、异常退出率、人工接管率。
- 运行层： 平均无故障运行时长、班次内中断次数、MTTR（平均恢复时间）、重启次数。
- 系统层： 关键节点在线率、总线/网络抖动、传感器时钟同步质量、控制环延迟。
- 安全与治理层： 告警误报率、漏报率、急停后恢复时长、版本变更可追溯性。
一开始不用把分数体系做得很复杂，但必须能回答一个现实问题：这次版本到底比上次更稳，还是只是刚好这几次没出事。
第 2 步，把“健康状态”做成分层诊断，而不是散落日志
ROS 社区的 REP 107 和 diagnostic_aggregator 给了一个很值得借鉴的思路，不是让每个驱动各喊各的，而是把诊断信息分成操作员能一眼看懂的层级摘要，再保留组件级细节用于排障。对 humanoid 项目，这个思路尤其重要，因为问题往往不是单个节点挂掉，而是多个边缘异常叠加后才把任务拖死。
落地时我建议至少做三层：
- 整机红黄绿： 是否允许继续执行任务，是否必须降级或停机。
- 模块层摘要： 运动控制、感知、抓取、导航/定位、通信、电源、远程接管各自是否健康。
- 设备层明细： 关节驱动器、电池、相机、深度传感器、网络链路、进程状态的原始诊断值。
如果你直接把几十个底层错误原样推给值守人员，结果通常只有两个，要么谁都看不懂，要么大家学会忽略告警。诊断系统的目标不是“信息更多”，而是“更快定位到该不该继续跑”。
第 3 步，把回放当成 readiness 的硬门槛
如果一次异常之后，你拿不到同步的状态估计、控制命令、模式切换、关键视觉输出和人工接管记录，这个版本就不该进入更大范围部署。MCAP 在 ROS 2 里的实践很值得参考，因为它强调把多通道时间序列数据录成可检查、可验证、可回放的统一文件，而不是分散在截图、终端输出和零散 CSV 里。
更实用的做法是把下面这些东西固定录下来：
- 机器人状态：关节状态、IMU、电池、足底接触、模式机状态。
- 任务上下文：当前工单、任务阶段、目标对象 ID、站点/工位编号。
- 关键感知输出：不是全量原始数据都长期保存，而是保留足够解释失败的关键 topic、截图或事件片段。
- 控制与恢复证据：控制命令、限幅触发、告警触发、人工确认、远程接管、恢复结果。
MCAP 文档里提到可直接验证文件、检查 topic 和回放内容，这一点很有用。对 humanoid 团队来说，真正重要的不是“录了包”，而是异常工单能否稳定关联到一段完整可复现的证据包。
第 4 步，别让告警系统把值守人员拖死
很多现场项目并不是死在重大故障，而是死在“永远有人被小问题吵到”。Prometheus Alertmanager 的分组、抑制和静默机制，给机器人值守系统提供了一个很好的工程参照：父故障已经触发时，不要再把一串子故障全都推给人；同一类短时间重复告警，不要一次次打断值守；维护窗口里，本该允许的告警要能被静默。
在人形机器人项目里，至少要做这几件事：
- 按动作后果分级，而不是按模块分级。 例如“视觉掉帧”在回放导出阶段可能只是黄灯，在搬运闭环阶段却可能直接升级到红灯。
- 做父子告警抑制。 例如“主交换机掉线”触发后，不要再把相机、控制器、边缘机全部各报一遍。
- 把值守消息做成可处理事件。 不只是通知你“有错”，而是给出建议动作，例如重试、切手动确认、暂停新任务、等待维护。
告警系统如果没有去重和抑制，团队会很快形成“先忽略，真出事再说”的习惯，这比没告警更危险。
第 5 步，把恢复路径和回滚路径写成明确 runbook
恢复能力不是“工程师熟练度”，而应该是系统资产。每一种高频异常，都应该有固定 runbook，至少写清楚：
- 什么信号触发该 runbook。
- 现场人员可以做什么，不能做什么。
- 是否允许自动重试，最多重试几次。
- 何时切到人工确认，何时必须停机。
- 是否需要回退到上一个稳定版本。
Mender 的 OS 更新文档里有两个对机器人很有价值的工程判断，一是升级包必须校验设备兼容性，二是升级过程被打断时系统也要能回到一致状态。对应到 humanoid 现场，这意味着你不应该把“回滚”理解成最后手段，而应该把它看成版本上线的一部分。没有回滚，很多团队就不敢放量试新版本；不敢试，系统就永远停在脆弱阶段。
第 6 步，用连续运行和恢复演练来做最终验收
真正决定 readiness 的，不是某次最优表现，而是下面这些“没那么好看，但更接近真实”的测试：
- 连续运行 2 小时、4 小时、半班次后，错误分布有没有恶化。
- 随机断开一个非关键传感器后，系统能否按预期降级。
- 触发 3 类高频异常时，值守人员能否按 runbook 在目标时长内恢复。
- 从当前版本回退到上一个稳定版本后，关键任务是否还能通过回归测试。
如果这些测试过不了，就别急着扩场景、扩班次或扩客户。部署边界应该由恢复能力决定，而不该只由商务节奏决定。
最容易翻车的地方
- 只有成功数据，没有失败证据。 这样你会越做越不知道系统为什么偶发性崩。
- 只做节点监控，不做任务监控。 进程都活着，不代表机器人还在完成任务。
- MTTR 没人负责。 中断后恢复一次要 20 分钟，哪怕任务成功率不算差，现场也很难接受。
- 版本上线没有退路。 一次错误更新就可能让值守负担瞬间翻倍。
- 告警太多又没有抑制。 团队最后会被训练成“听见报警也不当回事”。
怎么验证你真的搭对了
如果你已经把部署就绪度框架搭起来，至少应该能在一周内稳定回答下面这些问题：
- 过去 7 天中断最多的 3 类原因是什么，各自占比多少？
- 一次任务失败后，是否总能在固定位置找到对应日志、截图、模式切换和接管记录？
- 同一故障复发时，值守人员是否按同一套 runbook 处理，而不是每个人都靠经验乱猜？
- 发布新版本后，是否能比较出接管率、误报率、恢复时长有没有改善？
- 最差一次中断，从发现到恢复一共用了多久，是否在你给现场承诺的范围内？
如果这些问题还回答不了，我会认为系统还停留在“能演示”，还没到“可扩部署”。
下一步怎么做
如果你现在只能做一件最值回票价的事，我建议优先补统一事件证据包：把任务上下文、关键 topic、告警记录、人工接管和恢复结果绑定在一起。因为一旦证据链完整，后面的评分表、告警治理、恢复优化和版本回滚，才真正有了可比较基础。
再往后，优先顺序通常是：先压低接管频率，再压短恢复时长，最后才是扩大任务范围。不要反过来。
延伸阅读与参考来源
- ROS REP 107, Diagnostic System for Robots Running ROS: https://ros.org/reps/rep-0107.html
- MCAP ROS 2 Guide: https://mcap.dev/guides/getting-started/ros-2
- Prometheus Alertmanager Docs: https://prometheus.io/docs/alerting/latest/alertmanager/
- Mender, Deploy an Operating System update: https://docs.mender.io/get-started/deploy-an-operating-system-update