（我还在math.stackexchange.com上发布了这个问题，因为我不确定它应该属于哪里。）
我有一个具有以下输入的系统：
- 要完成的工作项目集。这些是可变大小的。它们不必按任何特定顺序完成。
- 有关过去完成工作项所需时间的历史数据。然而，过去的表现并不能保证未来的成功！也就是说，一旦我们开始实际执行一个工作项，我们可能会发现它比以前花费的时间更长或更短。
- 可能有我以前从未见过的工作项目，因此没有历史数据。
- 工作项进一步具有“并行”或“串行”的“分类”。
- 一组能够拾取工作项并对其进行处理的“代理”。代理的数量是固定的并且是预先知道的。代理一次只能处理一个工作项。
- 代理对其执行工作项的一组“服务器”。服务器具有不同的功能。具体来说，它们能够同时处理不同数量的代理。
规则：
- 如果服务器正在用于执行“串行”工作项，则它不能同时用于执行任何其他工作项。
- 如果服务器不用于执行任何“串行”工作项，它可以同时处理尽可能多的代理，所有代理都执行“并行”工作项。
- 有一些工作项必须针对特定服务器执行（尽管任何代理都可以这样做）。如果重要的话，这些工作项是“并行的”。（现在可能更容易忽略此规则！）
要求：
鉴于上述输入和规则，我需要“尽快”执行这组工作项。由于我们不知道一个工作项需要多长时间才能完成，我们不可能希望预先得出一个完美的解决方案（我想），所以“尽可能快”意味着不要像只使用一个代理那样明显地做一些愚蠢的事情一个一个地执行每个工作项！
从历史上看，我有一个非常简单的循环算法，并简单地按历史持续时间降序对工作项进行排序，以便更快地安排运行时间最长的工作项，并且希望在周期结束时我能够保留所有代理和服务器相当好地加载了短期工作项。这导致利用率图呈现出非常好的“方形”形状，在周期结束时没有长期工作项的长尾。
然而，这种历史算法要求我预先配置代理和服务器的数量，并将工作项预先分配给“池”，并将池分配给服务器，以及许多其他可怕的东西。我现在需要支持动态数量的代理和服务器，而无需重新配置。（请注意，在一个周期内服务器的数量是固定的——即数量只会在周期之间变化——但代理的数量可能会在周期的中间增加或减少。）
完成所有工作项后，我们会记录每个工作项进入下一个周期并从头开始重新开始的时间！