事故响应 playbook
Agent 系统级故障的对外沟通模板——推理失败、token 耗尽、上游模型不可用、输出严重错误。
触发条件
任一情形：
- agent 完成率全平台下降 > 20%（持续 > 15 分钟）
- 上游模型 API（Anthropic / OpenAI / 自有部署）不可用
- 同一类任务出现连续 > 5 个客户投诉同一种错误输出
- 系统性 token 计费异常（用户被多扣或被少扣 > 5%）
- 客户重要数据通过 agent 误发或泄漏
角色与责任
| 角色 | 主要责任 |
|---|---|
| 值班工程 | 第一响应；技术诊断；恢复服务 |
| 事故指挥（IC） | 协调；决定升级；批准对外沟通 |
| 客户成功（CSM） | 关键客户主动联系；收集影响范围 |
| 支持 | 处理用户工单激增；执行客户沟通模板 |
| 产品负责人 | 决定对外通告的措辞与发布范围 |
| 法务 | 涉及数据泄漏、合规事件、模型输出责任时介入 |
与 SaaS 事故的差异
Agent 产品事故有几类 SaaS 没有的形态，沟通策略不同：
1. “Agent 行为异常”vs”系统宕机”
SaaS 宕机：明确的”用得了 / 用不了”。沟通模板成熟。
Agent 行为异常：用户能用，但 agent 决策错误或质量下降。例如 prompt 被改坏导致全平台任务完成率从 95% 降到 75%——技术上服务”正常”，但客户体验事故级。
沟通要点：不能用”系统状态：正常”掩盖。需要明确公告”我们注意到 agent 在某类任务上的质量下降，正在排查”。这种透明比”假装一切正常”更能维持客户信任。
2. Token 计费异常
涉及金钱，比技术故障更敏感。
- 多扣：必须主动退款，不等客户发现；公告里说明退款时间表
- 少扣：原则上不向客户追补（信誉成本高于损失），公告里说明已修复
3. 模型输出错误导致客户损失
最严重的形态：agent 帮客户做了错误决定（发错邮件、点了错链接、写错合同条款）。
法律责任归属取决于合同条款（见 compliance），但沟通必须立即认领——agent 是产品的一部分，产品方承担首位责任，事后再追溯具体原因。
响应时间线
T+0 到 T+15 分钟
值班工程：
- 确认事故性质（哪类、严重度、影响范围）
- 启动事故频道（Slack / 战时会议室）
- 评估是否需要 IC 介入（影响 > 5% 用户或 > 1 个企业客户必须升级）
IC（如已升级）：
- 决定是否对外公告（默认是——延迟公告损失大于内部承认麻烦）
- 决定沟通范围（status page / 站内信 / 邮件主动通知）
- 指派客户成功对关键客户主动接触
T+15 到 T+60 分钟
值班工程：
- 继续技术排查与恢复
- 每 15 分钟同步进展到事故频道（无新进展也要说”无新进展”）
客户成功：
- 联系 Top 10 客户的主联系人（电话 / Slack，不是邮件）
- 主动告知事故性质与影响（而非等客户来问）
- 收集客户侧已观察到的现象
支持：
- 监控工单激增
- 执行预批准的沟通模板，避免每个客户得到不同口径
T+1 小时
IC：
- 决定是否升级（持续 > 1 小时未恢复升级到 VP 工程 + CEO）
- 发布首份对外公告（status page + 邮件）
产品负责人：
- 起草公告，包含：发生了什么、影响范围、当前进度、预计恢复时间、补偿政策（如适用）
- 法务审核（如涉及合规或客户损失）
T+恢复后
事故指挥：
- 发布”已恢复”公告
- 邮件主动联系所有受影响客户（包含 status page 上没有具体看到的，比如关键账户）
事故后 72 小时内：
- 完整事故复盘报告对外（postmortem）——agent 产品的客户对透明度的期待高于 SaaS
- 涉及数据问题的事故，72 小时内向法务确认是否触发合规通报义务（GDPR 72 小时窗口等）
沟通模板（中等严重度事故）
主题：[事故通知] agent 完成率下降事件
各位客户：
我们在 UTC HH:MM 检测到 agent 在 [任务类型] 上完成率从 ~95% 下降到 ~75%。
影响范围：约 [%] 用户的 [任务类型] 任务，预计自 HH:MM 起。
根因初步排查：[简短描述，例如"昨日 prompt 更新引入回退"]。
当前进度：[已回滚 / 正在回滚 / 调查中]。
预计恢复：[时间或"持续更新"]。
补偿：受影响时段内失败的任务我们将不计入您的本月配额，并在下月账单中体现。
我们会在每 30 分钟更新进展。最新状态：[status page link]。
事后我们会发布完整的复盘报告。
为给您带来的不便道歉。
[团队签名]关键不要做的事
- 不要在事故进行中辩护决策——客户损失正在发生，辩护”为什么这是合理的”会让事态恶化。先承认、补救，复盘里再分析根因
- 不要轻易公开承诺”再也不会发生”——agent 产品系统复杂度高，绝对承诺往往守不住；改用”我们做的具体改进措施”
- 不要让支持代替工程对客户解释技术问题——一线支持没有完整信息，错误解释会成为下一波客户不满的种子
- 不要在复盘里把责任全推给上游模型供应商——即使根因是上游，客户买的是产品方的服务；可以提及上游，但首要责任不可外推
与其他章节的衔接
- 监控指标与告警机制：operations/overview
- 模型输出责任的合规边界：compliance
- 客户主动接触的 CSM 流程：onboarding
这页有帮助吗？ 谢谢反馈。