<!-- title: 存档点之争：六框架持久化横评 -->

2026 年的 Agent 框架战争，主战场已经从"谁的工具调用更准"悄悄挪到了一个更无聊却更要命的地方——**进程崩了，脑还在不在**。三家出身迥异的框架（编排派 LangGraph、工作流派 Temporal、类型派 Pydantic AI）在七个月内独立收敛到同一个结论：把 Agent 状态在每一步之间外置持久化，崩溃后从"存档点"原样续跑，而不是靠 `try/except` 重新烧一遍 token。这一轮横评聚焦**持久化与恢复（Durable Execution）**这条 2026 年的新分水岭，看六大框架谁能把"会话记忆"升级成"执行日志"，谁还停在原地。

## 一、为什么"记住聊天"不等于"能恢复"

这是整篇文章最关键的认知翻新。Zylos Research 在 2026 年 4 月的研究里一针见血：**session memory is not durable execution（会话记忆不是持久化执行）**。把聊天历史存进数据库，只能让 Agent"记得说过什么"；但它证明不了哪条 shell 命令真的执行了、哪封邮件真的发出去了、哪个人工审批真的通过了、重试会不会把副作用再踩一遍。

一个会跑十分钟的自主编码/运维 Agent，可能在一次执行里装包、改文件、提 PR、发消息、重启服务、等人类 review、几个小时后继续。只要进程在"调 API 成功但本地状态还没落盘"的瞬间崩掉，所有进度就归零。持久化执行解决的就是这一类**分布式系统的祖传故障**：它不把 Agent 运行当成一串易失的模型调用，而是在每一个有意义的边界（模型决策、工具输入、结果回执、审批决定、图状态、工作流步骤）都打一个存档点。崩溃后从存档点续跑，而不是从日志里猜、把不安全的活儿重做一遍。

衡量一条持久化栈够不够格，看四件事：**执行日志（journal）有没有、工具幂等边界清不清楚、prompt/工具版本锁不锁、能不能在最坏时刻故意制造崩溃做恢复测试**。下面六家，差就差在这四件上。

## 二、六框架持久化能力横评

| 框架（版本 / Star） | 持久化机制 | 恢复粒度 | 状态是否外置 | 上手难度 | 最佳场景 |
|---|---|---|---|---|---|
| **LangGraph** 1.0 GA / 32.0k⭐ | checkpointer 每节点落盘 | 节点级（per-node） | 是（Postgres/SQLite/内存） | 中 | 生产级有状态 Agent、HITL |
| **Temporal** + Agents SDK GA / 事件历史重放 | 事件历史 + 确定性重放 | 工作流级 + Activity 级 | 是（外部 DB） | 高 | 长时、强一致、跨多 API 编排 |
| **Pydantic AI** v1.94 / 17.1k⭐ | tenacity 重试 + 类型契约自纠 | 步骤级（校验回喂） | 部分（靠外部 store） | 低 | 类型安全、校验优先的 Agent |
| **OpenAI Agents SDK** / 26.3k⭐ | session state + 借力 Temporal | 会话级 | 部分 | 低 | OpenAI 单栈、快速上线 |
| **Microsoft Agent Framework** + Durable Task | Durable Extension / Scheduler | 步骤级 + 运行时治理 | 是 | 中高 | 企业级、治理优先、.NET 栈 |
| **Restate** / 事件溯源日志 | journaled steps + 虚拟对象 | handler 步骤级 | 是（内置 KV） | 中 | 轻量有状态 Agent、定时器/回调 |
| （对比）CrewAI 51.4k⭐ | bolt-on 记忆 | 无执行日志 | 否 | 低 | 原型、角色分工 Demo |

> Star 数据取自 Presenc AI《AI Agent Framework GitHub Rankings》（2026-05-14）。可见一个反直觉现象：**Star 最多的不等于持久化最强**——CrewAI（51k）和 AutoGen（58k）Star 远超 LangGraph（32k）和 Restate，但在"执行可恢复性"这条 2026 新赛道上反而是后两者领跑。

## 三、深度分析：六条技术路线

### 1. LangGraph：编排原生的"每节点存档"

LangGraph 1.0 在 2025 年 10 月 22 日正式 GA，把 **checkpoint-per-node（每节点检查点）**做成了核心持久化原语——每执行完一个节点就把图状态写进 checkpointer，服务器挂掉后重启时从最后一个存档点续跑。Uber、LinkedIn、Klarna 已在生产跑它。它最讨巧的地方是持久化"长在编排里"，不需要你额外引入一套工作流引擎：

```python
from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.graph import StateGraph

graph = (StateGraph(State)
         .add_node("plan", plan_node)
         .add_node("act", act_node)
         .compile(checkpointer=PostgresSaver.from_conn_string(DB_URL)))

cfg = {"configurable": {"thread_id": "order-7331"}}
graph.invoke(None, config=cfg)   # 崩溃后同 thread_id 调用 → 从最后检查点续跑
```

**优点**：thread 抽象天然支持 HITL（人工审批暂停/恢复）、时间旅行调试、多分支重放。**坑**：官方文档明确——checkpointer 只在**节点之间**持久化，单个节点内的长循环崩溃仍会丢进度，必须拆成多节点；还有两枚必须正视的安全洞：CVE-2026-27794（缓存层 pickle 反序列化 RCE，需升级 `langgraph-checkpoint` ≥ 4.0.0 并关掉 pickle 回退）、CVE-2025-67644（SQLite checkpointer 元数据过滤键 SQL 注入）。**变现**：最适合包装成"生产级 Agent 工程"训练营，HITL + 检查点重放是付费学员最买账的硬核卖点。

### 2. Temporal：工作流引擎反向吞噬 Agent

Temporal 走的是相反方向——它本来就是为分布式工作流生的，**事件历史 + 确定性重放（deterministic replay）**是它的看家本领。2026 年 3 月 23 日它 GA 了与 OpenAI Agents SDK 的集成；更具分量的是，**OpenAI 自己的 Codex 底层就跑 Temporal**，每天处理百万级编码 Agent 请求。Replay 2026 大会又发布了面向 Agent 负载的 serverless worker 和 workflow streams。

关键纪律是 **Workflow/Activity 切分**：确定性逻辑放 Workflow，LLM 调用、shell、API、文件写、随机数、墙钟时间这些非确定的东西必须隔离进 Activity，否则重放会出错。

```python
from temporalio import workflow, activity

@activity.defn
async def run_agent_step(prompt: str) -> str:
    return await agent.run(prompt)        # 非确定步骤 → 隔离到 Activity,只执行一次

@workflow.defn
class DurableAgentWorkflow:
    @workflow.run
    async def run(self, task: str) -> str:
        # 崩溃后由事件历史重放,已完成 Activity 不会重跑 → 副作用零重复
        return await workflow.execute_activity(run_agent_step, task, start_to_close_timeout=...)
```

**优点**：工业级成熟、强一致、重试/补偿/定时器/HITL 全是一等公民。**坑**：运维重（自建需 server + DB，或上 Temporal Cloud）、学习曲线陡。**变现**：定位"企业级 Agent 可靠性"咨询和认证，单价天花板最高，但门槛也最高。

### 3. Pydantic AI：把类型契约变成恢复信号

Pydantic AI（v1.94.0，2025 年 9 月起 API 稳定）走第三条路——**校验即恢复**。它的重试层基于 tenacity，直连 httpx；`Agent` 构造器直接暴露 `retries / tool_retries / output_retries`。最有意思的是：当输出校验失败，`ValidationError` 会被**自动回喂给模型**，让 Agent 针对自己的类型契约自纠。

```python
from pydantic_ai import Agent

agent = Agent(
    'openai:gpt-4o',
    retries=3, tool_retries=2, output_retries=3,   # 十行内配齐三类重试
)
# 输出不符合结构化类型 → ValidationError 回喂 → 模型按类型契约自我修正
```

**优点**：上手最快、类型安全、校验护栏是 2026 年最干净的实现。**局限**：它是"校验优先"而非"执行持久化"——它管的是单步保真，跨崩溃的多步续跑仍需外挂 store。**变现**：适合"类型安全 Agent 开发"轻量课，门槛低、受众广，但深度不及前两家。

### 4. OpenAI Agents SDK：靠 session + Temporal 撑场

OpenAI Agents Python SDK（26.3k⭐，2025-03 创建）源自实验性的 Swarm，session state 是其状态管理的核心，handoffs / guardrails / session 三件套成型。但它真正进入"持久化"段位，是**借 Temporal 的力**——上面那条 Temporal × Agents SDK GA 集成，本质是把 OpenAI 官方 Agent 跑在 Temporal 的事件历史上。单用 SDK 时恢复粒度偏会话级，要跨进程/跨崩溃续跑，组合 Temporal 几乎是 2026 的事实标准。**适合**：OpenAI 单栈团队快速上线；**不适合**：需要厂商无关、多模型路由的生产编排。**变现**：蹭 OpenAI 官方光环，做"Agents SDK 实战"引流课转化率最高。

### 5. Microsoft Agent Framework + Durable Task：把治理塞进运行时

2026 年 4 月更新的 **Durable Task for AI agents** 把 Durable Task Scheduler 定位成 Agent 框架的检查点与协调基础设施，配套 Microsoft Agent Framework 的 **Durable Extension**（给单/多 Agent 加持久化执行）。SaaSToAgent 的 2026 指南点出它最狠的一招——**runtime governance（运行时治理）**：模型只负责"提议动作"，运行时网关在动作执行**之前**拦截（工具调用、API 请求、Agent 间消息），低延迟地做 allow/block/rewrite/escalate 的确定性裁决。这正是"model proposes, runtime decides"的落地。Dapr Agents（2026-03 有 checkpoint/resume 实操）走类似路线，把 Agent 当成有身份、有 inbox、有 wake-act-persist-sleep 生命周期的 worker。**适合**：.NET/企业栈、合规重的金融医疗；**坑**：微软生态绑定深。

### 6. Restate：日志优先的轻量持久化

如果嫌 Temporal 太重，Restate 是 2026 最被低估的选项。它核心是一条**事件溯源日志**：应用代码把已完成的操作记进 journal，恢复时重放 journal 并跳过已完成的工作。SDK 暴露 `ctx.run` 式的持久化步骤、内置 KV 状态、持久定时器、以及叫 awakeables 的持久回调等待。它的哲学是"持久化是普通 handler 都能用的东西，不必非得一套独立的 workflow-worker 架构"：

```python
import restate

rs = restate.Object("orderAgent")

@rs.handler("process")
async def process(ctx, order: dict):
    paid = await ctx.run("charge", lambda: charge_card(order))  # 只执行一次;崩溃后按日志跳过 → 不重复扣款
    ctx.set("status", "paid")                                   # 内置 KV 状态
    await ctx.sleep(3600)                                       # 持久定时器,跨重启仍准
```

**优点**：轻量、Rust 内核、虚拟对象天然有状态、awakeables 让外部回调也能持久。**坑**：生态比 Temporal 小、有"重放确定性陷阱"——每个副作用都必须走 journal，否则重放会偏。**变现**：适合做"轻量持久化 Agent"差异化课程，避开 LangGraph/Temporal 红海。

## 四、四层状态模型：避免"一团乱麻"的持久化纪律

SaaSToAgent 给出的 2026 最佳实践，是把状态拆成**四层**，别全塞进一条越来越长的 transcript：

- **Working State**：本轮推理需要的瞬时状态。
- **Durable State**：必须扛过崩溃的状态（写进 checkpoint store）。
- **Memory**：值得日后复用的蒸馏知识。
- **Event Log**：行动、工具调用、审批、失败的历史审计。

四层各有自己的生命周期与留存策略，分开后 Agent 才能既快、又可观测、又好调试。Agent 的核心循环也相应变成：**事件到达 → 装载 durable state → 模型决策 → 治理网关裁决 → 执行/等审批 → 写检查点 → 睡眠等下一个事件**。下图把这条循环和四层状态、检查点存储画在一起：

```mermaid
flowchart LR
    E[事件/消息/定时器] --> L1[1 装载 Durable State]
    L1 --> L2[2 模型决策]
    L2 --> G[3 治理网关<br/>model proposes<br/>runtime decides]
    G --> L3[4 执行工具<br/>契约+幂等]
    L3 --> L4[5 写检查点]
    L4 -.崩溃恢复.-> L1
    subgraph 四层状态
      S1[Working State 本轮]
      S2[Durable State 存活]
      S3[Memory 蒸馏]
      S4[Event Log 审计]
    end
    L4 --> S2
```

## 五、2026 的真正趋势：不是二选一，而是叠层组合

bestaiweb 那篇《Agent Crash Recovery》的结论很硬：2026 的架构问题已经不是"用哪个框架"，而是"**你上持久化执行了吗**"。更强的信号是**组合（composition）**——团队已经在跑 Temporal 做宏编排、把 LangGraph 当 Temporal Activity 里的微推理，或 Temporal 包 OpenAI Agents SDK、Pydantic AI 插进两者之间做校验。框架不是在抢同一个位置，而是在**叠罗汉**。"Agent 框架"和"工作流引擎"的边界正在溶解。

```mermaid
flowchart TB
    T[Temporal 宏编排<br/>事件历史重放]
    T --> A1[Activity: LangGraph 微推理<br/>checkpoint-per-node]
    T --> A2[Activity: OpenAI Agents 步骤<br/>session state]
    T --> A3[Activity: Pydantic AI 校验自纠<br/>type contract]
    T --> HITL[Human Approval 持久等待]
    T --> R[Restate 虚拟对象<br/>轻量有状态分支]
```

被甩开的，正是那些"持久化策略还停在 `for attempt in range(3)`"、以及"2025 年中之前自研的内部状态机"——维护成本已翻倍，因为商业框架现在开箱就带重放和恢复。

## 六、按场景的推荐方案

| 你的场景 | 首选 | 理由 |
|---|---|---|
| 长时强一致、跨多 API、金融级 | **Temporal**（+ LangGraph 当 Activity） | 工业级重放、副作用零重复 |
| 生产级有状态 Agent + HITL | **LangGraph 1.0** | 检查点原生、thread 重放 |
| 类型安全、校验优先、快速上线 | **Pydantic AI** | 类型契约即恢复信号、tenacity 零摩擦 |
| OpenAI 单栈、抢速度 | **OpenAI Agents SDK + Temporal** | 官方光环 + 借力重放 |
| 轻量有状态、不想上重型引擎 | **Restate** | 日志优先、内置 KV/定时器/awakeables |
| 企业合规、运行时治理、.NET | **Microsoft Agent Framework + Durable Task** | 治理塞进运行时 |
| 纯原型/Demo | CrewAI | 易上手但无执行日志，别上生产 |

一句话收口：**2026 年，Agent 的可靠性不在"多聪明"，而在"崩了能不能从存档点接着跑"。** 选框架时先问一句"它的状态活在哪、崩溃后从哪续、副作用会不会重踩"——答案决定了你是领先两代，还是在维护一套刚被淘汰的基础设施。

---

## 参考来源

1. [Durable Execution for AI Agent Runtimes: Checkpointing, Replay, and Recovery — Zylos Research](https://zylos.ai/research/2026-04-24-durable-execution-agent-runtimes/) — 提出"会话记忆 ≠ 持久化执行"，系统对比 Temporal/Restate/Inngest/Hatchet/DBOS/Cloudflare/AWS/Azure 与 LangGraph/OpenAI Agents/AutoGen/CrewAI/Dapr/Microsoft 的持久化原语。
2. [LangGraph, Temporal, Pydantic AI: Agent Resilience in 2026 — bestaiweb.ai](https://www.bestaiweb.ai/langgraph-temporal-and-pydantic-ai-how-2026-frameworks-are-solving-agent-resilience/) — 三框架七个月内收敛到持久化执行的综述，含 LangGraph 1.0 GA、Temporal × OpenAI Agents GA、CVE-2026-27794/CVE-2025-67644 等关键事件。
3. [The 2026 Guide to Building Stateful, Durable AI Agents — SaaSToAgent](https://saastoagent.com/blog/stateful-durable-ai-agents-2026.html) — 提出"worker 而非 session"、四层状态（Working/Durable/Memory/Event Log）与运行时治理（model proposes, runtime decides）模型。
4. [AI Agent Framework GitHub Rankings May 2026 — Presenc AI](https://presenc.ai/research/ai-agent-framework-github-rankings-2026) — Top 25 框架 Star/语言/类别排名（2026-05-14 截取），用于本文 Star 与语言分布数据。
5. [Durable Task for AI agents — Microsoft Learn](https://learn.microsoft.com/en-us/azure/durable-task/sdks/durable-task-for-ai-agents) 与 [Durable Extension — Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/integrations/durable-extension) — 微软把 Durable Task Scheduler 定位为 Agent 检查点/协调基础设施的官方依据（2026-04 更新）。

> [!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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)