漂移检测器的误报危机：HivePlane v0.2.0 的三个教训

在构建 AI Agent 可靠性保障体系时，漂移检测（Drift Detection）常被视为核心防线。但 HivePlane 项目作者在 v0.2.0 版本中揭示了一个反直觉的困境：一个会「狼来了」的检测器，比没有检测器更糟糕。因为每一次误报都会训练运维人员忽略信号，而一个被忽视的闸门，就不再是闸门。

当基准集变大被误判为能力衰减

HivePlane v0.2.0 的漂移检测器最初的设计是：对比智能体在不同语料版本上的失败计数。问题在于，当学习循环纳入一个经过审核的新用例，基准集从 10 个任务增长到 20 个时，一个原本 10/10 全通过的智能体，在新的计数方式下突然显示「失败 10 次」。作者在发布报告中写道：「智能体并没有变差，是基准集变大了。」

检测器无法区分「语料增长」与「能力衰退」，于是一个完全健康的智能体被自动隔离。这个发现编号为 #530，它改变了整个团队对漂移基线的认知。

修复方案是：漂移必须基于智能体自身在可比语料上的基线来衡量。比较的是同一批任务在不同复评中的表现，而不是不同规模语料上的失败计数。语料版本变更建立的是新基线，而不是漂移信号。基准集扩大是成长，不是回归。

漂移检测（Drift Detection） 在机器学习与 AI 运维语境中，指的是持续监控模型或智能体行为分布是否偏离既定基线的过程。传统做法是比较固定数据集上的评估指标随时间的变化，但这一范式隐含一个假设：评估集本身是稳定的。一旦评估集动态增长（例如持续纳入新审核用例），失败计数等绝对量指标就会失真。更稳健的做法是采用可比基线——在同一批任务、同一语料版本上重复评估，只比较同一集合内的前后差异。基线更新（如语料版本升级）应视为重置参照系，而非漂移事件。这也解释了为什么许多生产级监控系统会区分「数据漂移」「概念漂移」与「评估集变更」，只有前两者才应触发告警。

恢复机制拒绝了自己的隔离令

第二个问题（编号 F-13）更富讽刺意味。漂移自动隔离会将认证状态重置为 UNCERTIFIED，而不是 QUARANTINED。但恢复逻辑要求 status == QUARANTINED 才能执行。结果就是：创建隔离的闸门，拒绝解除隔离。一个工作负载可以被自动隔离，却永远无法恢复，因为前置条件描述的是一个检测器从未设置的状态。

修复方式是移除过时前置条件。恢复逻辑改为检查活跃的隔离记录，而非认证状态枚举——隔离记录才是「是否被隔离」的真相来源。这个缺陷在场景 S5 中被现场测试捕获，紧随 S4 的自动隔离之后。

状态枚举（Status Enum） 与 事件记录（Event Record） 是状态管理中两种常见的真相来源模型。状态枚举把当前状态压缩为一个字段值（如 UNCERTIFIED、QUARANTINED），简洁但容易与历史脱节；事件记录则保留每一次状态变更的完整轨迹，查询时通过聚合推导当前状态。本案例中，漂移检测器写入的是认证状态字段，恢复逻辑却读取隔离状态枚举，两者语义不一致导致「隔离令无人认领」。以隔离记录为真相来源，意味着任何写入隔离的路径都会留下可被恢复逻辑识别的记录，从而避免状态机出现不可达分支。这一模式在分布式系统与工作流引擎中被称为「以日志为中心的状态管理」。

探针无法嗅到衰减信号

第三个问题（#609 / S24）最为隐蔽。合成探针运行器忽略了 Spec.expected 字段，只检查运行是否被准入。这意味着探针只有在运行被拒绝时才会失败，它永远无法标记「智能体运行了但给出了错误答案」。作者对此有一个精辟的论断：探针是活探针，不是就绪探针。

探针的职责是在漂移阈值触发之前捕捉衰减。如果探针只检查「是否运行」，它就无法发现「运行是否正确」。修复后，探针会启动运行、等待终止，并将输出与 expected 比对。不匹配会触发 probe.decay 警告，此时探针就能比漂移检测器更早嗅到衰减。

就绪探针（Readiness Probe） 与 活探针（Liveness Probe） 源自 Kubernetes 的健康检查语义：就绪探针判断容器是否可以接收流量，活探针判断容器是否仍在运行。二者都只回答「能不能用」，不回答「用得对不对」。在 AI Agent 场景中，这远远不够——智能体可能正常运行却输出错误答案。因此需要第三类探针：断言探针（Assertion Probe），它会执行一次完整推理并比对 Spec.expected 字段。只有当探针具备输出断言能力时，才能在漂移阈值触发前捕捉到语义层面的衰减信号。这也是「活探针不是就绪探针」这一论断的技术根基：健康检查的层次必须与系统失效模式的层次相匹配。

误报控制就是产品本身

作者在总结中给出了四条原则：单次超限是警告而非隔离，隔离需要连续 N 次失败或强信号——稳定智能体绝不因噪声被隔离；漂移必须对可比基线度量，同一任务、同一语料版本；隔离记录而非状态枚举才是真相来源；探针必须断言预期输出，活探针不是就绪探针。

v0.2.0 的现场测试以场景 S4、S5、S8、S24 展示了完整闭环——漂移检测、评估、探针、自动隔离、重新认证后的恢复。36/36 的测试通过记录和完整设计文档已公开在项目仓库中。

如果运维团队已经学会不阅读就执行恢复操作，那么你的检测器不是控制措施，只是一个复选框。