OptaPlanner VRP场景：能否用模拟选择移动关联规划实体？

我目前正在使用OptaPlanner解决带取送货、时间窗的车辆路径规划问题（VRP）。待配送的货物由两个LoadJob组成：

@DeepPlanningClone
class Load {
    lateinit var pickup: LoadJob
        private set
    lateinit var dropoff: LoadJob
        private set
}

LoadJob是规划实体，包含可执行的时间窗和执行地点Location：

@PlanningEntity
class LoadJob {
    lateinit var load: Load
        private set
    lateinit var timeWindow: Interval
        private set
    lateinit var location: Location
        private set
}

除LoadJob自身的时间约束外，Location还有开放时间，仅在此期间可执行LoadJob。LoadJob被分配到Vehicle组成运输路线，且每个取货操作必须在对应的送货操作之前完成：

@PlanningEntity
class Vehicle {
    @PlanningListVariable lateinit var tour: MutableList<LoadJob>
}

当将某个取货LoadJob移至另一车辆时，对应的送货LoadJob也应同步移动。目前我已参考Geoffrey的旧VRP实验代码实现了自定义MoveIteratorFactory，用于生成符合该约束的CompositeMove。请问：

1. 能否通过模拟选择（mimic selection）实现该需求，例如配置：

<entitySelector mimicSelectorRef="entitySelector"/>
<valueSelector variableName="load.dropoff"/>

2. 若不能，自定义MoveIteratorFactory是否为正确方案？若是，该旧实现存在哪些风险，在OptaPlanner或Timefold新版本中有何缓解方法？

关于模拟选择的可行性 #

不能通过这种模拟选择配置实现需求。模拟选择的核心是让一个选择器复制另一个选择器的选择结果，但你的场景需要的是关联操作：选中取货LoadJob时，必须同步选中对应的送货LoadJob并执行联动移动。而模拟选择无法直接构建这种关联的CompositeMove，它只能复制选择对象，无法自动生成包含两个关联实体的复合移动。

自定义MoveIteratorFactory的正确性与风险缓解 #

正确性确认 #

自定义MoveIteratorFactory是实现该需求的正确方案，因为它允许你完全控制移动的生成逻辑，确保取货和送货LoadJob的移动始终同步，避免违反“取货必须在送货前完成”的硬约束。

旧实现的风险 #

• 性能瓶颈：旧代码可能未针对大规模场景做优化，比如缺少批量生成、缓存或高效迭代逻辑，导致求解速度随问题规模扩大急剧下降。
• 兼容性问题：旧代码基于早期OptaPlanner版本，新版本中Move、MoveIteratorFactory的API可能发生变化，直接复用会出现编译或运行时错误。
• 移动有效性校验缺失：旧实现可能未充分校验移动后的状态合法性（比如送货操作是否仍在取货之后、是否符合地点开放时间等），导致生成无效移动，浪费求解资源。
• 搜索空间受限：如果移动生成逻辑过于单一，会限制求解器的搜索范围，难以找到最优解。

OptaPlanner/Timefold新版本的缓解方法 #

• 利用内置关联移动支持：在Timefold或新版OptaPlanner中，可结合@PlanningPin或自定义MoveFilter实现批量联动移动，无需完全从头实现MoveIteratorFactory。
• 优化迭代逻辑：使用新版本提供的MoveListFactory或流式API批量生成合法移动，提升性能。
• API适配：参考新版本官方文档，将旧代码的API调用适配为当前版本规范（比如MoveIteratorFactory的方法签名变化），确保兼容性。
• 内置约束校验：借助求解器的约束流（Constraint Streams）实时校验移动合法性，过滤无效移动，减少不必要的计算。
• 丰富移动类型：结合内置移动类型（如ChangeMove、SwapMove）与自定义复合移动，拓展搜索空间，提升求解质量。

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