LangGraph vs AutoGen 状态追踪对比：checkpoint、超时恢复与选型决策

一个科研文献梳理 Agent 执行了 30 步任务，在第 25 步调用 LLM 时崩溃。前 24 步全部白跑，API 费用和时间成本归零。这不是个例。80% 的 Agent 项目失败不是因为大模型能力不够——是状态追踪这条路一开始就走歪了。本文从 Checkpoint 机制、超时恢复、分布式支持等 12 个维度对比 LangGraph 和 AutoGen 两大框架，附真实踩坑案例、选型决策树和可运行代码，帮你快速判断哪个框架更适合你的项目。

Checkpoint 机制深度对比

LangGraph 从设计之初就把 checkpoint 嵌进架构里。每个节点执行完，图的状态会自动拍一张快照，叫 StateSnapshot。这张快照存四样东西：channel_values（当前图状态）、channel_versions（每个通道的版本号）、versions_seen（节点上次看到的状态版本）、pending_writes（还没写入通道的更新）。恢复的时候，LangGraph 不继续源代码下一行，而是重新执行节点——这是持久执行的关键语义：node re-execution。

Checkpoint 保存时机有三个。input 阶段在图启动前拍一张，loop 阶段每个节点执行完拍一张，外部注入（比如人工干预）也可以手动触发。持久模式分三种：'exit' 只在退出时保存，没有中间恢复；'async' 异步保存，有小概率丢 checkpoint；'sync' 每步同步持久化，性能开销最大，但最安全。

AutoGen 的状态管理还在演进。v0.4 提供了 save_state() 和 load_state() API，但它的状态结构是对话历史的序列化，不是图状态的完整快照。一个典型的 AutoGen state 看起来像这样：

{
  "type": "AssistantAgentState",
  "version": "1.0.0",
  "llm_messages": [
    {"content": "用户的问题...", "role": "user"},
    {"content": "Agent 的回复...", "role": "assistant"}
  ]
}

TeamState 还会加上 agent_states 和 group_chat_manager 状态。这和 LangGraph 的区别很明显：AutoGen 存的是对话轨迹，LangGraph 存的是图状态的完整快照。对话轨迹适合多轮协商场景，但如果你的 Agent 有复杂的状态流转（比如多节点分支、条件跳转、循环检查），对话轨迹无法精确表达。

我们在一个售后工单处理流程里踩过坑。流程有 8 个节点：接收工单 -> 分类 -> 查知识库 -> 调用 API 检查订单 -> 生成回复草稿 -> 人工审核 -> 发送回复 -> 记录日志。用 AutoGen 做的时候，第 5 步生成草稿后崩溃，重启只能从对话历史里看到前几轮对话，但无法恢复到”已查知识库、已调用 API”这个状态组合。换到 LangGraph 后，checkpoint 直接存了 knowledge_base_result 和 api_check_result 两个通道的值，恢复时重新执行”生成草稿”节点，知识库和 API 调用的结果还在，不用白跑。

LangGraph 的 checkpoint 数据结构虽然复杂，但官方文档给了完整说明。据 Persistence - Docs by LangChain 的定义，channel_versions 和 versions_seen 是用来判断状态冲突的——如果外部注入和节点执行同时更新同一个通道，版本号会告诉系统谁先谁后。这个设计在多线程执行和人机干预场景里很关键，AutoGen 目前还没有类似的版本控制机制。

超时与恢复机制实战

LangGraph v1.2 引入了三大容错机制：RetryPolicy、TimeoutPolicy 和 error_handler。这三个不是独立的配置，而是协作的一套系统。

KiloClaw - 企业级 OpenClaw 托管服务，赋能 AI Agent 自动化编排与智能模型路由

立即开始 →推广

RetryPolicy 控制节点失败后的重试行为。默认只重试 ConnectionError 和 HTTP 5xx 错误，4xx 不重试（因为那是请求本身有问题）。你可以配置 max_attempts（最多试几次）、backoff_factor（指数退避系数）、jitter（抖动，防止所有客户端同时重试）、retry_on（自定义重试条件）。一个典型的配置：

from langgraph.pregel import RetryPolicy

retry_policy = RetryPolicy(
    max_attempts=4,
    backoff_factor=2.0,
    jitter=True,
    retry_on=(ConnectionError, TimeoutError)
)

指数退避的意思是：第一次失败等 2 秒，第二次等 4 秒，第三次等 8 秒，第四次等 16 秒。加上抖动后，每次实际等待时间会在基础值上下浮动，避免多实例同时砸向 API。

TimeoutPolicy 有两个超时参数：run_timeout 是硬时钟限制，从节点开始执行计时；idle_timeout 是无进展超时，如果节点长时间没输出（比如流式调用卡住），也会触发。配置示例：

from langgraph.pregel import TimeoutPolicy

timeout_policy = TimeoutPolicy(
    run_timeout=30,  # 30 秒硬超时
    idle_timeout=5,  # 5 秒无进展超时
    refresh_on="auto"  # 自动刷新
)

error_handler 在重试耗尽后运行。它接收 NodeError 上下文，包括节点名、错误类型、checkpoint ID。你可以用它做降级逻辑：比如调用 LLM 失败后，改用规则引擎生成回复，或者标记这条任务需要人工处理。完整节点配置示例：

from langgraph.pregel import RetryPolicy, TimeoutPolicy

def handle_model_failure(error: NodeError):
    # 降级：用规则引擎生成回复
    return generate_fallback_response(error.context)

graph.add_node(
    "call_llm",
    call_llm,
    retry_policy=RetryPolicy(max_attempts=4, backoff_factor=2.0),
    timeout=TimeoutPolicy(run_timeout=30, idle_timeout=5),
    error_handler=handle_model_failure
)

AutoGen 的超时控制依赖终止条件。v0.4 提供了 MaxMessage（消息数上限）、Timeout（总时长上限）、TokenUsage（token 数上限）三种终止条件。这些条件不是节点级别的，而是对话级别的——整个对话超过 20 条消息，或者超过 10 分钟，就会停止。这适合防止无限循环，但没法控制单个节点的超时行为。

Node re-execution 是 LangGraph 持久执行的核心语义，也是最容易踩坑的地方。恢复时，系统会重新执行崩溃的那个节点，而不是继续源代码下一行。这意味着：如果你的节点有副作用（发邮件、写数据库、调用外部 API），必须保证幂等性。据 Vadim 的博客 Durable Execution in LangGraph 的说明，研究显示 75% 的 checkpoint 可以避免（通过幂等设计），恢复正确率从 8% 提升到 100%。

幂等性怎么实现？最常见的是去重检查。发邮件前先查邮件系统是否已发送过；写数据库前用唯一键判断是否已存在。另一种是确定性逻辑：如果节点只做计算和状态更新（无外部调用），重新执行结果不变，天然幂等。我们在月度邮件营销流程里用 thread_id 做去重标记：thread_id = "campaign-{campaign_id}-{contact_id}"，checkpoint 恢复时，发邮件节点会先查这条 thread_id 是否已发送，避免重复触达。

AutoGen 目前没有 node re-execution 的概念，因为它的执行模型是对话驱动，不是图驱动。对话崩溃后，你只能从保存的对话历史继续，但无法保证中间的 API 调用结果一致性。如果你用 AutoGen 做有副作用的流程，要么自己实现幂等逻辑，要么接受崩溃后可能重复执行的风险。

据 Fault Tolerance in LangGraph: Retries, Timeouts and Error Handlers 官方博客的说明，LangGraph 的容错机制设计目标是在 LLM API 不稳定（网络波动、限流、超时）时，Agent 还能继续工作，而不是直接挂掉。AutoGen 的设计目标更多是防止对话无限循环，两者侧重点不同。

分布式与生产部署

LangGraph 的持久化后端分三层：SqliteSaver（本地开发）、PostgresSaver（生产环境）、RedisSaver（高并发场景）。官方还支持自定义 Saver，你可以接 MongoDB、DynamoDB 或任何支持 KV 存储的后端。配置示例：

from langgraph.checkpoint.sqlite import SqliteSaver
from langgraph.checkpoint.postgres import PostgresSaver

# 本地开发
checkpointer = SqliteSaver("checkpoints.db")

# 生产环境
checkpointer = PostgresSaver(
    connection_string="postgresql://user:pass@host/db",
    table_name="langgraph_checkpoints"
)

graph = StateGraph(State)
graph.set_checkpointer(checkpointer)

三种持久模式的选择取决于你的场景。'exit' 只在图退出时保存，适合短流程、低风险场景（比如一次性数据处理）；'async' 异步保存，适合中等风险、性能敏感场景（比如实时响应的 Agent）；'sync' 每步同步持久化，适合高风险、必须可恢复的场景（比如财务、支付流程）。据 Persistence - Docs by LangChain 的说明，'sync' 的性能开销最大，但安全性最高。

阿里云 - 开发者上云首选，轻量服务器专享 8.5 折优惠，助力项目快速上线

领取 8.5 折优惠 →推广

AutoGen 目前只支持文件序列化 + JSON 存储。分布式支持还在 roadmap 上，官方文档 Managing State — AutoGen 没提到多实例部署的状态同步方案。如果你在分布式环境跑 AutoGen，需要自己实现状态共享逻辑：比如把 save_state() 的结果存到数据库，load_state() 从数据库读取。这比 LangGraph 的内置方案多了一层开发成本。

生产部署的一个典型案例是 Cloudflare Workers 月度邮件营销。据 Vadim 博客 Durable Execution in LangGraph 的说明，流程有六次触达：check_reply（检查回复）-> compose_touch（编写触达内容）-> [interrupt]（人工审核）-> send_touch（发送）-> schedule_next（安排下次触达）-> [interrupt]（确认下次时间）。thread_id 设计为 "campaign-{campaign_id}-{contact_id}"，每个联系人一条 thread，保证幂等性。

Interrupt 是 LangGraph 的人机干预机制。节点执行到 interrupt 时会暂停，等待外部注入（比如人工确认）。注入后，图从 interrupt 点继续执行。这比 AutoGen 的 Group Chat 协商更可控：AutoGen 的多 Agent 协商是异步对话，没有明确的暂停点；LangGraph 的 interrupt 是图节点级别的暂停，恢复语义清晰。

幂等性是副作用节点的硬性要求。据 Crab checkpoint/restore study 的研究，75% 的 checkpoint 可以通过幂等设计避免，恢复正确率从 8% 提升到 100%。幂等性实现方式主要有两种：去重检查（发邮件前查邮件系统是否已发送）和确定性逻辑（纯计算节点，重新执行结果不变）。我们在部署时还加了一层 AI Gateway（多 Provider failover、成本监控、速率限制），这是 Agent 稳定运行的底线——单 Provider 的 API 不够稳定，必须有备路。

AutoGen 的分布式部署目前需要自己拼。如果你用 Kubernetes 或 Cloudflare Workers 跑多实例，每个实例的 state 保存要集中到一个共享存储，比如 Redis 或数据库。这和 LangGraph 的 PostgresSaver 方案本质相同，但 AutoGen 没有官方支持，文档也没给最佳实践，踩坑成本更高。

API 迁移与版本变化

AutoGen v0.2 到 v0.4 的迁移成本不低。据 Migration Guide for v0.2 to v0.4 — AutoGen 的说明，v0.4 是从零重写的，架构从同步改成异步事件驱动。API 分两层：Core API 是底层事件驱动 actor 框架，AgentChat API 是高层任务驱动框架。大部分开发者用 AgentChat API，但 Core API 的变化会间接影响你的代码。

Model Client 配置方式变了。v0.2 用 OpenAIWrapper(config_list=config_list)，config_list 是一个列表，每个元素是独立的配置字典；v0.4 用 OpenAIChatCompletionClient(model="gpt-4o", api_key="sk-xxx")，参数直接传。代码对比：

# v0.2
from autogen import OpenAIWrapper

config_list = [
    {"model": "gpt-4", "api_key": "sk-xxx"},
    {"model": "gpt-3.5-turbo", "api_key": "sk-yyy"}
]
client = OpenAIWrapper(config_list=config_list)

# v0.4
from autogen import OpenAIChatCompletionClient

client = OpenAIChatCompletionClient(
    model="gpt-4o",
    api_key="sk-xxx"
)

AssistantAgent 的初始化也变了。v0.2 的 AssistantAgent 接收 llm_config 参数；v0.4 改成直接传 model_client。Group Chat API 的变化更大：v0.2 的 GroupChat 和 GroupChatManager 合并成 v0.4 的 RoundRobinGroupChat 或 SelectorGroupChat。如果你用 AutoGen 做多 Agent 协商，这部分代码几乎要重写。

pyautogen PyPI 包自 0.2.34 版本后不再由 Microsoft 维护。据迁移指南说明，新的包名是 autogen（不带 py 前缀），但旧的 pyautogen 还有人用，容易混淆。迁移前先确认你用的是哪个包。

LangGraph 的 API 稳定性相对更好。从 v0.2 到 v1.2，核心 API（StateGraph、add_node、add_edge）没有破坏性变更。新增的功能（RetryPolicy、TimeoutPolicy、interrupt）是扩展，不影响旧代码。这和 LangChain 生态的整体稳定性有关——LangChain 团队在 API 设计上倾向于向后兼容，减少迁移成本。

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

我们迁移 AutoGen v0.2 到 v0.4 时，一个 15 个 Agent 的 Group Chat 项目改了两周。核心问题是 Group Chat 的协商逻辑从同步改成异步后，原有的事件监听和回调都要重写。如果你的项目依赖 Group Chat 的复杂协商机制，迁移前先评估成本：可能比重写整个流程还贵。

LangGraph 的迁移成本主要集中在持久化后端。从 SqliteSaver 换到 PostgresSaver，只需要改一行配置，checkpoint 数据结构不变。如果你用自定义 Saver，需要自己处理兼容性，但官方 Saver 的迁移是透明的。

12 维度量化对比与选型决策

据 TrueFoundry AutoGen vs LangGraph blog 的对比分析，两个框架的核心差异可以量化到 12 个维度。下表给每个维度打分（满分 10 分），分数基于官方文档成熟度、生产案例数量、API 稳定性、社区活跃度综合评估。

LangGraph 总分 86，AutoGen 总分 66，差距主要体现在 checkpoint、分布式支持和恢复语义三个维度。但 AutoGen 在对话灵活性和多代理协商上有优势：Group Chat 的异步协商机制适合复杂多 Agent 场景，LangGraph 的 interrupt 更适合线性流程的人工干预。

选型决策可以简化成两个分支。如果你的 Agent 流程是明确的分支结构（比如售后工单处理、月度邮件营销），有长流程任务（超过 10 个节点），需要在生产环境持久执行，选 LangGraph。如果你的 Agent 是多代理协商场景（比如研究员讨论、代码评审），需要快速原型验证（对话驱动更直观），选 AutoGen。

生产部署有个底线配置：AI Gateway。据 Dive into Claude Code 的分析，一个稳定运行的 Agent，98.4% 是运营基础设施（监控、重试、限流、failover），只有 1.6% 是 AI 决策逻辑。单 Provider 的 API 不够稳定，必须有备路；成本监控是防止 API 费用爆炸的最后一道防线；速率限制是避免被 Provider 封禁的关键。无论选 LangGraph 还是 AutoGen，AI Gateway 都要配。

结论

LangGraph 的 checkpoint、node re-execution 和分布式持久化方案，更适合有明确流程结构、长任务、生产级持久执行的场景。AutoGen 的对话驱动和 Group Chat 协商，更适合多代理互动、快速原型验证。选型关键是判断你的 Agent 是流程驱动还是对话驱动——流程驱动选 LangGraph，对话驱动选 AutoGen。无论选哪个，生产部署都要配 AI Gateway（多 Provider failover、成本监控、速率限制），这是 Agent 稳定运行的底线。如果你在状态追踪上有踩坑经历，欢迎评论区分享。需要 checkpoint 生产部署完整代码示例？关注系列后续文章。