很多 AI agent 平台在事故处理上，看起来已经很像成熟团队了。故障有值班、会开 incident room、会拉时间线、会写 postmortem，甚至还会列出三五条“后续行动项”。可只要你把时间拉长一点看，就会发现一种很刺眼的现实：同类故障还是会回来，只是每次触发点稍微变了一点。上一次是连接器字段漂移，这一次是 OAuth scope 变化；上一次是 review queue 卡住，这一次是 ETA 语义失真。表面上看根因不同，实际上暴露的是同一类治理债务一直没被真正关掉。
问题通常不在于团队不知道该补什么，而在于 corrective action 这一步没有被系统化追踪。postmortem 写完之后，动作项回到各个团队 backlog，优先级立刻被新需求、新事故、新上线窗口稀释。几周后再回头看，文档还在，教训也都写得很漂亮，可真正能阻止类似问题再次发生的改动并没有完成。
所以 postmortem 的价值，从来不只是把“发生了什么”解释清楚，而是把事故留下来的结构性债务真正纳入交付系统。没有 corrective action tracking，复盘就很容易变成一种让团队短暂感觉自己已经学会了教训的仪式。
建议配合 AI agent Incident Response Runbook、AI agent Connector Contract Drift Detection、AI agent Maintenance Window 与 Change Freeze 和 AI agent Version Set Pinning 与 Rollback 一起看。
根因写出来，不等于系统已经变得更安全
| Postmortem 产物 | 它解决什么 | 它解决不了什么 |
|---|---|---|
| 时间线 | 帮团队理解事故是怎样展开的 | 不能保证以后会更早发现 |
| 根因分析 | 帮团队知道哪里出了问题 | 不能保证对应修复真的会发生 |
| 行动项列表 | 给出理论上的改进方向 | 不能保证跨团队依赖真的会被推进 |
| corrective action tracking | 让动作有 owner、期限和验证证据 | 仍然需要组织承诺去维持优先级 |
很多团队其实停在第三行。他们不是不复盘，而是复盘之后没有进入真正的闭环系统。这样做的结果是，postmortem 更像知识沉淀，不像风险收口。知识当然重要，但对生产平台来说，客户更在意的是类似故障会不会被实质性减少。
真正有价值的 corrective action，不是“我们会改”，而是“改完后什么会不同”
一个动作项之所以容易失效，往往是因为它写得太像口号。比如“加强监控”“完善回滚”“增加沟通”“补齐文档”。这些都对，但没有一个能直接指导交付。更稳的 corrective action 通常具备四个要素：
- 明确 owner：不是某个团队大概负责，而是具体由谁推动到完成
- 明确期限：不是以后优化，而是在什么窗口前必须上线或验证
- 明确依赖：它会不会卡在另一个团队、另一个供应商或另一次发布上
- 明确验证：完成后怎样证明这项债务真的被收住了
如果没有最后这一层，动作项很容易在状态上显示“Done”，实际却只是代码合进去了、文档补上了，真正的风险没有被重新演练，也没有进入发布门槛。
AI agent 平台的 corrective action，最容易死在跨层依赖上
AI agent 事故的一个特殊点，是很多修复都不会只落在单一团队。一次严重的连接器事故，可能同时需要：
- 平台工程补重试和熔断边界
- 集成团队补 drift probe 与认证流程
- 支持团队更新升级交接模板
- 产品团队重写对外 ETA 语义
这就意味着 corrective action 很容易变成“大家都知道需要做，但没有一个人能单独关单”。如果没有跨团队跟踪板和统一的收口标准，动作项就会在每个团队的局部优先级里被一点点稀释，直到下一次事故把它重新拖回台前。
一个常见失败：每次都说要补 canary，下一次还是一样翻车
某团队的平台在三个月里连续发生两次版本回归。第一次复盘时，团队明确写了要补更严格的 canary 和 version set diff。文档看起来很完整，owner 也写了。问题在于，这个动作需要平台团队改发布系统、应用团队配合拆分配置、支持团队配合补充回滚观测面。由于没有统一的 corrective action tracking，这件事在各自 backlog 里都排不过当周新需求。结果第二次回归来时，团队又在 postmortem 里写了几乎同样的话。
真正修复之后，他们不是多开了一场复盘会，而是把所有 P1/P2 事故的 corrective action 放进单独的债务看板：必须有 owner、截止日期、依赖关系和验证证据；逾期动作会直接进入周度治理会，而不是继续躺在事故文档的最后一节。这个改动最明显的效果，不是 postmortem 写得更漂亮，而是重复事故开始明显下降。
如果你现在只能先补一层，先让事故债务也有老化视图
很多平台已经能看 review queue aging、incident backlog、support escalation aging，却仍然看不到 corrective action 自己在老化。这是一种很危险的盲区。因为事故债务和普通需求债务不同，它不是“以后再优化”的损失，而是“下次再出事”的概率。
如果现在只能先做一件事，比起更复杂的 postmortem 模板，更值得先补的是一张 corrective action aging board：哪些事故动作已经逾期、哪些卡在跨团队依赖、哪些虽然完成却还没验证过。把这张图做出来，团队才会真正感受到，事故并不是在复盘会结束时关闭，而是在结构性债务被清掉时才算过去。
延伸阅读：
