Long-Running Agents 与 Durable Execution
很多 Agent demo 都默认一件事:
任务会在一次请求里尽快完成。
真实系统里,这个前提经常不成立。
任务可能会:
- 跑很多步
- 中间等审批
- 等外部系统回调
- 碰到模型超时
- 遇到进程重启
- 被用户过一小时再接回来
这时候就进入 了 long-running agents 和 durable execution 的问题域。
参考资料主要来自:
1. Long-Running Agent 不是“多跑一会儿”
它真正意味着两件事:
- run 可能跨越多个时间片
- run 不能依赖单次进程内存活着
也就是说,系统需要回答:
- 中间进度存在哪里
- 中断后怎么恢复
- side effect 怎样避免重复执行
- 进程挂掉后怎么续上
2. Durable execution 解决什么问题
LangGraph 的定义很直接:
- 在关键点保存进度
- 之后可以从原位置恢复
- 不需要重做已经完成的部分
这套能力最适合:
- human-in-the-loop
- 长链路任务
- 容易中断的任务
- 有外部依赖的任务
重点不在“能重跑”,而在“能从上次位置继续”。
3. 最小 durable 执行图
这一层最关键的是 checkpoint,而不是 UI。
4. Durable execution 依赖什么
LangGraph 官方把要求说得很清楚,核心有 3 个:
4.1 持久化存储
也就是要有 checkpointer 或持久层,能把进度写下来。
4.2 稳定的 thread / run 标识
恢复时要知道:
- 这是哪条执行链
- 上次停在哪
- 当前该接哪一段状态
4.3 可重放但不重复副作用
这是最容易被忽略的一点。
如果恢复时会重复:
- 发邮件
- 写库
- 调支付
- 调外部 API
那 durable execution 反而会把问题放大。
5. 为什么要强调 determinism 和 idempotency
LangGraph 官方在 durable execution 文档里特别强调:
- workflow 最好尽量 deterministic
- side effect 要包装进 task
- 恢复时不要重新执行已经完成的非幂等动作
换成更直接的话,就是:
- 纯计算可以重放
- 带副作用的动作不能随便重放
6. OpenAI background mode 适合放在哪
OpenAI 的 background mode 很适合补这条线里的“异步长任务”一侧。
它解决的是:
- 请求不用一直挂着
- run 可以在后台继续
- 客户端可以轮询状态
- 必要时还能 cancel
这个模式很适合:
- 长推理任务
- 大输出任务
- 不想被同步超时卡住的场景
但它 不等于完整 durable execution。
因为 durable execution 更强调:
- checkpoint
- interrupt/resume
- 一致恢复
- 副作用控制
7. 哪些任务最需要 durable execution
最典型的是下面几类:
7.1 有人工审批的任务
例如:
- 发邮件前要审批
- 财务动作要确认
- browser / computer use 要人工放行
7.2 外部依赖多的任务
例如:
- 多次 API 调用
- 远程检索
- 长文档处理
- 多工具协作
7.3 跑得久的任务
例如:
- 研究型任务
- 多阶段报告生成
- 大规模代码分析
8. 最容易踩的坑
8.1 以为恢复就是重跑
这会导致:
- 成本翻倍
- 副作用重复
- 中间状态丢失
8.2 没有区分纯计算和副作用
如果所有步骤都按同一种方式恢复,外部动作会很危险。
8.3 把 thread id / run id 当成可选信息
一旦缺这层标识,恢复路径会非常脆弱。
8.4 checkpoint 粒度太粗
如果只在最终结果前保存一次,中间失败时基本没法恢复。