如果你现在要比较几台人形机器人平台，最容易踩的坑不是参数看错，而是从一开始就没有把“要做什么、怎么验收、失败后怎么回放”定义清楚。这篇不是讲谁在行业里“领先”，而是讲你怎么用工程方式比较候选平台，避免被演示视频、单次成功案例和漂亮 KPI 带偏。对大多数真正准备落地项目的人来说，最关键的判断不是谁走得更像人，而是谁能在你定义好的任务脚本里稳定跑完、留下可复核证据，并且在出错时能被接管、定位、修复。
这篇适合谁
- 准备选型或验收第一台人形机器人平台的团队负责人
- 要把机器人拉进仓内、工位、机房巡检、楼宇服务等半结构化场景的人
- 已经看了很多 demo，但还缺一套真正可执行评估框架的工程团队
先纠正几个很常见的误区
- 误区 1：先看运动能力，再看任务闭环。如果你的目标是搬运、巡检、补货、取放件、门禁穿越，那就应该先比较任务完成链路，而不是先比较空场走路视频。
- 误区 2：能跑通一次就算平台成熟。一次成功只能说明它“可能行”，不能说明它“可重复”。真正决定项目成本的是第 20 次、第 200 次还能不能稳定完成。
- 误区 3：只看机器人本体，不看接口与运维证据。如果供应商拿不出任务状态、日志回放、版本变更、人工接管路径，你后面会在集成和维护上补更贵的课。
- 误区 4：把选型写成市场排名。你不是在投票，也不是写行业报告。你需要的是一套和自己场景强绑定的验收清单。
关键实现判断
比较人形机器人平台时，我更建议把判断顺序固定成下面 5 层，而不是先看品牌声量：
- 任务闭环层：能不能在你的工位里完成起点、操作、结束、异常退出这整条链路。
- 连续运行层：不是单次成功率，而是连续运行 30 分钟、2 小时、1 个班次后的稳定性。
- 接管恢复层：失败时能不能被人安全接管，接管后能不能回到可继续状态，而不是必须整机重启。
- 证据回放层：每次成功和失败有没有统一日志、视频、时间线，能不能复盘。
- 系统接入层：是否具备任务接口、状态接口、电量/位置/任务阶段上报能力，方便接入现有调度或运维系统。
只要前 2 层不成立，后面谈规模化都太早。只要后 3 层缺失，项目会很难维护。
分步实践指南：怎么做一套真正能用的平台对比与验收框架
第一步，先冻结“任务族”，不要拿泛用口号做比较
平台比较最怕一句话需求，比如“我们想做通用作业”。正确做法是先把任务拆成 1 到 3 个可闭环的任务族，例如：
- 工位取放：拿取料盒，放到指定托盘，异常时请求人工确认
- 楼宇巡检：按路线行进，识别异常，上传证据，必要时人工升级
- 仓内补货：到达货位，识别料箱，抓取并放入周转区
每个任务族都要写清 4 件事：起点条件、成功条件、失败条件、允许的人工干预边界。没有这个冻结动作，后面所有比较都会滑向“谁的 demo 更好看”。
第二步，把比较维度改成“任务脚本 + 扰动矩阵 + 评分规则”
这里可以借鉴 NIST ARIAC 这类自动化竞赛的思路。它不是只看机器人做没做，而是把任务、扰动和评分规则绑在一起，要求系统在统一环境里反复跑。你也应该这么做。
我建议至少准备三层脚本：
- 基线脚本：理想物料、理想位置、无遮挡、单任务流。
- 轻扰动脚本：轻微偏位、光照变化、目标延迟出现、电量下降、路径局部受阻。
- 异常脚本：抓取失败、门未打开、物体缺失、定位跳变、上游系统超时。
每层脚本都要有统一评分项，例如任务完成率、单次耗时、人工接管次数、恢复时长、失败是否留下可复盘证据。这样你比较的是“在同一张卷子上的表现”，不是各自挑最好看的环节。
第三步，不要只录视频，必须做统一日志与回放
视频适合说服人，但不适合定位问题。平台验收至少要保留统一时间轴上的任务状态、传感器摘要、关键控制命令、告警、人工接管事件。
这一层可以直接参考 ROS 2 的 rosbag2 + MCAP 路线。MCAP 的价值不是“格式更潮”，而是它更适合把多通道时序数据放在一个可检查、可回放、可转换的容器里。你至少要做到：
- 每轮测试都能生成一份唯一编号的日志包
- 日志里能对齐任务阶段、机器人状态、关键消息和异常时间点
- 失败轮次可以在离线环境回放，而不是只能靠现场口述
如果一个候选平台不能稳定导出这些证据，哪怕本体表现不错，也要降低评分，因为后期调试成本会明显更高。
第四步，把回归测试自动化，不要靠人工“再跑一次看看”
只要平台进入候选名单，你就应该把最小验收脚本做成可重复运行的回归集。ROS 2 的 launch_testing 文档给了一个很好的方向：把多个节点一起拉起，在隔离环境里跑 active test 和 post-shutdown test，并生成标准化测试结果。
在真实项目里，你不一定要照搬 turtlesim 例子，但要保留这几个思想：
- 测试环境要可一键启动，不靠手工拼命令
- 不同轮测试要隔离，避免互相污染
- 测试完成后要能输出统一结果，而不是靠工程师主观描述
做到这里，你才真正拥有“候选平台 A 和 B 在同一套回归脚本里的差异”这类硬证据。
第五步，把系统接入能力单独打分
很多平台在 demo 阶段看起来都能完成动作，但一接入现场系统就露馅。这里可以参考 Open-RMF fleet adapter 的思路。它把位置、任务状态、电量、可用性、导航命令这类接口看成平台进入调度系统前必须补齐的桥接层。
所以在人形机器人平台验收里，我会单独拉一张“接入能力清单”：
- 是否能稳定上报任务阶段，而不是只有“忙 / 闲”两个粗状态
- 是否能输出位置、姿态、电量、故障、接管状态等基础遥测
- 是否有明确的任务下发、取消、超时、重试和人工接管接口
- 版本升级后这些接口是否保持兼容，还是每次都要重做集成
平台本体能力相近时，最后真正拉开差距的，往往就是这一层。
第六步，强制加入连续运行和恢复演练
只做短时单轮测试，很容易把问题藏起来。真正要比的是平台在疲劳、积热、缓存累积、网络抖动、场地扰动下会不会逐步失真。
我建议最低做两类长测：
- 连续运行长测：重复执行同一任务脚本，记录完成率、耗时漂移、异常增幅。
- 恢复演练：中途制造可控失败，比如目标丢失、通道阻塞、上游系统超时，检查是否能进入降级、等待接管、恢复执行。
如果一个平台每次失败都只能“整机重启 + 人工归零”，那它离真正上线还差得远。
最容易翻车的地方
- 把多个供应商 demo 拼成一个印象分。没有统一脚本和评分表，结论通常不可复用。
- 任务定义太宽。任务越宽，越容易让供应商挑最容易的子流程展示。
- 没有记录人工介入。很多看起来“跑通”的案例，其实背后靠工程师频繁补操作。
- 忽略恢复路径。只统计完成率，不统计失败后的恢复成本，会严重高估平台成熟度。
- 接口验收晚于本体验收。等本体选完再看接口，往往已经错过最该淘汰的平台。
怎么验证你真的比较对了
如果你的对比框架是靠谱的，最后应该能产出下面这些东西：
- 一份固定任务族定义，不随供应商演示临时改口
- 一套含基线、轻扰动、异常的任务脚本
- 一张统一评分表，至少覆盖完成率、耗时、接管次数、恢复时长、证据完整度、接入成本
- 每个平台都有对应的日志包、视频片段、问题单和回归结果
- 同一问题在修复后能通过回放或回归脚本被验证，而不是靠“这次看着好像没事了”
如果你最后拿不出这些产物，那你做的更像是一轮 demo 观摩，不是一轮工程验收。
下一步怎么做
如果你现在就要启动平台比较，我建议按这个顺序落地：
- 先选 1 个最值钱的任务族，不要一上来覆盖所有场景
- 用 2 周把脚本、评分项、日志要求冻结
- 让所有候选平台都在同一环境、同一扰动矩阵下跑
- 先淘汰没有回放证据和接管路径的平台
- 最后再比较性能上限，而不是一开始就被运动演示带节奏
这样做出来的结论，才更像能指导项目落地的工程判断，而不是一篇很快过时的“谁领先”评论。