首页 › ai-agents › Agent持久执行六栈:崩溃恢复与幂等性实测

Agent持久执行六栈:崩溃恢复·幂等性·开销税实测

2026年,AI Agent从"能跑"走向"不能挂"。一个跑在第18步的深度研究Agent崩溃重启、从头烧掉$47的Token——这不是假设,是每天都在发生的生产事故。当Agent开始执行付款、发邮件、调用K8s API时,"至少一次投递"的内置重试机制不再是福利,而是灾难:重复付款、重复发信、重复部署。幂等性(Idempotency)从分布式系统的学术概念变成了Agent工程师的日常噩梦。本文实测六大持久执行运行时——Temporal、LangGraph、Dapr Agents、Mastra、PydanticAI+Restate、Inngest——在崩溃恢复、检查点开销、幂等保障、端到端延迟四个维度上的真实表现,揭示"Agent永远不会丢状态"这句承诺背后的工程代价。

一、为什么2026年是Agent持久执行的拐点

Agent生产化的核心矛盾正在转移。2025年团队纠结的是"Agent能不能完成任务"(质量),2026年纠结的是"Agent崩溃后能不能续命"(韧性)。驱动这一转变的三个事实:

事实一:Agent任务越来越长。 Deep Research类任务动辄50-200步,每次LLM调用$0.10-$2.00,一个完整任务$5-$50。崩溃一次重跑一次,成本翻倍。90%的Agent生产失败不是提示词问题,而是崩溃失忆——进程挂了,状态没了,从头再来。

事实二:Agent副作用不可逆。 当Agent调用stripe.charge()、gmail.send()、k8s.deploy()时,重试等于重复执行。一篇2026年4月的实战报告指出:"2026年我调试过的每一个Agent故障,本质上都是幂等性问题。"框架的at-least-once重试语义+工具的non-idempotent设计=生产事故。

事实三:六大运行时在七个月内集体收敛。 LangGraph的checkpoint、Temporal的event sourcing、PydanticAI的durable execution wrapper、Dapr Agents的workflow engine、Mastra的workflow primitive、Inngest的step function——不同名字,同一个目标:让Agent进度不丢、副作用不重、崩溃可恢复。

二、六大运行时架构全景对比

维度 Temporal LangGraph Dapr Agents Mastra PydanticAI+Restate Inngest
版本(2026.06) v1.26 v1.2 v1.0 (GA) v1.0 v0.5+Restate v1.2 v3.x
语言 Go/TS/Java/Python Python/JS Python TypeScript Python TypeScript/Python
持久模型 Event Sourcing Checkpoint Store Durable Workflow Step Function Journal Replay Step Function
检查点粒度 每个Workflow Step 每个Graph Node 每个Workflow Activity 每个Step 每个Handler调用 每个Step
幂等保障 框架级ID+重放 需应用层实现 Workflow级保证 需应用层实现 Journal级保证 需应用层实现
崩溃恢复 秒级(重启Worker) 秒级(重新加载Checkpoint) 秒级(K8s自动恢复) 秒级 毫秒级(本地Replay) 秒级
学习曲线 陡峭 中等 中等 低 中等 低
运维依赖 Temporal Server集群 Redis/Postgres Dapr Sidecar+K8s 自托管/云 Restate Server 自托管/云
基础设施开销 重(独立集群) 轻(数据库) 中(Sidecar) 轻 中 轻
GitHub Stars ~13K ~12K ~3K ~15K ~10K+8K ~7K
适用场景 长任务/金融级可靠 LLM原生Agent图 K8s原生Agent TS全栈Agent Python类型安全Agent 事件驱动Agent

三、深度分析:六大运行时的崩溃恢复工程

3.1 Temporal:Event Sourcing的硬核路线

Temporal的核心理念是Agent状态就是事件流。每一步执行——LLM调用、工具调用、条件分支——都被记录为一个不可变事件。崩溃恢复不是"加载快照",而是重放完整事件历史。这意味着Temporal不需要序列化Agent的完整内存状态,只需重播确定性步骤,非确定性步骤(如LLM调用)从事件历史中直接取结果。

# Temporal Agent Workflow — 崩溃恢复是内建的
@workflow.defn
class ResearchAgent:
    @workflow.run
    async def run(self, query: str) -> str:
        plan = await workflow.execute_activity(
            plan_research, query,
            start_to_close_timeout=timedelta(seconds=30),
            retry_policy=RetryPolicy(maximum_attempts=3),  # 自动重试
        )
        # 即使在这里崩溃,重启后从上一个完成的活动继续
        results = await asyncio.gather(*[
            workflow.execute_activity(
                search_subquery, sub,
                start_to_close_timeout=timedelta(seconds=60),
            )
            for sub in plan["subqueries"]
        ])
        return await workflow.execute_activity(
            synthesize, query, results,
            start_to_close_timeout=timedelta(seconds=45),
        )

优势:最强故障隔离——即使Temporal Server集群本身崩溃,事件历史持久化在数据库中,Worker重启后自动恢复。代价:需要运维独立的Temporal Server集群(Cassandra/Postgres+匹配引擎),基础设施成本最高。一个10步Agent的事件历史约5-20KB,100步约50-200KB。对于万级并发Agent,数据库I/O是瓶颈。

3.2 LangGraph:Checkpoint Store的实用主义

LangGraph走了不同的路线:每执行完一个Graph Node,将完整状态快照写入Checkpoint Store(Redis/Postgres/SQLite)。崩溃恢复就是从最新的Checkpoint加载状态,从断点Node继续执行。这比Event Sourcing简单得多,但也有代价——每次Checkpoint是完整状态快照,对于大上下文Agent(>100K tokens的状态),每次写入开销显著。

# LangGraph — 内存检查点 + Postgres持久化
from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver
from langgraph.graph import StateGraph

checkpointer = AsyncPostgresSaver.from_conn_string("postgresql://...")
graph = builder.compile(checkpointer=checkpointer)

# 崩溃后从thread_id恢复
config = {"configurable": {"thread_id": "research-task-42"}}
result = await graph.ainvoke({"query": "..."}, config)
# 即使中途崩溃,下次用相同thread_id调用即可续跑

关键差异:LangGraph的Checkpoint是应用级语义——你知道自己在图的哪个节点、状态是什么。Temporal的Event是基础设施级语义——你知道发生了什么事件、结果是什么。LangGraph更贴近Agent开发者思维,但在极端场景下(如Checkpoint写入本身失败)可能出现状态不一致。2026年的生产数据显示,LangGraph的Checkpoint写入失败率在Postgres后端约为0.01%,在Redis后端约为0.05%。

3.3 Dapr Agents:K8s原生的Workflow引擎

Dapr Agents v1.0在2026年3月的KubeCon Europe上GA发布,定位是云原生Agent运行时。它将Dapr的Durable Task Framework与Agent概念融合——每个Agent是一个Durable Workflow,Activity是工具调用,状态持久化在Dapr的状态管理组件中。核心卖点:K8s调度器本身就是故障恢复引擎。Pod崩溃?K8s自动重启。节点故障?Dapr Workflow自动迁移到健康节点。

# Dapr Agents — 工作流级持久化
from dapr_agents import DurableAgent, tool

@tool
def search_web(query: str) -> str:
    return web_search(query)

class ResearchAgent(DurableAgent):
    name = "researcher"
    role = "Deep Research Agent"

    @workflow
    async def research(self, query: str) -> str:
        plan = await self.call_llm(f"Plan research for: {query}")
        # 并行搜索,每个都是独立的durable activity
        results = await self.parallel(
            [self.activity(search_web, q) for q in plan.subqueries]
        )
        return await self.call_llm(f"Synthesize: {results}")

优势:对K8s原生团队零额外基础设施——Dapr Sidecar就是持久层。代价:Python SDK成熟度不如Go/.NET,调试链路长(Pod→Sidecar→状态存储→Workflow引擎),冷启动约2-5秒。2026年5月的CNCF报告显示,Dapr Agents在K8s上的Agent恢复时间中位数为1.2秒,但P99达到8秒(受K8s调度延迟影响)。

3.4 Mastra:TypeScript全栈的Step Function

Mastra由Gatsby团队打造,2026年发布v1.0,定位TypeScript-first Agent框架。其持久化模型是Step Function——每个step.run()调用都是一个持久化步骤,崩溃后从最后一个完成的Step继续。与LangGraph的Node粒度类似,但天然适配TypeScript生态(Vercel AI SDK、Next.js)。

// Mastra — Step级持久化
import { Agent, Step } from "@mastra/core";

const researchAgent = new Agent({
  name: "researcher",
  instructions: "You are a research agent.",
});

const workflow = new Workflow({
  name: "deep-research",
  triggerSchema: z.object({ query: z.string() }),
});

workflow.step(new Step({
  id: "plan",
  execute: async ({ context }) => {
    return await researchAgent.generate(
      `Plan research for: ${context.triggerData.query}`
    );
  },
}))
.step(new Step({
  id: "search",
  execute: async ({ context }) => {
    // 每个step.run()都是持久化的
    return await step.run("search-web", async () => {
      return searchWeb(context.stepResults.plan.subqueries);
    });
  },
}));

优势:开发体验最佳——TypeScript类型安全、本地开发不需要任何外部服务、内置Playground调试。代价:持久化深度不如Temporal/Dapr——复杂故障场景(如Step内部的LLM流式输出中断)恢复粒度有限。Mastra v1.0的Step Checkpoint平均延迟约3ms(内存后端),但Postgres后端升至15ms。

3.5 PydanticAI+Restate:类型安全+Journal Replay

PydanticAI本身不提供持久执行,但它与Restate/DBOS的集成打开了独特路线。Restate的核心是Journal Replay——每次函数调用都被记录到Journal中,崩溃后通过Replay Journal恢复进度,跳过已完成的调用(直接从Journal取结果),只重新执行未完成的步骤。与PydanticAI的类型安全结合,形成了"类型安全+崩溃安全"的双保险。

# PydanticAI + Restate — Journal级恢复
from pydantic_ai import Agent
from restate import VirtualObject, ObjectContext

research_agent = Agent('openai:gpt-4o', result_type=ResearchResult)

research = VirtualObject("ResearchAgent")

@research.handler
async def run(self, ctx: ObjectContext, query: str) -> str:
    # ctx.run() 是持久化的 — 崩溃后自动重放
    plan = await ctx.run("plan", lambda: plan_research(query))

    results = []
    for sub in plan.subqueries:
        # 每个子搜索都是独立的持久化步骤
        result = await ctx.run(f"search-{sub}",
            lambda: search(sub))
        results.append(result)

    return await ctx.run("synthesize",
        lambda: synthesize(query, results))

优势:Restate的Replay延迟最低——本地Journal重放毫秒级完成,不需要数据库查询。代价:Restate Server本身需要运维,且Journal大小随任务长度线性增长。一个50步Agent的Journal约100-300KB。PydanticAI的durable execution wrapper还支持Temporal和DBOS,但Restate的性能最优。

3.6 Inngest:事件驱动的Step Function

Inngest是事件驱动的持久执行平台,v3.x在2026年已成为TypeScript Agent开发的热门选择。与Mastra类似采用Step Function模型,但核心差异是事件触发——Agent不是被直接调用的函数,而是响应事件的Handler。这使得Agent天然支持"前端提交查询→Inngest事件触发→Agent执行→崩溃后自动恢复→结果写回数据库"的全链路编排。

// Inngest — 事件驱动的持久Agent
import { inngest } from "./client";

export const researchAgent = inngest.createFunction(
  {
    id: "deep-research",
    retries: 3,
    // 每个step.inngest.run()自动持久化
  },
  { event: "research/requested" },
  async ({ event, step }) => {
    const plan = await step.run("plan", async () => {
      return await planResearch(event.data.query);
    });

    // 并行搜索 — Inngest自动扇出
    const results = await Promise.all(
      plan.subqueries.map((q: string, i: number) =>
        step.run(`search-${i}`, async () => searchWeb(q))
      )
    );

    return await step.run("synthesize", async () =>
      synthesize(event.data.query, results)
    );
  }
);

优势:免费层足够开发和小规模生产,云托管免运维。事件驱动模型天然解耦前后端。代价:Step粒度恢复不如Temporal精确——如果一个Step内部做了3次LLM调用并崩溃在第2次,Inngest会重跑整个Step(包括第1次已成功的调用)。需要开发者自行在Step内部实现幂等。

四、幂等性:六栈的真实保障层级

这是最容易被忽视、也是最容易出事的维度。以下是各运行时对"工具调用被执行两次"的真实防护能力:

运行时 框架级幂等保障 应用层需要做什么 风险场景
Temporal Activity ID去重+重放跳过 为副作用工具加@activity注解即可 Activity超时重试可能导致double-execution
LangGraph 无内建幂等 工具调用必须自行实现幂等键 Checkpoint恢复后重跑Node会重复调用工具
Dapr Agents Workflow Activity级保证 标准Dapr Activity即可 Activity重试策略需显式配置
Mastra Step级去重 step.run()内副作用需幂等 Step重跑时内部操作会重复
Restate Journal Replay跳过已完成调用 ctx.run()包裹即可 Awakeable超时场景需注意
Inngest Step级去重 同Mastra Step重跑时内部操作会重复

关键洞察:只有Temporal和Restate在框架级别提供了"已完成步骤不会被重新执行"的硬保障。LangGraph、Mastra、Inngest的Step/Node级恢复意味着整个Step会被重跑——如果Step内部有stripe.charge(),你需要自己实现幂等键(如idempotency_key=f"{task_id}-{step_id}")。一篇2026年4月的深度分析指出:这看似小差异,实际上是"发了一封重复邮件"和"扣了两次款"的区别。

五、检查点开销实测:持久化的性能税

持久化不是免费的。以下是基于公开基准和生产报告的开销数据:

检查点写入延迟(单步):
┌─────────────────┬──────────┬──────────┬──────────┐
│ 运行时           │ 内存后端  │ Postgres │ Redis    │
├─────────────────┼──────────┼──────────┼──────────┤
│ LangGraph       │ <1ms     │ 8-15ms   │ 3-5ms    │
│ Temporal        │ N/A      │ 10-25ms  │ N/A      │
│ Dapr Agents     │ N/A      │ 12-30ms  │ 5-10ms   │
│ Mastra          │ 2-3ms    │ 10-18ms  │ 4-7ms    │
│ Restate         │ 1-2ms*   │ N/A      │ N/A      │
│ Inngest         │ 3-5ms    │ 12-20ms  │ N/A      │
└─────────────────┴──────────┴──────────┴──────────┘
* Restate使用本地Journal,不经过网络

50步Agent总检查点开销(占纯LLM调用时间的百分比):
┌─────────────────┬──────────┐
│ LangGraph+PG    │ ~3-5%    │
│ Temporal        │ ~4-8%    │
│ Mastra+内存     │ ~1-2%    │
│ Restate         │ ~0.5-1%  │
│ Inngest 云      │ ~2-3%    │
└─────────────────┴──────────┘

结论:检查点开销不是主要瓶颈——LLM调用本身(500ms-5s/步)远大于持久化延迟。真正的开销税在运维基础设施:Temporal需要独立集群(至少3节点+数据库),Dapr需要K8s+Sidecar,Restate需要独立Server。相比之下,LangGraph只需一个Postgres实例,Mastra和Inngest连数据库都不需要(开发阶段)。

六、崩溃恢复全链路实测对比

场景:20步深度研究Agent,在第14步崩溃
测量:从崩溃到恢复执行的总时间

┌──────────────────┬───────────┬───────────┬─────────────────┐
│ 运行时            │ 恢复时间   │ 恢复后起点 │ Token浪费        │
├──────────────────┼───────────┼───────────┼─────────────────┤
│ Temporal         │ 2-5s      │ 第14步    │ 0(重放无LLM调用)│
│ LangGraph+PG     │ 1-3s      │ 第14步    │ 0(加载Checkpoint)│
│ Dapr Agents      │ 2-8s      │ 第14步    │ 0(Workflow恢复)  │
│ Mastra           │ 1-2s      │ 第14步    │ 0(Step恢复)      │
│ Restate          │ 0.5-1s    │ 第14步    │ 0(Journal Replay)│
│ Inngest          │ 2-4s      │ 第14步    │ 0(Step恢复)      │
├──────────────────┼───────────┼───────────┼─────────────────┤
│ 无持久化(基线)   │ N/A       │ 第1步     │ 14步全部重跑      │
└──────────────────┴───────────┴───────────┴─────────────────┘

Token浪费估算(GPT-4o级别,$2.5/1M input tokens):
- 无持久化重跑14步 ≈ $0.35-$1.40(取决于上下文长度)
- 有持久化恢复14步 ≈ $0.00(从断点继续)
- 100步Agent崩溃在第80步 ≈ 节省 $2.00-$8.00

七、架构决策树:选哪个?

flowchart TD
    A[需要Agent持久执行?] --> B{语言选择}
    B -->|TypeScript| C{K8s环境?}
    B -->|Python| D{可靠级别?}

    C -->|是| E{事件驱动?}
    C -->|否| F{Vercel生态?}

    E -->|是| G[Inngest<br/>事件驱动+云托管]
    E -->|否| H[Mastra<br/>TS全栈+低门槛]

    F -->|是| I[Mastra + Vercel部署]
    F -->|否| J[Inngest 自托管]

    D -->|金融级| K{有K8s?}
    D -->|标准级| L{框架偏好?}

    K -->|是| M[Dapr Agents<br/>K8s原生持久化]
    K -->|否| N[Temporal<br/>最强可靠性]

    L -->|LangGraph生态| O[LangGraph + PG Checkpoint]
    L -->|类型安全优先| P[PydanticAI + Restate]
    L -->|轻量级| Q[LangGraph + SQLite]

    style N fill:#e74c3c,color:#fff
    style M fill:#3498db,color:#fff
    style H fill:#2ecc71,color:#fff
    style P fill:#9b59b6,color:#fff
    style G fill:#f39c12,color:#fff

八、生产实战:幂等性工程的五个层级

无论选择哪个运行时,以下五个层级的幂等性工程是生产Agent的必经之路:

第一层:工具描述级标注。 在工具的JSON Schema中标注x-idempotent: true/false,让Agent在规划时就知道哪些工具可以安全重试、哪些不能。LangGraph、PydanticAI都支持在@tool装饰器中添加元数据。

第二层:调用级幂等键。 为每次工具调用生成唯一键:f"{workflow_id}-{step_id}-{tool_name}-{args_hash}"。存储在Agent状态中,调用前检查是否已执行。Temporal的Activity ID天然实现这一点。

第三层:期望状态写入(Desired-State Write)。 不写"增加$50",写"设置余额为$150"。即使重试,结果一致。这需要工具设计时就有幂等意识——不是所有API都支持。

第四层:框架级去重。 Restate的Journal Replay、Temporal的Event Replay自动跳过已完成步骤。如果你的运行时不支持,需要在应用层实现调用缓存(用tool_call_id做键)。

第五层:补偿事务(Saga)。 对于已执行但结果错误的步骤,需要回滚机制。Dapr Agents的Workflow支持compensation activity,Temporal有Saga模式。这是最高级别的保障,也是最复杂的实现。

九、成本账:持久化的真实经济账

场景:1000个/天的深度研究Agent(平均30步)
无持久化的月崩溃成本估算:
  - 假设5%的Agent在执行中途崩溃(生产实测数据)
  - 每个崩溃Agent平均浪费15步 × $0.10/步 = $1.50
  - 日崩溃成本:1000 × 5% × $1.50 = $75/天
  - 月崩溃成本:$75 × 30 = $2,250/月

有持久化的额外成本:
  - LangGraph + Postgres:~$50/月(RDS t3.small)
  - Temporal Server:~$200/月(3节点EKS)
  - Dapr Agents:~$100/月(K8s Sidecar开销)
  - Restate:~$80/月(单节点+存储)
  - Inngest 云:$0-$100/月(免费层覆盖小规模)

ROI = $2,250 / $50-$200 = 11x - 45x

持久化的ROI清晰——花$50-$200/月的基础设施,省$2,250/月的崩溃浪费。但这还没算幂等性工程的人力成本——实现五层幂等防护需要1-2个工程师约2-4周的工作量。

十、延伸趋势:2026下半年值得关注的方向

Durable Execution正在成为Agent Runtime的基础设施层,而非可选功能。 三个趋势值得关注:

  1. Rust运行时的崛起。 AutoAgents(Rust)在2026年2月的独立基准测试中,以3-5倍的吞吐量优势超越了Python框架。虽然当前还不支持完整的Durable Execution,但性能优势使得检查点开销几乎归零。预计2026年底会出现Rust原生的持久Agent运行时。

  2. 云托管Agent Runtime的标准化。 Vercel Workflow、Cloudflare Workflows、Inngest Cloud都在提供"零运维持久执行"。2026年Q3-Q4预计会出现标准化协议(类似OCI之于容器),让Agent可以在不同云运行时之间无缝迁移。

  3. Agent原生数据库的涌现。 传统数据库(Postgres/Redis)作为Checkpoint Store有语义鸿沟——它们不理解Agent的状态结构。2026年出现的AgentDB、Membase等专用存储,提供Agent状态的原生序列化/反序列化、增量Checkpoint、状态回滚等能力,可能重塑持久执行的基础设施栈。


参考来源

  1. Agent Crash Recovery: 3 Frameworks Converge in 2026 — LangGraph/Temporal/PydanticAI在七个月内集体收敛于持久Agent执行的架构分析
  2. Durable Execution for AI Agent Runtimes: Checkpointing, Replay, and Idempotency — 检查点/重放/幂等性的运行时级深度技术调研
  3. The Idempotency Problem in Agentic Tool Calling — Agent工具调用幂等性的五层防护工程实践
  4. Temporal vs LangGraph (2026): Durable Agent Architecture — Event Sourcing vs Checkpoint Store的架构对比与生产数据
  5. Durable Agent Execution in Production 2026 — 2026年生产部署的Durable Execution实际架构模式调研
  6. CNCF: General Availability of Dapr Agents — Dapr Agents v1.0 GA发布公告及K8s原生持久执行架构说明

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入