智能体系统事故响应手册¶

当团队已经具备追踪、策略门禁、审批路径与发布规则，但还没有一条简明的事故处置路径时，这份手册就有用了。

它不替代关于保障、可观测性或变更管理的章节。它把这些内容收束成一条可以执行的响应路径。

1. 什么算事故¶

对智能体系统来说，事故通常不只是宕机或质量下降，还包括：

在缺少必要审批路径时产生不可逆的副作用；
策略绕过或错误的网关决策；
向未批准外部系统发起危险出口访问；
记忆污染或错误的持久写入；
绕过评测或发布门禁的发布逃逸；
可疑自治行为、类似破坏的行为，或试图隐藏动作的情况。

2. 前 15 分钟¶

前几分钟的目标不是完成全部根因分析，而是先控制影响并保留证据。

最小动作顺序通常是：

停止或收窄高风险路径。
固定追踪与会话上下文。
判断是否已经发生外部副作用。
判断是否需要禁用能力、主体或连接器。
记录事故发生时生效的包与发布波次。

3. 必须立刻保留的内容¶

如果这些工件没有在最初几分钟保留下来，事故评审很快就会退化成靠记忆回溯：

trace_id
session_id
agent_id
tool_principal
approval_id，如果涉及审批路径；
bundle_id
change_id
rollout_wave
策略决策事件；
审批决策事件；
被读取或修改的记忆记录；
allowed_egress 信息以及实际的网络路径。

4. 快速遏制动作¶

好的事故响应依赖预先设计好的遏制动作：

禁用单个能力，而不是停掉整个运行时；
把高风险动作切换成强制审批模式；
临时暂停记忆写入；
撤销连接器凭据或工具主体；
停止当前发布波次；
启用更严格的策略包。

如果这些动作不存在，事故响应很快就会变成“谁有权临时关掉什么”的争论。

5. 最小分诊分类¶

最好在一开始就把事故归入某一类：

policy_bypass
unauthorized_side_effect
dangerous_egress
memory_contamination
approval_failure
eval_escape
agentic_misalignment

这些分类不仅适合写进工单，也适合回流到评测数据集、发布门禁与事后复盘纪律。

重复工单响应路径

对于贯穿的 support-triage 事故，先冻结 create_ticket，或把它切到强制审批模式；立即保留 trace_id、session_id、approval_id、tool_principal、idempotency_key、bundle_id 和 rollout_wave；然后确认副作用是否已经发生。如果状态未知，把这次运行标记为 side_effect_unknown，不要盲目重复写入，并在下次发布前把复盘结果转成 eval/rollout gate。

6. 在追踪与事件里先查什么¶

在第一轮调查里，团队最好尽快回答这些问题：

哪个输入或检索到的上下文触发了高风险路径；
哪个策略决策放行了它；
到底是哪一个主体执行了动作；
是否存在审批请求、拒绝或绕过；
哪些记忆记录被读写；
这次运行使用的是哪个工件包；
这是单次运行，还是会话/发布波次中更大的模式。

如果追踪无法回答这些问题，那问题就不只在事故本身，也在可观测性层。

7. 什么时候该回滚，什么时候局部修复¶

并不是每次事故都需要完整回滚。只有在下面这些前提成立时，局部处置才可靠：

影响半径已经清楚；
高风险路径可以被单独隔离；
当前生效的包可以准确定位；
发布波次可以在没有隐藏依赖的情况下停止。

如果团队无法把受影响的表面与系统其他部分可靠分开，完整回滚更常见。

8. 事后复盘应该写进什么¶

一份有用的智能体系统事后复盘通常包括：

当时生效的是哪个工件包；
哪个变更评审与发布门禁放行了这条路径；
缺了哪些检查或评测；
哪些检测规则没有生效；
采取了哪种遏制动作；
接下来策略、评测、发布规则或清单要改什么。

好的事后复盘不只是留下文档，还会更新生命周期工件。

9. 现在就该做什么¶

先过一遍这份短清单，把所有回答为“否”的地方单独记下来：

能否快速禁用单个能力？
能否恢复 trace_id→session_id→bundle_id→rollout_wave？
能否明确哪个主体执行了外部调用？
审批路径及其决策是否可见？
能否临时暂停记忆写入？
遏制动作的负责人是否明确？
事故是否会回流到评测与发布门禁？