过去十年，函数计算的核心卖点一直是按需触发、用完即走。代价是一个硬约束：单次执行时长有上限，进程随时可能被回收，所有状态必须外置。对于订单履约、数据管道、AI 智能体这类要跑几分钟到几小时、包含多步骤与人工审批的流程，开发者只能在函数之外再搭一套队列、状态机和调度器。

短时函数的结构性短板

这种拼装带来的复杂度集中在几处：

  • 超时天花板：主流平台单次调用上限通常在 15 分钟量级，长任务必须切段并自行续跑。
  • 状态外置：每一步的中间结果都要写入数据库或对象存储，读写与并发控制全由业务承担。
  • 重试不可控：失败重放时容易重复扣款、重复发消息，幂等逻辑被迫散落在各处。
  • 等待昂贵：等待外部回调或人工审批期间，计算资源要么被占用，要么需要额外的唤醒通道。

持久化执行成为新共识

近一年，主流云厂商与开源社区不约而同给出同一个答案：把编排逻辑写回普通代码，由运行时负责记录进度。开发者用 SDK 写出顺序执行的函数，遇到等待就挂起，运行时自动打检查点。

AWS 在 re:Invent 上预览了 Lambda Durable Functions，允许函数跨越长时间等待并保留状态；Cloudflare Workflows、Google Cloud Workflows 与 Azure Durable Functions 已把类似能力做成产品。开源侧的 Temporal、Restate、DBOS、Inngest 也把持久化执行推向更轻量的形态。

机制：事件溯源加检查点

这类运行时的底层思路接近事件溯源。每次函数返回或进入等待，引擎把结果写入持久存储并生成检查点；进程随后可以完全释放。当外部事件到来，引擎从最近的检查点重放代码，跳过已完成步骤，继续向下执行。重放要求编排代码保持确定性，时间戳、随机数和网络调用都必须包裹成步骤。

持久化执行与云上正在成熟的微虚拟机、快照恢复技术天然互补：挂起时不占用计算，恢复时用快照拉起，冷启动被压缩到毫秒级。计费模型也随之变化，从按占用时长转向按活跃执行与步骤数计量，闲置等待不再计费。

带来的变化与待解问题

对架构的直接冲击是编排层下沉。原本由业务代码维护的状态机、重试策略与补偿逻辑，被运行时接管，服务边界变得更薄。与此同时，新的约束也浮出水面：重放确定性难以调试，代码版本升级要与历史检查点兼容，跨步骤追踪需要新的可观测语义，深度依赖某家运行时还会带来迁移成本。

可以预见，函数计算正在从事件触发层演化为可承载长流程的执行底座。它未必取代工作流引擎，但会显著改变开发者划分服务与状态的默认方式：能写成顺序代码的业务，不再需要先拆成状态机。