规划推理系统在排产调度、物流路径和任务分配场景中，经常出现一个令人困惑的现象：模型里所有约束看起来都来自真实业务规则，求解器却在几毫秒内返回不可行，业务人员甚至能拿出人工调整后的可行方案。此时继续调整求解参数或增加搜索时间通常没有意义，真正的症结通常不在推理引擎，而在约束集合本身已经形成矛盾。解决这类问题需要从两个方向入手：一是快速定位冲突约束，二是重新设计资源分配中的硬约束与软约束边界。下面围绕约束建模、冲突诊断和分配松弛展开。
一、不可行首先来自硬约束的叠加冲突
规划推理中的不可行，指的是给定变量和约束之后，不存在任何一组变量赋值能够同时满足全部约束。业务系统中常见的约束可以归为三类：资源容量、时序依赖和任务分配唯一性。资源容量约束限制同一设备或人员在同一时段只能处理有限任务；时序依赖约束规定某些工序必须先后执行；分配唯一性约束保证一个任务只分配给一个执行主体。单独看每一条约束都很合理，但把它们同时放进模型后，却可能形成不可调和的矛盾。
典型的情况是：同一台设备容量为1，两个紧急任务都被硬性锁定在9点开始，且各自需要1小时。设备无法并行处理两个任务，模型自然无解。下面的代码用OR-Tools的CP-SAT建模了这个场景，两个区间变量都从9点开始，设备容量通过AddNoOverlap表示不能重叠。
from ortools.sat.python import cp_model model = cp_model.CpModel() a_start = model.NewIntVar(0, 23, 'a_start') a_dur = 1 a_end = model.NewIntVar(0, 23, 'a_end') a_interval = model.NewIntervalVar(a_start, a_dur, a_end, 'a_interval') b_start = model.NewIntVar(0, 23, 'b_start') b_dur = 1 b_end = model.NewIntVar(0, 23, 'b_end') b_interval = model.NewIntervalVar(b_start, b_dur, b_end, 'b_interval') model.Add(a_start == 9) model.Add(b_start == 9) model.AddNoOverlap([a_interval, b_interval]) solver = cp_model.CpSolver() status = solver.Solve(model) print(status == cp_model.FEASIBLE)
运行结果会稳定地输出False。这里的问题并不在于求解器找不到解，而是约束本身已经互相排斥。很多团队在此时会误以为算法能力不足，转向更复杂的元启发式方法，结果仍然是无效的。根本原因在于，业务偏好被错误地写成了硬约束。例如，业务方说希望某个任务当天完成，建模时就直接写成了end <= deadline，模型没有任何回旋余地。硬约束应当只用于物理极限、安全法规和不可更改的资源上限，而效率偏好、服务水平、交付时间等都应设计为软约束。
区分硬约束与软约束是修复不可行问题的第一步。硬约束必须无条件满足，软约束可以有偏差，但偏差会在目标函数中产生代价。把一条硬约束转换成软约束，模型就从是否存在可行解，变成了寻找代价最小的可行解。这样既保留了业务意图，又避免了模型直接返回不可行。
二、用约束传播和最小不可行子集暴露根因
当约束数量达到几百甚至上千条时，靠肉眼定位冲突几乎不可能。规划推理引擎通常会在搜索前进行约束传播，通过缩小变量取值范围来提前发现矛盾。例如，一个变量的取值域被压缩为空，就说明相关约束无法同时满足。约束传播本身能指出不可行结果，但不一定告诉用户具体是哪些约束在冲突。这时可以借助最小不可行子集，也就是MUS，它是一组互相矛盾的约束，去掉其中任意一条，剩余约束就能恢复可行。
下面使用Z3求解器演示如何获取不可行核。示例中有三个约束：第一个要求x大于1，第二个要求y小于0，第三个要求x加y等于0。这三个条件显然不能同时成立。通过assert_and_track为每个约束命名，并开启unsat_core，Z3可以输出冲突核。
from z3 import *
x = Int('x')
y = Int('y')
s = Solver()
s.set(unsat_core=True)
c1 = x > 1
c2 = y < 0
c3 = x + y == 0
s.assert_and_track(c1, 'c1')
s.assert_and_track(c2, 'c2')
s.assert_and_track(c3, 'c3')
print(s.check())
core = s.unsat_core()
print(core)
输出中会包含导致不可行的核心约束，通常为c1和c2。这是因为只要x大于1且y小于0，它们的和就不可能是0。这个例子虽然简单，但方法在真实模型中非常有效。拿到冲突核之后，开发人员可以集中检查这些约束对应的业务规则，判断哪一条应该被松弛或修正。
如果生产中使用的求解器不支持直接输出MUS，也可以采用增量添加约束的方式排查。先只加入资源容量约束，求解一次；再加入时序依赖，再求解一次；最后加入任务分配唯一性。一旦某一步模型从可行变为不可行，就说明新加入的约束组与已有约束存在冲突。接下来可以在该组内部继续二分排查，逐步缩小范围。
三、资源分配的核心手段：把硬约束改为可优化的软约束
定位到冲突之后，不建议直接删除约束。合理的做法是重新评估约束的性质，把部分硬约束改造成带有惩罚项的软约束。资源分配问题中，最常用的松弛手段有三种：容量弹性、时间窗柔性和优先级分层。
容量弹性适用于设备或人员的工作时间存在一定伸缩空间的场景。比如设备标准日工时为8小时，但实际上可以加班2小时。模型不需要把总工时严格限制在8小时以内，而是引入一个加班变量，让超出部分进入目标函数承担惩罚。下面代码展示了这种建模方式，三个任务总时长为9小时，超出标准容量1小时，求解器会返回加班量为1，并尽量减少惩罚。
from ortools.sat.python import cp_model
model = cp_model.CpModel()
tasks = [2, 3, 4]
total = sum(tasks)
overtime = model.NewIntVar(0, 2, 'overtime')
model.Add(total - 8 <= overtime)
model.Minimize(10 * overtime)
solver = cp_model.CpSolver()
status = solver.Solve(model)
if status == cp_model.OPTIMAL:
print(solver.Value(overtime))
时间窗柔性则把固定的开始时间改成可接受的范围。比如任务原定9点开始，可以扩展为9点到11点之间均可开始，越接近9点惩罚越小。这样设备冲突就有机会通过略微错开开始时间来解决。优先级分层则根据任务重要性不同，对高优先级任务保留硬约束，对低优先级任务使用违约惩罚变量，允许任务延迟或降级处理。三类手段可以组合使用，让模型在保业务底线的同时具备足够的搜索空间。
引入软约束后，规划推理不再是非此即彼的判断，而是输出带成本的方案。求解器返回的最优解可能包含少量加班、少量延迟或少量低优先级任务降级，但这些代价是显性的、可解释的。业务人员可以根据输出结果判断是否接受，而不是面对一个冷冰冰的不可行提示。
四、工程落地时不可行修复的检查流程
在实际项目中，不可行问题往往不完全是约束逻辑错误，还可能来自数据质量。排产数据中的空值、时间单位不一致、时区没有统一，都会在建模时转化成隐式冲突。例如某个任务持续时间字段为空，被默认成0，结果和另一个固定时间任务在区间变量上产生重叠。修复流程的第一步应当校验输入数据，确保所有任务时长、资源容量和时间窗字段都有合法值。
第二步是分模块构建模型。不要一次性把所有约束写入后直接求解，这样即使报不可行，也很难知道问题出在哪个模块。建议按照资源基础约束、任务需求约束、业务偏好约束的顺序依次添加，每一步都执行一次求解。某一步开始出现不可行时，问题必然集中在新加入的模块中。这种增量构建方式成本很低，却能显著缩小冲突范围。
第三步是保留不可行证明并推动规则调整。不同求解器在不可行时提供的信息量差异很大，有的可以直接输出冲突集，有的只能返回状态码。团队可以把每次不可行时涉及的约束编号和业务规则记录下来，形成约束冲突台账。对于频繁冲突的规则，应当推动业务方调整规则，或者将其从硬约束转为软约束。最终目标不是让模型无条件出解，而是让每一次不可行都能被解释、被修复，让规划推理从黑盒计算变成可信的决策支持。