Wiki Notes

Appearance

AI系统事故响应专题 ​

版本：v1.3

最后更新：2026-07-09

适用对象：正在维护生产 AI 系统、做 on-call、负责高风险 Agent / RAG / 审批链路，以及需要把“发现、止血、回滚、复盘、门禁回流”真正做成运行机制的产品、平台、SRE、安全与值班同学

AI 系统一旦进入生产，事故几乎不是：

  • 会不会发生

而是：

  • 什么时候发生
  • 发生后能不能快速止血

而且 AI 事故和传统接口事故非常不一样。

很多时候它不是直接 500，而是：

  • 结果突然变差
  • 高风险输出漏放
  • 知识库召回错了
  • 工具误调用增加
  • 成本异常飙升
  • 人工审批突然积压

所以这篇专题关注的不是“事故管理口号”，而是 AI 系统里更可执行的一套事故响应机制。

1. 为什么 AI 事故比传统系统事故更难发现 ​

传统系统更常见的症状是：

  • 服务挂了
  • 接口超时
  • 数据库不可用

AI 系统除了这些，还会出现一类更隐蔽的：

  • 行为型事故

例如：

  • 回答质量大幅退化
  • 引用来源突然错乱
  • prompt injection 开始生效
  • 权限边界被打穿
  • 模型升级后高风险场景退化

这类事故最大的难点不是“没日志”，而是：

  • 系统可能仍然 200 返回
  • 用户已经在承受坏结果

所以 AI 事故检测不能只看可用性，还必须看行为和风险信号。

2. 一个更实用的 AI 事故定义 ​

更适合生产落地的定义通常是：

  • 任何让用户价值、安全边界、审批约束、成本边界或关键质量指标明显偏离预期的事件

这意味着 AI 事故并不只包括：

  • 宕机

还包括：

  • 模型输出大面积退化
  • 高风险问题误放
  • 知识域污染
  • 审批链失效
  • guardrails 漏拦截
  • 单任务成本剧烈上涨

3. AI 事故最常见的五种类型 ​

3.1 质量事故 ​

例如：

  • 回答大面积变差
  • 特定场景退化
  • 工具选错
  • 编号、规则、产品名类 query 错误率上升

3.2 安全事故 ​

例如：

  • 敏感内容泄露
  • 高风险输出漏拦截
  • 跨租户召回
  • prompt injection 导致越权

3.3 成本事故 ​

例如：

  • token 使用异常
  • 工具重试放大成本
  • 低价值请求误走高成本模型
  • 长会话上下文失控

3.4 稳定性事故 ​

例如：

  • 工具超时
  • workflow 死循环
  • fallback 失效
  • 后台任务积压

3.5 治理事故 ​

例如：

  • 审批未触发
  • 审计链缺失
  • 关键 trace 没落下来
  • 规则变更未被记录

4. Google SRE 和 OpenAI 当前资料给出的共同原则 ​

根据当前可访问的 Google SRE：

  • Incident response
  • Incident management guide
  • Postmortem culture

以及 OpenAI 当前：

  • Production best practices
  • Evaluation best practices
  • Integrations and observability
  • Safety best practices

可以先抓住一条非常重要的原则：

  • 事故响应的第一优先级不是立刻解释根因，而是立刻缩小影响面

翻成 AI 场景的工程语言就是：

  • 先止血
  • 再诊断
  • 最后把结论变成门禁

5. AI 事故响应的第一原则：先止血，不先争论 ​

事故现场最常见的坏模式是：

  • 先讨论是不是 bug
  • 先讨论到底是谁的问题
  • 先讨论根因在哪一层

更成熟的做法通常是：

  • 先判断是否要切断高风险动作
  • 先判断是否要降级或回滚
  • 先判断是否要转人工

常见止血动作包括：

  • 关闭高风险工具
  • 回滚 Prompt
  • 回滚模型版本
  • 收紧权限或 guardrails
  • 暂停某类高风险 query 路由
  • 强制转人工
  • 暂停自动审批 / 自动执行

这和 Google SRE 对 incident response 的建议是高度一致的：

  • 先控制影响面，再慢慢找原因

6. 更可执行的 AI 事故响应流程 ​

一个更适合 AI 系统的最小流程通常是：

text
Detect
 -> Triage
 -> Stop the bleeding
 -> Investigate
 -> Rollback / Mitigate
 -> Recover
 -> Postmortem
 -> Feed into evals / guardrails / runbooks

这条链路的重点在于：

  • Detect 不能只依赖服务错误
  • Triage 不能只按基础设施优先级
  • Recover 不能只看服务活没活

7. Detect 阶段到底应该盯哪些信号 ​

建议至少同时关注：

7.1 可用性信号 ​

  • 错误率
  • 超时率
  • 工具失败率

7.2 质量信号 ​

  • 高频 query 通过率
  • 引用正确率
  • 空检索率
  • 高价值场景退化率

7.3 安全信号 ​

  • guardrail 命中率异常
  • 敏感内容误召回率
  • 审批绕过率
  • prompt injection 成功率

7.4 运营信号 ​

  • 人工接管量
  • 审批积压时长
  • 单任务成本
  • 长任务排队积压

如果只看 CPU、内存、500 数，很多 AI 事故根本不会被及时看见。

8. Triage 阶段最重要的是先判断事故类型和影响面 ​

更实用的第一轮问题通常是：

  1. 影响的是质量、稳定性、安全还是成本边界？
  2. 影响面是全部流量、某个工作流、某个租户还是某个工具？
  3. 是否存在真实世界副作用正在持续发生？
  4. 是否需要先关闭某个自动动作？
  5. 最近有哪些变更可能相关？

这样做的价值在于：

  • 先缩小判断范围
  • 避免所有问题都走同一套排查路线

8.1 第一轮分级最好先按“用户影响 + 风险副作用”做 ​

Google SRE 当前 incident management guide 在 2026-07-09 仍然强调两件很关键的事：

  • 告警要基于用户症状，而不是只基于内部原因
  • 事故管理要围绕 coordinate / communicate / control

放到 AI 系统里，一个更实用的分级视角通常是：

级别典型触发条件现场动作
SEV0 / P0已发生资金、权限、数据泄露、不可逆外部副作用，或高风险动作持续误放立刻停自动执行，拉起 IC，冻结相关工作流与外部动作，必要时全链路人工接管
SEV1 / P1面向核心用户的大面积质量 / 安全 / 稳定性事故，影响正在快速扩散立刻限流、降级、回滚或收紧 guardrails，同步业务 owner 和值班链
SEV2 / P2某一工作流、租户、模型路由或工具链明显退化，但影响面可控快速隔离问题流量，保留证据，按 runbook 做定向修复和灰度验证
SEV3 / P3局部异常、边缘场景退化、预警级成本抖动进入观察与排班处理，但必须记录证据和升级条件

这个表的重点不是名字，而是让团队在前 5 分钟就统一：

  • 现在是“观察问题”
  • 还是“必须立刻切断副作用”

8.2 AI 事故的前 15 分钟检查单 ​

很多团队的问题不是不会分析，而是现场第一批动作太慢。

更建议固定一个 15-minute triage checklist：

  1. 先确认事故级别和当前 owner。
  2. 先确认是否有真实世界副作用正在继续发生。
  3. 先关最危险的自动动作，例如 shell、写操作、审批自动放行、外呼、消息发送、数据库写回。
  4. 先锁定影响面：租户、工作流、模型路由、知识域、工具集。
  5. 先冻结变更：暂停继续发布、暂停自动切换、保留现场配置。
  6. 先抓证据：trace、版本、样例、告警、审计记录、知识索引版本。
  7. 再决定是限流、降级、灰度回退还是全量回滚。

如果前 15 分钟没有完成这几件事，后面往往会一边扩散一边排查。

8.3 不同事故桶的第一优先动作不一样 ​

  • 安全事故：优先停外部副作用、停敏感工具、停跨租户访问、保全证据。
  • 质量事故：优先切旧模型 / 旧 Prompt / 旧检索链，或强制转人工。
  • 成本事故：优先收紧高成本模型路由、长上下文、重试策略和并行工具调用。
  • 稳定性事故：优先熔断慢工具、降级多阶段工作流、缩短队列。
  • 治理事故：优先恢复审批、审计、trace 和记账链路，不要带着“无记录”状态继续跑。

9. 事故现场最好显式指定 IC / CL / OL，而不是所有人一起排查 ​

Google SRE 当前 incident response workbook 与 incident management guide 都把 ICS / IMAG 角色拆得很清楚：

  • IC 负责指挥与控制
  • CL 负责对内对外沟通
  • OL 负责技术处置

这个分工对 AI 系统尤其有用，因为 AI 事故常常同时涉及：

  • 模型行为
  • 工具执行
  • 权限与审批
  • 知识库与检索
  • 成本与队列

如果没有明确角色，现场很容易出现：

  • 所有人都在看 trace，但没人拍板止血
  • 所有人都在修问题，但没人同步业务和客服
  • 所有人都在发消息，但没人真正控制变更和恢复节奏

9.1 一个够用的 AI 事故桥接角色表 ​

角色主要职责常见人选
IC判断级别、拍板止血、决定升级与恢复节奏值班负责人、平台 owner、SRE lead
OL执行技术处置、推进排查、协调模型 / 检索 / 工具修复平台研发、SRE、Agent 平台 owner
CL对业务、客服、管理层、相关团队同步状态与下一次更新时间产品 owner、交付负责人、值班协调人
Model / Prompt lead判断模型路由、Prompt 版本、schema 和工具选择是否回退LLM / 平台工程
Retrieval / Data lead判断知识索引、召回、版本、新鲜度和过滤是否异常RAG / 数据工程
Security / Approval lead判断权限、guardrails、审批漏放与审计保全安全 / 合规 / 审批 owner

小事故可以一人兼多角，但大事故最好显式写在桥接文档里。

9.2 现场沟通要固定节奏，不要想到什么说什么 ​

Google SRE 当前资料把 communicate 放在 3Cs 里，不是附属动作。

对 AI 事故更建议固定：

  • T+0：确认事故、owner、初始影响
  • T+15：第一次止血结论和临时绕行
  • T+30：恢复路径、风险边界、下一次更新时间
  • 之后：按 30 分钟或 1 小时节奏更新，直到恢复

尤其当事故涉及：

  • 客户可见结果退化
  • 审批错误放行
  • 外部动作误执行
  • 成本异常烧穿预算

如果沟通没有固定节奏，业务侧会比技术侧更快失控。

10. AI 事故为什么特别依赖 trace、eval、版本和证据包 ​

AI 事故很多时候并不会直接抛异常，而是表现为：

  • 某类请求突然变差
  • 某个工具参数开始异常
  • 某个知识域召回开始偏
  • 某条审批链不再触发

这时最关键的证据通常来自：

  • traces
  • eval 基线
  • 变更记录
  • 知识库 / 索引版本
  • 审批和 guardrail 触发记录

OpenAI 当前 Integrations and observability、Evaluate agent workflows 与 Guardrails and human review 在 2026-07-09 复核时给出了三条非常直接的启发：

  • trace 要能看见 model calls / tool calls / handoffs / guardrails
  • trace grading 适合先从真实运行轨迹里找 regressions and failure modes
  • human review 负责敏感动作批准，guardrails 负责自动校验，不应混成同一层逻辑

没有这些证据，事故会非常难定位。

11. 事故证据包至少要包含哪些字段 ​

更建议把事故现场需要的关键证据收敛成一个固定对象，而不是临时到处翻。

11.1 最小 incident evidence packet ​

text
incident_id
severity
declared_at
owner_ic / owner_ol / owner_cl
workflow_id / tenant_id / env
model_version / prompt_version / routing_version
toolset_version / guardrail_version / approval_policy_version
retrieval_index_version / dataset_version / knowledge_release_batch
sample_trace_ids
sample_request_ids
first_bad_example
last_known_good_example
rollback_options
customer_impact_summary
external_side_effects

11.2 对 Agent / RAG 事故尤其关键的附加字段 ​

  • tool arguments 和 tool outputs
  • handoff 路径
  • guardrail 命中 / 漏放记录
  • approval pause / approve / reject 记录
  • retrieval query、filters、top-k 证据和 chunk 来源
  • token、延迟、成本、重试次数
  • 最近 24 小时变更记录

这会显著减少两种低效情况：

  • 修了半天，最后发现根本是昨天知识批次发错了
  • 讨论半天，最后发现是某个高风险工具批准策略失效

12. 更适合 AI 系统的排查顺序 ​

推荐按下面顺序推进：

  1. 先确认影响面和风险级别。
  2. 先判断是否还在持续发生外部副作用。
  3. 先决定能否通过 kill switch、限流、人工接管立即缩小影响面。
  4. 先看最近变更。
  5. 先看 traces 和关键样例回放。
  6. 再判断是模型、Prompt、检索、工具、权限还是审批层问题。
  7. 对高风险问题优先执行回滚或降级，再继续深挖。

12.1 一个实用的排查分叉树 ​

  • 如果是越权、泄露、误执行： 先停动作，再查 root cause。
  • 如果是“服务没挂但结果变差”： 先看 trace grading、样例回放、版本差异。
  • 如果是成本暴涨： 先看模型路由、重试、并行工具、长上下文和队列。
  • 如果是审批积压： 先看人工 review 队列、阈值变更、误杀率和 fallback。

这条顺序的重点是：

  • 不要把所有问题一上来都当成“模型抽风”

13. 事故前必须准备哪些开关和预案 ​

更成熟的团队通常会提前准备：

  • 高风险开关
  • 回滚路径
  • 人工接管路径
  • 事故分级标准
  • 联系人和升级链
  • 事故模板
  • Postmortem 模板
  • Runbook
  • 环境隔离与 staging 对照路径
  • 成本和速率阈值

OpenAI 当前 Production best practices 也明确建议在规模上来后把 staging 和 production 分开，并为项目设置独立的 rate / spend limits；同时通过 usage threshold 和 usage tracking dashboard 监控成本。

13.1 AI 系统值得单独准备的 kill switch ​

  • 停自动执行，只保留建议输出
  • 停某类工具，例如 shell、支付、写库、外呼、发信
  • 停高风险租户或高风险工作流
  • 停新模型 / 新 Prompt / 新检索链的流量
  • 强制切回旧索引 / 旧规则 / 旧审批策略
  • 强制进入人工 review

没有这些准备，事故响应很容易变成：

  • 临场 improvisation

而这通常会显著放大恢复时间。

14. AI 事故分级不应只按“服务可用性” ​

建议至少把下面这些维度纳入分级：

  • 是否涉及真实用户权益
  • 是否涉及高风险工具和动作
  • 是否涉及敏感数据
  • 是否已产生外部副作用
  • 是否正在扩散
  • 是否会带来合规 / 审计缺口
  • 是否会在短时间内烧穿成本预算

例如：

  • 服务可用但审批绕过
  • 服务可用但跨租户泄露
  • 服务可用但自动误执行退款或写库

这几种都不能因为“服务还活着”就被当成低优先级。

15. 恢复阶段不能只看“返回成功” ​

恢复完成不应只看：

  • 请求恢复 200

还要确认：

  • 关键质量指标是否回到正常
  • 高风险样例是否恢复
  • 审批与 guardrails 是否恢复
  • 人工接管量是否回到合理区间
  • 成本和延迟是否回稳
  • 外部副作用是否已经停止
  • 新版本是否已经冻结或替换完成
  • 告警是否恢复到可解释状态

15.1 恢复出闸条件最好写成显式清单 ​

一个更稳的 recovery exit criteria 通常包括：

  1. 至少一组代表性 bad traces 已复盘完。
  2. 修复或回滚动作已经生效，并通过样例回放。
  3. 高风险门禁样例重新跑过。
  4. 业务 owner 知道当前是否仍在灰度或带保护运行。
  5. 下一个值班人能看懂当前系统状态和未完成风险。

也就是说，恢复阶段本质上也需要：

  • 一轮验证

16. 事故后复盘真正应该产出什么 ​

很多团队复盘只写：

  • 某模型输出不稳定

但更重要的问题是：

  • 上线前为什么没发现
  • 哪道护栏失效了
  • 哪套 eval 没覆盖
  • 哪个组织角色缺位
  • 哪条回滚或降级动作不够快

Google SRE 当前资料继续强调：

  • postmortem 要尽快启动
  • 复盘要 blameless
  • 改进项要进入 backlog，而不是停在文档里

一次高质量复盘的关键产出通常应该包括：

  • 新增或修订的回归样例
  • 新增 trace grader 或 workflow grader
  • 更新后的 guardrails
  • 更新后的 runbook
  • 更新后的变更门禁
  • 更新后的值班和告警策略
  • 对外沟通模板或升级链修订
  • 明确 owner 和完成时限的 action items

如果复盘不回流到这些地方，事故知识就很难转化为长期能力。

16.1 AI 事故复盘不要只看“模型回答错了” ​

更值得问的是：

  • 检索证据为什么没挡住
  • 工具调用为什么没被 schema / policy 挡住
  • 审批为什么没 pause
  • 告警为什么没及时响
  • trace 为什么不够还原现场
  • 数据版本和变更单为什么没串起来

17. 事故响应最常见的反模式 ​

  • 事故时先争论是不是 bug
  • 没有高风险开关
  • 只有基础设施监控，没有行为监控
  • 只修当前样例，不补长期防线
  • traces / audit 不完整
  • 把 guardrails 和审批混成一个黑盒
  • 成本异常没有进入 on-call 视角
  • 复盘不进入 datasets / guardrails / checklist
  • 事故归零后不更新 runbook 和值班策略

18. 建议的建设顺序 ​

第一阶段：先建立事故分级和止血动作 ​

至少知道：

  • 哪些问题必须先关什么
  • 哪些动作必须立刻转人工
  • 哪些事故需要谁拍板

第二阶段：补 traces、评测基线和变更记录联动 ​

让定位不再全靠经验。

第三阶段：补 incident bridge、runbook 和沟通模板 ​

让团队在压力下也能执行。

第四阶段：把事故结论反哺门禁、回归和发布 ​

让同类事故下次更早被发现、更快被止血。

第五阶段：做演练和轮值训练 ​

Google SRE 当前资料仍然强调通过练习和 training 让 on-call 真正熟悉流程。对 AI 系统来说，至少要定期演：

  • 模型路由错误
  • 检索污染
  • tool misfire
  • approval backlog
  • cost runaway

19. 推荐搭配阅读 ​

20. 重点官方资源 ​

以下资源已按 2026-07-09 复核可访问：