持久执行让 AI agent 在进程崩溃、超时、部署或长时间等待后恢复多步骤任务，同时避免重复已经完成的外部影响。它需要持久化进度、可安全重复的写入，以及针对结果未知调用的恢复规则。
只有重试循环并不等于持久执行。响应丢失后重新发送邮件或付款，可能恰好制造出系统原本想恢复的故障。
围绕外部影响建立工作流模型
假设一条工作流先创建发票、发送发票，再将任务标为完成。如果发送成功，但 worker 在记录成功前崩溃，下一次运行不能安全地假定操作成功或失败。
sequenceDiagram
participant W as Workflow
participant L as Operation ledger
participant E as Email provider
W->>L: Reserve send_invoice:task_442
W->>E: Send with operation key
E-->>W: Response lost
Note over W: Worker restarts
W->>L: Read operation status
W->>E: Reconcile by provider ID or key
E-->>W: Already sent
W->>L: Mark completed
W->>W: Continue from checkpoint
工作流记录说明系统原本想做什么，提供商或权威后端说明实际发生了什么。恢复过程应先核对两者，再决定是否重复调用。
将工作流与 activity 分开
工作流协调步骤、等待、分支和重试。Activity 则执行调用 API 或写入文件等外部影响。使用基于重放的引擎时，工作流决策必须保持确定性，而网络调用、时钟、随机值和提供商 SDK 应隔离在 activity 中。
Temporal 的持久执行模型记录事件历史，并通过确定性重放在故障后恢复工作流状态。你可以采用该引擎，也可以使用操作表和队列实现一个较小的状态机。核心要求相同：恢复位置必须由持久化历史决定。
让每项可重试写入都具备幂等性
为一项逻辑影响分配一个键，并在客户端、worker 和提供商重试中复用。保存第一个终态结果，并拒绝使用相同键提交不同参数。
Stripe 的幂等请求契约会保存某个键首次请求的状态码和响应体，包括失败结果。其保留规则只适用于 Stripe，但设计原则可以通用：由服务端而不是模型判断重复请求是否属于同一项操作。
如果提供商不支持幂等性，应在 adapter 周围增加操作账本。这能减少自身重试产生的重复影响，却不能证明一次超时的提供商调用已经失败。应增加结果核对查询；对于无法确认的高影响结果，则要求人工审核。
在检查点记录已经验证的事实
有效的检查点应记录已经完成的操作 ID 和下一个合法状态转换。在验证外部影响后写入检查点，并尽可能让状态转换与自身数据库写入处于同一原子事务中。
不要只为模型消息建立检查点。对话记录中的“邮件已发送”可能只是模型声明，并非提供商结果。应保存提供商消息 ID 或操作记录引用。
持久状态指南说明了如何区分任务进度、记忆和业务数据。
明确每次重试由哪一层负责
模型 SDK、HTTP 客户端、队列、工作流引擎、工具服务器和提供商都可能重试。多层叠加后，配置的三次尝试可能变成几十次调用。
每项操作都应记录：
- 哪些故障可以重试；
- 由哪一层执行重试；
- 最大尝试次数和最长持续时间；
- 退避规则与提供商速率限制信号；
- 所有尝试复用的幂等键；
- 尝试耗尽后的终态。
校验和授权失败应直接停止。遇到速率限制可以等待。写入发生网络超时后，应先核对结果再重试。模型不应根据错误字符串自行编造这些规则。
将等待视为持久状态
人工审批、计划时间、Webhook 和长期部署都属于工作流状态，而不是需要保持休眠的进程。应持久化等待条件和唤醒信号。重复信号必须安全，并且延迟审批恢复时需要再次验证其代表的用户仍有权限。
将取消公开为一项状态转换。取消应阻止后续步骤，却无法抹除已经完成的外部影响。补偿操作（例如作废发票）应与取消分开定义。
测试结果不明确的窗口
成功路径测试会漏掉最棘手的状态：服务端可能已经完成请求，但客户端没有收到响应。应在外部调用之后、完成记录之前注入故障，再由另一个 worker 恢复，并验证结果只核对一次。
还应分别在审批期间、退避期间和取消后中断。原始尝试和恢复后的运行应使用相同的工作流及操作 ID，并记录到同一条追踪中。故障恢复指南会将这些场景整理为完整运行手册。
下方的提示词会在不接触生产环境的情况下设计首次中断测试。如果预期结果只是“agent 会自行处理”，说明工作流还没有恢复契约。