Durable Execution · 持久化执行
"agent 跑到一半进程崩了"是 production 的家常便饭。Durable execution 是工程上"接着跑"的标准答案。
Core Curriculum
Level 2 · 工程判断
阅读时间 · 19 分钟
练习 · 建议必做
低波动
Last reviewed · 2026-04-22
你将学会什么
- 理解《Durable Execution / 持久化执行》在 agent harness / coding agent 学习路径里的核心作用。
- 能用本页给出的判断法区分“概念、机制、边界、代价”。
- 知道这页内容之后会在哪一章被复用到源码阅读或动手实践里。
学习前提
建议先读《create_agent vs 完整 Harness》；如果你是跳读，至少先看本章索引与本页 TL;DR。
这页在课程中的位置
runtime 认知层，用来分清编排、执行、持久化与产品边界。
本页 1 句话结论
"agent 跑到一半进程崩了"是 production 的家常便饭。Durable execution 是工程上"接着跑"的标准答案。
带走的判断法
先分清谁负责编排、谁负责执行、谁负责产品化，再评估复杂度。
Source Policy
课程主线：稳定 runtime 机制 + 官方实现。
TL;DR
- "Durable" 不是"持久化数据"，是"持久化 执行"——agent 跑到一半进程死了，重启后能从断点接着跑，而不是从头来。Long-horizon agent 的工程必备。
- 核心机制：每 step 写 checkpoint，重启时 load 最后一份 checkpoint 续跑。LangGraph / Inngest / Temporal / Restate 都是这套思路，差异在持久化粒度、resume 语义、idempotency 模型。
- 最难的不是"存"，是 idempotency——崩溃前已经发出去的 tool call（如
send_email）resume 时不能再发一次。这要求"side-effect" 与 "state mutation" 分开记录。
- 4 种典型 storage backend（内存 / sqlite / postgres / redis）的取舍主要在持久性 / 多租户 / 延迟三个维度。多数 agent 的甜蜜点是 postgres。
1. 没有 durable 会怎样：一个具体的反例
设想一个 agent 接到任务："找 100 个最近 release 的 GitHub repo，逐个 read README，挑出 multi-agent 相关的，整理一份清单。"
朴素 agent（无 checkpoint）的故事：
- 第 1-37 轮：跑得很顺，已经处理了 37 个 repo，写了一些笔记。
- 第 38 轮：模型在 reasoning 时遇到一个 provider rate-limit，进程异常退出。
- 用户 30 分钟后回来发现 agent 死了。整个进度全没——messages 丢了、笔记丢了。重启等于从头跑。
有 checkpoint 的版本：
- 第 38 轮崩溃，但 checkpoint #37 还在 postgres 里。
- 用户重启 agent，传
thread_id，runtime 自动 load checkpoint #37 → 接着跑。前 37 个 repo 的 message 历史完整保留。
- 用户感知是"中间停顿了几秒"，进度没丢。
2. Checkpoint 机制 · 何时存、存什么、怎么恢复
何时存
- 每 step 之后（LangGraph 默认）：粒度细，恢复点多。代价是 IO 频繁。
- 每 N step / 每 X 秒：粒度粗，可省 IO。代价是恢复时回放更多。
- 事务边界（Temporal / Inngest）：每个有持久性的"step"完成时存。粒度由开发者声明。
存什么
- 完整 state（LangGraph 默认）：把整个 state 序列化成 blob。简单、易恢复，代价是大 st
