你的智能体（agent）刚刚做了一些它不该做的事情。也许它给错误的人发了邮件。也许它执行了本应是读取操作的数据库写入。也许它给出的医疗建议让用户进了医院。你现在正处于一场 AI 事故中——而你一直以来使用的应对软件停机的策略（playbook）对你毫无帮助。
传统的事故应对指南建立在一个基本假设之上：给定相同的输入，系统会产生相同的输出。这个假设让你能够重现故障、二分定位原因并验证修复。但在处理基于自然语言的随机（stochastic）系统时，这些都不适用。同一个提示词（prompt）通过同一个流水线，在不同的运行、供应商、区域和时间下，可能会产生不同的结果。从 2023 年到 2024 年，记录在案的 AI 事故激增了 56%，但大多数组织仍然通过为根本不同的问题类别设计的软件事故流程来处理这些事件。
这就是他们本该编写的应对指南。
为什么你现有的应对指南会误导你
标准的软件应对指南通过询问“发生了什么变化？”来工作。找到部署记录、配置更改或依赖更新。回滚，然后验证。
AI 事故拒绝这种框架，原因有以下几点。
首先，系统可能根本没有发生变化。你的检索索引由于上游数据的更新而发生了漂移。你的模型供应商在一个稳定的 API 版本背后悄悄更新了模型。你的上下文窗口增长超过了系统提示词被截断的阈值——这不是因为代码改动，而是因为对话比平时更长了。“发生了什么变化”这个问题通常没有你可以指出的答案。
其次，故障可能无法重现。LLM 的输出是从概率分布中采样的。你正在调查的有害补全（completion）可能是一个低概率事件，它只发生过一次，而且在测试中可能再也不会发生。运行相同的提示词会返回正常的输出。你的测试套件通过了。这并不能证明系统无罪——这意味着你的评估方法需要改变，而不是说系统是安全的。
第三，爆炸半径（blast radius）更难界定。在确定性系统中，你可以列举触及该 bug 的每一个执行路径。在 AI 系统中，与行为异常的智能体进行的每一次交互都是一个独特的事件。除非你记录了每一次补全，否则你不知道哪些用户收到了错误的输出——而许多团队并没有这样做。
第一步：在了解原因之前先止血
在传统事故中，你可能会容忍在采取行动之前进行调查的时间，因为你可以界定持续的损害。但在 AI 事故中，当系统正在积极采取行动——发送消息、写入记录、调用 API 时——每一分钟的持续运行都有可能扩大危害。
第一个决定是二选一的：这个系统是否需要立即关闭，或者你是否可以在不完全停机的情况下缩小爆炸半径？
要在没有堆栈跟踪（stack trace）的情况下做出决定，请根据你拥有的信号进行推理：
访问范围 ：这个智能体可以触及哪些数据、系统和用户？一个只从 FAQ 数据库读取数据的面向客户的聊天机器人范围很窄。一个具有生产记录写入权限和对外通信权限的智能体范围则很广。
运行速度 ：系统每分钟执行多少次操作？一个在低风险工作流中每天处理 10 个请求的智能体给了你调查的时间。一个每小时处理 10,000 个请求的智能体则刻不容缓。
检测窗口 ：在你注意到之前，这种情况可能已经持续了多久？如果监控在几分钟内发现了这一点，损害可能得到了控制。如果上周开始的异常情况直到今天才浮出水面，请做最坏的打算并向前审计。
这种情况下的爆炸半径估计是一个乘积：范围 × 速度 × 检测窗口。一个临床文档智能体访问 200 万份患者记录，每天处理 1,000 份记录，如果在 30 天内未被发现，其理论爆炸半径为 30,000 次受影响的交互。这个计算结果会告诉你应该立即关闭系统还是谨慎行事。
如有疑问，直接关闭。在大多数领域，持续造成危害的声誉和法律成本远超不必要的停机成本。
第二步：在证据消失前保存它
团队在 AI 事故中犯下的最大错误是在捕获证据之前让其过期。日志会被轮转。模型供应商的追踪数据会失效。原本似乎可以重现的上下文窗口，一旦底层模型更新，就再也无法重现。
在宣布事故后的前 15 分钟内，请冻结以下内容：
完整的提示词和补全日志 （包含时间戳），而不仅仅是输入和输出。系统提示词很重要。对话历史很重要。产生有害输出时处于上下文中的任何内容都是潜在的证据。
模型版本元数据 ：你调用的是哪个模型，温度（temperature）是多少，采样参数是什么？如果你使用可变模型别名（如 "gpt-4" 而不是特定的版本字符串）调用供应商 API，你可能无法找回实际提供请求的模型版本。这是一个关键漏洞——在生产系统中应优先使用固定的版本字符串。
工具调用追踪 ：如果智能体调用了外部工具，请保存每一次调用和返回值。调用了哪个工具，顺序如何，参数是什么，返回了什么？这通常是你发现实际故障的地方——不在模型的推理中，而在于它被赋予的推理依据。
身份和委托链 ：谁或什么授权了这一行动？如果你的智能体代表用户操作，是哪个用户触发了这一系列事件？这对于技术补救和法律披露都至关重要。
检索上下文 ：如果你使用 RAG，检索并排序了哪些文档？有害输出通常可以追溯到模型被赋予的内容，而不是它凭空捏造的内容。请保存检索输入、查询和排序后的结果。
一旦你捕获了这些数据，它们就无法被抹除。请在开始补救之前完成此操作，因为补救步骤（回滚、数据修复、提示词更改）会改变你试图重建的系统状态。
步骤三：以诚实面对不确定性的态度进行沟通 AI 事故沟通中最难的部分在于，你通常无法解释发生了什么。你无法指向某行代码，也无法提供 diff。你知道系统行为异常，但你无法给出一个清晰的技术解释——至少在最初的一个小时内是这样。
大多数团队对这种不确定性的反应是保持沉默，或者说一些模糊到毫无意义的话。这两种策略都会适得其反。用户和监管机构会将沉默解读为隐瞒。像“我们正在调查一个技术问题”这样含糊其辞的声明，会引发通常比现实更糟糕的猜测。
更好的框架是：沟通你所知道的、你所不知道的，以及你正在针对这种不确定性采取什么措施。
在第一个小时内：内部协调。确保你的团队对情况有统一的、共享的理解。在官方回应发布之前，不同团队成员向用户传达的相互矛盾的言论，比什么都不说还要糟糕。
在几个小时内：如果已经发生或可能发生损害，请通知用户。消息不需要解释根本原因。它需要从用户的角度承认发生了什么，他们应该采取什么行动（如果有的话），以及你正在积极处理。即使是坏消息，具体化也能建立信任。
需要避免的是：向用户解释模型产生了“幻觉 (hallucinated)”。这个短语已经成为一种社会普遍接受的、免除 AI 故障责任的方式，而资深用户会识破这一点。它没有解释任何问题，并暗示这种失败是随机且不可预防的——而事实几乎肯定并非如此。
步骤四：系统化调查，而非凭直觉 “模型产生幻觉”永远不是根本原因。它只是对症状的描述。真正的根本原因始终存在于你围绕模型构建的系统中。
高效的调查应遵循层级，而非直觉：
首先是检索层 (Retrieval layer) ：如果你使用 RAG，系统是否检索到了相关的、准确的文档？发送到检索系统的查询是否准确捕捉到了用户的需求？当模型被迫从空白或误导性的上下文中生成内容时，经常会出现幻觉。
其次是提示词层 (Prompt layer) ：系统给模型下达了什么指令？是否存在相互矛盾的指令？是否有些指令在结合特定用户输入时，产生了意想不到的交互？Prompt 故障是系统性的——如果发生了一次，在类似条件下就会再次发生。
再次是模型层 (Model layer) ：只有在排除检索和 Prompt 故障后，才应检查模型本身。这是该模型系列已知的故障模式吗？你是否在有记录显示质量会下降的 Temperature 或上下文长度下观察到了故障？模型层面的故障是真实存在的，但它们很少是随机的——它们具有你可以发现的结构。
最后是安全层 (Safety layer) ：你的护栏 (guardrails) 在哪里，为什么它们没有捕捉到这一点？如果你有输出过滤器，它们给这次生成的评分是多少？如果你没有输出过滤器，那就是根本原因。
Meta 的生产环境根本原因分析平台——运行在 300+ 个团队中——发现，真正的根本原因分析需要对每一层进行系统化调查，并在每一步进行异常检测和维度分析。像“模型产生幻觉”这种单一因素的解释，只是无法产生任何有效修复措施的捷径。
步骤五：编写真正有帮助的事后分析报告 (Post-Mortem) 传统的事后分析报告 (Post-Mortem) 以行动项结束：添加测试、修复 Bug、改进监控。AI 事故的事后分析需要不同的结构，因为故障模式往往无法通过单元测试来消除。
该文档需要记录事故中保留了哪些数据，以及为什么这些数据充足或不足。如果你因为缺乏 Prompt 日志而无法重建时间线，那么补齐这个缺口就是一个行动项。如果你因为没有每个用户的生成日志而无法确定影响范围 (blast radius)，那也是一个行动项。
“哪里出了问题”部分应拒绝接受跳过层级的解释。如果草案写着“模型产生了有害输出”，那是不完整的。完整的版本应该说明是哪种检索或 Prompt 条件创建了上下文，导致产生了有害输出，以及为什么安全层没有拦截它。
修复措施应明确你要增加什么样的可观测性——不是为了再次检测同一起事故，而是为了检测该事故所属的故障类别。AI 系统的故障是有模式的。一个给错误的人发送邮件的 Agent，很可能是因为身份混淆故障。除非你在整个系统中增加对身份相关异常的监控，否则这种模式会以不同形式再次出现。
最后：建立观察期。与软件修复不同，AI 系统的修复措施不会提供明确的通过/失败信号。在更改 Prompt 或添加护栏后，应在一段有意义的时间内，监控系统在各种条件下的行为分布——而不是仅仅进行一次测试运行。随机性 (Stochastic) 系统需要持续观察，而非特定时间点的验证。
责任的底层转变 最重要的事故是那些用户信任你的系统并因此受到伤害的事故。一个给出危险医疗建议的聊天机器人。一个基于错误推理执行金融交易的智能体（Agent）。一个在被人发现之前已经默默损坏记录数周的文档处理系统。
这些不是 AI 开发中的边缘案例。它们是核心工程问题。构建一个有用的 AI 系统和构建一个安全的系统是同一个项目，而事故应对手册（Runbook）正是让这一切变得具体的载体。
所需的运行规范——记录一切、限制访问范围、在无需系统配合的情况下使其可中断、在不确定性下诚实沟通——并不光鲜。它不会出现在 Demo 中。但它正是区分能够将 AI 投入生产运行的团队与只能做演示的团队的标准。
当你的智能体造成伤害时，你的首要任务是限制这种伤害。你的第二优先级是理解它。你的第三优先级是构建一个让下一次事故更容易控制和理解的系统。现在从事这项工作的团队正在构建一些随着 AI 系统获得更多权限和更高自主性而变得愈发重要的东西。从一份认真对待随机（Stochastic）故障的 Runbook 开始，是正确的起点。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
