仓储与物流一直是人形机器人最容易被拿来讲故事的场景，但真正能跑起来的第一版，通常并不是“在整个仓里什么都能干”，而是一条任务边界、站点边界和接管边界都写得很清楚的短链路。这篇文章要解决的，就是仓储物流里的人形机器人第一条闭环到底该怎么选、怎么搭、怎么验。它适合已经有样机、移动双臂平台或外购人形平台，准备进真实站点试点的团队。最关键的工程判断是：第一版不要追求全仓通用性，而要先把“固定交接点 + 明确上游系统 + 可回放异常链”做成闭环。
这篇适合谁
- 准备在仓储、配送中心、转运区做 humanoid 试点的人。
- 已经有 AMR、WMS、WES、输送线或分拣设备，想评估人形机器人该插在哪一段的人。
- 在“先做整箱搬运、先做料箱转接，还是先做异常工位补位”之间犹豫的项目负责人。
- 不想再听抽象市场判断，只想知道第一版任务怎么切、接口怎么定、验收怎么做的工程团队。
先纠正几个很常见的误区
误区 1：仓储物流适合人形机器人，是因为它“通用”
不对。仓储物流之所以适合作为早期场景，不是因为它天然通用，而是因为这里本来就有任务单、货位、节拍、交接点、责任人和上线指标。它更像一个容易被治理的系统，不像家庭或开放公共空间那样到处都是隐形变量。
误区 2：第一版应该直接做拣选、搬运、补货、盘点全流程
这很容易把项目做死。第一版更稳的做法，是先选一条短链路，比如“AMR 把料箱送到交接位，人形机器人转到输送线”或者“从固定货架取标准容器，送到打包位”。先把起点、终点、异常出口和人工接管做清楚，再谈扩展。
误区 3：只要本体能走能抓，仓里剩下的问题都能慢慢补
真实仓储项目里，更容易卡住你的往往不是单个动作，而是任务下发、资源占用、站点冲突、状态确认、故障升级和回放复盘。动作能力当然重要，但没有系统层约束，它只能做 demo，做不了值班。
关键实现判断：先做“站点型闭环”，不要先做“全仓自由作业”
如果你问仓储物流里第一条最值得做的人形闭环是什么，我更倾向于下面这类任务，而不是一上来就让机器人满仓自由移动：
- 固定交接点上的料箱/周转箱转接。 上游来源稳定，下游目标稳定，异常也容易人工接管。
- 限定区域内的补位和补料。 路径短、目标位少、节拍可测，适合先做版本验收。
- 高重复但偶尔有几何变化的搬运动作。 它比完全固定治具更需要灵活性，但又没有开放环境那么失控。
Agility Robotics 公开讲过一个很有参考价值的仓储流，AMR 先把 tote 送到 Digit 的站点，再由 Digit 把 tote 转到输送线。这个案例真正值得借鉴的，不是公司名字，而是它把任务压成了“固定上游 + 固定下游 + 明确拥堵恢复”的站点闭环，而不是让机器人自己去理解整座仓库。
仓储里的人形机器人第一版，最该证明的不是“它能干多少种活”，而是“它能不能在一个被约束的站点上稳定接单、稳定交接、稳定退出”。
分步实践指南：怎么把仓储物流里的第一条闭环搭起来
第 1 步：先冻结一条 30 到 90 秒能跑完的任务链
别从“仓储自动化升级”这种大词开始，先把任务写成一条短链路：
- 输入是什么，比如 AMR 到站、货格到位、人工按下确认键、WMS/WES 发出一张短任务单。
- 动作是什么，比如取箱、转身、放箱、确认释放、回到等待位。
- 输出是什么，比如下游输送线接收成功、托盘位空出、任务单回写完成。
- 异常出口是什么，比如抓取失败 2 次、下游堵塞、物体尺寸异常、站点占用超时。
如果你现在写不出这四项，就还没到做试点的时候。仓储项目怕的不是技术难，而是任务定义糊。
第 2 步：优先做“站点作业”，不是“自由巡航 + 临场判断”
第一版尽量选一个站点化任务。原因很简单，站点化任务更容易收敛下面这些变量：
- 物体入口更稳定。 料箱、周转箱、包裹进入视野的位置可以被约束。
- 放置目标更稳定。 你可以定义输送线入口、缓存位、托盘格或工装边界。
- 人工介入更清楚。 出问题时，站点边上就能接管，而不是整仓找人。
- 节拍更容易算。 每循环多少秒，堵站多少次，恢复多久，都能稳定统计。
人形机器人在仓里不是不能移动，但第一版最好把移动范围压缩到站点附近的必要动作。把“会不会自由穿仓”留到第二阶段，先把“站上能不能值班”做出来。
第 3 步：把上层系统和机器人之间的接口先写死
很多仓储试点一开始就输在接口模糊。建议你至少先冻结这 4 类字段：
- 任务字段： 任务编号、来源站点、目标站点、物体类型、优先级、超时阈值。
- 状态字段： 等待中、执行中、阻塞中、人工接管中、完成、失败。
- 资源字段： 站点是否占用、下游是否可放行、上游 AMR 是否到位、门禁或输送设备是否 ready。
- 异常字段： 感知不确定、抓取失败、姿态越界、货物异常、下游拥堵、人工取消。
VDA 5050 的价值就在这里，它强调的不是某一家机器人的能力，而是主控系统和移动机器人之间应该如何交换任务、状态和确认信息。人形机器人不一定直接照搬它的协议，但非常值得借它的思路，把任务和状态语言先稳定下来。
第 4 步：给仓库侧保留一个编排层，不要让机器人直接对 WMS“裸连”
如果 WMS、WES、输送线 PLC、AMR 调度和人形机器人都彼此直连，后面会非常难维护。更稳的做法，是在仓库侧保留一个薄编排层：
- 上层系统负责生成任务、控制优先级、管理资源占用。
- 编排层负责把任务翻译成机器人看得懂的站点动作。
- 机器人只负责感知、操作、局部恢复和状态上报。
Open-RMF 的 fleet adapter 教程很值得参考。它把机器人状态、任务竞标、导航命令和上层调度拆开，让接入层成为“翻译器”，而不是让每台机器人自己去理解整座设施的业务逻辑。人形机器人接仓储系统时，也应该优先用这种适配层思路。
第 5 步：把“抓到了没有”改成可验证的三段式确认
仓储站点里，失败最常见的不是根本抓不住，而是系统以为抓住了、其实没抓稳；或者放下去了，但没有真正释放干净。第一版建议把确认逻辑拆成三段：
- 取前确认： 目标是否在预期区域，姿态是否在可抓包线内，是否允许当前动作执行。
- 取后确认： 手部/夹具状态、负载变化、视觉复核是否一致。
- 放后确认： 目标位是否被占据、末端是否完全释放、下游是否确认接收。
别把成功判定只写成“动作执行结束”。仓储节拍里最贵的错误，往往是系统把一件未完成动作错记成已完成，之后整条链都会错位。
第 6 步：异常接管要按层级设计，不要全都升级给工程师
仓储站点的异常大致分三层：
- 机器人局部可恢复： 重新对位一次、换抓取姿态一次、等待下游清空一次。
- 站点人工可恢复： 现场操作员清障、重新摆正容器、按键确认继续。
- 系统级异常： 版本问题、配置错、站点状态错乱、接口失联，这才交给工程团队。
如果所有异常都默认呼叫工程师，项目一上线就会被值守成本拖死。你要做的不是把异常消灭干净，而是让大多数异常停在最低成本的恢复层里。
第 7 步：上线前先把“堵站场景”设计出来
很多 demo 看起来很顺，是因为只跑理想单件流。真实仓里更容易出事的是：
- 下游输送线暂时堵住，机器人该继续拿还是进入缓存动作。
- 上游连续来料，站点已经堆积，是否需要暂停接单。
- 人工临时插入任务，当前动作该打断、延后还是先安全收尾。
Agility 那个 tote 转接案例里，一个实用细节就是下游拥堵时先做边侧堆放，等输送线恢复再继续主流程。这种“非理想但可管理”的队列策略，比追求永远零阻塞更接近真实部署。
第 8 步：统一记录站点级回放证据，别只留视频
仓储项目很容易犯一个错，只保存监控视频，不保存可对齐的系统日志。更实用的做法，是至少把这些数据放到统一时间线上：
- 任务状态变化。
- 站点资源状态。
- 关键感知输出和抓放确认结果。
- 人工接管开始与结束。
- 版本号、配置号、任务单编号。
MCAP 的 ROS 2 方案很适合做这种站点级回放。它不是魔法，但它让你更容易把控制、状态和消息流放到一条统一时间线上复盘，而不是每次都靠群聊和监控回忆“刚才到底发生了什么”。
最容易翻车的地方
- 第一版就想覆盖整仓。 结果路径、门禁、调度、感知、抓取和运维一起失控。
- 只定义动作，不定义任务完成条件。 系统很容易出现“动作结束了，但任务没真正闭合”。
- 让机器人直接吃业务逻辑。 一旦 WMS 或输送逻辑变化，机器人侧就跟着频繁改代码。
- 异常全靠工程师远程救火。 试点可能能跑，正式值班一定顶不住。
- 只看单次成功视频，不看 100 次循环后的节拍波动。 仓储项目最后比的不是精彩片段，而是连续运行质量。
怎么验证你真的搭对了
我建议至少用下面 5 组指标看第一版仓储闭环：
- 连续循环表现： 连跑 50 到 200 次，完成率、平均周期、P95 周期是否稳定。
- 堵站恢复表现： 下游阻塞、上游连续来料、人工插单时，是否还能保持任务和状态一致。
- 接管成本： 现场操作员是否能在 1 到 2 分钟内完成常见恢复，而不需要工程师介入。
- 状态一致性： WMS/WES、编排层和机器人侧对同一任务的状态是否始终一致。
- 证据链完整性： 任意一次失败，是否都能在回放里找到任务号、版本号、异常点和恢复动作。
如果你能把这 5 组指标做实，哪怕任务还很窄，这个项目也比一堆华丽 demo 更接近可复制部署。
下一步怎么做
- 从现有仓储流程里挑 1 条最短的站点型任务链，先写清输入、输出和异常出口。
- 冻结任务/状态/资源/异常四类字段，别等联调时再临时补。
- 先上一个薄编排层，把 WMS/WES 和机器人逻辑解耦。
- 先把堵站、让路、人工插单这 3 类非理想场景做成回归测试。
- 当站点闭环稳定后，再扩到第二个相邻站点，而不是立刻跳到整仓自由作业。