当"认证"不等于"安全"：一次险些签发的回归事故

一个被忽略的红色警报

v0.2.0 的发布流程是这样的：重新认证、生成回归报告、晋升。回归报告上清清楚楚写着 blocked=True——一个关键任务已经回归失败。但晋升照常进行，认证声明被写入，工作负载被推入生产环境。

我在一个已知有问题的工件上签了字，差点把它送上生产。这就是 HivePlane v0.2.0 的故事——那个我早在 v0.1.0 就承诺要加的晋升闸门，最终却基于错误的证据放行了一个被自己回归报告标记为不合格的工作负载。

rss source: I Signed a Regression and Almost Shipped It

这引出一个比任何通过率阈值都更根本的问题：你的闸门到底是在阻止问题，还是只是在注释问题？

闸门放行错误的四种方式

v0.2.0 的现场测试暴露了四个独立的缺陷，每一个都代表一种"绿灯但错误"的路径。

发现	闸门做了什么	为什么是错的
#522（严重）	`recertify_and_promote` 在回归报告为 `blocked=True` 时仍然放行	报告只是脚注，不是前置条件
#523（高）	默认 `min_production_runs_survived=50` 使 `certified` 状态不可达	生产闸门与自身阈值死锁
#530	漂移检测器跨语料库版本比较失败计数	扩容基准测试自动隔离了一个健康智能体
#527	回归报告与任何状态的先前认证进行比较	不可比的基线掩盖了真实回归

通过率阈值是必要的，但远远不够。这四个缺陷各自代表一种方式来获得一个"绿色但错误"的结果。核心教训是：检查如果只注释而不阻断，它就是一个建议，而不是一个控制。

签名在回归之上

#522：当报告只是装饰

真正让我夜不能寐的是 #522。流程本该是：重新认证 → 生成回归报告 → 晋升。报告说 blocked=True，关键任务已经回归。晋升却照常进行。

回归报告生成了，附加到记录上了，然后被忽略了。它是一个评论，不是一个闸门。

这里有一条值得刻在墙上的原则：如果你的晋升可以在回归报告为红色时成功，那你的回归报告就是装饰品。

修复方式很直接：回归报告必须是硬前置条件。recertify_and_promote 在报告为 blocked 时直接拒绝：

if regression_report.blocked:
    raise PromotionRefusedError(
        workload,
        f"regression report is blocked: {regression_report.critical_failures}",
    )

关键回归会直接写入拒绝原因。在回归被解决或带着归属明确豁免之前，晋升无法完成。

#523：不可达的状态

#523 是另一种承认失败。默认的 min_production_runs_survived=50 意味着一个工作负载必须在生产环境中存活 50 次运行才能被标记为 certified。但在一个只运行一次的现场测试中，面对本地技术栈，这永远不可能实现。

生产闸门与自己的阈值死锁了。工作负载可以永远通过每一个基准测试，却永远无法达到 certified 状态。

一个不可达的闸门就是一个不存在的闸门。运维人员会绕过它，而被绕过的闸门只是一块昂贵的仪表盘。阈值必须在它被执行的环境中可达，否则你构建的是一个状态循环，而不是一架梯子。

状态机中的可达性（reachability） 是发布闸门设计里最容易被忽视的形式化性质：一个状态如果不存在任何从初始状态出发的合法迁移路径能抵达它，那么它在运行时就不具备任何约束力。certified 这类状态通常由多个条件合取而成，例如"通过全部基准"且"生产存活运行次数 ≥ N"。只要其中任一条件在当前部署环境（一次性现场测试、本地栈、短生命周期任务）中无法被满足，整个状态就退化为死状态。工程上的对策有三种：让阈值由环境能力推导而非硬编码、为不可达情形提供显式的降级状态（如 provisional）、或在配置校验阶段就拒绝启动一个自相矛盾的闸门。

#530：那个不存在的基线

#530 改变了我对漂移的思考方式。检测器跨语料库版本比较失败计数。如果你把基准测试从 10 个任务扩展到 20 个——因为学习循环增加了一个经过审核的用例——一个原本 10/10 通过的健康智能体现在按你的算法"失败"了 10/20。

语料库增长看起来像性能衰减。扩容基准测试自动隔离了一个健康智能体。

修复：漂移是相对于智能体在可比语料库下的自身基线来测量的。比较相同的任务，而不是不同的计数。语料库版本变更是一个新的基线，不是漂移信号。

漂移检测（drift detection） 的统计前提是：比较的两组观测必须来自同一分布的可比样本。当基准语料库从 10 个任务扩展到 20 个任务时，通过计数（如 10/10 → 10/20）会机械性地下降，这属于测量工具变化而非被测对象变化，统计上称为基准断裂（benchmark break）。正确做法是改用比率并在同一任务子集上比较，或把语料库版本变更显式登记为一次新基线（new baseline），从该版本起重新累积参考分布。任何跨版本直接对比原始计数的漂移算法，都会在扩容时产生大量假阳性隔离，进而侵蚀运维人员对告警的信任。

#527：比较了错误的基线

#527 在晋升侧是同样的教训：回归报告与任何状态的先前认证做 diff，包括 quarantined 状态的。所以一个针对已知坏基线的回归看起来像没有回归。

基线必须是最后一个 certified 记录，否则你是在与一个从未安全过的版本进行比较。

回归报告（Regression Report） 是认证流水线中用于回答"这个工件相比上一个已知良好状态，是否有行为退化"的产物。它通常包含通过/失败的任务清单、关键任务（critical task）的失败项，以及一个汇总的布尔标志（本文中的 blocked）。关键区别在于它的消费方式：如果下游的晋升逻辑只是把它写进审计记录、并不读取 blocked 字段来决定是否继续，那这份报告在语义上等价于一条日志。回归测试的本质是"对照基线做差分"，因此其正确性完全取决于两件事：基线选得对不对（见 #527），以及任务集合在两次比较之间是否可比（见 #530）。

学到了什么

在已知有问题的工件上签名比不签名更糟糕——它携带了认证的权威，却没有安全。这三条原则值得每个构建发布闸门的人记住：

回归报告必须阻断，而不是注释。一个能被忽略的报告不是控制。
身份绑定认证，而非清单。改变哈希，丢失认证。认证与身份是不可分割的。
存活闸门必须可达，否则你构建的是状态循环，而不是梯子。

v0.2.0 的现场测试演示了晋升闸门通过可重放的 diff 阻断回归（场景 S3）、漂移自动隔离与恢复（S4/S5），以及回归 diff API。完整证据在现场测试报告中，认证与晋升设计在认证 v2 设计文档中。

对你意味着什么

如果你正在构建任何形式的 AI 智能体认证或发布流水线，这四个缺陷提供了可直接借鉴的模式。闸门的意义不在于生成报告，而在于当报告为红色时说"不"。

你上一次的晋升闸门拒绝了回归报告标记的东西是什么时候？如果你想不起来，你的报告就是评论——不是闸门。

参考：

HivePlane — pip install hiveplane==0.2.0
现场测试报告 (36/36)
认证 v2 设计 · 学习循环设计
教程：认证、晋升与漂移生存