S40：重放、幂等、对账、补偿与审计的恢复路径

内容类型：预习教材（不代表已完成）
日期：2027-01-01
阶段：P2 · AI Systems Engineering 90
总路线：Day 130 / 360
周次：W6 · Agent Runtime & Durable Workflow
节奏：周五知识整理
状态：教材已备；学习未完成
标签：replay、reconciliation、compensation、audit、recovery

一句话定义

可靠恢复不是一个 retry 开关，而是用重放重建进度、用幂等控制重复、用对账确认外部事实、用补偿处理已知副作用，并用审计串起原因与责任。

学习目标

1. 把 W6 的五个恢复概念放入同一条因果链而不混淆。
2. 理解 event history 重放与重新执行模型/副作用的差异。
3. 能根据外部动作可查询、可逆和风险程度选择恢复路径。
4. 形成一张恢复路径图和一份简短 W6 小结。

核心知识

• Replay 读取已记录事件重建状态；正确重放应得到相同确定性状态，不代表再次发出所有命令。
• Idempotency 保护相同业务意图的重复执行，是安全重放外部 activity 的必要手段之一，但不覆盖所有未知状态。
• Reconciliation 比较内部期望与权威外部事实，产生差异并决定修复；它适合异步、迟到和不可确定的系统。
• Compensation 是新的业务动作，例如发起退款或撤回建议，不是删除历史。它可能失败，也需要自己的状态机。
• Audit 记录谁、在何时、基于什么版本和证据、为何触发哪次命令及结果。日志量大不等于审计链完整。
• 恢复策略与风险相关：只读查询可积极重试，高价值或不可逆写入应优先查询、审批和对账。

机制与推导

恢复路径可以按两个问题分叉：外部状态是否可查询？动作是否可逆？

状态已知失败 + 可安全重复 -> retry with idempotency
状态未知 + 可查询         -> query then reconcile
状态已知成功 + 需撤销     -> compensate then verify
状态未知 + 不可查询/高风险 -> pause and escalate

审计事件应关联 workflowId、causationId、correlationId、actor、bundleVersion、decision 与 effectRef。Correlation 表示同一业务旅程，causation 表示“哪个事件直接导致这个事件”。若只有 timestamp，很难从并发事件恢复因果顺序。

重放还涉及代码版本。旧 history 由 v1 逻辑产生，v2 若改变分支，直接重放可能不确定。常见做法是 workflow version marker、旧 worker 保留或显式迁移；本日只理解问题，不实现完整版本系统。

最小练习或观察步骤

1. 将 S36～S39 的案例合并成一张恢复路径图。
2. 为四类状态分别选择 replay、retry、query、reconcile、compensate、escalate 中的一项或组合。
3. 写五条审计事件，确保能用 causation id 重建先后原因。
4. 构造 workflow 代码升级导致旧 history 分支不同的反例。
5. 用自己的话写 W6 三条联系和两项边界，不做评分。
6. 若没有运行源码，只记录设计推演，不写恢复成功率。

常见误区与边界

• 将 replay 解释为重新调用模型与全部外部工具。
• 认为补偿必然恢复原状，忽略时间、费用和不可逆影响。
• reconciliation 只生成差异报表，却没有 owner 与处理状态。
• 审计记录包含决定却没有使用的 policy/bundle 版本。
• 通过删除失败事件让轨迹“更干净”，破坏因果证据。
• W6 小结不是可靠性认证，也不要求覆盖所有分布式事务模式。

系统 / 金融 / Web3 场景连接

金融核心系统常是账户余额和交易状态的权威源，AI runtime 只保存流程期望，必须周期性对账。退款是补偿动作而非数据库回滚。Web3 的权威事实来自特定链与确认深度；reorg 可能改变早期观察，恢复路径必须记录区块高度和最终性假设。

自检问题

1. replay 与 retry 的对象分别是什么？
2. 为什么 compensation 也需要验证和审计？
3. correlation 与 causation 分别支持什么分析？
4. workflow 代码升级为什么影响历史重放？

专业课程对齐

• 阅读 Temporal 官方文档 的 Event History、replay、versioning 与 failure recovery 主题，关注确定性代码和已记录 activity 结果的边界。
• 阅读 MIT 6.5840 Distributed Systems 中容错、复制状态机和一致性课程内容，把“由日志重建状态”连接到更一般的分布式系统思想。
• 阅读 Google SRE 资源 中 incident response、postmortem 与 reliability 章节入口，观察恢复动作怎样留下可学习而非归责的运营证据。

深入学习提示

用“权威事实在哪里”统领恢复选择。每遇到异常先写内部已知、外部可查询、动作可逆、风险等级，再选机制。深入时可比较 saga orchestration 与 choreography，但不必扩展实现；本周最重要的是理解不存在一个覆盖所有未知状态的 retry 配置。

学后填写区

• W6 恢复路径图：
• 一组 causation / correlation 示例：
• 一个代码版本风险：
• 三条最重要联系：
• 待复习问题：