作业车间调度中深度强化学习状态特征设计方法论

1. 这个问题到底难在哪：调度问题的本质与状态特征的枢纽地位

先讲一个我最近遇到的真实场景。某个做离散制造系统的朋友找我聊，说他们工厂的排产经理每天要面对四十多个订单、六十多台设备、上千道工序，光是把一个班次的加工顺序排明白就要花两三个小时。更麻烦的是，现场一旦出现设备故障、紧急插单、物料不到位，整套计划就得推倒重排。他问我：深度强化学习这东西到底能不能真正用起来，帮排产经理从繁重的重复劳动里解放出来？

这个问题问到了点子上。车间调度尤其是作业车间调度（Job Shop Scheduling，JSP），确实是制造业数字化转型里最难啃的骨头之一。它的难度体现在两个层面：第一，它是典型的NP-hard组合优化问题，随着工序数和机器数增长，可行解空间爆炸式膨胀，精确算法在真实规模下根本算不动；第二，真实车间是动态的、带约束的、目标多元的，传统数学规划方法把问题建模后，稍微加一个扰动约束，重算成本就高得离谱。

深度强化学习（DRL）跳出了“一次性求解”的框架。它把调度过程看作一个序贯决策问题：智能体在每一个决策时刻观察当前车间状态，选择一个动作（比如把某道工序指派给某台机器），执行后环境发生变化，给出奖励，然后进入下一个决策时刻。这个思路的最大好处是，训练完成后的策略网络可以用在未见过的订单组合、机器数量甚至工艺路线上，推理速度极快，特别适合动态重调度场景。

但DRL在调度领域落地有个非常隐蔽的瓶颈：状态特征设计。策略网络本质上是一个函数逼近器，它有多聪明，取决于喂给它的状态表示有多好。状态特征设计框架做得扎实，智能体才能看一眼车间状态就知道“现在该优先处理哪个订单”“哪台机器已经过载了”“哪个工序再不加工就要拖期了”。这个“观察-理解-决策”的翻译环节，是整个DRL调度系统的眼睛。眼睛瞎了，策略再先进也是白搭。

我见到的很多调度DRL项目，算法模型换得很勤，PPO不行换DQN，DQN不行换A2C，折腾半天效果上不去，最后排查下来问题往往不在算法，而在状态特征的表达方式——信息冗余、归一化不当、关键信号被噪声淹没。所以我想把状态特征设计这个环节单独拎出来，从框架层面整理一套可以直接落地的设计方法论，顺便把我在实际项目里踩过的坑、验证过的细节一起写出来。

这篇文章适合谁看？第一类是正在做制造执行系统或者APS（高级计划排程系统）的工程师，想用DRL替代规则引擎做智能排产；第二类是研究调度优化方向的学生，需要把强化学习模型跑起来做对比实验；第三类是纯粹对“特征工程如何影响决策质量”感兴趣的算法同学。下文所有讨论都围绕一个核心问题展开：给定一个作业车间调度场景，怎么把原始状态编码成深度强化学习能用好、且在不同实例间能泛化的特征向量。

2. 状态特征设计框架：从原始车间数据到可学习状态张量

2.1 一个通用的“观察-编码-决策”闭环

在动手设计特征之前，先把整个DRL调度系统的信息流梳理清楚。一般来说，一个完整的调度闭环包含以下环节：

• 环境建模：定义订单、工序、机器、工艺路线、约束条件，以及调度目标的数学表达；
• 决策时刻划分：确定智能体在什么时点做决策，常见做法是每完成一道工序触发一次，或者每经过固定时间间隔触发一次；
• 状态观察与特征构造：从环境里提取原始数据，加工成固定维度的张量或图结构，这一步就是本文的主题；
• 策略网络计算：把状态张量输入神经网络（常用的是图注意力网络、Transformer或者多层感知机），输出各候选动作的得分或概率分布；
• 动作掩码与环境交互：屏蔽掉当前不可行的动作，执行选中的动作，环境推进并产生新的状态；
• 奖励反馈与参数更新：根据调度的目标函数设计奖励信号，用PPO或DQN等算法更新策略参数。

在这个闭环里，状态特征设计处于“承上启下”的位置。往上承接的是离散制造车间的物理现场——各种传感器数据、MES系统里的工单、设备台账；往下对接的是神经网络的输入层——形状固定、数值归一化、语义明确的多维张量。这两端的语言完全不一样，特征设计就是翻译官。

翻译得好不好，可以用三个维度来度量：充分性（决策需要的关键信息有没有被包含）、紧凑性（有没有冗余和噪声）、泛化性（换个规模的实例，特征含义是否保持一致）。我在项目评审里有个习惯，先不看策略网络的结构，先把状态特征说明书拉出来看一遍，基本能判断这个方案能走多远。

2.2 三种主流编码范式：各有各的适用边界

设计框架的第一步是选编码范式。目前学术界和工业界落地的方案大致分成三类，我给它们起了比较直观的名字：全局状态矩阵、图结构状态、局部观测窗口。

全局状态矩阵是最传统的方式，也是现在很多文章里说的“基于实例编码”。思路是把整个车间所有订单、工序、机器的关键属性堆叠成一个或多个二维矩阵。比如可以构造一个“工序×机器”的矩阵，每行代表一道工序，每列代表一台机器，矩阵元素表示该工序在某台机器上的加工时间；再叠加上“工序×特征”矩阵，包含剩余处理时间、等待时长、截止期紧迫度等。这种范式实现简单，固定形状的输入对网络结构友好，适合规模不大且机器数量相对固定的场景。

图结构状态是近几年非常主流的方向。把工序看作节点，工艺路线中的先后关系看作有向边，机器作为另一类节点，工序和机器之间的可行性关系构成二分图的边。这种表示天然保留了调度问题的组合结构，图神经网络（比如图注意力网络）可以直接在节点上做消息传递，节点特征可以做得非常丰富。它的优势是泛化性好——图结构可以适应不同数量的工序和机器，而全局矩阵一旦实例规模变化就得重新设计维度。代价是实现复杂度高，图网络训练也比普通多层感知机更敏感。

局部观测窗口则更贴近实际车间里“决策者看不到全局”的真实场景。智能体只观察当前时刻附近的信息，比如各机器的即时利用率、正在排队的工序数、最近一小时产出量。这种设计适合分布式决策或多智能体调度场景，因为每个智能体本来就只有局部视角。但在单智能体全局调度场景里，局部观测窗口通常表现不如全局信息，因为它看不到订单的整体交付压力，容易陷入“局部优化、全局失衡”。

从我的经验来看，如果项目目标是在固定机器数的基准实例上跑实验，全局状态矩阵是最稳妥的起点；如果目标是做一套能适配不同车间布局的通用排产工具，图结构状态是值得投入的方向；而局部观测窗口更适合设备层或产线级的分布式调度。三种范式不是互斥的，实际工程里完全可以混合使用——比如用图结构表达工序约束，再拼一个全局统计向量表达整体进度。

表：三类编码范式对比

2.3 特征层级的分解：从订单到设备再到时间维度

确定了编码范式之后，再把具体特征逐层拆开。我习惯把调度状态的特征空间分为五个层级，分别为订单层、工序层、机器层、时间层和全局统计层。每个层级的特征回答的问题不一样，合在一起才构成完整的决策依据。

订单层回答的是“哪张订单更急”。常见特征包括订单剩余工序数、剩余总加工时间、截止期紧迫度（按剩余时间除以剩余所需时间计算）、订单优先级、是否已出现拖期等。排序决策在很大程度上是由订单紧急程度驱动的，这些特征能直接左右策略的选单逻辑。

工序层回答的是“这道工序现在什么状态”。包括工序的剩余处理时间、在设备上的加工时间、已完成工作量、等待时长、紧前工序是否完成、是否有可用替代机器等。工序特征刻画的是微观可行性，策略网络需要用这些信息来判断“当下有哪些工序可以进入下一轮选择”。

机器层回答的是“这台设备能否承接新任务”。包括机器当前负载率、排队等待工序数、平均加工速度、单位时间产出、故障停机状态、剩余可用时间等。在动态调度场景里，机器一旦故障，相关工序的可用设备集合立刻变化，这个信号必须及时反映到状态中。

时间层回答的是“时间压力有多大”。包括当前全局时间、最大完工时间（makespan）的当前上界、与截止期的平均时间裕度、平均等待时间等。时间特征是全局信号和局部信号的汇合点，它让智能体感知到“现在整体进度是超前还是落后”。

全局统计层回答的是“车间整体运行健康度”。包括当前各机器利用率的标准差、瓶颈机器的识别状态、在制品库存水平、产出速率等。这些特征对策略有种“方向盘校准”的作用——当某台机器利用率明显高于其他机器时，策略应当避免继续给它塞任务，而是把任务分流到有裕量的设备上。

这五个层级的特征合在一起，就构成了一套比较完整的状态画像。在设计具体框架时，不建议一开始就堆几十个特征。我常用的做法是先选每层三到五个最核心的特征，跑通基线实验后再逐步增加，每加一个特征都要单独检验它对最终调度指标的影响。换句话说，状态特征设计也要当成一次“单变量实验”，而不是一次性堆完然后听天由命。

3. 核心特征设计的构造方法：每个维度的语义都要想清楚

3.1 工序级特征的语义设计与取值逻辑

工序是调度决策的最小单元。在构造工序级特征时，需要特别注意“相对信息”和“绝对信息”的区别。比如“剩余处理时间”这个特征，不同的工序绝对值可能从几分钟到几天不等，如果直接输入网络，数值大的工序天然会在特征向量里占据主导地位，但这不代表它在决策上就比小工序重要。所以工序级特征通常要做相对化处理，比如用“该工序剩余时间占订单剩余总时间的比例”替代绝对时间。

另外还有一个非常容易被忽视的特征是“工序的属性随状态演化而变化”。很多初学者把工序特征当成静态属性一次性构造好，这其实是错的。等待时间这个特征的演化尤为重要：一道工序如果迟迟没有被安排，它的等待时间持续增长，这代表它所在订单的交付风险在上升。策略网络必须有途径感知这种演化，因此状态特征需要在每个决策时刻重新计算，而不是复用初始值。

在设计工序级特征时，我还建议加入一个“工序松弛度”（操作的松弛时间）指标，计算公式是：剩余可用时间（距截止期的时间）减去剩余工序（包括当前工序）总处理时间。松弛度为负说明已经开始拖期，为正在零则说明已经处在临界状态。这个指标比单纯的截止期紧迫度更能刻画真实压力，因为它把“还剩多少时间”和“还需要多少时间”做了一次真正的对比，类似生活里判断一件事来不来得及，只看“还有几天”是不够的，还得看“还要干多久”。

3.2 机器级特征：负载、瓶颈与可用性的动态表达

机器级特征的构造核心是“负载画像”。最直接的特征是当前机器队列中所有待加工工序的总处理时间，也就是这台机器还有多长时间的活要干。但这个绝对时间会受不同机器速度差异的影响，所以最好再配合一个相对特征：机器当前负载率——待处理总时间除以机器在观察窗口内的可用时间容量。负载率超过0.9说明已经超负荷，低于0.3说明相当空闲，这些阈值信息对策略网络非常友好。

机器可用性特征在静态调度里往往被忽略，但在动态场景里是必须处理的。现场设备时刻可能发生故障、维保、换型，一旦某台机器不可用，原来分配给它的工序需要重新选择替代设备。这个信息可以用一个布尔特征表示（1可用，0不可用），也可以更细腻地编码为“预计恢复时间占比”——用距离恢复的时间除以当前全局最长剩余时间，这样既表达了故障状态也表达了故障严重程度。

机器瓶颈识别也是个值得写进状态的特征。我通常的做法是动态计算每台机器的利用率滑动平均值，然后找出利用率最高的前两台机器，给它们单独打上瓶颈标记，再用一个特征表示“当前策略是否正试图将工作负载从瓶颈机器转移出去”。这个特征的设计逻辑很直接：调度问题的核心矛盾往往集中在瓶颈资源上，让智能体明确知道瓶颈在哪，相当于给它的搜索过程装了个罗盘。

3.3 订单级特征与时间维度特征的交互设计

订单级特征和时间维度特征的交互，是整个状态特征框架里最需要“算力”的地方。一个订单的状态不能只看它还剩多少道工序，还要看这些工序的剩余处理时间与剩余可用时间的匹配度。我管这个叫“交付压力指数”，它的计算方式是：订单当前剩余处理时间总和除以截止期减去当前时间。压力指数大于1，说明按当前速度肯定要拖期；小于0.7，说明产能余量充足。

更精确的时间维度特征是要把“全局时间”和“局部时间节奏”区分开。全局时间就是从那批订单开始加工起经过了多少时间，这个特征帮助智能体感知整体进度；局部时间节奏指的是最近一段时间内完成工序数量的移动平均值，这个特征能反映车间的“呼吸节奏”——如果最近一小时完成的工序数量明显下降，很可能出现了物料供应延迟或者设备隐性故障。

从我的实验经验看，时间特征对调度策略的稳定性影响极大。没有时间特征的智能体往往学出一套“看起来合理但进度失衡”的策略，比如一开始拼命抢工，把优先级高的订单全排完了，后面低优先级订单大面积拖期。加入时间特征之后，智能体才能学会在时间维度上做取舍。这也是为什么我建议在所有时间相关特征前面都加一个全局进度锚点——比如当前已完成工序数除以总工序数，让每个时间特征都有一个可对照的参考系。

3.4 归一化不是可选操作：方法选错训练直接崩

状态特征设计里最容易被轻视、影响却最大的环节是归一化。调度场景的特征尺度差异极大：加工时间可能是分钟级，截止期可能是天级，机器数量可能是台级，如果这些原始数值直接拼成一个向量输入神经网络，大尺度的特征会主导梯度更新方向，小尺度特征的信息根本学不到。

归一化的第一个关键决策是“用谁的尺度做分母”。我见过很多失败的案例是直接除以训练集里的最大值，一旦测试实例的工艺时间比训练集更长，归一化后的特征范围完全错位，策略直接失效。正确做法是采用“实例内归一化”——每个调度实例的状态特征都除以该实例内部的某个参考值。比如工序剩余时间除以该实例所有工序总加工时间，机器负载除以该实例所有机器的平均负载。这种归一化方式保证了特征的数值含义在不同规模实例间保持一致，是泛化性的基石。

归一化的第二个关键决策是“是否要做动态滑窗归一化”。车间是动态系统，特征分布会随时间变化。比如开工初期，所有机器负载率都在0附近，特征分布集中；到了中后期，机器负载率可能遍布全区间。如果使用固定的归一化参数，前期特征几乎没有区分度。滑窗归一化做法是，用最近一个时间窗口（比如最近50个决策步）内特征的均值方差做归一化，每一步都更新统计量。这种方法会让特征始终能反映“当下车间的相对紧张程度”，我在项目里实测下来，比全局静态归一化的训练稳定性和最终指标都要好不少。

表：三种归一化方案对比

3.5 掩码机制：预特征设计外的第二个安全阀门

在设计状态特征时，掩码（mask）机制经常被放到“后处理”环节，但我认为它应该被当作状态特征设计框架的一部分来思考。原因很简单：特征告诉策略“现实是什么样的”，掩码告诉策略“什么事现在做不了”，二者共同决定了智能体的行动空间边界。

最典型的掩码有两类：工序可用性掩码和机器可用性掩码。工序可用性掩码标记当前哪些工序的紧前约束已经完成、可以被安排；机器可用性掩码标记哪些机器当前运行正常且没有被占用。这两类掩码必须基于环境状态事实生成，如果在特征计算和掩码计算之间状态发生了变化，就可能导致策略网络输出了一个已经被掩码屏蔽的动作，在训练时会引发逐步累积的错误。

还有一个实际经验是：掩码信息也要以特征形式保留部分。比如在某一步，可供选择的工序只有两三个，那么这是个“低自由度决策点”；如果有几十道工序可选，那就是“高自由度决策点”。把候选工序数量本身作为特征喂给网络，相当于把决策点的难度信息也告诉给智能体，这在训练前期效果特别明显，能让策略网络更快地理解“什么时候需要谨慎决策，什么时候可以放心大胆地选”。

4. 实操过程与核心环节实现：从零搭建一套可复用的状态特征框架

4.1 一个可复现的基准实验设置

讲完设计原则，这里把整套框架落到可运行的代码结构上。以一个常见的作业车间调度基准配置为例：设为6台机器，订单数可在10到30之间变化，每张订单包含5到10道工序，工艺路线随机生成但保证无环，每道工序可从全部或部分机器中选择一台加工，加工时间在区间内随机取值。目标是最小化最大完工时间，即让最后一张订单的完成时刻尽可能早。

之所以选这个配置，是因为它既保留了作业车间调度的典型结构（每张订单有各自的工艺路线，工序之间有先后约束），又不至于大到代码运行时间不可控。在这个配置下，决策时刻可以定义为“每当某台机器完成一道工序并空闲时”，智能体决定下一步该把哪道候选工序放到这台机器上。动作空间大小等于当前可用工序数，候选工序需要满足前序工序已完成。

4.2 状态张量构建的代码骨架

按照前面提出的框架，我把状态特征组织成三块：一个换代（全局）向量、一个按机器汇总的矩阵、一个按工序汇总的矩阵。机器学习库用PyTorch接口，模型部分用torch实现。

import torch import numpy as np class JobShopStateEncoder: def __init__(self, num_machines, max_orders, max_ops_per_order, feature_dim_global=8, feature_dim_machine=6, feature_dim_op=7): self.num_machines = num_machines self.max_orders = max_orders self.max_ops_per_order = max_ops_per_order self.feature_dim_global = feature_dim_global self.feature_dim_machine = feature_dim_machine self.feature_dim_op = feature_dim_op def compute_global_features(self, env_state, norm_ref): # norm_ref 参考分母：各时间/负载指标用实例级参考值归一化 g = np.zeros(self.feature_dim_global, dtype=np.float32) total_ops = env_state['total_ops'] ops_done = env_state['ops_done'] g[0] = ops_done / max(total_ops, 1) # 整体进度 g[1] = env_state['current_time'] / norm_ref['max_time'] # 时间归一化 g[2] = env_state['avg_wait_time'] / norm_ref['max_op_time'] g[3] = env_state['urgent_ratio'] # 松弛度<0的工序占比 g[4] = env_state['bottleneck_machine_load'] # 瓶颈机负载率 g[5] = env_state['load_std'] # 各机负载标准差 g[6] = env_state['queue_len_avg'] / max(env_state['max_queue_len'], 1) g[7] = env_state['due_time_pressure'] # 全局交付压力 return torch.tensor(g, dtype=torch.float32).unsqueeze(0) def compute_machine_features(self, env_state, norm_ref): # 返回形状 (num_machines, feature_dim_machine) M = np.zeros((self.num_machines, self.feature_dim_machine), dtype=np.float32) for m in range(self.num_machines): M[m, 0] = env_state['machine_queue_time'][m] / norm_ref['total_work'] M[m, 1] = env_state['machine_utilization'][m] # 已经归一化 M[m, 2] = env_state['machine_queue_len'][m] / norm_ref['max_queue_len'] M[m, 3] = 1.0 if env_state['machine_available'][m] else 0.0 M[m, 4] = env_state['machine_remaining_repair_time'][m] / norm_ref['max_time'] M[m, 5] = env_state['machine_speed_ratio'][m] # 相对加工效率 return torch.tensor(M, dtype=torch.float32) def compute_op_features(self, env_state, order_idx, op_idx, norm_ref): # 单道工序的特征向量 f = np.zeros(self.feature_dim_op, dtype=np.float32) op = env_state['ops'][order_idx][op_idx] f[0] = op['proc_time'] / norm_ref['max_op_time'] # 处理时间 f[1] = op['remaining_ops_in_order'] / norm_ref['max_ops_per_order'] f[2] = op['wait_time'] / norm_ref['max_op_time'] # 等待时间 f[3] = op['slack_ratio'] # 松弛度比例 f[4] = 1.0 if op['eligible'] else 0.0 # 前序是否完成 f[5] = op['due_pressure'] # 订单交付压力 f[6] = op['alternative_machine_count'] / self.num_machines # 可用机器覆盖度 return torch.tensor(f, dtype=torch.float32) def encode(self, env_state): norm_ref = env_state['norm_ref'] global_f = self.compute_global_features(env_state, norm_ref) machine_f = self.compute_machine_features(env_state, norm_ref) return global_f, machine_f

这段代码是一套可运行的状态编码骨架。需要特别说明几个设计细节：

一是norm_ref的预计算逻辑。在环境初始化阶段，遍历所有订单的所有工序，计算出最大工序加工时间、总加工时间、订单平均截止期等参考值，作为归一化分母。这些参考值必须在实例内保持固定，不能随训练过程改变，否则状态特征的含义会漂移。

二是eligible字段必须和掩码严格保持一致，这个字段代表该工序前序工序是否全部完成。我踩过几次坑，特征计算用了一个状态快照，掩码计算用了另一个快照，结果训练时策略明显混乱，排查了很久才发现是状态一致性问题。

三是机器不可用时的处理。如果某台机器不可用，它的其他特征应回归为中性值，靠可用性特征表达状态即可，而不要用极端数值（比如把队列时间置为无穷大）去惩罚网络，这样会让网络把“不可用”和“负载极高”搞混。在代码里，我给不可用机器的特征采用当前实例的平均值填充，效果比均匀随机初始化稳定得多。

4.3 策略网络前向计算演示

状态张量构造好之后，策略网络的处理方式取决于编码范式。这里用一个混合结构举例：全局特征经过多层感知机压缩成全局嵌入，机器特征经过一层带掩蔽的注意力层聚合，工序特征和全局嵌入拼接后过一个全连接层输出动作概率。

class PolicyNet(torch.nn.Module): def __init__(self, num_machines, feature_dim_machine=6, feature_dim_op=7, feature_dim_global=8, hidden_dim=64): super().__init__() self.machine_encoder = torch.nn.Sequential( torch.nn.Linear(feature_dim_machine, hidden_dim), torch.nn.ReLU(), torch.nn.Linear(hidden_dim, hidden_dim) ) self.global_encoder = torch.nn.Sequential( torch.nn.Linear(feature_dim_global, hidden_dim), torch.nn.ReLU(), ) # 候选工序用特征转投影 self.op_proj = torch.nn.Sequential( torch.nn.Linear(feature_dim_op + hidden_dim, hidden_dim), torch.nn.ReLU(), ) self.action_head = torch.nn.Linear(hidden_dim, 1) def forward(self, global_f, machine_f, candidate_ops, mask): # candidate_ops: [batch, max_candidates, feature_dim_op] global_h = self.global_encoder(global_f) # (batch, hidden_dim) # 机器特征池化 machine_h = self.machine_encoder(machine_f) # (batch, num_machines, hidden_dim) machine_h = torch.softmax(machine_h, dim=1).mean(dim=1) # 简单全局池化 ctx = global_h + machine_h.unsqueeze(1) # (batch, 1, hidden) cat_feat = torch.cat([candidate_ops, ctx.expand(-1, candidate_ops.size(1), -1)], dim=-1) logits = self.action_head(self.op_proj(cat_feat)).squeeze(-1) logits = logits.masked_fill(mask == 0, float('-inf')) return torch.softmax(logits, dim=-1)

这个网络结构并不复杂，重点在两个方面：其一是用了机器级的池化向量和全局向量做广度信息的汇合，让单个工序在决策时不仅能看见自己的局部信息，还能看到车间的全局压力；其二是在输出层直接做掩码屏蔽，保证无效动作的采样概率严格为零。如果是用PPO训练，还需要同时实现一个价值网络，结构类似，这里就不再单独列出。

4.4 训练环节的关键配置

实验配置方面，我比较推荐的组合是：采用PPO算法，轮次采样步数定在4096步左右，mini-batch设为512，学习率从3e-4开始，在训练过程中按线性衰减。车间调度问题的奖励通常比较稀疏，很多情况下要跑完整个实例才能算一次makespan，所以训练初期可以把奖励设计成“每个决策步缩短完工时间的增量”，也就是局部奖励塑形。

关于奖励塑形，有一点要特别警惕：如果局部奖励设定得不合理，策略可能学出“贪小便宜吃大亏”的行为。比如按“每次选择工序后立即压缩空闲时间”设置奖励，智能体可能会倾向于频繁打断当前加工，只顾眼前不拖堂。更稳妥的做法是设置“稀疏主奖励+稠密辅助奖励”的组合。主奖励仍然是完工时间的负数，辅助奖励用经过缩放的变化量，比如当前全局平均拖延时间相比上一个决策步的差值，再乘以一个小于1的系数，让它只能作为梯度方向的微调信号存在。

训练评估时，最好把验证集和训练集严格分开。用某种随机种子生成训练的订单组合，再用另一种种子生成验证的订单组合，避免模型单纯记住特定实例的分布。每若干轮训练就做一次贪婪策略评估，记录验证集上的平均makespan和相对最佳规则的提升比例，以此判断状态特征设计是否有效。

5. 状态特征设计中的常见问题与排查技巧实录

5.1 特征冗余导致收敛缓慢

状态特征设计的一个常见失误是把高度相关的特征堆在一起。比如“机器负载率”和“机器队列长度”在很多情况下几乎是同向变化的，如果两个特征都进入网络，它们提供的梯度信号方向重复，网络需要额外的训练时间才能把冗余部分“压下去”。

我自己的排查方法是，在训练前先对特征做一次相关性分析。把所有特征在多个随机实例上的取值组成矩阵，计算两两相关系数。如果某两个特征的相关系数绝对值超过0.85，就保留其中一个，或者用主成分分析把这二者合并成一个新特征。这个方法虽然看起来简单，但能非常有效地防止“特征维度很高、有效信息很少”的局面。

表：易混淆特征对的典型处理

5.2 特征分布漂移导致跨实例失效

在实际落地的过程中，最让我头疼的问题是“训练集上表现很好，一换到新订单组合上效果骤降”。这种情况很大概率是特征分布的漂移导致的。比如训练实例里的加工时间大多在60到120分钟之间，而实际生产里的新订单加工时间普遍在200到300分钟的范围。用训练集最大值做归一化，新实例里所有特征都会被压缩到很小的数值区间，神经网络看到的输入分布和训练时完全不同，策略自然失效。

解决这个问题最有效的办法是上一节提到的实例内归一化。改用“每道工序加工时间除以当前实例所有工序的平均加工时间”之后，即便不同实例的绝对加工时间差异很大，特征的数值分布也能保持在大致相同的范围内。我推荐把这个原则变成一个硬性约束：凡是涉及时间、数量、负载的特征，一律不得使用跨实例的固定统计量作为归一化分母，必须基于每个实例自身的参考值做变换。

5.3 图结构特征的过平滑问题

如果选择了图结构状态编码，训练过程中经常会遇到特征过平滑问题——图网络层数堆深之后，所有节点的特征向量越来越相似，节点的区分性快速衰退。这个问题在调度场景里尤其致命，因为调度的本质就是“区分不同工序的紧急程度”，如果所有工序的表示都糊成一片，策略网络就拿不到有效信号。

应对方式主要有三种：第一是限制图神经网络的层数，当前经验是两层到三层足够表达调度约束关系，再深收益很小；第二是图节点特征拼接原始特征作为跳跃连接（残差连接），让信息始终有通道绕过非线性变换直接流到输出层；第三是采用邻居注意力权重而不是简单的平均聚合，让网络自己学会“哪些邻居的信息值得参考”。这些手段可以同时使用，效果比单独使用任何一种都要稳定。

5.4 掩码与动作空间不一致导致训练崩溃

掩码机制在训练中出问题往往不是算错，而是时序问题。环境状态实时变化，状态特征计算和掩码计算如果不在同一个步内完成，或者在网络前向传播过程中环境又往前走了一步，就会出现“特征来自时刻A、掩码来自时刻B”的错位。

我的做法是设计一个统一的状态快照对象。在每一个决策步开始时，从环境中取出完整的状态快照，所有特征和掩码都从这份快照计算，网络前向传播结束后，再基于快照中的动作更新环境。这个约定听起来微不足道，但可以省掉大量的BUG排查时间。

还有一个训练稳定性的隐患：如果某一步掩码把所有候选动作全屏蔽了（理论上是极端情况，但如果状态和掩码错位就可能触发），softmax会输出NaN。所以要在策略网络前向传播后加一个数值检查，出现全屏蔽时强制给所有动作一个均匀小概率，并醒目地记录环境状态和掩码信息，方便定位问题源头。

5.5 奖励信号稀疏，学习效率过低

车间调度问题天然奖励稀疏，因为最核心的目标指标（比如makespan）往往要等整个实例跑完才能计算。状态特征设计虽然不能直接解决奖励稀疏，但好的特征能显著降低策略探索的难度。具体而言，在状态里加入交付压力、松弛度这类“风险前兆”特征，策略网络可以直接从特征中感知到“这个订单快要来不及了”，而不必等到终局奖励才能学会紧张感。

如果稀疏奖励导致的训练速度仍然太慢，可以在状态特征不变的前提下调整奖励结构。我给调度任务用过一种“阶段性里程碑奖励”：当某一订单的全部工序完成且目标没有拖期时，给一个正奖励；当某台设备持续空闲时间超过阈值时，给一个负奖励。有了这些阶段性信号，策略的训练速度提升明显。但要注意，辅助奖励的权重不能压过主奖励，否则策略会变得短视。

5.6 常见问题排查速查表

6. 最后再聊聊我个人的几个实操心得

文章写到后段，分享几个我在真实项目里总结出来的心得，不一定写进论文，但对实际落地很有参考价值。

第一，状态特征设计框架一定不要一步到位。刚开始做时，能跑通环境、训练出可用的策略，比追求特征完备性更重要。先用最核心的三五个特征跑通闭环，再逐步增加特征维度，每次增加后对比调度指标。这样做的好处是，一旦策略表现变差，能很快定位到新特征是否有问题。我见过太多团队前期花三四周设计了三四十个特征，训练时一头雾水，完全不知道问题出在哪。

第二，通用调度策略比特定实例优化更有工程意义。如果是做生产系统的售前验证，拿几个公开基准数据跑出漂亮数字当然重要；但真正部署到客户现场，一定会遇到训练时没见过的工序类型、机器组合、订单到达节奏。状态特征设计必须从一开始就考虑跨实例泛化，否则就是“论文能发，落地不能跑”。这也是我不厌其烦强调实例内归一化的原因。

第三，可解释性可以为状态特征设计提供反向指导。调度排产经理不太信任黑盒模型，但我遇到过好几位对这种系统态度开放，真正让他们产生疑虑的，是智能体做了明显违反常识的决策，比如把一批紧急订单放着不管，先处理遥遥无期的高价值订单。这时候如果状态特征设计里没有把交付压力作为显式特征，甚至没办法向业务方解释智能体为什么会这么选。加入清晰语义的特征，不仅帮助训练，也帮助项目推进过程中和人沟通。

第四，动态调度场景里，状态特征设计需要为“重调度”留好接口。实际生产很少让你从头到尾按一个静态计划跑完，设备故障、物料延迟、紧急插单随时可能发生。在状态里显式加入订单到达时间和设备扰动事件标记，能让策略网络在遭遇动态变化时做出及时响应，而不是把之前学到的东西全部推翻重来。

状态特征设计这件事，拆开看每个特征好像都不复杂，但组合起来的框架质量，往往直接决定了调度智能体能力的上限。希望这篇文章能把作业车间调度中深度强化学习状态特征设计的关键思路、实现细节和避坑经验讲透，给正在这个方向尝试的朋友一些可复用的参考。