资源容量校验：如何发现多项合作承诺的重复占用

在多方合作计划中，多项承诺可能依赖同一份设备、工时或库存。可能性发现的资源检查器 verify_k1_conservation 接收一个记录了资源来源、容量、承诺和分配量的账本，检查有效承诺是否有足量来源支持，并汇总同一来源的总分配量。它输出是否通过及具体冲突，供后续修改方案；它本身不寻找最优分配，也不安排时间表。

一台设备在某个确定的周期内还能提供十小时服务。方案甲需要六小时，方案乙也需要六小时。分别检查时，两个方案都没有超过十小时。把它们同时答应下来，设备却要工作十二小时。

问题出在检查的对象。逐条看承诺，我们只能看到“六小于十”；回到它们共同依赖的那台设备，才看见“六加六大于十”。多方合作中，这种重复占用不一定来自欺骗，也可能只是两份局部计划没有在同一处汇总。

可能性发现的资源检查器，为每一项有效承诺记录它用了哪份来源、用了多少。随后按来源合计，检查总量。这是一种很朴素的算法，但来源一旦明确，它能阻止一种自然语言审阅很容易漏掉的错误。

先给设备在这个周期里的可用额度一个明确编号，比如“设备 A，本周剩余额度”。容量记为十小时。方案甲和方案乙分别从这个编号分配六小时，而不是各自在说明里写一句“设备应该够用”。

检查器先看单条承诺。如果甲承诺提供六小时，但它列出的来源分配只有四小时，即使设备总量充足，这条承诺也少了两小时的依据。反过来，若列出八小时去支持六小时，账面同样不平衡。实现要求各来源分配之和与该条承诺的数量相等。

单条检查完成后，再把指向同一来源的分配放在一起：

合计超过容量，检查器会指出超配的来源，以及引用它的两条承诺。所以得到的不只是一个红色状态：修改方案的人知道该回头改哪两项承诺。在我们的研究代码里，凡是会让这项检查变红的改动都会被拒绝，账本保持原样。

如果乙改成四小时，合计变成十，数量检查就能通过。也可以给乙寻找另一台设备，或者明确增加原设备的可用额度。不过，检查器自己不会选择哪种修复，更不会替设备所有者答应延长工作时间。它负责把冲突定位到足够具体，供后续决策使用。

实现会检查来源是否已在账本里登记、资源类型是否相同、分配与承诺是否使用相同单位，以及承诺提供方是否控制这份来源。十小时不能拿十件库存支持，甲的设备也不能仅凭乙写进计划就变成乙可以支配的资源。

这些信息决定加法有没有意义。用符号表达，对每份来源 s，我们要求：

所有有效承诺从 s 分配的数量之和 ≤ s 的容量

同时，对每条承诺 e，要求：

e 列出的各来源分配之和 = e 承诺提供的数量

第一条防止同一份资源被重复用掉，第二条防止承诺的数量没有来源支撑。它们是两种不同错误：一条来源充分的承诺，可能与别的承诺争用资源；一个没有超配的账本，也可能仍有某条承诺没有获得足量分配。

资源分配、线性规划和网络流里，都能见到这样的容量约束。最大流问题要在每条线路的容量限制内，找出从一点能送到另一点的最大流量；这里的检查器接收已经提出的分配，核对它是否违反约束。最大流问题（Ford 与 Fulkerson，1956）

我们不需要把这一道汇总加法包装成新发明。它在本地系统中的作用，是让模型生成的方案接受明确数量关系的检查。模型可以提出“这两项应该能一起做”，但这句话不能把十二改成十。

“十小时”必须先有确定含义。若甲要用上午六小时，乙要用下午六小时，设备一天是否真有十二小时可用，需要另行定义。把乙减到四小时，合计十小时能通过数量检查；但如果两项任务都必须在同一个六小时窗口里完成，十小时的工作仍然排不下。

当前这项检查按来源编号汇总数量，不会自动排时间表。因此，教学例子把两项安排绑定到同一周期的十小时额度。需要处理时间冲突时，应让来源表达相应时间窗口，或接入调度约束。不能把总量通过当作排程通过。

来源身份同样重要。如果两份计划给同一台设备用了两个不同编号，各自都登记十小时容量，按编号汇总的程序可能看不出重复。这是登记与识别层要解决的问题；求和算法只能对输入中明确相同的来源进行合并。它也不会自行证明设备真的存在、可用时间真实，或者所有者愿意履行。

这些限制并没有让检查失去价值。它明确划出了一个能够机械回答的问题：对于已经登记、类型一致、身份明确的来源，当前有效承诺有没有在数量上相互冲突？这个问题一旦被稳定地回答，人和模型就可以把注意力放在真正需要协商的分配上。

本轮教学复算中，六加六触发超配，六加四通过这项检查。我们还没有据此测出真实项目的冲突下降率。当前获得的能力，是让重复许诺在成为执行事故之前，以具体来源和具体承诺的形式显现出来。

实现与证据。 资源来源与容量检查（实现定位保留于编辑档案）。函数名为 verify_k1_conservation，本文只解释其中来源支持与总容量核对的具体含义；数量使用 Decimal。十小时例子为教学构造，并非实际设备运营记录。通过这一项检查，不代表方案也通过了研究代码里的其他检查，例如每项承诺有没有获得授权、所需的预留是否到位、接收方有没有见证交付的安排。

更正（2026年10月26日）：初版有四处与研究代码或例子本身对不上。一是说检查出超配后，系统“还知道应当回到哪两项安排进行协商”，实际检查器只点名超配的来源和两项承诺，研究代码会拒绝让检查变红的改动，并不拿这份名单去协商；二是说实现会检查“来源是否存在”，实际查的是来源有没有在账本里登记；三是讲时间窗口的例子沿用了两项各六小时，合计十二小时本来就过不了总量检查，例子不成立，现在改成乙减到四小时之后的情形；四是把其他检查写成“授权与履行检查”，实际这些检查都在执行之前做，并不核对承诺后来有没有履行，现在改为列出实际有的几项。四处已在正文改正。

本篇另备有明亮、适合手机连续阅读的公众号排版稿，配图按照本文机制单独绘制。查看公众号版，或下载 Markdown、HTML、PNG 与 SVG 配图包。