为什么盲目重试是最危险的恢复方式
动作成功，响应丢了
部署、发送、创建资源或扣费可能已经在外部系统完成。客户端只看到超时，不代表动作没有发生。
状态源已经变化
崩溃期间可能有用户、CI 或另一个 Agent 继续操作。恢复时只读旧上下文，会覆盖更新后的真实状态。
部分步骤已经落盘
SQLite 写入成功但 Neo4j 同步失败，或文件已生成但索引未更新。恢复需要区分主存储与延迟同步。
旧计划已不再适用
仓库提交、依赖版本、目标页面或用户授权已经变化。恢复前必须重新绑定当前事实。
一个可靠的恢复模型包含四层
| 层 | 回答的问题 | 典型来源 |
|---|---|---|
| 检查点 | 任务上一次明确停在哪里 | 阶段、当前目标、下一步和待确认项 |
| 操作账本 | 哪些写入已提交，哪些同步待完成 | SQLite、Neo4j 延迟同步、不可变事件 |
| 长期记忆 | 过去有哪些决定、失败与约束 | 实体、FTS5、文件和可选向量召回 |
| 外部事实 | 系统现在真实是什么状态 | Git、CI、服务、供应商 API 和用户界面 |
检查点不是外部事实。它告诉 Agent 上次以为自己在哪里，但恢复时仍要重新读取仓库、服务或供应商状态，确认动作是否真的完成。
AgentMesh Runtime 如何重建状态
- 运行
agentmesh-runtime doctor，先确认 SQLite、Neo4j、同步账本和检查点健康。 - 执行
rehydrate --write-default --print-path，组合检查点、近期记忆与仓库状态。 - 读取生成的恢复快照，明确已完成、待确认、外部状态未知和下一步。
- 对可能已产生外部影响的动作先对账，不把超时自动解释为失败。
- Neo4j 曾经不可用时，在恢复后运行
sync backfill重放延迟同步。 - 由宿主 Agent执行真正的验证。Runtime 的
verify是记录脚手架，不证明业务结果正确。
恢复快照越小越好，但必须包含能让新会话做出正确下一步的证据。关于长期记忆结构，请阅读 AI Agent 持久记忆指南。
常见问题
恢复后可以直接重跑最后一条命令吗？
不一定。外部动作可能已成功但响应丢失，直接重跑会产生重复资源、重复消息或重复付费。应先读取外部事实。
Runtime 会自动验证业务结果吗？
不会。Runtime 记录和重建状态，真实结果验证仍由宿主 Agent 根据仓库、服务、供应商或用户结果完成。
Neo4j 不可用时还能恢复吗？
可以继续使用 SQLite、文件检索、检查点与同步账本；Neo4j 恢复后可 backfill 延迟同步。