Durable Execution（持久执行）

持久执行（Durable Execution） 是一种执行基础设施模式，核心思想是：将函数中每个步骤的输入、输出、重试记录持久化到外部存储，使工作流在进程重启、崩溃或部署后能从上一个成功步骤恢复，而不是从头重新执行。

这个问题在普通后端任务里就存在，但在 Agent 工作流里被放大了两倍：一是 LLM 调用有真实成本（重跑意味着重复付费），二是 Agent 可能在执行中途已经产生了副作用（发了 Slack 消息、调用了子 Agent），重跑会造成重复副作用。

核心问题：uptime vs correctness（可用性 vs 正确性）

把 Agent 循环跑在一台服务器上，进程迟早会死——Deploy、OOM、Spot 实例回收。进程重启后，循环从第几步开始？它是否已经发过那条通知？它是否已经启动了那个子 Agent？

没有持久执行，这些问题没有答案：

循环重启，从头开始
已经完成的 LLM 调用重新执行（重复成本）
已经发送的通知再发一次（重复副作用）
已经启动的子 Agent 再启动一次（重复工作）

容器提供的是 uptime（可用性），不是 correctness（正确性）。 容器重启能让进程活回来，但无法让工作流从中断点正确续接。持久执行解决的是 correctness，而不是 uptime。

Claude Managed Agents 的 session / harness 分离是同一原则在 Agent harness 层的实现：session log 放在 harness 外部，harness 崩溃后可以由编排器 wake(session_id) 启动新 harness，读取事件日志并继续。容器或 harness 进程是否一直存活不再是正确性的前提；正确性来自外部事件日志、幂等 append 和可重放上下文。

六个关键属性

1. 步骤级检查点（Step-level Checkpointing）

每个 step.run() 完成后，其结果写入持久存储。进程重启后，已完成的步骤直接返回缓存结果，不重新执行。

2. 步骤级独立重试（Independent Step Retry）

步骤 3 失败，重试步骤 3，不重跑步骤 1 和 2。传统方式（全函数重试）在长工作流里意味着重复执行全部前置步骤，包括已经成功的 LLM 调用。

3. 子 Agent 生命周期管理

可以调用子函数/子 Agent，等待其完成（可能几小时后），并在父任务被取消时级联取消子 Agent。普通进程不具备这种父子生命周期绑定。

4. 保障事件投递（Guaranteed Event Delivery）

如果进程不在线时触发了一个事件，事件不会丢失，等进程恢复后会被消费。普通事件队列在消费者不在时可能丢失事件。

5. 内建可观察性（Built-in Observability）

每个步骤的输入、输出、重试次数、错误信息全部持久化，可以在事后查阅任意一次运行的完整执行轨迹。可观察性是执行模型的自然产出，而非事后加上的监控层。

6. 热部署（Hot-deploy without Downtime）

部署新版本函数时，不中断当前正在执行的 run。正在进行中的任务按旧版本完成，新触发的任务按新版本执行。

并发控制

持久执行引擎通常内置并发原语：

Singleton：某个函数同一时刻最多运行 N 个实例（如每个服务最多 1 个告警 triage）
限流队列：超出并发上限的任务排队等待，而不是直接失败或重复执行

这对 Agent 工作流尤其重要：如果两个健康检查同时检测到同一服务异常，触发两次 triage，没有并发控制就会产生两条重复告警。

持久执行与 LLM 成本

步骤级检查点不只是正确性问题，也是成本问题。

假设一个 5 步工作流，步骤 3 是一次 LLM 调用（成本最高的步骤），步骤 4 调用外部 API 超时失败。没有步骤级持久化，重试会重新跑步骤 1、2、3（重复 LLM 调用）才能到达步骤 4。

把这个场景放到 10 个、30 个并行 Agent，重试成本的累积不可忽视。步骤级检查点在这里同时是正确性保障和成本节约机制。

三层 Agent 执行架构

DJ Farrelly 基于持久执行提出了一个三层架构框架，用于构建生产级 Agent 循环系统：

层	角色	具体形式
Loop（循环）	Cron + 决策者	定时/事件触发，LLM 决定下一步做什么
Skill（技能）	可复用的持久工作流	多步骤、可重试、可独立部署的函数
Orchestrator（编排器）	运行一切的引擎	调度 Cron、执行步骤、管理重试、存储历史、热部署

这个框架重新表述了 Agent 系统的构成：不是"LLM + 工具"，而是"循环 + 技能 + 编排"。LLM 和工具在循环内部，编排层使整个系统在生产中可靠运转。

这里的"Skill"含义与 Skill（技能）词条（SKILL.md 文件、项目知识打包）不同——在持久执行语境里，Skill 是一个可独立部署、自带重试逻辑的持久工作流函数，是系统积累的可执行资产。

编排感知 Agent（Orchestration-Aware Agent）

持久执行基础设施上的 Agent 不只是在循环内执行任务，还可以成为编排感知 Agent（Orchestration-Aware Agent）：

Agent 将编排 SDK 作为工具使用
Agent 可以编写新的持久函数（技能），注册到编排引擎
新函数立即生效，无需人工部署
技能独立运行，不依赖创建它的 Agent 进程是否存活
另一个审查循环（review loop）定期读取运行历史，评估技能性能，必要时调用 Agent 更新技能

Agent 过程是短暂的，它的产出（技能）是持久的。 杀死 Agent 进程并重启它，已部署的技能继续运行。替换底层模型，技能继续运行。Agent 的价值不在于它的存在，而在于它构建了什么。

这一模式将 Skill（技能）从"每次对话加载的知识"升级为"独立运行的基础设施资产"——每部署一个新技能，每个循环的能力就增强一次，复利在系统层面积累，而非停留在对话层面。

失败处理的两个层次

持久执行系统通常提供两类失败处理：

瞬时错误（步骤级重试）：API 超时、网络抖动，步骤自动重试，成功后继续后续步骤，不影响其他步骤。

不可恢复错误（onFailure hook）：所有重试耗尽后，onFailure 处理器被触发。原始事件数据保留，可以通知运维、记录原因，下一次调度周期重新尝试。这不等于数据丢失，而是把"当前无法处理"和"永久失败"区分开来。

数据研发 Multi-Agent 的实践把失败语义进一步拆成三档：工具超时或检索范围不足等问题可在当前步骤重试或降级；方案评审、代码测试不通过时回退到上一个稳定检查点并重新调用对应 specialist；需求理解根本偏差、关键依赖安装失败或多轮检索仍无结果时则中止并请求人工介入。三档的重点不是名称，而是让每种错误预先绑定恢复边界，避免 Agent 在不适合自动恢复的故障上无限重试。

容器 vs 持久执行

能力	容器重启	持久执行
进程存活	✓	✓
步骤级续接	✗	✓
避免重复 LLM 调用	✗	✓
避免重复副作用	✗	✓
子 Agent 生命周期	✗	✓
事件不丢失	✗（进程不在时）	✓
可观察性	需单独搭建	内建
热部署	✗（重启中断）	✓

Snapshot 与 Rehydration

OpenAI 在 2026 年 4 月 15 日的 Agents SDK 更新中把长时 Agent 的恢复问题落到 sandbox 场景：当 Agent Sandbox（Agent 沙箱）容器失败或过期时，不能让整个 run 因为 compute 层消失而丢失。做法是把 Agent 状态外置到 Harness Engineering（驾驭工程）层，通过 snapshot 记录可恢复状态，再在新容器中 rehydrate，继续从最近 checkpoint 执行。

这和本页“容器提供 uptime，不提供 correctness”的判断一致。沙箱本身可以重建，但必须有外部 harness 记住：模型已经看过什么、哪些工具动作已经完成、工作区里哪些文件是输入/中间产物/输出，以及下一步应该从哪里继续。

彩虹部署（Rainbow Deployment）

彩虹部署 是一种专为长时任务设计的版本发布策略——与蓝绿部署（Blue-Green）或金丝雀发布（Canary Release）类似，但聚焦于不中断正在执行中的 Agent 任务。

普通的滚动部署或重启在短时任务下可以接受，但 Agent 研究任务可能持续数分钟乃至更长时间。直接切换版本会：

中断正在运行的 Agent 循环
丢失未持久化的中间状态
导致用户体验断裂

彩虹部署的做法：

旧版本继续服务所有已启动的任务，直至自然完成
新版本只接受新进入的任务
两个版本同时运行，流量按任务生命周期自然迁移
随着旧任务完成，旧版本实例逐步退场

「彩虹」得名于同时运行多个颜色标记的版本（类比调色板），相比蓝绿二值更能表达多版本并存的状态。Anthropic 在其多智能体研究系统中采用此策略。彩虹部署是步骤级检查点（Step-level Checkpointing）的自然伴侣——有持久化支撑才能安全地让旧版本任务续跑完毕。

代表性系统

Inngest（GitHub）：事件驱动的持久执行引擎，通过 step.run()、step.invoke()、cron 触发器、事件控制流、并发控制和步骤级可观察性实现上述属性。DJ Farrelly 的文章基于 Inngest 写成，并附有一个开源演示项目 utah，展示了编排感知 Agent 的完整实现。

Temporal（GitHub）：另一个持久工作流引擎，更偏向服务端 workflow orchestration，在分布式系统和长时间运行任务中被广泛使用。

Azure Durable Functions：微软在 Serverless 体系里的有状态工作流产品，“Durable"这个词在工业界的稳定化部分来自这个产品的推广。

三者的共同点：把"步骤"作为持久化的基本单位，而不是整个函数。