Optaplanner基于ProblemFactCollectionProperty的动态规划变量卡车派单求解咨询

场景适配性说明 #

你描述的是典型的**多趟次VRP（Multi-trip VRP, MT-VRP）**场景，OptaPlanner官方没有提供开箱即用的示例，但框架本身完全支持该场景的落地，无需对核心逻辑做二次改造。
你提到的「官方示例均固定规划变量数量」是OptaPlanner的现有特性限制：求解过程中不支持动态增减规划实体，所有规划实体必须在求解启动前完成初始化，因此所有公开示例都会提前确定规划变量的数量边界。

你的思路可行性评估 #

你提出的「预计算最大行程数+硬约束过滤无效行程」是目前OptaPlanner生态下的标准可行解法，不存在原理性问题，调整几个细节即可达到生产可用水平：

• 预计算的最大行程数不需要完全精准，取理论上限的1.1~1.5倍冗余值即可（理论上限=单卡车司机最长工作时长/最短单趟往返时长，向上取整），多余的空行程会被硬约束自动判定为无效，求解器不会分配客户到这些行程上，仅会带来可接受范围内的性能损耗
• 不需要将「最大行程数」本身设置为规划变量，只需要将行程设为规划实体、「行程绑定的卡车」设为规划变量即可，变量设计更简洁，求解效率更高

推荐优化实现方案 #

可以基于标准VRP的链式规划结构做少量调整即可适配：

1. 核心实体定义
   • Truck：问题事实，存储卡车载重上限、司机可用时长、最早出勤时间等固定属性
   • Trip：规划实体，关联所属卡车，用影子变量自动计算单趟的总载重、出发/返回时间
   • Customer：规划实体，通过链式规划变量绑定所属行程的停靠顺序
2. 约束配置（用ConstraintProvider实现）
   • 硬约束1：单趟Trip的总载重不超过所属卡车的载重上限
   • 硬约束2：单辆卡车关联的所有Trip总耗时（含往返仓库时间、行程间隔）不超过司机可用时长
   • 硬约束3：所有待配送客户必须被分配到有效行程中（若允许部分客户延后配送可调整为软约束）
   • 软约束1：所有行程的总行驶里程最短
   • 软约束2：空行程数量最少，降低资源浪费
3. 初始化逻辑
   预生成所有卡车的理论最大行程总数的空Trip实例，作为初始规划实体传入求解器即可。

内容的提问来源于stack exchange，提问作者user2697026