故障演练与复盘

演练验证具体系统假设

把“验证可靠性”改写成可证伪假设。例如：“Tool 成功但响应丢失时，Agent 会进入待对账，值班人员能从告警定位到同一幂等键，且不会产生第二次更新。”这个假设同时覆盖检测、影响限制、恢复、业务一致性和组织动作。

演练目标包含预期信号、影响预算、停止条件、通过证据和不在范围内的系统。触发错误本身不算成功；如果告警没有命中、Runbook 过时或恢复依赖作者口头提示，演练发现了真实缺口，应判为未通过并保留证据。

构造跨层故障场景

场景库按失败传播链组织，而不是平均覆盖组件。模型层包括限流、长延迟、版本漂移、错误 Tool 与结构错误；知识层包括索引过期、越权召回、引用错误和间接注入；Tool 层包括响应丢失、重复执行和部分成功；Runtime 层包括 Worker 崩溃、乱序、检查点不兼容和队列积压。

人和安全同样在系统内：审批误批、过期或无人处理，凭据撤销，域名重定向，Sandbox 逃逸尝试和数据外传。高价值场景应跨层，例如“恶意知识文档诱导 Agent 调用高风险 Tool，审批 UI 又未展示真实参数”，因为单层单元测试无法发现防线组合失效。

演练自身不能制造真实事故

优先在可重置环境执行，使用模拟 Provider、Tool 与数据。必须接近生产时，限制到专用租户、单个任务、只读能力或极小灰度，冻结不相关变更，备份必要数据，并由独立安全观察员持有紧急停止权限。副作用尽可能通过模拟或 dry-run 验证。

方案在开始前完成风险审批，列出参与者、观察者、业务 Owner、事件指挥、通信渠道、开始/终止时间、Abort 条件与恢复前置。不得在未知客户流量、无回滚或无法停止写操作的情况下“试试看”。凭据、注入载荷和敏感 Trace 按最小必要共享。

同时观察技术和组织响应

技术侧记录注入开始、首个错误、SLI 变化、告警触发、首个确认、限制影响、恢复和验证完成。Trace 应连接模型、检索、Tool、审批、状态与外部回执；日志和指标使用同一 Run ID、版本和幂等键。若只能看到“模型幻觉”，说明证据语义不足。

组织侧观察谁发现、谁担任 Incident Commander、谁负责技术处置、谁判断业务影响、谁沟通，以及 Runbook 是否在没有作者提示下可执行。Google SRE 的 Incident 生命周期资料把准备、响应、恢复和缓解视为完整闭环，演练也应覆盖这些阶段。

指标可包含 Time to Detect、Time to Mitigate、Time to Recover、未知结果数量、重复副作用、恢复后 Eval 与 Runbook 步骤成功率，但不预设漂亮目标。先记录真实演练基线，再依据风险预算设改进目标。

复盘聚焦控制为何失效

复盘先写影响、时间线、事实证据和系统条件，再区分触发因素与促成条件。案例中“网络丢包”是触发，“超时被归类为安全重试、Tool 缺幂等、终态只看模型文本、告警未覆盖未知结果”才解释影响为何扩大。

避免把根因写成“模型幻觉”或“操作员误批”。继续追问：为何模型拥有该 Tool，策略为何未校验，审批为何没展示参数，后置条件为何没核验，Trace 为何无法对账，培训和文档为何没阻止。Google SRE 的Postmortem Culture强调从失败中学习和无责文化；无责不等于无责任，而是让责任落到可改进的系统与明确 Owner。

行动项必须可验收

立即止血与结构修复分开。止血可以关闭写 Tool、降低权限或强制人工对账；结构修复包括统一幂等契约、增加未知终态、补充门禁、告警和 Runbook。每项有 Owner、优先级、截止时间、受影响资产和完成证据，不能只写“加强监控”“优化 Prompt”或“提高意识”。

// 教学用行动项 Schema
type ActionItem = {
  controlGap: string;
  change: string;
  owner: string;
  dueAt: string;
  acceptance: string[];
  verificationCase: string;
  rolloutAndRollback: string;
};

代码修复由回归测试证明，配置控制由策略测试与审计证明，告警由合成信号证明，Runbook 由非作者演练证明，架构修复由邻近变体证明。行动项完成率不是目标，真正目标是控制在相同与变体场景中生效。

验证改进真正生效

修复后重跑原场景，确认此前缺口被关闭；再改变 Provider、Tool、租户、延迟或审批条件，检查机制能否迁移。持续监控线上同类信号，但下降可能来自流量变化或上报缺失，需结合覆盖率解释。

把新失败加入 Golden Dataset、发布门禁、威胁模型、SLO 与培训；更新 Runbook 版本和资产清单。跨团队分享抽象机制、检测信号和修复模式，隐去客户、凭据和敏感拓扑。若同类行动项反复逾期，升级为路线图或治理问题，而不是继续增加复盘文档。

把演练转成可信的资深能力证据

对外表达必须先说明这是 GameDay 或案例推演，不是生产事故。讲清为什么选择该假设、如何限制影响、观察到哪些意外、你做了什么判断、哪些防线失效、如何权衡止血与长期修复，以及复验是否通过。不要编造客户影响、收入、恢复时间或团队规模。

可信证据包括去敏方案、注入代码、Trace、时间线、Runbook 差异、复盘、行动项和复验报告。即使演练未通过也有价值，只要能用事实解释缺口并关闭循环；“一切按预期”反而可能说明场景过于简单或观察不足。