AI agent 的一个残酷现实是：进程一定会挂。可能是部署重启，可能是 OOM，可能是网络闪断，也可能只是某个执行节点突然失联。真正决定系统是不是生产级的，不是“能不能做到永不崩溃”，而是崩溃后能不能继续，而不是重复执行已经做过的动作。
很多系统虽然有 checkpoint，却仍然在 harness 故障后出问题。原因通常是 checkpoint 解决的是“从哪继续推理”，而 wake flow 解决的是“新进程怎样知道哪些 side effect 已经提交、哪些事件需要跳过、哪些状态应该重放”。两者不是一回事。
建议先结合 AI agent Session Store 设计、AI agent Checkpoint 与断点恢复、AI agent 幂等与去重实践 和 AI Agent Session Replay 调试指南 一起看。
Harness 崩了，不等于 run 应该从头来过
一个更稳的 wake 流程，至少要先回答 4 个问题：
| 问题 | 为什么关键 |
|---|---|
| 上一个进程最后 durable 到哪一步 | 决定新进程从哪读事实 |
| 哪些 side effect 已经提交 | 避免重复外发、重复写库、重复扣费 |
| 当前 run 还归谁执行 | 避免两个进程同时接管 |
| 哪些上下文应该重新组织 | 防止把旧噪音整个塞回新上下文 |
如果这四个问题回答不出来，所谓“恢复”通常只是盲目重试。
Wake flow 最关键的不是重建上下文，而是先重建执行边界
很多系统恢复时第一件事是把历史消息重新塞回模型。更稳的顺序通常正好相反：
- 先拿 lease，确认当前进程有权接管
- 读取 session 中最后 durable 的 checkpoint 与 committed side effect
- 决定哪些步骤跳过、哪些步骤重放、哪些步骤转人工确认
- 最后才组织模型需要的上下文切片
这套顺序的价值在于：先恢复事实边界，再恢复推理上下文。否则新进程可能还没弄明白外部动作做到哪了，就又开始往下跑。
失败案例：恢复时按 checkpoint 继续了，但没有检查外发动作是否已经成功
某系统在“发送账单邮件”前写了 checkpoint，但没有把邮件网关的 committed 事实写回 session。结果 harness 在发送成功后、落库前崩溃。新进程醒来时，只看到 checkpoint 尚未越过“发送邮件”这一步，于是又发了一次。
这类事故说明，checkpoint 只能告诉你“流程走到哪”，不能替代“副作用是否已提交”的事实记录。wake flow 真正要查的是：
- 最后 durable checkpoint
- 最后 committed side effect
- 对应幂等键和外部确认
这也是为什么 crash recovery 最终一定要和 idempotency、session log 一起设计。
一个最小可执行的 wake protocol
{
"runId": "run_123",
"wakeReason": "harness_crash",
"lastCheckpointId": "cp_08",
"lastCommittedEffects": [
{"type": "email_send", "idempotencyKey": "mail_88"}
],
"resumeMode": "skip_committed_and_continue"
}
这份协议的意义在于，恢复动作不再只是“把历史读回来”，而是明确说明：为什么醒、醒到哪、哪些动作必须跳过。
Crash Recovery Checklist
- harness crash 后是否先做 lease 接管，而不是直接恢复执行
- session 是否同时保存 checkpoint 和 committed side effect 事实
- wake 时是否检查幂等键与外部确认，而不是只看流程位置
- 新进程是否按 event slice 组织上下文，而不是全量历史重塞
- replay 系统是否能解释本次 wake 为何跳过或重放某一步
- 高风险 side effect 在恢复后是否支持转人工确认
这类系统最终拼的是什么
Crash recovery 真正拼的，不是“恢复速度够不够快”，而是系统能不能在新进程醒来的第一分钟内，知道哪些事情已经真实发生过。只要这一点还靠猜，系统就迟早会在重启后的那一刻，把最贵的副作用再做一遍。
延伸阅读：
