🏗️ 架构范式

持久化执行(Durable Execution)

别名:持久化执行Durable Execution持久工作流确定性重放Durable Workflow
分类🏗️ 架构范式
阅读时间⏱️ 16 分钟
更新时间📅 2026-10-30
条目编号ENC-ARCH-22-durable-execution
持久化执行是一种运行时架构:把长时运行工作流的每一步写入持久日志,进程崩溃、重启或迁移后从断点精确恢复执行,使智能体任务无需从头重来。

关键要点 ✦

为什么智能体需要持久化执行

传统 Web 请求的生命周期以秒计,崩溃了大不了重试;智能体任务则不同——它可能连续运行数小时、调用几十个工具、在中间等待人类审批。此时进程被杀、依赖的 API 限流、机器重启,任何一次意外都意味着状态全丢。据第三方工程媒体的梳理,2026 年长时运行的智能体工作流已从「演示可行性」进入「生产可靠性」阶段,脆弱的临时编排层不再够用。

持久化执行的思路是把「跑任务」变成「记任务」:运行时把工作流的每一步(含输入输出)写入持久日志,故障后依据日志重放到断点继续。这与本站智能体运行外壳条目(ENC-ARCH-15)互补——外壳定义智能体的边界与接口,持久化执行保证它死不掉。

核心机制:确定性重放

让重放成立的前提是确定性:同样的事件序列必须把工作流重放到完全相同的状态。工程上的标准做法是二分——外层的计划、循环与分支逻辑写成确定性代码;所有不确定的副作用(LLM 调用、工具执行、外部 HTTP 请求)推入活动单元,活动的真实结果只算一次并记入日志,此后每次重放都直接读取记录值。LLM 想返回什么都可以,初次执行时记录下来,之后就是固定输入。

这带来一组工程纪律:工作流代码不得直读系统时钟(用运行时提供的 now)、不得直接生成随机数(用运行时的 uuid)、不得调用不可重放的全局状态。违反确定性的逻辑要么放进活动,要么无处安放。Temporal 的 SDK 会在重放时标记违例,Restate 与 DBOS 则在编译或初跑阶段暴露问题。

平台谱系与选型

据 2026 年多家第三方对比文章,四条路线各有取舍。Temporal 是成熟路线:开源集群加 Temporal Cloud,SDK 覆盖 Python、TypeScript、Go、Java 与 .NET,公开用户包括 OpenAI、Replit、Cursor、Lovable、Retool,代价是要运营一个集群。Restate 是轻量路线:单个 Rust 二进制、push 模型、调用幂等内建,Vercel AI SDK 与 Pydantic AI 的一级集成使其贴近事件驱动的智能体形态,许可为 BSL 1.1(四年后转 Apache 2.0)。

DBOS 把运行时塞进进程内:以装饰器包装普通函数,状态持久到 Postgres,零新增基础设施,代价是与关系库耦合、生态较小。Inngest 面向 serverless:TypeScript 优先,适配 Vercel、Cloudflare Workers 与 Lambda,步级事件日志加托管运行时,换取的是免运维。与框架 checkpointer 的关系可以概括为一句话:短任务用检查点足够,跑得比一次部署周期更久的智能体,需要的是运行时级保障。

资本与生态信号

2026 年 9 月的两笔融资相隔约两周:Temporal 5.5 亿美元 E 轮、估值 125.5 亿美元,官方口径约 4300 家付费客户与近两万亿计费动作;柏林公司 Restate 获 Singular 领投的 2000 万美元 A 轮,Capital One Ventures 参投——金融企业对「智能体交易失败代价高」有切身感知。两笔合计 5.7 亿美元投向同一层基础设施,行业共识是持久化执行正在成为智能体栈的标配层。

生态整合同步加速:Temporal 与 OpenAI Agents SDK 的集成进入公开预览、提供官方 Google ADK 插件,并与 AWS Bedrock AgentCore 深度绑定;Restate 在 2025 年 11 月带来 Vercel AI SDK 与 Pydantic AI 的一级持久化支持并开放 Restate Cloud。Replit 采用 Restate 做智能体编排,理由是需要既快又对开发者友好的运行时。对本站条目体系而言,这一层与托管运行时(ENC-ARCH-16)共同回答「智能体跑在哪里、凭什么不丢状态」。

工程纪律与局限

采用持久化执行不是免费的。工作流版本化是现实难题:长运行会跨越多次部署,改了代码之后旧实例还能否安全重放,需要在生产事故之前设计好策略。日志写入带来的存储放大会在高步数、高并发下进入数据库指标;被投毒的工作流若没有死信队列与重试上限,一个坏输入就能占满 worker 池。这些都需要显式配置,多数平台对智能体场景并无合理默认值。

另一个常见误判是高估任务时长:不少团队为「未来-proof」选了 Temporal,最后为九秒钟的智能体运营一个集群。合理的判断顺序是先看智能体真的跑多久、是否要跨部署存活、是否有人机回环等待(ENC-ARCH-20 的 interrupt 语义在持久化运行时里天然成立),再决定引入哪一层。

🎯 应用场景

长时研究与分析智能体
数小时到数天的多步任务,跨崩溃、限流与部署持久推进,日志可完整审计。
人机回环审批流程
等待人类批准数小时甚至数天的智能体流程,状态持久挂起、批准后精确续跑。
资金与基础设施操作
多步副作用不可重复执行的场景,靠活动去重与幂等保证一致性。

✅ 最佳实践

  • 把所有非确定性副作用(LLM、工具、外部请求)放入活动单元,工作流代码保持严格确定性。
  • 在上线前明确工作流版本化策略,长运行跨越部署时才能安全重放。
  • 显式配置重试上限与死信处理,防止异常输入占满 worker 池。
  • 按任务真实时长选型:分钟级短任务用框架 checkpointer 即可,跨小时跨部署的任务再引入持久化运行时。
  • 对许可证敏感的团队核对 Restate 的 BSL 条款与转 Apache 2.0 的时间表。

🔮 未来展望

持久化执行正从分布式系统工具演变为智能体基础设施的公共层:预计会与 MCP、A2A 等协议及托管运行时进一步融合,智能体框架的 checkpointer 与独立运行时之间的边界会更清晰。随着常驻型智能体与人机回环成为主流形态,「任何公司都会用上持久化执行」正在从判断变成默认假设。

📖 相关条目

🛠️ 相关产品

🏷️ 标签架构范式持久化执行工作流可靠性事件溯源基础设施