WES 任务'烂尾'了：卡在执行中的任务，超时回收与重派实战

你肯定见过这种画面：WES 屏幕上一个拣选任务显示"执行中"，半小时了没动。AGV 停在原地，输送线上那箱货不知道去了哪，WMS 那边还等着收货确认，整个波次卡在那儿。任务烂尾了。

我是搞自动化设备出身的，看 WES 任务调度，我脑子里转的不是软件状态机，是设备的老毛病。这篇文章就用设备工程师的视角，把 WES stuck task timeout recovery 这套机制掰开：为什么任务会烂尾、超时回收的阈值到底设多少、重派逻辑怎么防重复执行、死任务怎么一层层往下查。

先搞懂：任务为什么会"烂尾"

WES 下发任务的链路是四级：WES → WCS → 设备控制器（PLC/工控机）→ 执行机构（AGV、输送机、提升机、机械臂）。你下发一个"把托盘从 A 口搬到 B 口"的任务，WES 把它标成 executing，然后等下面的回执。

这就像你点了外卖，订单状态是"配送中"。骑手手机没电了、路上摔了、把餐送错了楼——平台只看到"配送中"，其实单子已经凉了。WES 面临的烂尾原因，设备端就这几类：

第一类：设备压根没收到。 网络抖动、WCS 服务重启、PLC 通讯中断。任务在 WES 这儿是 executing，在设备那儿是"啥也没收到"。你查设备日志，干干净净——因为它根本不知道这个任务存在。

第二类：设备收到了，干到一半卡住了。 AGV 遇到障碍物停了、输送机电机过载跳闸、提升机安全门被打开。设备在报警，PLC 知道，但回执没往上抛——很多现场的 PLC 程序只管报警停机，回执逻辑是后来补的，补得还不全。

第三类：货被"人"拿走了。 这是最气的。任务让 AGV 去 3 巷道取一托货，AGV 到了，发现货被人工叉车提前取走了。设备回"取货失败"，但 WES 的任务状态机里没有对应的失败分支，任务就这么挂在 executing 上，直到天荒地老。

三类烂尾，本质都是同一个问题：WES 对"任务正在执行"这件事，只有发起，没有闭环确认。 超时回收机制，就是给每个任务装一个"闹钟"——到点没回音，系统自动介入。

超时阈值：WES stuck task timeout recovery 不是拍脑袋定的

很多项目的超时阈值是实施顾问随手填的：300 秒、600 秒，一刀切。这是第一个坑。

超时阈值得按任务类型分别算。公式很简单：

超时阈值 = 正常执行时间 × 1.5 + 通讯容忍时间

正常执行时间要实测。比如 AGV 搬运任务：从接到指令到放下货，实测节拍是 90～120 秒（这取决于巷道长度和载重，我经手的一个项目里，满载 1 吨的 AGV 在 80 米巷道里单程就要 75 秒）。那搬运任务的超时阈值就是 120 × 1.5 + 30（通讯容忍）= 210 秒，取整 240 秒。

你可以用"心跳检测"做补充：WES 每 30 秒问 WCS 一次"任务还活着吗"。心跳断了 3 次（90 秒），不等超时阈值，直接触发回收。心跳是高频低成本的探针，超时阈值是兜底的闹钟，两个配合用。

反常识的判断来了：超时设得太短，比设得太长更坑。 很多人觉得阈值短=响应快，这是软件思维。设备现场是这样的：AGV 满载爬坡时速度会降 20%，遇到行人会主动降速避让，一个正常 100 秒的任务，偶发能跑到 160 秒。你把阈值设成 120 秒，WES 就会在任务还没干完时强行回收——回收的动作是"取消原任务、重派新任务"，结果就是两个 AGV 往同一个库位跑，撞车或者重复取货。我见过一个现场，阈值设 90 秒，高峰期每天误回收 40 多次，最后是靠人工在屏幕前一个个确认才没出大事。超时太长，顶多是烂尾任务多占一会儿资源；超时太短，是系统自己在制造事故。宁可设 1.5 倍实测上限再加通讯容忍，也别为了"快"去赌设备的偶发波动。

自动化仓库中 AGV 小车在巷道内搬运货物作业

现场案例一：AGV 任务"假死"，180 个任务堵成一锅粥

2024 年 11 月，华东某电商仓（自动化立库 + 28 台 AGV，拣选区）。大促当天上午 10 点，WES 屏幕上 180 多个搬运任务全是 executing，AGV 一半停着不动，现场一片混乱。

排查过程是这样的：WES 日志显示任务都已下发；WCS 日志显示 12:00 左右有一次服务重启——重启后，WCS 内存里"正在执行的任务"清单丢了，但它没告诉 WES。WES 还以为那 180 个任务都在执行中，继续等回执；AGV 那边呢，WCS 重启后没给它们重发指令，车就停在原地等。两边信息一错位，任务集体假死。

根因就一句话：WCS 重启后没有做"任务对账"——没有拿自己的 executing 清单去跟 WES 对一遍。修复方案：在 WCS 启动时加一个自检流程，5 分钟内把本地任务状态上报 WES，WES 对"自己有、WCS 没有"的任务全部标记超时并重派。同时 WES 侧加了心跳：WCS 连续 3 次心跳无响应，WES 自动把该 WCS 辖区的所有 executing 任务冻结，人工确认后再批量重派。

这个项目的经验值：心跳周期 30 秒、3 次判定失联、WCS 重启自检 5 分钟。数字不大，但这是用一次大促事故换来的。

现场案例二：人工叉车"截胡"，任务在 executing 上挂了 6 小时

2025 年 3 月，华南某 3PL 仓。WES 给一台 AGV 下了取货任务，库位是 B-01-01。AGV 开到库位，举升机构顶上去——空的。货呢？半小时前被人工叉车取走了，系统账还没销（人工取货走的是另一套流程，延迟录入）。

AGV 回了个"取货失败"的码。但 WES 的任务状态机里，executing 的下一个状态只有"完成"，没有"失败"分支——实施的时候，顾问觉得"失败了人工处理就行"，没做失败回执的映射。于是这个任务在 executing 上挂了整整 6 小时，直到夜班主管巡检屏幕才发现。更糟的是，WMS 那边这票货一直显示"拣选中"，下游的复核打包全在等。

修复：给 WES 状态机补全失败分支——取货失败 → 自动查库存账（是不是被人工动了）→ 账实不符 → 任务标记异常、通知人工，同时触发补货任务。这个案例的教训是设备工程师的老话：状态机里没有"失败"这个状态，失败就会变成"永远执行中"。

死任务排查链路：从上往下一层层剥

任务卡住了，别一上来就重启服务。按这个顺序查，每一层 5 分钟内能定位就别往下走：

层级	查什么	典型症状	工具/方法
WES 层	任务状态、超时阈值、心跳记录	executing 超过阈值无回执；心跳正常但无进度	WES 任务监控屏、任务日志
WES→WCS 通讯	指令是否送达 WCS	WCS 日志里没有该任务编号	查 WES 下发日志 vs WCS 接收日志，对任务 ID
WCS 层	任务分解、设备分配	WCS 有任务但没分给设备；或分给了已离线的设备	WCS 任务队列、设备在线状态表
WCS→PLC 通讯	通讯是否中断	PLC 侧无任务记录；通讯报警	PLC 通讯状态字、网络 ping、交换机日志
PLC/设备层	设备是否执行、是否报警	设备报警停机；传感器误报；货被人工拿走	设备 HMI 报警履历、现场看一眼

排查铁律：先对任务 ID，再看时间戳。 很多"查不到"是因为两边用的任务编号体系不一样（WES 的任务号和 WCS 分解后的子任务号对不上），先确认你在查的是同一个任务，再谈别的。第二个铁律：现场看一眼，顶查一小时日志。 设备报警灯是红的、AGV 面前挡了个托盘——这种一眼的事，别在屏幕前翻日志翻到天黑。

重派逻辑：最怕"一单两送"

超时回收之后要重派，这里有个大坑：原任务可能没死，只是回执丢了。 你重派一个新任务，原任务的 AGV 突然"复活"继续执行，结果就是两台车干同一单——轻则重复取货报警，重则两车在巷道里顶头。

所以重派之前必须做三件事，顺序不能乱：

先取消，再重派。 给原任务发取消指令，并等 WCS 回执"已取消"（或取消超时）。取消指令本身也要有超时和重试。
查设备实际状态。 取消之后，问设备"你现在在干嘛"。如果设备已经在执行原任务的后半段（比如货已经在车上了），就别重派了，把原任务状态修正为"执行中（已确认）"继续等。
新任务带"幂等键"。 新任务的任务号里带上原任务号（如 TASK-8848-R1），WCS 和 PLC 侧做去重：同一个幂等键的任务，重复收到只执行一次。这是防"一单两送"的最后一道闸。

幂等设计是预防烂尾的根本。你可以理解为快递单号：同一个单号，快递员扫两次，系统只算一单。WES 的任务号在全链路（WES→WCS→PLC）必须唯一且可追溯，这是设计之初就要定死的规矩，后期补很痛苦。