一种常见的AI安全叙事是：在AI代理投入生产时，所有动作在输出前都必须经过人类批准。
我也是这么做的。AI代理帮我打理个人品牌的公开互动内容，例如评论、回复和短文。在我于一个私人频道里点击批准之前，任何内容都不会发布。我故意设计了这套流程，因为我不愿将自己的声誉委托给一个语言模型。
上周，我审查了自己的审批关卡。按钮看起来完美无瑕，它在每一条AI生成的提案下方都渲染得无可挑剔，绿色的，自信满满，让人安心。
但在其中一些卡片背后，这个按钮根本没有与任何东西相连。
整个链路里的第一次“在线”发送本应只是走个形式。AI代理草拟了一条评论，审批卡片出现在我的频道里，我点了“批准”。什么都没发生。没有确认信息，没有报错，什么都没有，只有一个聊天客户端里几乎看不见的警告图标，那种极易被忽视又无从诊断的符号。
后来我发现，这个按钮可能在两种截然不同的方式下失效，而我把这两种问题全占了。
第一种失败：这张卡片是由错误的信使发出的。有两个应用可以在那个频道里发帖，但这张卡片恰恰来自一个根本没有监听到按钮点击能力的应用。平台会将点击事件路由到发布该消息的应用，于是我的审批决定就在聊天客户端内无声无息地消失了，我控制的服务器端从未收到任何信号。
我这端没有任何可以调试的东西，因为在我这边，就什么都没发生过。需要说明的是，这种路由行为有文档说明，是正确的。接线接错的人是我。但除了那个无法解读的图标，界面上没有任何提示说明哪里出了问题。按钮看起来和一个能正常运作的按钮一模一样，同样可以被点击。
第二次失败要严重得多。有些卡片在流转到我面前时，根本没有后端数据记录作支撑。审批存储库，也就是点击操作本应写入决策信息的那套记录系统，压根就不知道有这条审批建议存在。于是，即便我的点击精准地抵达了我自己的服务器，也没有任何对象可以附着这次决策。这是一个没有对象的审批。那一晚，我不得不手动创建了审批记录，好让我自己的那下点击产生一点意义。
这两种错误都没有抛出任何报错。两张卡片在像素级别上，都和一张能正常工作的卡片完全相同。这是一个值得认真对待的细节：当审批仅仅是一个用户界面元素，而不是一个有约束力的数据记录时，系统无法区分“有个人批准了这件事”与“一个按钮曾经存在过”。
线路修复之后，在把更多事情托付给这个系统前，我进行了一次对抗性审计：跨越六种失效模式视角，完成了88次有界审查，对每个候选发现都进行了三次独立的驳斥尝试。有27个问题被发现。其中3个是阻塞级别。
而那个彻底重塑了我认知的发现，并非线路逻辑中的缺陷。那个自动发送分支，其实从未真正为一个真实条目触发过。每一次计划执行时，遇到的都是一个空队列，无事发生。迄今为止唯一一次真正的发送，其实就来自我手动测试的那一次。
整条绿色的发送通道一路畅通，但没有任何东西被它捕获到。
一个看起来运行健康的系统，和一个从未被真正考验过的系统，可以表现得毫无区别。
热门跟贴