排程为什么交给确定性求解内核，大模型只在外围工作

先说结论

• 生产排程要同时满足机台兼容、工序先后、工作日历、物料齐套、换型时间等约束，改一处牵动一片，不能靠穷举，也很难靠直觉一次排对。
• 公开研究显示，约束一多、一交织，大模型直接排程的可行率明显下降，同一个问题换一种说法结果也可能不同；在当前阶段，把多约束排程的计算直接交给大模型，可行性和一致性都难以保证。
• 我们的分工：确定性求解内核负责建模、求解、生成候选方案，并在写入前复核约束；大模型只负责解释计算结果、回答提问，数字从系统取；采纳哪套方案、何时下发由人拍板。
• 这样分工可复核、状态说得清，代价是建模成本高、高度依赖数据质量，严格可复现与求解质量之间也要取舍；我们的排程产品 APSer-Aps 按这个分工设计。

大模型能写代码、读合同、总结会议纪要，很多人自然会问：生产排程能不能也直接交给它？把订单、机台、工序一股脑贴进对话框，让它排一张计划出来。

我们的做法是把这件事拆开：计划本身由确定性的约束求解内核计算，大模型只在外围做解释、查询这类与语言打交道的工作，最后由人拍板。本文说明这样分工的理由、它带来的好处，以及它要付出的代价。

需要先说明范围：本文讨论的只是生产排程这一类问题。别的业务场景适合怎样分工，要按那个问题自身的性质另作判断，本文的结论不外推。

本文说的「确定性求解内核」，指排程系统里负责计算计划的那一部分：它把订单、工序、机台和各种规则写成由变量、约束和目标组成的数学模型，先由构造式派工按优先级、交期和上游完工顺序，很快排出一版满足全部硬约束的可执行计划，再交给约束求解器去搜索更好的排法，结果更好才替换；构造式派工不调用求解器，求解器返回的每一个解都满足写进模型的全部约束，并标明这个解处于什么状态。两步都是确定的程序，都不经过大模型。「确定性」指的是：模型、数据和求解设置都相同时，计划可以重现、可以逐条核对。要满足哪些条件才能重现，后文「可复现，但有条件」一段有具体说明。

生产排程为什么难？

一张车间计划要回答的问题看上去很简单：什么活，在哪台机上，什么时候干。难在这些回答之间互相牵制。以离散制造为例，一张计划通常要同时满足下面这些条件：

• 机台兼容：一道工序只能上能加工它的机台。
• 机台不重叠：一台机同一时刻只能干一件活。
• 工装同时性：同一套模具或钢网同一时刻只能用在一处。
• 工序先后：同一个工单的工序有先后顺序，子件做完才能进父件装配。
• 工作日历：班次、周休、节假日、设备维保时段不能排活。
• 物料齐套：料没到齐，这道工序就不能开工。
• 换型时间：同一台机从 A 产品切到 B 产品，要留出换模、换料、调机的时间。

这些条件单独看都不复杂，麻烦在于它们叠在一起。假设来了一张急单，要在 3 号机上挤出两个小时：原本排在那里的工序得往后挪；它后面的工序跟着往后挪；如果被挪动的工序用的模具下午还要去 5 号机，5 号机的安排也要变；下游的装配工序因为子件晚完工，可能撞上周末停工，只能再顺延一天。改一处，牵动一片。

从计算的角度看，这类问题属于资源受限的调度问题。学术界把资源受限项目调度问题（RCPSP）的可行性判定归为 NP 完全问题类 [1]。通俗地说，随着工序和机台增加，可能的排法数量增长极快，不能靠穷举，也很难靠直觉一次排对。

排程有哪两种思路，根本差异在哪里？

面对这样的问题，大致有两种思路。

第一种：让大模型直接排。 把订单、工序、机台和各种规则写成一段文字交给大模型，让它输出一张排产表。这种方式门槛很低：不需要建数学模型，大模型能读懂不太规整的描述，输出的计划读起来也像人写的。

第二种：把问题写成数学模型，交给约束求解器。 每道工序表示为一个带开始时间、时长和结束时间的变量，各种规则写成变量之间必须满足的约束，再写出希望压低的目标（例如加权延期、总工期、换型次数），由求解器去搜索满足全部约束的排法。

以 Google 开源的 OR-Tools 为例，它是一套以 Apache 2.0 许可发布的组合优化工具集，其中包含 CP-SAT 约束求解器 [4]。CP-SAT 的排程文档介绍了这类建模方式：区间变量由开始、长度、结束三部分组成，求解器自动保证「开始 + 长度 = 结束」；「不重叠」约束要求一组区间互不相交，可以用来表达一台机同一时刻只干一件活；区间还可以标记为可选，用一个开关变量决定它是否生效，适合表达「这道工序可以放在几台兼容机台中的任意一台」 [5]。

两种思路的根本差异在于：求解器返回的每一个解都满足写进模型的全部约束，并且会明确告诉您这个解处于什么状态；大模型输出的是一段看起来合理的文本，其中是否每条约束都满足，需要另外检查。

大模型能不能直接求解排程，公开研究怎么说？

关于大模型能否直接求解排程这类约束问题，近两年有几项公开研究可以参考。

约束一多、一交织，可行率明显下降。 R-ConstraintBench 用资源受限项目调度问题评测多款大模型，逐步增加约束数量和种类 [1]。论文报告：只有工序先后约束时，能力强的模型接近满分；当停机时段、时间窗和互斥类约束叠加交织时，可行率出现崩塌式下降。作者认为主要瓶颈来自约束之间的相互作用，依赖关系图的深度影响较小。论文还指出，在规整的合成题上表现好，并不能保证在贴近真实业务的场景里同样表现好。

对照工厂现场：停机时段对应设备维保和节假日，时间窗对应交期和物料到货，互斥约束对应同一台机、同一套模具不能同时使用。这几类恰好都是生产排程的日常。

同一个问题换一种说法，结果可能不同。 SCHEDBench 把作业车间调度、资源受限项目调度、护士排班和课程排课等 1132 个实例改写成多种语义等价的自然语言表述，评测了 13 款前沿模型和开放权重模型 [2]。论文的结论是：模型对同一问题的不同表述并不稳定，表述变化会降低可行率，也会改变硬约束的违反情况；在单独测试的几种变化中，调整约束的叙述顺序带来的影响最明显。

对排程系统来说，这意味着计划员换一种方式描述同样的需求，得到的计划可能满足约束的程度不同。

研究也在推进。 另一项研究 Starjob 构建了 13 万个作业车间调度问题的训练样本，用它微调了一个 80 亿参数、开放权重的模型 [3]。论文报告，这个模型在两组公开基准上超过了传统的优先派工规则，也超过了一种此前的神经网络方法。这说明经过专门训练的模型在规整的调度问题上确实有进展。同时也要看到，这项研究的比较对象是派工规则和神经网络方法，测试题是标准基准实例，与带日历、换型、物料齐套和急单插入的工厂现场之间还有距离，这与前一项研究提到的迁移问题相呼应。

综合这些公开结论，我们的判断是：在当前阶段，把多约束排程的计算直接交给大模型，可行性和一致性都难以保证；把大模型用在与语言打交道的环节，更符合它已被验证的长处。

几种排程做法怎样对比？

选型时，您大概会在下面几种做法之间比较。表中关于大模型的判断依据前一节的公开研究 [1][2]，关于求解器的判断依据 CP-SAT 的官方文档 [6][7]；「前期投入」指上线前的建模和数据整理工作量，不含软件本身的费用。

求解内核、大模型和人各负责什么？

基于上面的判断，我们把排程系统里的工作分给三方：

内核负责计算。 订单按物料清单拆成工单，每道工序连同机台兼容、工装、先后、日历、齐套、换型等规则写成约束，求解器在这些约束内按目标搜索排法。急单进来时，内核可以在不同的目标取向下各算一遍，给出几套候选方案，并把每套方案的代价（总工期、准时率、换型次数、被挤动的订单）算清楚。每一版计划写入系统之前，再按写入类型做一轮独立复核，核对机台兼容、机台与工装不重叠、工序先后与上下层依赖，发现违反就拒绝写入。

大模型负责解说和问答。 求解器给出的是数字和状态，计划员需要的是「为什么这张单会晚」「这几套方案差在哪」。大模型读取内核已经算好的结果，把它讲成人话；计划员用自然语言提问时，大模型负责理解问题，答案里的数字从系统已有的计算结果中取。

这里有两条界线：大模型不直接计算或改写计划；排程计算也不依赖大模型，大模型不可用时，计划照常计算，只是少了文字解说。

人负责拍板。 系统把方案摆出来、把代价标明白，采纳哪一套、要不要动已经答应客户的订单、何时下发给车间，由计划员和车间决定，并留下记录。

这样分工有什么好处？

可复核。 求解内核的输出是一组具体的开始和结束时间，任何一条约束都可以拿出来逐项核对：这道工序是不是在兼容的机台上，这台机同一时刻有没有两件活，这套模具有没有同时出现在两处。写入前的独立复核按写入类型核对其中的关键几项，把这件事变成固定流程。

状态说得清。 CP-SAT 会明确返回求解状态 [6]。其中「FEASIBLE」表示找到了满足约束的解，但搜索在证明它无法再改进之前就停止了；「OPTIMAL」表示已经证明没有更好的解（在设定了允许误差时，表示已在该误差范围内）。对最小化问题，求解器还会给出一个经过证明的目标下界 [6]，可以据此说明「当前方案离已证明的下界还差多少」。这让系统能够如实标注每一版计划的成色，避免把一个尚在改进途中的计划说成已经做到头。

解释有依据。 大模型的解说建立在内核已经算好的数字之上，数字本身不由大模型生成。解说如果出错，可以拿系统里的数字对照纠正。

可复现，但有条件。 这一点需要照实说。CP-SAT 的参数文档说明：随机种子会在每次求解开始时重置，换一个种子，求解过程可能做出不同的选择；线程数设为 1 表示不并行 [7]。在单线程并固定随机种子时，同样的模型和数据可以得到同样的结果，便于回溯和对比。多线程求解时，各线程之间的协作时序每次不同，结果可能逐次不同。

还有一个容易忽略的条件：时间上限。求解器的时间上限可以按实际经过的秒数设置，也可以按求解器自己计量的「确定性时间」设置 [7]。如果求解在时间上限处被截断，按实际秒数计时的截断位置会受机器快慢和负载影响，即使单线程、固定种子，结果也可能不同；按确定性时间计时，或求解在上限之前自然结束，才不受这个影响。

模型可以替换。 由于大模型不在计算链路上，换用哪一款模型，影响的只是解说的文字质量，计划本身不受影响。

把可靠的部分和概率性的部分隔开。 经济学家阿格拉沃尔、甘斯和戈德法布在《权力与预测》里指出，把预测引进一个系统，会让系统从确定性变成概率性；一个决策牵动许多别的决策时，系统靠的是可靠，预测带来的不确定一旦传开，别处的安排都要跟着乱 [9]。书里给的一条应对是模块化：在用预测的那一部分周围设一道隔离，让它的变化传不到别处。排程要牵动采购、仓库和车间，我们把大模型放在外围、计算留在确定的程序里，就是这样一道隔离。

这样分工的代价和局限是什么？

这种分工有明确的代价，下面照实列出。

建模成本高。 每一类约束都要先说清楚、再写成数学形式。老师傅心里的经验，比如「这套模具上机前要先预热」「换深色料要清洗二十分钟」，必须先整理成明确的规则才能进入模型。一个新的行业、一种新的工艺，往往意味着新的约束要建模和验证。这部分工作量不会因为用了求解器而消失，反而要求比手工排产更精确。

求解需要时间，规模越大越难。 求解器能保证输出满足约束，但在给定时间内能把目标压到多低，要看问题规模和结构。工序和机台多到一定程度，在可接受的时限内往往只能拿到可行解，无法证明它已经做到头 [6]。常见的应对是把问题按订单或时间切成几段分别求解，这样能在时限内给出结果，代价是每一段只看到局部，段与段之间的配合不如整体求解。

可复现和求解质量之间要取舍。 CP-SAT 的文档写明，求解器按并行设计，单线程也能得到不错的解，多线程通常能得到更好的结果 [8]。而前面说过，严格可复现需要单线程。两者不可兼得时，需要按场合选择：需要回溯对比的场合用单线程加固定种子，日常排产可以用多线程，但要如实说明结果可能逐次不同。

高度依赖数据质量。 求解器会严格执行输入给它的数据。标准工时不准、物料清单缺项、机台兼容关系没维护，求解器会基于这些错误数据给出一张「满足约束」的错误计划。数据整理和持续校准，往往比求解本身更花功夫。

模型只知道写进去的东西。 某台机今天状态不稳，某位师傅特别擅长某类产品，客户私下同意可以晚两天，这些没有写进模型的信息，求解器一概不知。所以最终的拍板权留给人，计划下发后也要允许车间按现场情况调整并留痕。

解说本身也可能出错。 大模型负责的解说和问答同样可能说错或理解偏。应对的原则是：数字只从系统取，模型生成的文字与计算结果要区分开。这只能降低风险，不能消除风险。

引入约束排程，按什么顺序做？

结合前面说的好处和代价，我们建议按下面的顺序推进。

1. 列出约束清单。 把机台兼容、工序先后、工作日历、物料齐套、换型时间这些规则逐条写下来，每条注明数据从哪里来、由谁维护。模型只知道写进去的东西，漏写的规则，求解器不会替您补上。
2. 整理并校准基础数据。 核对标准工时、物料清单和机台兼容关系，先在一两条产线上把数据校准。求解器严格执行输入的数据，数据错了，得到的就是一张「满足约束」的错误计划。
3. 拿一段历史订单做回放。 选一段已经执行完的真实订单建模求解，把结果和当时的实际计划、实际完工对照。结果已知的数据，最适合用来发现漏掉的约束和不准的工时。
4. 定好求解设置。 需要回溯对比的场合，用单线程、固定随机种子，时间上限按确定性时间设置；日常整体排产可以用多线程，但要如实说明结果可能逐次不同 [7][8]。可复现和求解质量不可兼得，事先定下来，事后才说得清某一版计划是怎么来的。我们的排程产品 APSer-Aps 在急单重排时给出的几套方案，每套都用一个求解线程加固定随机种子求解。
5. 接上写入前复核和解说。 每一版计划写入系统前，按约束独立复核一遍；大模型只读取已经算好的结果做解说。生成和检查分开，数字从系统取，解说说错了也能拿系统里的数字对照纠正。
6. 小范围试运行，再逐步扩大。 先在一个车间或一类订单上用起来，采纳哪套方案由计划员拍板，车间的现场调整留下记录，再据此修正约束和数据。计划员对系统的信任，要在真实数据上一轮轮建立起来。

以下是我们的看法

以下内容是我们的观点，供您参考。

第一，在生产排程上，我们认为计划的价值首先在于可执行、可复核、改得动：急单来了能快速给出几套方案，每套方案的代价说得清，改完之后能确认没有违反任何硬约束。在这几件事上，确定性求解器已经是成熟、可检验的工具；大模型的价值更多体现在人与系统之间，让计划员更快看懂结果、更方便地提问。

第二，我们看重「生成方案」和「检查方案」分开。即使将来的研究表明大模型能更稳定地满足复杂约束，一套独立于生成方式的约束检查仍然有必要，因为车间按计划开工之后，违反约束的代价是停线、等料和误交期。到那时，分工可以重新评估，但检查这一环我们会保留。

第三，这套分工是针对排程这类约束严格、错一处牵动全局的问题得出的。对于其他类型的业务问题，大模型和确定性程序各自承担多少，要按问题本身的性质具体分析，不能照搬本文的结论。

第四，排程的难点有相当一部分在求解器之外：数据是否准确，现场经验能否说清楚，计划员是否信任并愿意使用系统。求解器解决的是「算得对」，其余几件事仍需要与使用方一起，在真实数据上一点点磨合。

我们的排程产品 APSer-Aps 按这个分工设计：排程内核自研，底层约束求解引擎采用 Google 开源 OR-Tools CP-SAT（Apache 2.0 许可）。

参考来源