一、 哪些故障场景容易造成库存状态不清？
在自动化仓库中，无人叉车（AGV）与 WMS/WCS 系统的联动是高度自动化的，但当硬件或网络发生突发故障时，系统数据与物理现场容易出现“脱节”。最常见的混乱场景包括以下 4 种：
取货后车体故障/报警停机：无人叉车货叉已插入托盘并锁死抬升，但在刚驶离库位时发生激光雷达遮挡、避障报警或电池断电。此时原货位在系统里可能已被标记为“空”，但目的地货位又未收到“入库确认”，导致这批货物在系统账目中处于“在途”或“消失”悬空状态。货物已放下，但任务未成功反馈：AGV 已将托盘放入目标货位，但由于现场无线 Wi-Fi 信号漫游抖动或死角，AGV 发出的“Task Completed（任务完成）”信号丢失。WMS 系统判定任务超时，甚至可能误认为货物仍在车辆上。任务中途中断，系统显示货物仍留在原货位：AGV 收到取货指令并启动，但在前往取货点的路上故障停机，或者取货动作未完全完成（如高度传感器未到位）。此时系统未收到取料成功信号，以为货物还在原位，后续系统可能继续给该货位分配新的出入库任务，造成“重叠派单”。人工紧急接管后，货物被手动搬离但系统未更新：现场操作人员为了快速恢复通道畅通，手动用人工叉车把故障 AGV 上的货物抬走，但未在 WMS 系统后台进行任何异常账目调整或移库操作，导致“物理货物走了，系统数据还在”。
二、 为什么设备状态与库存状态不能混为一谈？
许多企业在刚上线 AGV 项目时，容易犯一个逻辑错误：把 AGV 的设备运行状态（Equipment Status）直接等同于库存物流状态（Inventory Status）。
车辆停止不代表任务已经取消：AGV 报警停在路中间，WCS 系统可能只是暂停（Pause）当前指令，并没有终止（Abort）任务。此时如果人工强行干预，AGV 恢复常态后可能会继续执行未完成的动作，造成二次碰撞或错放。任务失败不代表货物没有发生物理移动：传感器报错“取货失败”，可能货叉已经把托盘抬起了 5 厘米；如果直接清除任务，物理位置已经偏离了原点。系统任务完成状态不能单独证明货物实际位置：WCS 收到反馈只是通信协议层的“握手成功”，如果现场发生托盘滑脱、条码扫错或托盘放偏，系统里的“已入库”在物理现场其实是“错库”或“掉落”。
因此，设备层（AGV/WCS）的控制逻辑与业务层（WMS）的账目逻辑必须解耦，且设立防呆校验机制。
三、 故障发生时现场应该如何处理？
当现场发生 AGV 故障停机时，仓库标准 SOP（标准作业程序）应遵循以下四步法：
第一步：暂停相关任务的自动重试或后续操作第一时间在 WCS/WMS 调度大屏上冻结该故障 AGV 绑定的当前任务，禁止系统自动将该任务重派给其他 AGV，防止两台车前往同一地点争抢货位或发生碰撞。第二步：现场实地确认“车、货、位”三者状态操作人员持 PDA 移动终端前往现场，按顺序核对：车辆具体停在何处？货叉上是否有货物？货物条码/托盘号是多少？原起始货位和目标货位的物理状态是否为空？第三步：根据现场确认结果处理库存与任务记录若货物还在货叉上：通过 PDA 扫描托盘码，在系统挂起该托盘状态为“异常待核查”，禁止二次分配。若货物已放入目标位但系统没更新：在 PDA 上手动执行“现场补录确认”，强制刷新 WMS 账目。第四步：授权人员决定任务恢复、取消或重新执行普通操作员无权直接删除调度任务。必须由班组长或系统管理员在确认物理现场安全无误后，在后台进行“任务撤销”或“人工接管复位”，最后释放 AGV。
四、 系统设计层面需要具备哪些防呆机制？
防范账实不符，不仅靠制度，更靠系统软件的底层设计。在 AGV 和 WMS 对接开发阶段，必须要求厂商具备以下机制：
粒度化记录任务执行阶段：任务不能只有“开始”和“结束”，必须细化为：收到任务 $\to$ 到达取货位 $\to$ 载具提升完成 $\to$ 在途 $\to$ 到达卸货位 $\to$ 载具放下完成 $\to$ 任务彻底终结。每个阶段都需要双向信号二次确认。未确认的货物移动自动触发“锁定/异常”状态：一旦 AGV 在“载具提升完成”后发生中途异常中断，WMS 需自动将该批次 SKU 标记为“不可动用（In-Freeze）”，直到人工现场盘点解封。防重复执行与幂等性设计：防止网络重传导致同一笔移库指令被 AGV 执行两次。强制记录人工接管日志：所有手动修改 WMS 账目、手动复位 AGV 任务、手动解锁货位的操作，系统必须保留操作人 ID、时间戳及修改原因，便于后续审计追溯。