持久化执行

链盒的流程执行是「持久化」的——执行过程中的每一步状态都被记录， 即使中途崩溃也能从断点恢复，而不是从头重跑。本篇解释这个机制如何工作。

为什么需要持久化

自动化流程可能很长：等待审批可能耗时数小时，循环处理上千条数据可能跑几十分钟。 如果执行过程只在内存里，一旦进程重启（部署、崩溃、OOM），整个流程就丢了， 必须从头再来——对生产环境是不可接受的。

断点恢复机制

链盒在每个步骤执行完成后，把当前进度（已执行到哪一步、各步的输出）持久化到数据库。 当执行被中断：

1. 进程重启后，引擎检测到中断的流程运行
2. 从最后成功完成的步骤恢复
3. 已执行过的步骤不会重跑（避免重复发消息、重复写入）
4. 从中断点继续往后执行

这保证了每一步至多执行一次——既不丢失进度，也不重复执行副作用。

断点（Wait Points）

流程在某些步骤会主动暂停等待，这些是天然的断点：

• 延迟/等待节点：等待指定时间或条件
• Webhook 触发器等待：等待外部回调（默认 AP_WEBHOOK_TIMEOUT_SECONDS=30）
• 审批节点：等待人工审批结果

到达断点时，执行状态被持久化并从内存释放，等待条件满足后再恢复。 这让链盒能高效处理大量并发等待中的流程，不占内存。

重试与回放

在运行历史中，可以对失败的流程运行执行：

• 重试：从失败的步骤重新执行（已成功的步骤不重跑）
• 回放：用相同的触发数据重新跑一遍整个流程（调试用）

这在 流程调试 时很有用—— 修复问题后不必等下次触发，直接重试即可。