3. 任务模型与生命周期

在WCS（仓储控制系统）中，“任务”不是一条数据库记录那么简单，它是连接上层业务系统与底层输送分拣设备的核心执行单元。一个订单或一个包裹进入仓库后，必须经过层层分解，才能最终转化为某台输送机、某台分拣机或某个扫码器的具体动作。理解任务模型与生命周期，是进行任务编排工程的前提。

一、从订单/包裹到设备动作的任务分解

任务分解的本质是“业务粒度”向“设备粒度”的逐级收敛。以电商仓常见的出库场景为例，一个客户订单可能包含多个SKU，每个SKU对应若干件商品，这些商品可能分布在不同的拣选位。WCS接收到的通常不是原始订单，而是上游WMS下发的出库单或波次任务。此时，任务分解需要完成以下映射：

• 订单层：客户订单号、收货人、时效要求（如当日达、次日达）。
• 波次/批次层：按配送线路、承运商或时效窗口聚合，形成可批量处理的波次。
• 包裹层：每个订单拆分为一个或多个包裹，每个包裹有唯一包裹号、目标格口或集包位。
• 搬运任务层：包裹在输送线上需要经过“入口—扫码—分拣—出口”等节点，每个节点间的移动构成一个搬运任务。
• 设备动作层：搬运任务进一步拆解为具体设备指令，如“输送机A启动”“扫码器B触发”“分拣机C在格口D动作”。

这种分解不是一次性的，而是随着包裹在物理设备上的推进动态展开。例如，包裹到达扫码位之前，WCS只需知道“包裹X需要去格口Y”；扫码完成后，才生成具体的分拣动作指令。因此，任务模型必须支持“父子任务”或“任务链”结构，父任务代表包裹级目标，子任务代表设备级动作。

二、任务状态机

任务状态机定义了任务从创建到终结的全部合法状态及迁移条件。一个健壮的状态机应覆盖正常流转和异常分支。以下是一个典型的WCS任务状态集合：

状态迁移必须遵循严格规则。例如，CREATED不能直接跳到COMPLETED，必须经过QUEUED、DISPATCHED、EXECUTING。TIMEOUT和EXCEPTION是异常终态或可恢复态，取决于业务策略：有些超时任务允许重试，有些异常任务需要人工介入后重新入队。

三、优先级设计

WCS同时处理的任务数量可能达到数百甚至上千，优先级决定了谁先占用设备资源。优先级不能简单按“先来先服务”，而应结合业务时效、设备负载和任务类型综合设定。常见的优先级维度包括：

• 业务时效：当日达订单高于次日达，次日达高于普通订单。
• 任务类型：异常恢复任务、人工插单任务通常高于常规批量任务。
• 设备瓶颈：如果某台分拣机是瓶颈资源，应优先保障高优先级包裹通过。
• 等待时长：同等优先级下，等待时间长的任务优先，防止饥饿。

工程上常用“优先级数值+等待时间加权”的方式计算调度分数。例如：调度分数 = 基础优先级 × 10 + 等待秒数。分数越高越先调度。这样既保证高优先级任务优先，又避免低优先级任务永远得不到执行。

四、超时与异常状态定义

超时和异常是任务生命周期中必须显式定义的状态，不能靠“任务一直卡在EXECUTING”来隐式表达。超时通常指任务在某个状态停留超过预设阈值。例如：

• 任务下发后，设备控制器在3秒内未返回“已接收”，判定为下发超时。
• 扫码任务启动后，5秒内未返回条码结果，判定为扫码超时。
• 分拣动作发出后，3秒内未收到“动作完成”信号，判定为分拣超时。

异常状态则涵盖更广的范围：设备通信中断、条码重复、包裹在输送线上丢失、格口满溢、分拣机故障等。异常任务需要记录异常码、异常发生时间、关联设备、包裹号等上下文，以便后续排障和恢复。异常码建议按设备类型分段，例如1xxx为输送机异常，2xxx为扫码器异常，3xxx为分拣机异常。

五、任务生命周期的工程落地要点

在实际WCS开发中，任务状态机通常以状态表或状态机引擎实现。每次状态迁移都要写入任务历史表，记录“谁在什么时间把任务从什么状态改为什么状态”。这不仅是审计需要，更是排障时还原现场的关键依据。

任务分解的粒度也需要权衡。粒度过粗，设备调度不灵活；粒度过细，任务数量爆炸，调度开销大。一般建议以“一个包裹在一个设备节点上的完整动作”作为最小任务单元，例如“包裹X从扫码位移动到分拣格口Y”就是一个任务，而不是把“启动输送机”“触发扫码”“打开格口”拆成三个独立任务。这样既保留了设备动作的完整性，又便于超时和异常定位。

最后，任务模型必须与设备模型解耦。任务描述“要做什么”，设备描述“谁能做”。调度器负责把任务匹配到合适的设备上。这样当设备增减或更换时，任务模型不需要大改，只需更新设备能力描述即可。这是WCS任务编排工程可维护性的基础。