先给结论：立库和 AMR 对接（ASRS AMR Integration），90% 的坑不在设备，在两者之间的"缝"上——任务在哪交接、谁先知道任务、节拍对不上时谁等谁。这三件事没想清楚就上项目，堆垛机再快、AMR 再多，入库口照样排长队。这事分两面：一面是物理的（交接点放哪、缓冲区多大），一面是信息的（WCS 和 AMR 调度系统谁指挥谁）。物理好补，信息错了，返工是以月为单位的。
说白了，立库和 AMR 是两种脾气的设备。立库是"死心眼"——堆垛机按固定巷道跑，节拍稳定得像钟表，一分钟几托就是几托，多一托都不行。AMR 是"自由人"——满场跑、会避让、会排队，但一拥堵节拍就飘。把钟表和自由人绑在一起干活，难的从来不是让它们各自快，是让它们在同一个节拍上交接。
我亲历的坑：ASRS 与 AMR 对接，入库口那 40 米
2022 年 11 月，苏州一家汽配仓，4 巷道堆垛机立库，配了 12 台 AMR 做入库输送。项目验收时数据很好看：堆垛机单台 90 托/小时，AMR 空载 1.8 米/秒。投产第一周，入库口就堵了。AMR 在入库输送线前排起长队，最多时 8 台车在那儿等，最长的等了 11 分钟。堆垛机呢？有一半时间在空等——货没送到，它只能干瞪眼。
问题出在哪？交接点设计。AMR 把托盘送到入库口的辊道上，辊道满了（只能缓存 3 托），后面的 AMR 只能原地等。而 WCS 下发入库任务有个 2～3 分钟的延迟——AMR 到了，WCS 还没告诉堆垛机"去接货"。一头是物理瓶颈（3 托缓存），一头是信息延迟（任务晚到），两头一夹，12 台 AMR 的运力实际只发挥了六成。
怎么救的？三招。第一，把入库口缓存从 3 托扩到 8 托，给波动留余量——记住，缓存不是浪费，是两种节拍之间的"翻译器"。第二，WCS 任务预下发：AMR 距离交接点还有 2 分钟路程时，WCS 就提前把入库任务派给堆垛机，让它提前到位等货，而不是货到了再派活。第三，AMR 调度加"交接点预约制"——去同一个入库口的 AMR 提前排队编号，不许 8 台车同时涌向一个口。这三招下去，AMR 平均等待从 11 分钟降到 40 秒以内，堆垛机利用率从 52% 拉到 88%。
我见过太多项目把钱花错地方：AMR 不够就加车，堆垛机慢就提速。其实瓶颈在缝上，不在设备上。
ASRS AMR Integration 的两面：物理交接与信息交接
物理这面，核心就一张表：ASRS AMR Integration 对接设计要点。
| 对接要素 | 设计要点 | 常见错误值 | 建议值 |
|---|---|---|---|
| 交接点位置 | 入库口/出库口设独立交接工位，不占用主线 | AMR 直接怼主线辊道 | 独立工位+缓存区，与主线解耦 |
| 缓存托盘数 | 按两者节拍差×波动系数算 | 2～3 托"意思一下" | 6～10 托，至少覆盖 5 分钟波动 |
| 节拍匹配 | 以慢的一方为基准排产 | 按快的排，慢的"加油" | 慢方定节拍，快方留 15% 余量 |
| 异常处理 | 交接失败自动回退到人工位 | 死锁了等工程师来 | 超时 3 分钟自动转人工+报警 |
| 安全隔离 | AMR 区与堆垛机巷道口硬隔离 | 画条黄线了事 | 物理护栏+光栅，AMR 不进巷道口 2 米 |
信息这面，是 WCS 和 AMR 调度系统的分工，也是 ASRS AMR Integration 里最容易返工的部分。 我的原则就一句话：WCS 管"货去哪"，AMR 调度管"车怎么走"，两者之间只交换任务状态，不互相指挥。WCS 下发"把 A 托盘从 1 号口送到 B 点"，AMR 调度自己决定派哪台车、走哪条路、怎么避让。任务状态回传要细：已接单、已取货、已送达、异常，四种状态缺一不可。最忌讳的是两边都觉得自己是老大——WCS 想直接指挥每一台 AMR 的路径，AMR 调度又想自己决定任务优先级，最后两边打架，现场死锁。
节拍不匹配时谁等谁？这是个 trade-off，答案是：让便宜的等贵的。堆垛机一台几百万，AMR 一台十几万，显然让 AMR 等。但有个例外：如果 AMR 车队是瓶颈（比如只有 6 台车要喂 4 个巷道），那就反过来，让堆垛机降速等——因为让贵的设备空转，比让便宜的排队更亏。算账：堆垛机空转一小时，折旧+能耗+机会成本，够 AMR 多跑 50 趟。所以排产时先算清谁是瓶颈，再定谁等谁，别凭感觉。
第二个坑：出库口的"幽灵任务"
2024 年 3 月，美国中西部一家 3PL 仓，穿梭车立库配 AMR 做播种墙补货。出库口的问题比入库更阴：WCS 已经把出库任务派给穿梭车了，AMR 也出发了，结果订单被客服取消了。穿梭车把货送到了出库口，AMR 也到了，货没人要了——成了"幽灵任务"。高峰期一天能攒出 40 多托这种无主货，出库口缓存区被占满，正常出库全被堵死。
根因还是信息缝：订单取消的消息只到了 WMS，没同步到 WCS 和 AMR 调度。修法：在 WCS 和 AMR 调度之间加一层"任务有效性校验"——AMR 取货前 30 秒，向 WCS 确认任务仍然有效；无效直接取消，AMR 空车返回待命区。这个校验的成本是一次 API 调用，几十毫秒；不校验的成本是 40 托无主货+半小时清场。项目上线后，幽灵任务从每天 40 多托降到 3 托以内（剩下的 3 托是校验窗口期内取消的，认了）。
一句话收尾
立库和 AMR 对接，记住这句反常识的话：瓶颈永远不在轮子或轨道上，在信息到得早还是晚。AMR 排队、堆垛机空等、幽灵任务，病根都是"该知道的人不知道"。先把任务交接的信息流画清楚，再谈加车、提速、扩缓存——顺序反了，钱就白花了。
作者：老米｜20年美国供应链老兵
