Agent如何驱动生产排程
摘要
生产排程不是简单地按照交期对订单排序，而是一个同时受到设备能力、工艺路线、物料齐套、人员技能、设备日历、换型成本和交付要求影响的复杂组合优化问题。
AI Agent 可以帮助计划员理解异常、拆解任务、调用业务系统并解释排程结果，但仅依赖大语言模型，难以稳定保证设备不冲突、工序顺序正确以及全部硬约束得到满足。
更可靠的技术架构是：由 Agent 理解业务目标和组织决策流程，由业务本体统一描述订单、工艺、设备和物料之间的关系，由模型生成器将业务规则编译为数学约束，再由 MIP、CP-SAT 或启发式算法搜索可执行方案。
本文从系统架构、数据流、数学建模、算法选择、动态重排、结果验证和工程难点等方面，拆解一套“Agent + 业务本体 + 求解器”的生产排程实现方法。
适用读者
本文适合以下读者：
-
AI Agent 开发工程师
-
运筹优化算法工程师
-
APS、MES 和工业软件开发者
-
制造业数字化架构师
-
生产计划与调度系统技术负责人
一、为什么不能让大模型直接生成排程表
假设一家工厂收到三张生产订单：
| 订单 | 产品 | 数量 | 交期 |
|---|---|---|---|
| O1 | 产品A | 100 | 8月5日 |
| O2 | 产品B | 60 | 8月4日 |
| O3 | 产品A | 80 | 8月6日 |
产品需要经过不同工艺路线：
产品A：切割 -> 焊接 -> 喷涂 -> 检验
产品B：切割 -> 装配 -> 检验
排程时还要同时考虑：
-
同一台设备同一时间只能加工一个任务；
-
后一道工序必须等待前一道工序完成；
-
不同产品切换时可能产生换型时间；
-
部分设备存在维护和停机时间窗；
-
生产任务需要等待物料齐套；
-
某些工序只能由具备特定资质的人员执行；
-
紧急订单和关键客户订单具有更高优先级；
-
已经开工的任务通常不能随意迁移设备。
大语言模型可以根据经验生成一张“看起来合理”的排程表，但它难以严格保证：
-
所有设备均不存在时间冲突；
-
所有工序先后关系均正确；
-
工序与设备能力完全匹配；
-
物料、人员和设备日历约束均得到满足；
-
排程结果在数学模型意义上可行；
-
给定目标下的方案质量达到可接受水平。
因此，生产排程本质上不是文本生成问题，而是约束满足与组合优化问题。
更合适的分工是：
大语言模型：
理解自然语言
识别业务意图
拆解决策任务
选择和调用工具
解释方案与影响
求解器：
处理复杂约束
搜索可行方案
优化交期与成本
计算上下界
在条件允许时证明模型不可行
需要注意的是，只有当求解器明确返回 INFEASIBLE 时，才能认为当前模型不存在可行解。
如果求解器因为时间限制返回 UNKNOWN，只能说明在给定时间内没有找到可行解，也没有完成不可行性证明。
二、整体系统架构
一套完整的智能排程系统，可以划分为六个层次：
用户交互层
↓
Agent任务编排层
↓
业务本体与统一领域模型
↓
数据校验与模型生成层
↓
优化求解层
↓
验证、执行与反馈层
进一步展开：
┌────────────────────────────────┐
│ 用户输入 │
│ 插单、设备故障、交期提前、缺料 │
└───────────────┬────────────────┘
↓
┌────────────────────────────────┐
│ Agent任务编排层 │
│ 意图识别、实体解析、任务拆解 │
│ 工具选择、流程控制、结果解释 │
└───────────────┬────────────────┘
↓
┌────────────────────────────────┐
│ 业务本体与统一领域模型 │
│ 订单、订单行、产品、工艺、设备 │
│ 物料、人员、班次、排程任务 │
└───────────────┬────────────────┘
↓
┌────────────────────────────────┐
│ 数据校验与模型生成层 │
│ 数据映射、规则编译、变量生成 │
│ 约束生成、目标函数配置 │
└───────────────┬────────────────┘
↓
┌────────────────────────────────┐
│ 优化求解层 │
│ MIP、CP-SAT、启发式、局部搜索 │
└───────────────┬────────────────┘
↓
┌────────────────────────────────┐
│ 验证与执行层 │
│ 约束复核、影响分析、计划发布 │
│ MES下发、执行反馈、异常闭环 │
└────────────────────────────────┘
在这套架构中，Agent 不直接计算最终排程，而是负责组织整个决策过程。
三、业务本体如何描述生产世界
工业 Agent 面临的首要问题不是调用哪个接口，而是准确理解业务对象之间的关系。
生产排程涉及的核心实体通常包括：
Order 订单
OrderLine 订单行
Product 产品
ProductVersion 产品版本
ProcessRoute 工艺路线
Operation 工序
Machine 设备
MachineType 设备类型
Material 物料
Worker 人员
Skill 技能
Shift 班次
ScheduleTask 排程任务
实体之间可能具有以下关系：
Order -> contains -> OrderLine
OrderLine -> references -> Product
OrderLine -> specifies -> Quantity
ProductVersion -> uses -> ProcessRoute
ProcessRoute -> contains -> Operation
Operation -> executableOn -> MachineType
Operation -> consumes -> Material
Operation -> requiresSkill -> Skill
ScheduleTask -> assignedTo -> Machine
ScheduleTask -> belongsTo -> OrderLine
业务本体不只是字段映射，还应包含：
-
概念和分类；
-
实体之间的关系；
-
属性及其数据类型；
-
业务层级；
-
合法性约束；
-
可以推导出的业务语义。
例如，一台设备可以表示为：
{
"entity_type": "Machine",
"machine_id": "M-102",
"machine_type": "WeldingMachine",
"status": "AVAILABLE",
"capacity": 1,
"calendar_id": "SHIFT-A",
"supported_operations": [
"WELD-01",
"WELD-02"
]
}
经过统一领域模型和业务本体映射后，Agent 可以理解：
M-102 是一台焊接设备，目前处于可用状态，执行能力为 1，可执行 WELD-01 和 WELD-02 工序，并受到 SHIFT-A 设备日历约束。
这比让 Agent 直接理解不同系统中的数据库字段更加可靠。
四、生产排程系统的数据流
排程系统通常需要处理四类数据。
1. 主数据
包括：
-
产品和产品版本；
-
工艺路线；
-
工序定义；
-
设备和设备能力；
-
物料清单；
-
人员技能；
-
班次和设备日历。
2. 动态业务数据
包括：
-
销售订单；
-
生产订单；
-
当前库存；
-
采购到货时间；
-
在制品状态；
-
设备实时状态；
-
当前生产计划；
-
实际报工进度。
3. 优化配置
包括：
-
订单优先级；
-
目标权重；
-
计划冻结时间窗；
-
最大求解时间；
-
允许延期范围；
-
换型时间和成本；
-
外协和加班规则。
4. 求解结果
包括：
-
工序开始时间；
-
工序结束时间；
-
分配设备；
-
订单预计完成时间；
-
延期时间；
-
换型次数；
-
计划变更记录；
-
求解状态；
-
目标函数值；
-
最优性差距。
推荐的数据流如下：
ERP / MES / WMS / IoT
↓
系统适配与数据映射
↓
统一领域模型
↓
数据质量检查
↓
数学模型生成
↓
优化求解
↓
独立结果验证
↓
计划发布
↓
生产执行反馈
其中，数据质量检查不能省略。
典型检查包括：
订单是否存在有效工艺路线
每道工序是否存在可用设备
加工时间是否缺失或异常
工艺路线是否形成循环依赖
物料可用时间是否晚于开工时间
设备维护日历是否完整
已开工任务是否被错误修改
人员技能是否满足工序要求
如果输入数据本身存在冲突，求解器返回不可行并不意味着算法失效。
五、生产排程的数学建模
以下以柔性作业车间排程为例，说明基本建模方法。
1. 集合与参数
设：
-
$\mathcal{J}$：生产作业集合；
-
$\mathcal{O}_j$：作业 $j$ 的工序集合；
-
$\mathcal{M}$：设备集合；
-
$\mathcal{M}_{j,k}$：能够执行作业 $j$ 的工序 $k$ 的设备集合；
-
$p_{j,k,m}$：工序 $(j,k)$ 在设备 $m$ 上的加工时间；
-
$d_j$：作业 $j$ 的交期。
2. 决策变量
定义：
-
$x_{j,k,m}\in{0,1}$：工序 $(j,k)$ 是否分配给设备 $m$；
-
$S_{j,k}$：工序开始时间；
-
$C_{j,k}$：工序完成时间；
-
$C_j$：作业完成时间；
-
$T_j$：作业延期时间；
-
$C_{\max}$：最大完工时间。
3. 设备分配约束
每道工序必须分配到一台合法设备：
$$
\sum_{m\in\mathcal{M}{j,k}}x{j,k,m}=1
$$
4. 加工时间约束
工序完成时间等于开始时间加实际加工时间：
S_{j,k}
+
\sum_{m\in\mathcal{M}{j,k}}
p{j,k,m}x_{j,k,m}
$$
5. 工序先后约束
如果工序 $k+1$ 必须在工序 $k$ 完成后开始，则：
$$
S_{j,k+1}\ge C_{j,k}
$$
如果工艺路线是有向无环图，则应对每一条工序前驱边建立先后约束。
6. 设备互斥约束
同一台设备在同一时间不能加工两个任务。
对于两个任务 $i$ 和 $k$，定义：
-
$x_{i,m}=1$：任务 $i$ 分配给设备 $m$；
-
$x_{k,m}=1$：任务 $k$ 分配给设备 $m$；
-
$y_{i,k,m}=1$：当两个任务都在设备 $m$ 上执行时，任务 $i$ 排在任务 $k$ 之前。
可建立：
H(1-y_{i,k,m})
H(2-x_{i,m}-x_{k,m})
$$
Hy_{i,k,m}
H(2-x_{i,m}-x_{k,m})
$$
其中，$H$ 是排程时间的有效上界，例如规划周期长度。
$H$ 不能无限放大。过大的 Big-M 会削弱模型松弛并增加数值不稳定风险。
如果求解器支持指示约束，应优先考虑指示约束，而不是手工设置过大的 Big-M。
7. 作业完成时间
如果工艺路线是一条固定链，可以直接令：
$$
C_j=C_{j,k_j^{\mathrm{last}}}
$$
其中，$k_j^{\mathrm{last}}$ 是作业 $j$ 的最后一道工序。
如果作业包含并行分支，则可建立：
$$
C_j\ge C_{j,k},
\qquad
\forall k\in\mathcal{O}_j
$$
在目标函数中最小化作业完成时间或延期时间后，$C_j$ 会被压缩为所有相关工序完成时间的最大值。
8. 延期时间
延期时间定义为：
$$
T_j=\max(0,C_j-d_j)
$$
在 MIP 中，应线性化为：
$$
T_j\ge C_j-d_j
$$
$$
T_j\ge0
$$
9. 最大完工时间
建立：
$$
C_{\max}\ge C_j,
\qquad
\forall j\in\mathcal{J}
$$
10. 优化目标
常见目标包括：
-
最小化订单延期；
-
最小化最大完工时间；
-
最小化换型成本；
-
最小化计划变更；
-
最小化加班成本；
-
提高关键设备利用率。
组合目标可以写为：
$$
\min
\left(
\alpha C_{\max}
+
\beta\sum_{j\in\mathcal{J}}w_jT_j
+
\gamma\text{SetupCost}
+
\delta\text{ChangeCost}
\right)
$$
其中：
-
$w_j$：作业优先级；
-
$\text{SetupCost}$：序列相关换型成本；
-
$\text{ChangeCost}$：相对于原计划的变更成本。
实际项目中，不建议一开始就加入大量目标。
更稳妥的优先级是：
第一层：满足全部硬约束
第二层：保证关键订单交付
第三层：减少总体延期
第四层：降低换型和计划变更
第五层：优化设备利用率和能耗
当业务目标具有明确优先级时，分层优化或词典序优化通常比简单设置大量权重更容易解释。
六、使用CP-SAT表达排程约束
排程问题中存在大量时间区间和资源互斥约束，因此 CP-SAT 或约束规划通常具有较自然的表达方式。
核心思路是：
-
为每个任务创建开始时间和结束时间变量；
-
为每个候选设备创建一个可选区间变量；
-
使用布尔变量表示任务是否选择该设备；
-
对同一设备上的所有区间施加
NoOverlap； -
对同一任务的候选设备施加唯一选择约束。
伪代码如下：
model = CpModel()
for task in tasks:
start[task.id] = model.new_int_var(
0,
horizon,
f"start_{task.id}"
)
end[task.id] = model.new_int_var(
0,
horizon,
f"end_{task.id}"
)
candidate_assignments = []
for machine_id in task.compatible_machines:
assigned = model.new_bool_var(
f"assign_{task.id}_{machine_id}"
)
interval = model.new_optional_interval_var(
start[task.id],
task.processing_time[machine_id],
end[task.id],
assigned,
f"interval_{task.id}_{machine_id}"
)
assignment[task.id, machine_id] = assigned
machine_intervals[machine_id].append(interval)
candidate_assignments.append(assigned)
model.add_exactly_one(candidate_assignments)
for machine_id, intervals in machine_intervals.items():
model.add_no_overlap(intervals)
for predecessor, successor in precedence_relations:
model.add(
start[successor] >= end[predecessor]
)
这段代码主要用于说明建模结构，实际接口名称应以所使用的求解器版本为准。
CP-SAT 通常要求变量和系数采用整数表示。
如果加工时间或成本包含小数，需要先确定精度并进行缩放，例如将 1.5 小时转换为 90 分钟。
七、Agent如何把自然语言转成优化任务
假设计划员输入：
一号产线下午停机两小时，请优先保证客户甲的订单，尽量不要调整已经开始生产的任务。
Agent 需要完成多个步骤。
1. 意图识别
{
"intent": "RESCHEDULE",
"reason": "MACHINE_DOWNTIME",
"priority_customer": "客户甲",
"stability_requirement": "KEEP_STARTED_TASKS"
}
2. 实体解析
Agent 需要通过业务本体确认：
-
“一号产线”对应哪些设备；
-
“下午”对应哪个日期和时间范围；
-
“客户甲”对应哪些未完成订单；
-
哪些任务已经开工；
-
哪些任务处于计划冻结时间窗内。
结构化结果可以表示为：
{
"machine_group": "LINE-1",
"downtime_start": "2026-07-30T14:00:00",
"downtime_end": "2026-07-30T16:00:00",
"priority_customer_id": "CUSTOMER-A"
}
3. 业务规则映射
| 用户表达 | 模型处理 |
|---|---|
| 一号产线停机 | 增加设备不可用时间窗 |
| 优先保证客户甲 | 提高相关订单延期惩罚 |
| 不调整已开工任务 | 固定实际开始时间和当前设备 |
| 尽量少调整 | 增加计划变更成本 |
对于已开工任务，不应简单地固定原计划。
更准确的处理方式是：
-
固定实际开始时间；
-
固定当前设备；
-
根据报工进度更新剩余加工时间；
-
保留已完成部分；
-
除非业务允许，否则禁止中断或迁移。
4. 生成优化请求
{
"fixed_tasks": [
"TASK-001",
"TASK-002"
],
"machine_blackouts": [
{
"machine_group": "LINE-1",
"start": "2026-07-30T14:00:00",
"end": "2026-07-30T16:00:00"
}
],
"priority_weights": {
"CUSTOMER-A": 10,
"default": 1
},
"objectives": [
"MINIMIZE_WEIGHTED_TARDINESS",
"MINIMIZE_SCHEDULE_CHANGES"
]
}
5. 调用求解器
def handle_reschedule_request(user_input):
intent = agent.parse_intent(user_input)
entities = ontology.resolve_entities(
machine=intent.machine,
customer=intent.customer,
time_window=intent.time_window
)
current_schedule = schedule_service.load_current_schedule()
production_data = validator.validate_input(
entities=entities,
current_schedule=current_schedule
)
model = model_builder.build(
production_data=production_data,
fixed_tasks=intent.fixed_tasks,
blackouts=intent.machine_blackouts,
priorities=intent.priority_weights,
objectives=intent.objectives
)
result = solver.solve(
model=model,
time_limit_seconds=120
)
if result.status in {"OPTIMAL", "FEASIBLE"}:
verification = verifier.validate(result.schedule)
if not verification.is_valid:
raise InvalidScheduleError(
verification.errors
)
explanation = agent.explain_result(
result=result,
schedule_changes=result.schedule_changes,
objective_breakdown=result.objective_breakdown
)
return {
"status": result.status,
"schedule": result.schedule,
"explanation": explanation
}
if result.status == "INFEASIBLE":
diagnosis = infeasibility_analyzer.explain(
model
)
return {
"status": "INFEASIBLE",
"diagnosis": diagnosis
}
if result.status == "MODEL_INVALID":
raise ModelValidationError(
result.message
)
return {
"status": "UNKNOWN",
"message": "在给定时间内未找到可行解，也未证明模型不可行。"
}
八、求解算法应该如何选择
生产排程不存在适用于所有场景的单一算法。
1. 混合整数规划
适合以下场景：
-
目标函数以线性成本为主；
-
经济决策和排程决策需要统一建模；
-
需要最优界和最优性差距；
-
模型规模和求解时间允许精确优化。
优点：
-
数学表达统一；
-
易于加入成本、产能和库存约束；
-
可以计算上下界；
-
便于分析最优性差距。
局限：
-
大量设备顺序变量可能导致模型迅速膨胀；
-
Big-M 约束可能造成松弛较弱；
-
高精度时间离散可能显著增加规模。
2. 约束规划和CP-SAT
适合以下场景：
-
时间区间约束复杂；
-
设备资源互斥明显；
-
工序先后关系较多；
-
存在大量逻辑条件；
-
需要处理可选设备和可选工序。
优点：
-
区间变量适合表达排程；
-
NoOverlap等全局约束较自然； -
不需要为所有资源冲突手工构造 Big-M；
-
对复杂离散逻辑具有较强表达能力。
局限：
-
通常要求整数变量和整数系数；
-
与连续经济模型结合时可能不如 MIP 直接；
-
求解性能仍然高度依赖模型结构。
3. 启发式和局部搜索
适合以下场景：
-
任务规模较大；
-
需要秒级响应；
-
允许近似最优方案；
-
需要频繁进行动态重排。
常见方法包括：
-
遗传算法；
-
模拟退火；
-
禁忌搜索；
-
大邻域搜索；
-
变邻域搜索；
-
基于规则的构造算法。
优点：
-
可以快速得到可用方案；
-
邻域结构可以结合业务知识设计；
-
适合在线调度和局部修复。
局限：
-
很难证明最优；
-
参数较为敏感；
-
约束处理不当时容易产生大量不可行方案；
-
不同实例上的稳定性可能存在差异。
4. 混合求解架构
工业项目中更常见的是混合方案：
业务规则生成初始顺序
↓
启发式快速构造可行解
↓
CP-SAT或MIP进行局部优化
↓
大邻域搜索继续改进
机器学习也可以用于预测：
-
加工时间；
-
设备故障概率；
-
订单延期风险；
-
物料到货时间；
-
初始任务优先级。
但最终的资源分配和严格约束满足，仍应交给求解器完成。
求解器选择不能只依据任务数量，还取决于：
-
变量类型；
-
约束结构；
-
时间精度；
-
模型松弛强度；
-
初始解质量；
-
动态重排范围；
-
可接受求解时间。
同样规模的问题，采用不同建模方法，求解难度可能相差很大。
九、动态重排中的计划稳定性
很多排程系统只关注新方案是否更优，却忽略了计划变更带来的执行成本。
如果原计划已经发布，设备、人员和物料通常已经按照原计划准备。
此时，即使新方案在数学上略优，大规模调整也可能导致：
-
人员频繁切换任务；
-
物料配送计划失效；
-
设备准备工作被打乱；
-
现场执行人员难以适应；
-
MES 中出现大量任务撤销和重发。
因此，动态重排需要增加计划稳定性目标。
设任务 $i$ 在原计划中的开始时间为 $S_i^0$，新计划中的开始时间为 $S_i$。
定义辅助变量 $u_i\ge0$：
$$
u_i\ge S_i-S_i^0
$$
$$
u_i\ge S_i^0-S_i
$$
则时间变更成本为：
\sum_i w_i^{\mathrm{change}}u_i
$$
如果任务 $i$ 原来分配给设备 $m_i^0$，设备变更成本可以表示为：
\sum_i
c_i
\left(
1-x_{i,m_i^0}
\right)
$$
最终目标可以写为：
$$
\min
\left(
\alpha\sum_jw_jT_j
+
\beta\text{ChangeCost}
+
\gamma\text{MachineChange}
\right)
$$
还可以设置分层冻结时间窗：
当前时间至未来2小时：
完全冻结，不允许调整
未来2至8小时：
原则上保持稳定，仅允许局部调整
8小时以后：
允许进行较大范围优化
这比每次发生异常后都从零开始重新排程更符合实际生产环境。
十、结果验证不能依赖求解器模型本身
求解器返回结果后，不应直接下发到 MES。
原因是求解器只能保证结果满足已经写入模型的约束。
如果模型漏掉某项业务规则，求解结果仍可能无法执行。
因此，需要建设独立结果验证层。
def verify_schedule(schedule):
errors = []
errors.extend(
check_machine_overlap(schedule)
)
errors.extend(
check_operation_precedence(schedule)
)
errors.extend(
check_machine_compatibility(schedule)
)
errors.extend(
check_material_availability(schedule)
)
errors.extend(
check_worker_skill(schedule)
)
errors.extend(
check_machine_calendar(schedule)
)
errors.extend(
check_frozen_tasks(schedule)
)
return errors
验证内容包括：
-
设备是否发生时间重叠；
-
工序前后关系是否正确；
-
工序与设备能力是否匹配；
-
物料是否在开工前可用；
-
人员技能是否满足要求；
-
任务是否落在设备可用日历内；
-
已冻结任务是否被修改；
-
已开工任务是否被非法迁移。
十一、不可行问题如何诊断
生产数据中经常存在相互冲突的条件，例如：
-
唯一可用设备正在维护；
-
订单交期早于物料到货时间；
-
某道工序没有合法设备；
-
已冻结计划与新停机约束冲突；
-
所有可用人员均不具备所需技能。
系统需要区分：
模型构造错误
输入数据错误
业务规则冲突
真实业务不可行
求解时间不足
推荐的诊断流程是：
求解器确认模型不可行
↓
调用IIS或冲突分析能力
↓
若不支持，则执行分组约束放松
↓
将冲突约束映射为业务对象
↓
生成可解释的修复建议
需要注意：
-
逐组关闭约束只能视为启发式诊断；
-
找到的一组冲突约束不一定是唯一冲突；
-
修复一组冲突后，模型中仍可能存在其他冲突。
最终应向业务人员输出可理解的解释，例如：
订单O102无法在8月3日12:00前完成。
主要冲突：
1. 关键物料预计8月3日15:00到货；
2. 唯一可用设备8月3日上午处于维护状态；
3. 订单要求8月3日12:00前完成。
可选方案：
- 提前关键物料到货时间；
- 启用替代设备；
- 放宽订单交期；
- 允许部分工序委外生产。
十二、求解时间应该如何控制
工业系统通常不能无限等待全局最优解。
更合理的做法是采用分阶段求解策略：
第一阶段：
以快速找到可行解为目标
第二阶段：
重点改善订单延期和最大完工时间
第三阶段：
继续优化换型、稳定性和设备利用率
达到时间上限：
返回当前已找到的最好可行解
不能写成“5 秒内一定找到可行解”，因为任何求解器都无法对任意实例作出这种保证。
系统应记录：
-
求解状态；
-
当前最好目标值；
-
最优下界；
-
最优性差距；
-
求解耗时；
-
终止原因；
-
是否使用了初始解；
-
是否触发降级策略。
如果在时间上限内没有找到可行解，应返回 UNKNOWN，而不是直接判断模型不可行。
十三、大规模动态重排如何缩小问题范围
设备发生故障后，没有必要重新计算整个工厂的所有订单。
可以只选择受影响的任务集合：
-
故障设备上的未完成任务；
-
这些任务的后续工序；
-
同一资源池中的替代设备；
-
与受影响任务竞争资源的任务；
-
冻结时间窗以外的任务。
局部重排流程可以表示为：
识别异常设备
↓
查找直接受影响任务
↓
沿工艺关系扩展后续任务
↓
查找替代设备及竞争任务
↓
构造局部优化子问题
↓
与未调整计划重新合并
这种方法可以降低模型规模，并减少新方案对现场执行的扰动。
十四、工程实现中的关键难点
1. 模型生成可靠性
不建议让大语言模型自由生成完整求解器代码。
主要风险包括：
-
漏掉关键约束；
-
使用错误变量；
-
索引维度不一致；
-
误解业务规则；
-
不同调用生成不同模型。
更稳妥的方案是采用约束模板注册机制：
CONSTRAINT_REGISTRY = {
"machine_assignment": build_machine_assignment,
"machine_no_overlap": build_machine_no_overlap,
"operation_precedence": build_precedence,
"machine_calendar": build_machine_calendar,
"material_availability": build_material_constraint,
"frozen_task": build_frozen_task_constraint,
"due_date": build_due_date_constraint
}
Agent 负责决定：
-
启用哪些约束；
-
约束作用于哪些业务对象；
-
参数取值是什么；
-
目标优先级如何配置。
底层变量和约束仍由经过测试的模板生成。
2. 数据版本一致性
排程求解可能持续几十秒或几分钟。
在求解期间，MES、WMS 或设备系统中的数据可能发生变化。
因此，需要记录：
-
输入数据版本；
-
库存快照时间；
-
设备状态快照时间；
-
当前计划版本；
-
模型版本；
-
业务规则版本。
求解完成后，应检查关键数据是否已经发生变化。
若发生变化，应根据影响范围决定：
-
直接丢弃结果；
-
局部修正；
-
重新求解；
-
人工确认后发布。
3. 结果可解释性
Agent 不应只返回甘特图，还应说明：
-
哪些任务发生变化；
-
为什么发生变化；
-
哪些订单受到影响；
-
交期、换型和设备利用率之间如何取舍；
-
是否存在未解决风险。
例如：
由于设备M3在14:00至16:00停机，
原计划中的3项焊接任务被调整。
调整结果：
- 客户甲订单仍按原交期完成；
- 两张普通订单分别延后40分钟和65分钟；
- 已开工任务未发生迁移；
- 总换型次数增加1次；
- 一号产线最终完工时间延长50分钟。
4. 人工修改闭环
计划员可能对求解结果进行人工调整。
系统应记录：
-
被修改的任务；
-
修改前后时间；
-
修改前后设备；
-
修改原因；
-
修改人；
-
是否导致其他约束风险。
这些数据可以帮助系统逐步识别真实业务偏好。
十五、算法自进化可以发生在哪些环节
算法自进化不等于让大模型自动重写整个求解器。
在工业系统中，更现实的自进化主要发生在以下方面。
1. 参数自适应
根据历史实例自动选择：
-
求解时间；
-
搜索策略；
-
邻域大小；
-
初始解生成方式；
-
启发式参数。
2. 模型和算法选择
根据实例特征选择：
线性经济约束较多：
优先考虑MIP
时间区间和资源互斥复杂：
优先考虑CP-SAT
大规模实时重排：
优先考虑启发式或大邻域搜索
生产、库存和物流联合优化：
考虑分解算法或混合求解
3. 初始解学习
从历史优秀排程中学习：
-
订单排序；
-
设备分配；
-
工序优先级；
-
换型分组；
-
瓶颈设备保护策略。
学习模型不直接决定最终方案，而是为求解器提供初始解或搜索提示。
4. 目标偏好校准
如果计划员经常牺牲少量设备利用率来减少计划变更，系统可以逐步提高稳定性目标的重要程度。
但目标权重变化应受到：
-
上下限约束；
-
人工审批；
-
版本管理；
-
离线回放测试。
5. 算法组合选择
系统可以根据实例自动选择：
规则构造 + MIP优化
规则构造 + CP-SAT优化
历史方案 + 局部搜索
分区求解 + 全局协调
预测模型 + 约束优化
这种受控的策略选择，比让大模型自由生成算法代码更加稳定。
十六、常见误区
误区一：让大模型直接输出排程表
大模型生成的结果无法天然保证资源互斥、工序顺序和设备能力约束。
大模型更适合生成结构化决策请求和业务解释。
误区二：Agent就是固定工作流
固定工作流按照预设步骤执行。
工业 Agent 还需要根据数据和求解状态动态选择下一步：
数据缺失 -> 请求补充或使用降级数据
模型不可行 -> 启动冲突诊断
结果质量较低 -> 调整求解策略
设备故障 -> 启动局部重排
关键数据变化 -> 重新构造模型
误区三：目标函数越多越好
目标过多会导致：
-
权重难以解释；
-
目标相互冲突；
-
调参成本上升；
-
方案表现不稳定。
应明确区分：
硬约束
一级目标
二级目标
偏好项
误区四：求解器返回结果就是正确结果
求解器只保证结果满足模型中的约束。
如果模型遗漏业务规则，结果仍可能无法执行。
因此，必须建设独立验证层。
误区五：数学最优等于业务最优
数学目标更优的方案，不一定更适合现场执行。
还需要考虑：
-
计划稳定性；
-
人员接受程度；
-
数据可信度；
-
现场操作习惯；
-
计划变更成本；
-
业务风险偏好。
十七、一个可落地的最小版本
首次建设智能排程系统时，可以从最小闭环开始。
第一阶段：统一基础数据
先接入：
-
生产订单；
-
工艺路线；
-
设备；
-
加工时间；
-
设备日历；
-
当前计划。
不要一开始就接入全部工业系统。
第二阶段：实现核心硬约束
先支持：
-
设备唯一分配；
-
工序先后关系；
-
设备资源互斥；
-
设备可用日历；
-
交期；
-
已开工任务固定；
-
冻结时间窗。
第三阶段：选择单一主要目标
可以先从以下目标开始：
最小化加权订单延期
暂时不加入过多换型、能耗和设备利用率目标。
第四阶段：加入Agent交互
支持计划员询问：
为什么订单A会延期？
设备M1故障后需要调整哪些任务？
优先保证客户B会影响哪些订单？
怎样减少本次调整的换型次数？
第五阶段：建立执行反馈
记录：
-
实际开始时间；
-
实际结束时间；
-
实际加工时长；
-
设备异常；
-
人工计划修改；
-
订单实际交付结果。
形成：
业务数据
↓
排程求解
↓
生产执行
↓
结果反馈
↓
参数和策略优化
总结
AI Agent 在生产排程中的核心价值，不是替代数学求解器，而是连接用户、业务数据、业务语义和优化算法。
一套可靠的智能排程系统，应形成清晰分工：
Agent：
理解目标、拆解任务、调用工具、解释结果
业务本体：
统一订单、产品、工艺、设备和物料语义
模型生成器：
将业务规则转换为变量、约束和目标
求解器：
搜索可行方案并优化结果
验证器：
独立检查资源冲突和业务规则
执行系统：
发布计划并反馈实际生产结果
真正可落地的工业 Agent，不应只做到“调用一次 APS 接口”，还应进一步具备：
-
理解当前生产环境；
-
判断异常影响范围；
-
构造结构化优化任务；
-
选择合适的建模和求解策略；
-
区分可行、不可行和求解超时；
-
验证方案能否实际执行；
-
解释方案中的业务取舍；
-
根据执行结果持续优化。
从系统架构上看，智能排程不是一个单纯的大模型应用，而是由 Agent、业务本体、数学模型、优化求解器和工业执行系统共同构成的决策闭环。
中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。
更多推荐
19
0- 0
已为社区贡献1条内容
所有评论(0)