AI 事故应对指南:当你的智能体造成现实世界损害时
你的智能体(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,你可能无法找回实际提供请求的模型版本。这是一个关键漏洞——在生产系统中应优先使用固定的版本字符串。
工具调用追踪:如果智能体调用了外部工具,请保存每一次调用和返回值。调用了哪个工具,顺序如何,参数是什么,返回了什么?这通常是你发现实际故障的地方——不在模型的推理中,而在于它被赋予的推理依据。
身份和委托链:谁或什么授权了这一行动?如果你的智能体代表用户操作,是哪个用户触发了这一系列事件?这对于技术补救和法律披露都至关重要。
- https://www.mdpi.com/2624-800X/6/1/20
- https://www.glacis.io/guide-ai-incident-response
- https://engineering.fb.com/2025/12/19/data-infrastructure/drp-metas-root-cause-analysis-platform-at-scale/
- https://engineering.fb.com/2024/06/24/data-infrastructure/leveraging-ai-for-efficient-incident-response/
- https://www.datadoghq.com/blog/llm-observability-hallucination-detection/
- https://partnershiponai.org/wp-content/uploads/2025/09/agents-real-time-failure-detection.pdf
- https://thefuturesociety.org/us-ai-incident-response/
- https://www.nist.gov/itl/ai-risk-management-framework
- https://opentelemetry.io/blog/2025/ai-agent-observability/
- https://responsibleailabs.ai/knowledge-hub/articles/ai-safety-incidents-2024
