事故记录与事后复盘链接 Schema¶

这页描述了智能体系统中事故评审的最小契约层：事故记录应该包含哪些字段，它如何与追踪、审批、发布和生命周期工件相连，以及哪些数据必须在遏制阶段之后仍然保留下来。

它也直接连接到书里的 Evidence Spine：从请求到发布判断，因为事故评审正是这条受治理链路必须保持完整的关键场景之一。

如果智能体系统事故响应手册回答的是“前几分钟和后续复盘该怎么做”，那么这页回答的是“这些内容应该以什么形式被固定下来”。

1. 为什么需要单独的事故记录¶

如果没有专门的事故工件，复盘通常会裂成几块彼此脱节的材料：

追踪在可观测性系统里；
审批历史在审计轨迹里；
回滚决策在聊天记录里；
事后复盘在文档里；
变更链接只能靠记忆回溯。

这种方式偶尔可以工作，但对重复事故、审计、回归更新和生命周期修正都很脆弱。

2. 核心实体¶

这套最小模式通常围绕两个实体展开：

incident_record
incident_postmortem_link

这已经足够把运营响应与生命周期修正连接起来。

3. 事故记录¶

incident_record 用来记录发生了什么、影响半径有多大，以及事件发生时哪些工件正在生效。

kind: incident_record
incident_id: inc-2026-04-09-001
title: "Unauthorized ticket_write path during onboarding run"
severity: sev2
status: contained
category: unauthorized_side_effect
detected_at: 2026-04-09T09:14:00Z
detected_by: automated_detection
agent_id: support-triage-ref
trace_id: trace-2026-04-09-001
session_id: session-2026-04-09-001
bundle_id: bundle-2026-04-07-a
change_id: chg-2026-04-07-001
rollout_wave: canary
tool_principal: svc-ticket-writer
approval_id: apr-2026-04-09-001
idempotency_key: ticket-req-2026-04-09-001
affected_surfaces:
  - approval_path
  - tool_gateway
  - rollout_gate
containment_actions:
  - force_mandatory_approval
  - disable_ticket_write_v1
owner: platform-operations

这里最关键的字段是：

category，它把事故与分诊分类、评测更新连接起来；
bundle_id、change_id 与 rollout_wave，它们把事故与发布纪律连接起来；
tool_principal、approval_id 与 idempotency_key，它们能更快定位真实副作用，并说明重试是否可以安全匹配已经创建的对象；
affected_surfaces，它提醒团队不要把问题缩减成单纯的模型输出。

重复工单线索的事故记录

在支持分流（support-triage）事故里，记录必须把 idempotency_key 和 trace_id、session_id、approval_id、tool_principal、bundle_id、rollout_wave 放在一起。否则，复盘就无法可靠地区分一次状态未知的写入和第二次真实的 create_ticket 副作用，也无法把事故转成评测/更新门禁。

规范事故案例（Canonical incident cases）

事故记录（incident record）应该为三个规范案例（canonical cases）留下不同的纠正路径（corrective paths）。支持分流（Support triage） 记录结果未知的写入（unknown write）、idempotency_key、重复工单恢复（duplicate-ticket recovery）和评测/更新门禁（eval/update gate）。内部知识助手（Internal knowledge assistant） 记录陈旧检索（stale retrieval）、来源归因缺口（source attribution gaps）、记忆污染（memory contamination）、访问控制违规（access control breach）和知识来源修复（knowledge provenance repair）。事件协调（Incident coordination） 记录升级延迟（escalation delay）、通知副作用（notification side effects）、响应归属缺口（response ownership gap）、交接失败（handoff failure）和事件后学习更新（post-incident learning update）。

漏洞审核路径扩展¶

这个参考 Anthropic CVD 的建议契约仅在确有事件时将 finding_id 关联到 incident_id：并非每个候选项都是事件。这是文档模式扩展，不是参考运行时已实现的字段。

字段	含义
`finding_id`, `duplicate_of`, `discovered_at`	稳定的发现项、重复关系及队列起点
`review_requested_at`, `review_events[]`	进入审核队列；审核者、独立性、时间、代码版本、结论和受保护的证据链接
`disclosure_events[]`	接收者、时间、报告链接及发送时的 `route_at_send: independently_reviewed / direct_unreviewed`
`maintainer_response`	回复时间和内容，与有效性判断分开
`severity_assessments[]`	级别、评估者、时间和适用范围
`remediation`	`unknown / pending / patched / wont_fix`、补丁版本或提交、时间及证据；风险接受需责任人与理由
`deployment_verification`	受影响资源、已安装版本、时间和回归结果；未知资源不视为已修复
`as_of`, `evidence_access_policy`	数据时效及访问、披露限制

null 表示缺少信息，不代表否定结论。保留迟到和相互矛盾的评估；发送报告、收到回复或分配 CVE 都不能证明独立审核。一项发现可对应多个公告。

以下是建议的检查场景，本次未执行：

直接报告并收到维护者回复，但无独立审核：该记录不进入独立审核分母；后续审核增加事件，不改写发送历史。
未收到回复但补丁已发布：有证据即可记录上游修复，但在验证部署前不得关闭本地风险。
一个缺陷同时有 CVE、GHSA、重复报告且安装情况未知：指标按唯一发现项计数；发布不能变成安装证明。

建议扩展：证据包与负面结果¶

灵感来自 Cloudflare Managed Defense；以下字段由本书建议，不是供应商 API 或已实现的运行时模式。

evidence_package_id、package_version、package_digest、investigation_id、tenant_id、subject、scope、window_start、window_end、collected_at、policy_version 固定快照边界。每个来源记录 API/查询版本、参数、观察时间、原始产出物引用和 coverage_gaps。
check_id、claim_id、query_ref、execution_status（completed | timeout | unavailable | denied）、match_count、coverage_ref 和 evidence_refs 描述具体检查。match_count: 0 只能用于已完成查询，不能替代错误；截断结果必须明确标记不完整。
negative_evidence_state：not_checked | checked_no_match | absence_supported。仅用于相应的负面或未知结果；正向发现单独保存。absence_supported 需要可验证的断言与范围/窗口绑定及充分覆盖证据，而不仅是零计数。
citation_validation 与 claim_support_review 分开；后者记录复核者/方法、结果和理由。其他租户、案件或证据包版本中的有效引用仍然不合法，无论文本多么可信。模型接收内容前先检查权限；允许的跨租户聚合需要单独的准入策略。
recommendation_status（supported | insufficient_evidence | needs_review）及不作建议的原因不能替代事故状态。证据不足既不表示误报，也不授予行动权限。

重新获取数据应创建与旧版本明确关联的新证据包版本，而不是改变旧结论的输入。按访问、最小化和保留政策保存产出物；摘要不授予权限，也不保证真实性。重放还需记录模型、提示和复核者版本。四个建议场景见事故协调案例。

4. 事故事后复盘链接¶

incident_postmortem_link 把某个具体事故与纠正动作、生命周期工件连接起来。

kind: incident_postmortem_link
incident_id: inc-2026-04-09-001
postmortem_id: pm-2026-04-09-001
corrective_actions:
  - change_id: chg-2026-04-09-003
  - bundle_id: bundle-2026-04-09-b
  - eval_dataset_update: eval-set-2026-04-09
  - retirement_plan: retire-ticket-write-v1
owners:
  - platform-safety
  - platform-runtime
status: open

这一层的价值在于：它迫使事故评审以具体的生命周期更新结束，而不只是停留在文字总结里。

5. 它与追踪模式的关系¶

事故记录几乎总是依赖追踪模式与事件目录：

trace_id 与 session_id 把事故连到运行历史；
策略事件说明什么被允许了；
审批事件说明是否存在人工门禁；
工具事件说明真实的副作用；
会话摘要帮助判断这是一次性运行还是更大的模式，也能看出像 failure_reason 这样的失败运行导出证据是否仍然完整。

6. 它与审批和策略包的关系¶

当团队需要快速恢复这些信息时，事故记录尤其重要：

当时激活的是哪条审批路径；
做出的决策是什么；
哪个策略包正在生效；
到底是哪一个主体执行了动作。

因此事故记录模式应该紧挨着：

7. 它与变更管理和发布的关系¶

事故评审很少止步于遏制。

团队通常还要判断：

哪个 change_id 引入了高风险路径；
哪个 rollout_gate_record 放行了它；
哪些检查没有拦住它；
是否需要回滚、受限模式或退役。

这就是为什么事故记录应该和变更评审与发布门禁模式以及生命周期工件模式相连。

8. 与参考包的关系¶

agent_runtime_ref 已经具备几类能让这套模型落地的基础构件：

追踪与会话摘要；
审批队列；
生命周期工件；
发布检查；
策略与控制链接。

即使包目前还没有存储完整的 incident_record，书里也已经可以明确这种记录至少应包含哪些字段。

9. 最小不变量¶

成熟的事故层通常有这些不变量：

每个事故都有稳定的 incident_id；
trace_id 与 session_id 会立刻被保留下来；
bundle_id、change_id 与 rollout_wave 可以在不靠猜测的情况下恢复；
遏制动作会被明确记录；
事故会连接到纠正动作；
事后复盘会推动生命周期工件、评测或策略包的更新。

10. 最常见的失败模式¶

常见问题通常包括：

事故工单根本不知道追踪和会话；
副作用看得见，但主体不清楚；
变更链接只能靠回忆拼出来；
事后复盘没有对应的纠正工件；
事故从不进入评测数据集或发布标准；
名义上已关闭的事故之后，已退役路径仍然活着。

11. 现在就该做什么¶

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

事故有稳定的 incident_id 吗？
团队能否快速恢复 trace_id、session_id、bundle_id 和 change_id？
能看出是哪一个主体和审批路径参与了事件吗？
遏制动作是否被记录？
是否存在清晰的事故→事后复盘→纠正动作链路？
事故会回流到评测、发布门禁与生命周期更新吗？