AI护栏机制为何失效：那些从未触发或静默停摆的“安全网”

原文：https://dev.to/mickyarun/nobody-checks-whether-the-guardrail-is-running-3ng（作者 @mickyarun）

眼下几乎所有关于AI与工程的帖子都在讨论添加护栏。

比如让智能体无法绕过的Lint规则、发布提示词修改前的评估流程、每个PR上的审查机器人、基于真实生产故障构建的回归测试套件，以及将架构规则存入代码仓库，让模型在加载时读取。

我写过其中一些帖子，至今仍相信这些做法的价值——正是这类工作让AI工具能被高级工程师真正用起来，而非成为累赘。

但在过去一周，我在这平台上参与了三次看似不同、实则指向同一个问题的讨论，而这个问题与该添加哪种护栏无关。

一个从未触发的护栏和一个静默停止运行的护栏，其输出结果完全相同：

绿灯。

从未亮绿灯的部署流水线

维森特·雷耶斯的GitHub Actions工作流名为“部署到DigitalOcean”。它配置完备：SSH操作、密钥管理一应俱全。然而每次他推送后端更改时，依然需要手动SSH登录服务器执行git pull。

部署任务本应依赖CI通过：

on:
  workflow_run:
    workflows: ['CI']
    branches: ['main']
    types: [completed]

jobs:
  deploy:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}

这看似合理，但问题在于——CI流水线从未在main分支上成功过。不是偶尔失败，而是从未成功。因此每次部署任务都显示“已跳过”，流水线永久卡在一道无法开启的关卡上。

他关于此事的总结值得铭记：一条被永久静默阻断的流水线，从远处看，与根本不存在的流水线别无二致。

GitHub Actions的界面上不会显示此工作流已连续40次未成功，你必须主动查询才能发现。

无法说“不”的评估器

在讨论如何设计可信AI评估系统的帖子里，海因里希·内布指出：每个评估器都需要一个已知会失败的“双胞胎”用例——一个它应该拒绝的输入，以及该用例上次实际触发拒绝的日期记录。

他的表述是我见过最犀利的版本：一个从未失败的评估器和一个静默停止运行的评估器，显示的都是相同的绿色。

这与维森特流水线的问题本质相同，只是上升了一层：他的情况是关卡卡在关闭状态，而评估套件的情况是关卡卡在开启状态——后者更糟糕，因为卡死的关闭关卡烦人到足以促使某人去排查，而卡死的开启关卡则会持续放行。

思考一下评估套件实际是如何腐烂的：

• 有人修改了提示模板，评估器的正则表达式停止匹配，导致所有测试都显示通过
• 有人重命名了数据集字段，加载器返回空列表，套件在0.4秒内运行0个测试用例并报告100%通过率
• 服务商更改了默认设置，你的评估模型变得更加“随和”

所有这些情况，看起来都像是成功。

没有溯源记录的评分

第三个问题来自我自己的经历，出自同一个讨论帖。

一个没有附带框架版本、数据集快照和提示词修订记录的评估结果，不是证据，而是自我声明。

这没问题——直到评分发生变化。这时有人会问：是模型变好了，还是评估套件变简单了？如果你无法回答，那你就从未真正拥有过测量结果。你拥有的只是一个带小数点的模糊印象。

这种警觉源于支付领域的工作经验。在受监管的系统中，没人会要求你“相信某项控制措施已执行”，而是要求你证明：在何种输入、何时、依据哪版规则下，哪项控制措施被触发了。这可能是数月之后，面对一位当时不在场且不会轻信你的陌生人提出的质询。

工程领域已悄然继承了这项负担。评估结果日益成为发布决策的核心依据，只是配套的文档记录工作尚未跟上。

真正的关联所在

当你将某项检查自动化时，你实际上是用一个问题替换了另一个问题，却浑然不觉。

自动化前，问题是“有人检查过这个吗？”——你能通过找到那个人并询问来获得答案。

自动化后，你以为自己在问的问题仍然是“检查通过了吗？”，但你实际依赖的问题变成了“这项检查还在运行吗？”

几乎没有人对第二个问题进行监控。

这在运维领域是常识：你不仅要监控错误警报，还要监控心跳信号的消失——因为一个宕机的监控系统，看起来就像一个没有任何问题的系统。“死人开关”的存在正是为此而设。

但我们不知为何，没有将这个原则应用到代码检查机制上。CI工作流、Lint规则、评估套件、智能体策略——这些本质上都是正确性监控系统，而我们运行它们时，却没有配置任何心跳监测。

为护栏建立信任前的准备

这一切都并不复杂。

一个它必须拒绝的已知坏输入。 每项检查都需要一个它理应拒绝的用例，并与真实用例并行运行。如果你的代码检查规则抓不住自己的金丝雀测试，那它就没在运行。如果你评估的阴性对照组被评分通过，那评分器就坏了，而那轮测试的所有其他数字也都是噪音。这与实验室的阴性对照是同一个道理。没人会相信一个永远显示清洁结果的化验。

记录上次拒绝的日期。 不是上次运行的时间，而是上次说“不”的时间。一个四个月没拒绝过任何内容的护栏，要么是在保护一个纪律异常严明的团队，要么是在五月份就坏了，而这两种情况在仪表盘上看起来一模一样。把它记在某个字段里。如果没人能回答“它上次抓出问题是什么时候”，那它就是个装饰。

有人偶尔会查看的运行计数。 零用例失败是最隐蔽的，因为一套加载空数据集的检查会快速通过并得到满分。要断言用例数量。如果预期有240个用例但得到0个，这是一个严重失败，而不是100%通过。

结果的溯源信息。 测试框架的提交记录、数据集哈希、提示词版本、模型版本、时间戳。这些信息要附在评分上，而不是放在只有三十天保留期的CI日志里。测试很简单：六个月后，你还能复现这个确切的数字吗？如果不能，你就无法用它来为一个决策辩护，这意味着它从来就不是那个决策的真正依据。

为什么代理会让情况变糟而非好转

我反复强调这个话题，是因为AI改变了问题的比例。

AI代理在工程中的价值——也是我真正相信的一点——在于你能获得一支几乎不犯错的“初级工程师”大军。瓶颈不再是人们写代码的速度，而是他们审查代码的速度。因此，你需要通过增加自动化审查来补偿。更多的代码检查规则、更多的测试、更多的评估、更多的策略检查。

这是正确的做法，我也会这么做。

但这意味着你的系统正确性越来越多地依赖于无人看管的自动化组件。当人工审查一切时，一个坏掉的代码检查规则只是大网上的一个小洞。当自动化审查一切时，那个坏掉的代码检查规则就是那张网。

护栏恰恰在无人足够密切地关注它们、以至于未能察觉它们已停止工作的那个时刻，变成了承重结构。

去检查一个吧

选择一个你最不愿失去的护栏。比如控制提示词变更的评估套件，或者阻止代理接触支付路径的规则，无论你的是什么。

然后回答关于它的一个问题：它上次说“不”是什么时候？

如果你能在一分钟内找到答案，很好。如果你根本找不到，那你有的就不是一个护栏。你有的只是一个后面空无一物的绿灯，而你却一直把它当作证据。

原文：https://dev.to/mickyarun/nobody-checks-whether-the-guardrail-is-running-3ng（作者 @mickyarun）