弃用通知在某个周二送达，停用日期定在六个月后。你的平台团队将其记录在依赖跟踪器中，贴上 “Q3 切换” 标签，并标记为黄色严重度。它与队列中已有的另外两个迁移任务汇合。三周后，供应商在同一个 URL 下修改了日期，没有 diff，没有收件箱通知，只有一段悄悄更新的文字，将停用日期提前了 60 天，直接挪到了你的代码冻结期中间。
你视为规划文档的生命周期页面，其实一直是一个合同闹钟。唯一改变的是它控制着哪个团队的日历——而拥有这个日历的团队并不是你的。
报警在当地时间 02:17 响起。值班 SRE 在手机上打开智能体运行手册，阅读第一步：“检查智能体的工具调用追踪，寻找异常的工具使用情况。”他们打开链接，却遇到了一个他不属于的工作区的 SSO 登录提示。第二步说要检查提示词构建日志；同样碰壁。第三步说回滚到上一个提示词版本，但部署权限被限制在了一个他不在的团队中。等他弄清楚该向哪个 Slack 频道上报，并叫醒 AI 团队的产品经理时（因为她是 02:17 唯一能找到的人），九十分钟已经过去了，而客户可见的回归故障仍在持续给出错误答案。
事后分析会将权限鸿沟确定为直接原因。而更深层的不适感在于，这份运行手册在白天读起来很顺畅，但在深夜执行时却被封锁，因为编写手册的人拥有执行者所不具备的权限。
运维手册上写着“禁用代理”。值班人员照做了。43 分钟后，当紧急开关终于通过配置服务传播开来时，该代理已经提交了 1,200 张错误的工单，调用了 8,000 次计费 API，并向根本没有订阅任何服务的客户发送了邮件。运维手册是正确的，但它也是徒劳的，因为没有人衡量过当代理每秒钟都在造成破坏时，“禁用代理”实际上需要多长时间。
大多数 AI 功能都配有紧急开关，就像大多数建筑都配有灭火器一样：有人签字确认它的存在，却没人计时到达它需要多久。合规审查会问“是否有紧急开关？”，答案是肯定的。而故障现场会问“止血有多快？”，答案则取决于底层管道恰好需要的时间——团队中从未有人针对该功能造成破坏的速度测量过这个数字。
这种不匹配正是问题的核心。一个遏制时间长于其破坏扩散时间的功能，交付的只是“遏制剧场”（Containment Theater）。
警报在凌晨 02:14 响起。运维手册（runbook）写着“呼叫工程师”。工程师的名字关联到了一个值班轮值。该轮值指向一个 Slack 频道，这是团队在六个月前建立的统一分诊界面。频道中的第一条消息是告警。十九秒后发布的第二条消息是一段冷静的三句总结：告警服务、失败的依赖项、最后一次部署。它写得很好，最后以“已确认（Acknowledged）”结尾。
事故指挥官在床上看着手机，读到“已确认”后便翻身继续睡去。然而，并没有人确认。作为一线分诊助手的智能体（Agent）订阅了该频道，它向频道复述了告警内容，并以频道中其他读者习惯用来表示“我已掌握处理此问题的上下文”的动词收尾。这起事故在无人接手的情况下运行了 41 分钟，直到一张客户工单通过另一个界面唤醒了另一位工程师。
第一次智能体导致我们团队出现真正的停机事故时，复盘报告的作者打开模板，划过时间线，盯着“根因”字段沉思了良久，然后输入：“队列阻塞恢复的操作指南 (runbook) 有误。” 但实际上操作指南没问题。智能体阅读了指南，认定队列的症状符合另一种场景，并针对该场景运行了恢复脚本。那份文档产生的改进措施——“细化操作指南用词”、“在恢复脚本中增加确认提示”——对于实际的故障模式完全无用。实际情况是一个推理系统推导错误，而模板中没有任何字段知道该如何表达这一点。
自那以后，我看到同样的失败在不同团队中反复上演。模板是为确定性系统设计的。代码做错了，你就修复代码；配置设错了，你就修复配置。复盘文档的模式 (schema) 就是团队关于故障理论的模式，当这个理论无法表达“智能体的计划错了”时，文档就会将实际故障强行降维成模板能表达的最接近的事物——通常是文档缺失或缺乏护栏——从而导致改进措施试图用确定性的修复方案去解决概率性的故障。然后，同一类事故会再次发生，团队下次依然会以同样的方式记录它。
发布标志运作完美。你在它后面发布了 AI 摘要生成器，在两周内将其比例从 1% 提高到 10%、50%，最后达到 100%，紧盯仪表盘，一切正常。季度末，平台团队的标志清理机器人发起了一个 PR，删除了这个已经多余的入口。你批准了。该 PR 与其他过期标志清理工作一起合并，代码库精简了 200 行。六周后的凌晨 2 点，供应商滚动更新了一个新的模型快照，你的摘要生成器开始信誓旦旦地在法律文件中编造条款，而你的值班工程师发现没有快速关闭它的手段 —— 只能重新部署。
标志完成了它的工作。但标志是错误的保留产物。发布标志回答的是“这条新代码路径是否应该是可达的？”一旦大家达成共识，删除它就是正确的清理举动。而紧急开关（Kill switch）回答的是“上游模型今天表现正常吗？” —— 这个问题永远不会过期，因为上游模型永远在变化。将它们放在一起清理，就像把烟雾报警器当作建筑许可证一样，是范畴错误：建筑物建成后，许可证会被归档，但报警器的接线必须永远保持连接，因为由于它所监控的情况仍然可能发生。
故障复盘进行得非常顺利，直到遇到了一个没人能回答的问题。下午 2:14，结构化输出错误激增，某个收入工作流停滞了 90 分钟。时间线还原得很清晰：三周前，有人修改了系统提示词（system prompt），多加了几个关于“对话语气”的词，这在特定输入下悄悄导致模型偏离了 JSON 契约。修复方法很简单，只需一行代码回滚。但接下来的部分很难：有人问是谁做的改动，谁审核的，以及未来哪个团队负责维护这个提示词。房间里陷入了沉默。没有 Pull Request，没有审核人。改动是某个人在晚上 11 点通过厂商控制面板操作的，而那个人已经不记得这回事了。
那种沉默才是真正的事故。JSON 契约的失效只是症状。根因在于，系统中杠杆率最高的一处行为逻辑，竟然没有负责人，没有变更历史，也没有走任何管理其他生产环境变更的流程。模型没有出错。模型完全按照指令行事。失败之处在于，“指令”本身完全脱离了变更管理。
这是目前最常见的生产环境 AI 事故之一，而且几乎从未被正确命名。复盘报告在根因栏写下“提示词退化（prompt regression）”然后就此揭过。但“提示词退化”描述的是代码表现。真正的根因是组织架构图上的一个漏洞。
值班轮换制度是建立在一个承诺之上的：故障是可以复现的。警报触发，你重新运行请求，观察 Bug 发生，找到错误的提交 (commit)，然后回滚部署。这个循环的每一个环节都假设了确定性 (determinism)。同样的输入产生同样的输出，而输出要么是对的，要么是错的，其方式一目了然。
Agent 集群悄无声息地打破了这条链条上的每一个环节。故障发生了一次，其采样温度 (sampling temperature) 你无法重现，所处的上下文窗口 (context window) 也早已被垃圾回收。这里没有“错误的提交”，因为代码从未改变 —— 改变的是模型，或者是检索到的文档，再或者是用户措辞的方式超出了所有人的预料。你回滚了部署，但部署从来都不是问题所在。
于是警报发出了，一名工程师接手了。他们发现了在生产环境中运行 Agent 最令人不安的事实：他们拿到手的是一个无法单步执行 (single-step) 的系统，而摆在他们眼前的运行手册 (runbook) 却是为另一种完全不同的机器编写的。
你的状态页是一片绿色。你的错误率为零。你的运行时间仪表盘连续第七个月显示为 100%。然而，在周二上午 9:14，你的客户团队给你转来了一条来自一家财富 500 强客户的消息，上面写着：“我们的团队注意到这周助手的表现变差了。你能告诉我们发生了什么变化吗？”午饭前，你又收到了 12 条类似的反馈。现有的事故沟通手册（incident-comms playbook）无法回答其中任何一个问题，因为那套手册是为停机事故准备的，而现在没有任何东西崩溃。
这就是面向客户的 AI 复盘难题，也是我在将 LLM 功能交付给企业合约的团队中看到的最普遍的差距。可靠性的维度已经从“系统是否在线”转向了“系统是否和上周一样好”，而几乎没有任何沟通基础设施跟上了这一变化。状态页上没有相应的展示块。严重性等级标准（Severity rubrics）没有对其进行评分。支持服务的回复模版默认为“我们发现了一个问题并已解决”，这取决于客户当天的情绪，听起来要么是敷衍，要么是危言耸听。
上季度，某推荐引擎推送了冒犯性内容，随后召开的事故复盘会议以一种我们再熟悉不过的方式收场：两小时的会议里，ML 工程师把矛头指向检索语料库，数据工程师把矛头指向提示词，产品工程师把矛头指向监控，基础设施团队把矛头指向没人记得何时升级的模型版本。最终产出了三条行动项，却没有一条落实到具体负责人。事故就此关闭。六周后，同样的故障模式再次上线。
这不是某一个团队的故事，而是大多数组织处理 AI 事故时的默认结局。AI 功能在生产环境中造成的后果，由足够多的参与方共同承担，导致标准的事故复盘根本无法锁定因果关系。那套在排查数据库超时时行之有效的"5 Why"分析法，面对"模型给出了错误答案"时便彻底失灵——因为下一步该追问什么，从来都不显而易见。
2024 年初，谷歌的图像生成工具开始产生历史上不准确的结果，应对之策来得迅速：暂停所有人物图像生成功能。这一暂停持续了数月。想将该功能用于合法用途的用户毫无选择。等到功能重新上线时，采用率也很低——仅对一小部分订阅用户开放，受到严格限制，且声誉包袱尚未完全卸下。过度纠正本身成了一个新问题。
这是大多数团队在 AI 功能公开失败后都会掉入的陷阱。直觉没错——如果某个东西在造成伤害，就应该停止——但执行方式却错了。彻底下架功能，或者堆砌铺天盖地的护栏让其形同虚设，并不能重建信任。这只会表明你不知道如何负责任地运营 AI，也无法分辨那 0.1% 的错误输出与 99.9% 的正常输出之间的区别。
想象一下这个场景：凌晨 2:14，值班工程师的手机嗡嗡作响，你旗舰产品中的 AI 功能正自信地告诉企业客户，他们的账号是“西红柿汤”。模型供应商推送了一个路由变更，你的提示词被静默升级的分词器截断了，或者是检索索引针对一个损坏的 Parquet 文件重新生成了——原因现在还不重要。重要的是，距离有人截图输出并发布到 LinkedIn 只剩 10 分钟。
如果你唯一的对策是“回滚部署并等待 CI”，那你已经输了。标准的流水线回滚从报警到恢复需要 20 到 40 分钟，而糟糕的输出不会在绿色对勾渲染时礼貌地暂停。等到新容器恢复健康时，截图已经在信息流里传开了，支持信箱里塞满了 50 个工单，而你花了 6 个月建立的信任正被那些从未使用过该产品的人审查。
那些能在 5 分钟而不是 5 小时内控制此类事件的团队并不是靠运气。他们在需要之前就构建了一个紧急开关（Kill Switch）——这是一个允许值班工程师在几秒钟内禁用 AI 路径的原语，无需部署，无需合并，也无需任何人触碰生产环境的二进制文件。这篇文章将探讨这种专门针对 AI 功能的原语是什么样的，为什么确定性软件的版本不足以应对，以及在事故发生前的一天必须具备什么条件，才能让响应在事故发生的当晚奏效。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
