AWS Lambda 有一个人人皆知的限制：15 分钟。

函数最多跑 15 分钟，超时就被杀掉。这个限制已经存在了好多年，也是无数开发者绕了无数弯路的根源——要跑更长的任务，你得自己实现状态保存、断点续跑、错误重试，一套下来比业务逻辑本身还复杂。

2026 年 2 月，AWS 改了这件事。

Lambda Durable Functions：单次调用还是 15 分钟，但整个工作流可以跑最长 1 年。

它解决的核心问题

AI agent 出现之后，“长时间运行"这个需求变得比以前紧迫得多。

一个典型场景：agent 接到任务"帮我起草合同，等法务审批，审批通过后发给对方”。这个流程可能需要等法务几个小时甚至几天。用传统 Lambda，你要么在等待期间一直让函数挂着（浪费钱），要么把整个流程拆成多个函数 + SQS + 状态数据库（代码量翻几倍）。

Lambda Durable Functions 让你直接写：

1
2
3
4
5
6
7
8

// 发邮件等审批，最多等 24 小时
const verification = await context.waitForCallback(
  "wait-for-approval",
  async (callbackId) => {
    await sendApprovalEmail(draft, callbackId);
  },
  { timeout: { hours: 24 } }
);

等待期间——Lambda 不收费。外部系统发回一个回调，函数从断点继续跑。

背后的机制：checkpoint + replay

Durable Functions 的核心是一套 checkpoint/replay 机制。

每次调用 context.step() 或 context.wait()，Lambda 会把当前执行状态持久化。如果中途失败，Lambda 重新调用函数，从头走代码，但已经完成的 step 直接跳过，只重跑失败的部分。

这个机制跟 Microsoft Azure Durable Functions、Temporal.io 的思路是一样的——但现在是 Lambda 原生支持，不需要额外引入框架。

关键参数：

  • 单次 invocation timeout：最长 15 分钟（不变）
  • ExecutionTimeout（整体工作流）：最长 1 年（异步调用）
  • 等待期间：不计费

为什么现在

一个字：AI agent。

过去的 serverless 工作流主要是"处理完就走"的无状态计算——API 调用、文件转换、消息处理。这类任务 15 分钟绰绰有余。

但 AI agent 的工作流完全不一样：

  • 调用 LLM 生成方案，可能需要几分钟
  • 等人工审批，可能需要几小时
  • 多个 sub-agent 并行执行，需要收集结果
  • 失败了要重试，成功了要记录

这是一个天然的"长时间、有状态、需要容错"的计算模式。Lambda Durable Functions 的产品定位页面上直接写着：“AI agent orchestration and durable workflows”。

AWS 在告诉你：这是给 AI agent 设计的。

跟现有方案比

老方案是 AWS Step Functions——专门做工作流编排的服务，配合 Lambda 使用。它的缺点是：工作流逻辑和代码逻辑分离，State Machine 的 JSON/YAML 配置繁琐，调试困难。

Lambda Durable Functions 把工作流直接写在代码里，同一个函数文件，同一套语言，逻辑更直观。

当然，两者不是完全替代关系——Step Functions 支持更复杂的可视化编排，Durable Functions 更适合"代码优先、逻辑复杂但步骤相对线性"的场景。

一句话

Lambda 的 15 分钟限制，从来都不是技术瓶颈，是产品边界。现在这个边界移到了 1 年。

对于 AI agent 工作流来说，这不是小升级——这是 serverless 终于能承接 agent 任务的信号。

发布时间：2026 年 2 月 6 日 来源：AWS Compute Blog，作者 Rahul Pisal & Ben Freiberg 文档：aws.amazon.com/lambda/lambda-durable-functions/