评测集扩容，竟让健康 Agent 被隔离

我的漂移检测器隔离了一个正常的 Agent。Agent 并没有变差，只是基准测试规模变大了。检测器比较的是不同测试集版本中的失败次数，因此，当基准测试从 10 个任务扩展到 20 个时，一个原本 10/10 全部通过的 Agent，看起来就像有一半测试“失败”了。测试集的扩充，被误判成了能力衰退。

我为 HivePlane v0.2.0 构建了这个漂移检测器，用来捕捉我在 v0.1.0 中写过的一种失效模式：“危险的 Agent 通常是发生了漂移，而不是被人修改了。”结果发现，更难的问题并不是检测漂移，而是不把不存在的漂移检测出来。一个总喊“狼来了”的检测器，会让运维人员逐渐学会忽略告警信号，而一个被忽略的门禁，也就失去了门禁的作用。

吞掉自身基准的检测器

这次发布中最令人后怕的，并不是漏掉了一次漂移，而是一个正常的 Agent 被隔离了，原因是检测器拿它与一个已经不存在的基准进行比较。

被误判为能力衰退的基准扩充

Agent 并没有变差，只是基准测试规模变大了。检测器分不清这两者，于是隔离了一个完全正常的 Agent。

修复方式是：在可比较的测试集上，以 Agent 自身的基线衡量漂移。重新评估时，应该比较相同任务上的表现，而不是不同的计数。测试集版本发生变化，意味着需要建立新的基线，而不是出现了漂移信号。扩大基准测试规模是扩充，不是回归。

提示：如果你的漂移指标是一个计数，那么基准测试的变化就会看起来像行为变化。应该比较 Agent 自身在相同任务上的表现，否则，任何测试集修改都可能导致误隔离。

拒绝解除自身隔离的恢复流程

F-13 暴露了隔离与恢复流程之间的不对称。漂移触发自动隔离后，认证状态会被重置为 UNCERTIFIED，而不是 QUARANTINED。但恢复流程要求 status == QUARANTINED。于是，执行隔离的门禁，却拒绝解除自己施加的隔离。一个工作负载可能被自动隔离后就再也无法恢复，因为恢复的前置条件要求的是一个检测器从未设置过的状态。

修复方式是移除这个过时的前置条件。只要存在有效的隔离记录，就可以执行恢复：重新认证工作负载，并重新检查准入条件。状态字段不是事实依据，隔离记录才是。门禁判断时用错了依据。

实地测试在场景 S5 中发现了这个问题：按顺序执行时，S4 触发自动隔离，随后 S5 的恢复操作失败了。两个场景，一个 bug，教训是：判断“是否处于隔离状态”的事实依据，应该是隔离记录，而不是认证状态枚举。

嗅不出能力衰退的探针

探针的职责，是在漂移达到阈值之前发现能力衰退。如果探针只检查“有没有运行”，就无法发现“运行得对不对”。修复方式是：runner 启动运行，等待运行进入终态，再将输出与预期结果进行比较。如果不匹配，探针检查就会失败，并产生 probe.decay 警告。这样，探针就能嗅出漂移检测器尚未测量到的能力衰退。

控制误报是产品的核心能力，不是锦上添花：单次运行超出阈值只应触发警告，隔离则需要连续 N 次失败，或者出现强信号——绝不能因为噪声就隔离一个稳定的 Agent。衡量漂移时，要使用可比较的基线：相同的任务、相同的测试集版本；测试集版本升级意味着建立新基线，而不是发生回归。隔离记录才是事实依据，状态枚举不是——恢复流程必须依据隔离记录，否则，它就会拒绝解除本应解除的隔离。探针还必须断言输出是否符合预期，而不只是检查运行是否获准执行——存活不等于就绪。

v0.2.0 的实地测试通过 S4、S5、S8 和 S24 场景，演示了完整闭环：漂移检查到期、评估、探测、自动隔离，以及重新认证后的恢复。在 S24 中，合成探针在漂移达到阈值之前就标记出了能力衰退。完整证据见实地测试报告；认证和学习闭环的设计，分别见认证 v2 设计和学习闭环设计。

HivePlane — pip install hiveplane==0.2.0

实地测试报告（36/36）

认证 v2 设计 · 学习闭环设计

运维手册——漂移与隔离

你的检测器上一次隔离正常对象，是什么时候？如果运维人员已经养成了不看原因就直接恢复的习惯，那么你的检测器就不再是一项控制措施，而只剩下一个走过场的勾选框。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。