APS 排产真正难的，从来不是把订单排个顺序

从有限产能、换型矩阵到模拟退火与蚁群算法，讲清一张生产计划是怎样算出来的

很多人第一次看到 APS，注意力都会落在甘特图上。

一条条彩色任务被放到设备时间轴上，订单从左向右推进，看起来就像把生产任务拖到合适的位置。于是很容易得出一个结论：所谓高级排产，无非是把订单按照交期、优先级或加工时间排个顺序，再把结果画出来。

如果 APS 只是这样，它不会成为制造业里最难做好的系统之一。

真正的排产问题是：一张订单可能要经过多道工序，每道工序有不同的候选设备；设备速度不同，换型时间还与前后产品有关；加工时又要同时占用人员、模具和物料。与此同时，现场已经开工的任务不能随意移动，尚未到货的原料不能提前消耗，设备故障和急单又会不断破坏原计划。

因此，APS 不是“给订单排序”的工具，而是一套持续回答以下问题的决策系统：

在当前真实约束下，哪些任务可以做，应该在哪里做，什么时候做；如果不能全部按期完成，应该牺牲什么，又应该保护什么？

最近，我把这套逻辑整理成了一份完整资料——《Athena APS 从业者指南与排产算法图解》。本文不打算复述整份资料，而是挑出最值得先理解的几条主线，讲清 APS 的核心计算到底发生在哪里。

MRP 已经给了生产日期，为什么还要做 APS？

MRP 关心的是供需平衡。

它会计算现有库存和已安排供应能不能覆盖需求。如果不能，就形成计划订单、采购申请或调拨建议，并通过提前期倒推一个大致的开始日期。

但这个日期不一定考虑同一台设备上还有多少订单。

假设今天系统产生三张生产订单，每张订单都需要瓶颈设备加工 8 小时，客户都要求明天交货，而这台设备明天只有一个 8 小时班次。

如果采用无限能力日期计算，三张订单完全可以同时显示为明天开始、明天完成。每张订单单独看都没有问题，但它们放到同一台设备上就不可能同时成立。

APS 的有限排程会把这三个需求放入同一个资源时间轴争抢。最终结果可能是：一张按期完成，一张延期，一张改到其他合格设备；也可能是启用加班、拆分批次，或者把低优先级订单移到后面。

这时，系统给出的就不再是一个理论日期，而是一份带有资源占用关系的计划。

所以可以这样理解：

MRP 解决“缺什么、缺多少”；APS 解决“有限资源下怎样真正做出来”。

这两个问题相互关联，却不能被一个简单的日期字段替代。

图 1：APS 不是独立排序器，而是承接主计划、MRP，并将执行反馈重新传回上层计划。

一张可执行计划，至少要同时通过五本账

很多 APS 项目失败，并不是因为没有使用高级算法，而是因为只维护了一本“设备时间账”。

机器上没有重叠，就认为排程可行。但真实生产中，一项任务能否开工，至少要同时通过五类检查。

第一本是工艺账。后道工序不能早于前道工序完成；有些工艺还规定最小等待、最大等待或零等待。热处理后的工件必须在限定时间内进入下一工序时，只写一个“前序完成后允许开始”是不够的。

第二本是资源账。主机有空，不代表人员、模具、夹具和搬运设备都有空。某工序从 10:30 到 12:00 可以完整放进机器日历，但如果必需模具在 11:30 被另一张订单占用，这个时间槽依然不可执行。

第三本是物料账。ERP 中显示 10 件库存，并不代表两张各需 8 件的订单都已经齐套。第一张订单分配 8 件以后，只剩 2 件；第二张订单不能继续拿原来的 10 件再判断一次。供应的数量、归属、批次和真正可用时间都要进入同一份数量事件账。

第四本是换型账。换型通常不是订单自身的固定属性，而是由前件和后件共同决定。浅色转深色可能只需简单清洗，深色转浅色却可能需要彻底清洁。因此：

setup(A→B) 不一定等于 setup(B→A)

如果把一张急单 X 插入 A 与 B 之间，系统不能只增加 A→X 的换型，还必须删除原来的 A→B，并重新计算 X→B。许多看起来换型很少的计划，就是在这里少算了一条边。

第五本是现场事实账。已经完工的操作不能被算法排回未来，已经开工的操作能否中断、转机，也不能由优化器自行决定。计划可以被调整，事实不能被改写。

APS 的“有限找槽”，本质上就是在这几本账之间寻找共同成立的时间区间。它并不是简单地计算：

开始时间 = max(物料时间, 前序完成时间, 设备可用时间) 

这个最大值只给出了候选下界。下界之后是否存在一段足够长、同时满足主机、人员、模具和日历的连续区间，还要继续搜索。

这也是为什么一个可靠的排程系统，需要把数据快照、物料关联、日历容量、有限解码、目标评价和独立校验拆开，而不是把所有逻辑写进一个“优化”按钮。

图 2：一份可发布计划要经过快照、批量与路线、物料齐套、日历容量、求解、有限解码和独立校验。

同一组订单，不同算法为什么能排出完全不同的答案？

要真正理解算法，最好的方式不是先背概念，而是让不同算法解决同一道题。

假设只有一台机器，初始状态为 R 族。四张订单在时间 0 都已齐套，不允许中断加工。订单数据如下：

同族连续生产不需要换型，R 与 B 之间切换需要 30 分钟。

我们用总加权拖期评价计划：

Tj = max(0, 完工时间Cj − 交期dj)      总加权拖期 = Σ wj × Tj 

提前完成不会产生负拖期去抵消其他订单的延期；权重越高，延期一分钟的代价越大。

如果按照录入顺序 FIFO 生产，顺序是 A→B→C→D。机器在 R、B、R、B 之间来回切换，累计换型 90 分钟，高权重的 D 最后完成，总加权拖期达到 750。

如果使用最早交期 EDD，顺序变成 B→D→A→C。B 和 D 同属 B 族，A 和 C 同属 R 族，既照顾了交期，也减少了切换，总加权拖期降到 90。

如果使用最短加工时间 SPT，短任务 D、B 先做，平均等待倾向会变好，但长任务 A 被放到最后。A 的权重为 3，因此总加权拖期反而是 360。

如果采用“同族优先”，先连续生产 A、C，再切换到 B、D，累计换型只有 30 分钟，全部任务也在 330 分钟内完成。这两个指标都很好，但高权重的 D 等待太久，总加权拖期达到 600。

对四张订单的 4!=24 种顺序全部计算后，目标最好的顺序是：

A → D → B → C

它的总加权拖期只有 60。

这个例子揭示了 APS 中最重要的一件事：

没有脱离目标函数的“最佳排产算法”。

最少换型、最短总工期、最小平均等待、最小总拖期和最少计划扰动，可能对应不同方案。计划员说“希望设备利用率高”，销售说“必须保证重点客户”，生产说“不要频繁换型”，这些需求如果不转化成清楚的硬约束和目标优先级，优化器无法替企业做价值判断。

更进一步，多目标也不等于把所有指标随便乘一个权重再相加。拖期的单位可能是分钟，换型是次数，库存是件·天，计划扰动又是开始时间偏移。没有归一化和业务解释的加权和，只是在混合几组不可比数字。

有些场景适合使用字典序：先确保强制订单覆盖，再尽量降低重点订单拖期，在前两个目标不明显变差的前提下减少换型。有些场景则适合输出一组 Pareto 方案，让计划主管在服务和成本之间做选择。

图 3：蓝色为 R 族、绿色为 B 族、金色为换型。最早完成、最少换型和最小加权拖期并不是同一个目标。

模拟退火的价值，不在“退火”二字，而在跨过局部最优

局部搜索通常从一份可行计划出发，通过交换、插入或改机产生邻居。如果新方案更好就接受，不好就拒绝，这种策略非常直观。

问题是，通往更优区域的路上，可能必须先经过一个较差方案。

仍以上面的四张订单为例。EDD 方案 B→D→A→C 的总加权拖期是 90。将 A 插到前面后，方案 A→B→D→C 暂时变成 150；再交换 B 和 D，则得到 A→D→B→C，目标降到 60。

90 → 150 → 60

一个只接受改善的算法可能停在 90，永远不愿跨过中间的 150。

模拟退火使用概率接受机制。对最小化问题，候选方案比当前方案差 Δ 时，常见接受概率为：

p = exp(-Δ/T)

当 Δ=60、T=100 时：

p ≈ 0.5488

算法生成一个 [0,1) 的随机数。如果随机数小于 0.5488，就暂时接受这个较差方案。温度较高时更愿意探索；温度逐渐下降后，算法越来越倾向于保留改善。

但这里有一个工程上极易写错的地方：

当前方案可以变差，历史最好方案不能丢。

程序必须分别维护 Current、Candidate 和 Best。即使 Current 从 90 变成 150，Best 仍是 90；只有找到 60 时才更新 Best。最终返回的也应该是 Best，而不是搜索停止时碰巧所在的 Current。

把模拟退火放进 APS 时，温度和概率只是外层搜索策略。真正决定计划是否可执行的，仍然是邻域和解码器。

一次“改机”移动必须重新计算该设备的速度、进入换型、离开换型、辅助资源和下游时间；一次“插入”必须重算被跨越任务的相邻关系；冻结操作和已开工任务则不能进入普通邻域。

如果候选违反硬约束，可以拒绝，也可以进入明确设计的不可行搜索和修复流程，但绝不能把高罚分当作发布许可。安全、质量和资源资格不是“罚得足够高就允许违反”的软偏好。

模拟退火适合已有可靠初解、局部动作清晰、评价可以增量计算的场景。它不保证在有限时间找到全局最优，理论上的渐近收敛条件也不能直接变成工业性能承诺。

图 4：模拟退火可以接受较差的当前解，但必须独立保存历史最好解，并让每个候选通过有限解码。

蚁群算法真正学习的，是“哪些排产决策经常出现在好方案中”

蚁群算法经常被简单描述成“模拟蚂蚁找最短路径”。这个说法没有错，却不足以解释它怎样用于 APS。

在组合优化中，人工蚂蚁并不是在车间里爬行，而是在一个构造图上逐步选择决策组件。每一次选择同时参考历史信息素和当前启发式信息：

P(i→j)  = τij^α × ηij^β        / Σ(所有合法候选的权值)

τ 是信息素，表示某个决策组件在历史优质方案中积累的经验；η 是当前启发式吸引力，可以来自较早交期、较小换型、较短加工或 ATC 紧迫度；α 和 β 控制两类信息的重要性。

放到排产问题里，“下一步”不一定只是下一张订单，还可能是：

• 从前序已经满足的操作中选下一项；
• 为当前操作选择一台合格机器；
• 选择操作与模式的组合；
• 决定某个产品族是否继续形成 Campaign。

这里最关键的不是概率公式，而是合法候选集合。

前序未完成的工序不能进入候选；没有加工资质的设备不能被抽中；被冻结的任务不能重新分配；物料尚未齐套时，解码器可能需要推进到未来事件，而不是强行立即加工。

一只蚂蚁构造完顺序后，还不能立刻强化信息素。候选必须先经过有限解码：把抽象顺序放进资源日历，计算换型、物料、人员和模具占用，验证完整性，再得到真正的目标值。

随后才会执行信息素挥发和强化：

τ ← (1-ρ)τ + Δτ

挥发防止早期偶然选择永久支配搜索，强化让好方案中的结构更容易再次出现。

不同蚁群变体的逻辑也不同。Ant System 可以让多只蚂蚁贡献信息素；ACS 常带有局部更新和更强的开发机制；MAX-MIN Ant System 会限制信息素上下界，以缓解所有蚂蚁迅速走向同一条路径的停滞。

因此，“我们使用了蚁群算法”仍然不是一个完整的技术说明。至少还要回答：

信息素挂在相邻操作、位置还是操作—机器组合上？启发式信息是什么？合法候选怎样生成？构造失败如何处理？信息素何时更新？是否叠加局部搜索？停滞怎样判断？

如果这些问题没有答案，所谓蚁群往往只是一个概率排序器。

图 5：蚂蚁只能从当前合法组件中抽样；完整候选要先经过有限解码和局部搜索，才能更新信息素。

遗传、粒子群、差分进化和蜂群，最终都绕不开“编码—解码”

元启发式名称很多，但进入 APS 以后，必须经过同一个工程关口：怎样把算法内部表示转换成一份合法生产计划。

遗传算法可以维护一组候选排程，通过选择、交叉和变异组合其中的结构。但普通数组从中间切开拼接，可能产生两个 A、没有 D。排列排产需要顺序交叉等专门算子；多工序车间还必须按操作身份而不是订单号检查是否遗漏。

粒子群和差分进化原本面向连续向量。一个常见适配方式是随机键：每个操作绑定一个实数，按实数排序得到优先列表。比如：

A=0.62，B=0.15，C=0.81，D=0.33

升序解码得到 B→D→A→C。

但这些数值不是开工时间，0.62 与 0.15 的差也不是等待 0.47 小时。若 D 的前序尚未完成，解码器仍不能先排 D。连续空间中的“位置移动”和“向量差”，必须通过清楚的离散映射才能获得排产业务意义。

人工蜂群维护多个“食物源”，通过雇佣蜂开发当前候选、观察蜂重点关注较好候选、侦察蜂重置长期停滞候选。它与蚁群不同：蜂群不依靠构造路径上的信息素学习。将二者都归为群智能，不代表可以混用同一套公式。

NSGA-II 则解决另一个问题：当企业不愿意预先把拖期、换型和成本压成一个分数时，可以通过非支配排序保留多组互不支配方案。

如果方案 A 的拖期更少、换型更多，方案 B 的换型更少、拖期更多，它们可能同时进入当前 Pareto 前沿。算法负责给出有代表性的选择，最终业务取舍仍由有权限的人完成。

这也说明，算法只是搜索层。一个完整的 APS 至少应包含：

制造事实与约束           ↓      排产编码            ↓      搜索器            ↓      有限解码            ↓      独立校验            ↓      目标评价与方案审批 

搜索器可以更换，业务事实和可行性边界不能随着算法更换而消失。

图 6：无论使用 SA、ACO、GA 还是 PSO，制造事实、可行解码和独立校验都不能被搜索器替代。

做 APS，最危险的不是算法不够高级，而是把“算出来”当成“能执行”

一份成熟的排产系统通常要区分三种状态。

事实状态来自 ERP、MES、WMS、QMS 和维护系统，包括订单、库存、报工、质量和停机。它们不能被求解器随意修改。

模拟状态属于某个数据快照和场景。计划员可以比较正常班次、加班、替代设备或外协等方案，这些试算不能直接污染现行计划。

执行计划状态是经过审批并发布的版本。发布之前还必须重新检查订单、资源、库存和实绩是否已经变化。计算时可行，不代表十分钟以后仍然可发布。

因此，APS 架构中最好将求解 Worker 与业务写入隔离。Worker 读取不可变快照，返回候选方案；独立校验器重新检查硬约束；计划员比较变化并审批；发布适配层进行版本复核和执行系统对账。

“求解成功”“已经批准”“已经发布”“MES 已确认”是四种不同状态。

如果外部系统只接受了一部分操作，也不能把 HTTP 200 当成整份计划已经执行。系统需要保留逐对象确认、部分失败和后续补偿。

现场发生故障以后，也不是简单地把所有任务向右拖动。系统应先保留已完成和已开工事实，再找出同资源相邻任务、下游依赖、共享模具和共享物料形成的影响子图。局部右移能恢复可行就不必全厂洗牌；局部修复失败，再扩大时间窗和资源范围。

计划稳定性本身也是目标。一张低优先级订单提前十分钟，却移动了一百张已经通知现场的任务，未必是一份更好的计划。

图 7：事实数据、模拟快照、无业务写入的计算 Worker、独立校验、计划工作台和发布适配应保持清晰边界。

为什么我要把这套内容整理成一份完整指南？

关于 APS 的资料并不少，但经常分散在三个世界里。

业务资料讲计划流程，却不讲算法怎样计算；算法论文讲标准 Job Shop 或 Flow Shop，却很少讨论物料、冻结和系统发布；产品资料展示功能，却不一定公开内部方法和适用边界。

我希望把这三个世界连接起来。

所以在《Athena APS 从业者指南与排产算法图解》中，不只是罗列算法名称，而是统一按照“由来、原理、公式、程序步骤、APS 编码与解码、解决的问题、数值例子、参数和局限”展开。

完整版覆盖了 EDD、SPT、WSPT、Johnson、NEH、动态规划、分支定界、MILP、CP/CP-SAT、模拟退火、禁忌搜索、遗传算法、蚁群、粒子群、差分进化、人工蜂群、NSGA-II、GRASP、VNS、ILS、LNS/ALNS、移动瓶颈、EOQ、Wagner–Whitin，以及滚动重排、鲁棒计划、仿真和学习增强的边界。

它还专门讨论了很多算法文章容易略过、但实际项目无法绕开的内容：

如何定义操作身份，怎样避免交叉后漏单和重单；插入任务时如何重算两侧换型；随机键如何恢复工艺先后；什么时候“可行解”不等于“完整计划”；求解超时、没有找到可行解和已经证明不可行，为什么必须返回不同状态；局部子问题最优为何不能宣传成全厂最优。

资料中共有 34 张可编辑 Draw.io 图。流程节点、判断分支、连线和甘特条都能继续修改，既可以用来学习，也可以直接作为内部培训、产品设计和方案讨论的底稿。

写在最后

算法不是 APS 的全部，但不懂算法，很难真正做好 APS。

只会算法也不够。真正能够落地的系统，需要把业务数据、可行性解码、搜索优化、独立校验、人工决策和执行反馈接成闭环。

有些现场，一套清楚的规则加可靠的有限找槽，就能比黑盒优化器创造更大的价值；有些复杂场景，则需要精确求解、元启发式和大邻域修复协同工作。

重要的不是追逐最新的算法名字，而是知道：

它在改变什么决策，依赖什么假设，怎样保证可执行，又怎样证明它真的比现行方案更好。

​

阅读原文：原文链接