围绕三个高风险故障定义注入点、预期终态和恢复证据，检验治理链路是否有效。
本文于 2026-09-12 补充整理，按 2026-08 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
演练要有明确预期
正常演示很容易成功：输入清楚、依赖健康、任务没有重试。故障演练关注的是最容易导致业务损害的窗口。本篇设计三个合成场景，不把它们描述为真实生产事故。
每个演练都应记录注入点、原始状态、预期终态、实际动作和恢复证据。只看到接口最终返回成功，不足以判断系统是否可靠。
场景一：工单创建成功，响应丢失
测试工单服务先保存工单，再模拟网络断开。工作进程没有拿到成功响应，并在保存结果前重启。
预期行为是任务进入结果核对，沿用同一操作 ID 查询下游；确认存在后记录成功。若下游不能按稳定标识查询，则停在待人工核对，而不是立即重发创建请求。
注入点：下游提交之后、调用方收到响应之前
关键证据：operation_id、下游工单数、任务状态变更
不应出现：新幂等键、第二张相同工单、静默标记未执行
Outbox 模式可以帮助任务事件最终送达，但不能代替外部操作的幂等与对账。演练必须观察下游记录，而不只是消息队列。
场景二：权限撤销后命中旧缓存
先让用户成功查询一份受限规范，并缓存答案；随后撤销权限，再用相同问题查询。还要测试模型已经拿到证据、但最终答案尚未发送的窗口。
预期是旧缓存不再可用，受影响回答被丢弃或重新生成，旧引用链接拒绝访问。不能只隐藏引用标题，却继续把敏感结论发给用户。
记录检索过滤条件、权限版本、缓存命中判定和发送前校验。日志中的敏感正文需要脱敏，避免测试隔离时又通过观测系统泄露数据。
场景三：模型反复要求继续检索
让模拟模型持续返回“证据不足，再搜索一次”，工具始终返回相似结果。这样可以稳定触发无进展循环，不依赖真实模型偶然失控。
预期是在调用次数、时间或 token 预算任一达到上限时停止，保存已找到的证据和停止原因。任务不能继续启动新的子任务，也不能把失败统计为正常成功。
除了最大轮次，还可以观察相同工具参数和重复证据比例，用于识别没有进展的循环。这个检测用于提前停止，不能替代硬预算。
先隔离演练环境
写工具使用测试替身，使用合成租户和数据，关闭真实通知。每次运行前重置隔离数据，运行后核对副作用清单。模型若仍使用真实供应商，应限制调用预算并记录版本。
演练本身也需要截止时间和停止入口。不能为了验证“不会无限执行”，再启动一个无法停止的测试任务。
用时间线解释结果
结果报告可以采用以下结构：
| 时间点 | 状态 | 观察 |
|---|---|---|
| T0 | RUNNING | 操作已开始 |
| T1 | OUTCOME_UNKNOWN | 响应丢失，未判定失败 |
| T2 | RECONCILING | 通过原操作 ID 查询 |
| T3 | SUCCEEDED | 下游唯一记录得到确认 |
时间线中的数值由真实运行填写，不预填恢复耗时。若实际表现与预期不符，保留失败数据，并把修复后的同一案例纳入发布回归。
架构能力很大一部分体现在如何定义失败语义。能清楚解释哪些情况可重试、哪些必须核对，通常比声称系统“具备高可用”更有信息量。
