lang: zh slug: langgraph-stateful-agent-orchestration-2026 title: ‘LangGraph 1.2 投入生产’ description: ‘LangGraph 是一个低级编排框架,适用于长期运行、有状态的 AI 代理。 32.6k GitHub star,v1.2.1。 真实的部署指南,涵盖图形设计、持久执行、人机循环检查点、LangSmith 调试以及 LangGraph 何时击败 CrewAI / AutoGen / 纯 LangChain。’ tags: [“ai-agent”, “automation”, “guide”, “open-source”, “reference”, “tutorial”] date: 2026-05-21 00:00:00+08:00 lastmod: 2026-05-21 00:00:00+08:00 tech_stack:

    • Python
    • TypeScript
    • PostgreSQL
    • Redis application_domain: Llm Frameworks source_version: ‘1.2.1’ licensing_model: Open Source license_type: MIT file_size: ’' file_md5: ’' download_url: ’' backup_url: ’' github_repo: ‘https://github.com/langchain-ai/langgraph' last_maintained: ‘2026-05-21’ draft: false categories: [’llm-frameworks’] aliases:
    • /posts/langgraph-stateful-agent-orchestration-2026/ faqs:
    • q: ‘What is LangGraph and how is it different from LangChain?’ a: ‘LangGraph is the LangChain team’’s low-level orchestration framework for stateful, long-running AI agents, modeled as a graph-based state machine of nodes, edges, and persistent state. Unlike LangChain (which provides composable components like LLM wrappers and tools), LangGraph adds durable execution, human-in-the-loop, and state tracking as first-class features, and it complements rather than replaces LangChain since many LangGraph nodes wrap LangChain components.’
    • q: ‘How does LangGraph survive crashes and process restarts?’ a: ‘LangGraph’’s Checkpointer snapshots the workflow state after every node execution, backed by Postgres, Redis, or in-memory storage. If the process crashes, you resume from the last checkpoint using a thread_id and checkpoint_id instead of restarting from zero, and you can also replay any checkpoint deterministically for debugging.’
    • q: ‘When should you choose LangGraph over CrewAI or AutoGen?’ a: ‘Pick LangGraph for stateful, long-running agents that must survive restarts and crashes, where you need maximum control plus the LangChain ecosystem. Choose CrewAI for fast role-based multi-agent demos and AutoGen for conversational group-chat or debate workflows, though Microsoft has shifted AutoGen to maintenance mode and recommends evaluating the Microsoft Agent Framework for new projects.’
    • q: ‘How do you add human approval steps to a LangGraph agent?’ a: ‘Use the interrupt function from langgraph.types to mark a node as interruptible: the workflow pauses, surfaces its state to a UI, waits for human input, then resumes. This is the recommended pattern for irreversible actions like sending email or charging cards, where running without a human-in-the-loop checkpoint risks the agent eventually doing something harmful.’
    • q: ‘What are the most common mistakes when starting with LangGraph?’ a: ‘The top pitfalls are: creating too many fine-grained nodes (each node is a checkpoint write, so 50-node graphs run slowly), forgetting reducers (state updates without a reducer get replaced rather than merged), skipping interrupt for irreversible write actions, not wiring up LangSmith from day one, and treating state as a database instead of keeping it lean by referencing large objects by ID.’ featureImage: /images/articles/resources-llm-frameworks-langgraph-stateful-agent-orchestration-2026.jpg——如果您构建了一个简单的 LLM 代理,并发现它在进程重新启动时忘记了所有内容,在一个工具调用超时时丢失了一半的进度,或者在两个事件同时触发时默默地损坏了状态 — 您就遇到了障碍 LangGraph 旨在突破。LangGraph 是 LangChain 团队的用于有状态、长时间运行的代理的低级编排框架。 LangChain 提供组件(“这是一个 LLM 包装器,这是一个工具,您自己编写它们”),而 CrewAI 提供高级角色抽象(“这是一个‘研究人员’代理和一个‘作家’代理”),而 LangGraph 则介于两者之间:一个基于图的状态机,您可以在其中显式地建模节点(函数/代理)、边(转换)和持久状态。 持久执行+人机循环+状态跟踪是首要考虑的问题,而不是事后的想法。到 2026 年中期,它拥有 32.6k GitHub star 并发布了 v1.2.1,使其成为最流行的框架,专门用于需要承受崩溃、重新启动和多小时运行的生产代理工作流程。
      LangGraph 1.2 投入生产:在崩溃中幸存的状态代理编排(2026 年完整指南)— dibi8.com
      ## 1. LangGraph 实际上是什么(和不是什么):基于图形的代理运行时,您可以在其中定义“节点”(Python/TS 函数,通常包含 LLM 调用)、“边缘”(确定性或 LLM 决定的转换)以及在整个工作流程中持续存在的“状态”对象。这不是
    • LangChain 的直接替代品(它补充了 LangChain;许多 LangGraph 节点包装了 LangChain 组件)
    • 无代码工具(开发人员优先,Python 或 TypeScript)
    • 高级“用自然语言描述代理”工具——这是 CrewAI 的领域心智模型: “代理工作流程 = 显式状态机,而不是隐式对话。” 您绘制图表,LangGraph 运行它。## 2. 为什么“有状态”很重要(LangGraph 修复的错误)如果没有适当的状态管理,三种故障模式会杀死生产代理:1. 工作流程中崩溃 → 代理从零重新启动,重做 30 分钟的工作,丢失任何面向用户的进度
    1. 并发工具调用 → 状态突变不可预测地交错,代理最终处于无效状态
    2. 多小时工作流程 → 进程被云提供商的空闲超时杀死,没有恢复点LangGraph 的“检查点”(由 Postgres、Redis 或内存中支持)在每个节点执行后快照状态。 碰撞? 从最后一个检查点重新启动。 需要注入人类反馈吗? 在检查点暂停,修改状态,恢复。 需要调试吗? 确定性地重播任何检查点。这个错误会让你说“我应该使用 LangGraph”——通常是在尝试使自定义解决方案发挥作用的第 3 周之后。## 3. 快速安装(5 分钟)```` bas h pip install -U langgraph langchain langchain-openai
    或者使用 Postgres 检查点: #

    pip install -U langgraph langgraph-checkpoint-postgres

    — 计数最多为 5,具有检查点状态,可在进程重新启动后继续存在:````蟒蛇
    从输入导入 TypedDict
    从 langgraph.graph 导入 StateGraph,开始,结束
    从 langgraph.checkpoint.memory 导入 MemorySaverc```
    pytho
    n
    从输入导入 TypedDict
    从 langgraph.graph 导入 StateGraph,开始,结束
    从 langgraph.checkpoint.memory 导入 MemorySaver
    
    类状态(TypedDict):
    计数器:整数
    
    def 增量(状态:状态)-> 状态:
    返回{“计数器”:状态[“计数器”] + 1}
    
    def should_continue(state: State) -> str:
    如果 state["counter"] < 5,则返回“increment”,否则 END
    
    图 = StateGraph(状态)
    graph.add_node("增量", 增量)
    graph.add_edge(START, "增量")
    graph.add_conditional_edges(“增量”,should_continue)
    
    应用程序 = graph.compile(checkpointer=MemorySaver())
    
    # 使用 thread_id 运行以保持状态
    config = {“可配置”:{“thread_id”:“demo-1”}}
    结果 = app.invoke({"counter": 0}, config=config)
    打印(结果)# {'计数器':5}
    ``我实际使用### 持久执行(`Checkpointer`)
    每个节点返回值都会被快照。 进程死掉? 从“thread_id”和“checkpoint_id”恢复。 仅此一点就值得对运行时间超过 5 分钟的任何代理采用 LangGraph。### 人在循环(`中断`)
    将节点标记为可中断。 工作流程暂停,将状态显示到 UI,等待人工输入,然后恢复。 构建“人工智能提出变更,人类批准”工作流程的唯一明智方法。````蟒蛇
    从 langgraph.types 导入中断defapproval_gate(状态):
    user_decision = 中断({"propose_action": state["plan"]})
    返回{“已批准”:user_decision}
    ````### 内存层(`add_messages`)
    内置短期(线程内)和长期(跨线程)内存。 使用“add_messages”减速器来实现会话状态,或者通过 [AgentMemory MCP](/resources/llm-frameworks/agentmemory-mcp-persistent-memory-2026/) 插入 [mem0](/resources/llm-frameworks/mem0/) 以跨线程进行语义调用。### 朗史密斯集成
    每个节点执行、每个状态转换、每个 LLM 调用都会出现在 LangSmith 的跟踪查看器中。 “为什么代理要走那个分支?”的可视化调试 ——对于复杂的图表来说是无价的。## 5. 生产部署模式大多数团队选择的 4 部分模式:````
    ┌──────────────────────────┐
    │ 您的应用程序 / FastAPI │
    │ ````蟒蛇
    从 langgraph.types 导入中断
    
    defapproval_gate(状态):
    user_decision = 中断({"propose_action": state["plan"]})
    返回{“已批准”:user_decision}
    ````────────────┘
    │ 检查点写入
    ▼
    ┌──────────────────────────┐
    │ PostgreSQL │ ← 状态持久性
    └──────────────────────────┘
    │ 跟踪流
    ▼
    ┌──────────────────────────┐
    │ LangSmith (或自托管) │ ← 可观察性
    └──────────────────────────┘
    ````标准产品部署:容器化 LangGraph 应用程序,将其指向托管 Postgres 以获取检查点,配置 LangSmith 以获取跟踪。 DigitalOcean App Platform
     适用于无状态层; 对于严重的工作负载,请使用 HTStack Hong Kong VPS
    (至少 8 GB)+ DO Managed Postgres 进行低延迟状态写入。## 6. LangGraph vs LangChain vs CrewAI vs AutoGen(何时选择什么)| 需要| 选择|
    |---|---|
    | 有状态,长r```
    ┌──────────────────────────┐
    │ 您的应用程序 / FastAPI │
    │ (LangGraph SDK 或 REST) │
    └──────────┬────────────────┘
    │
    ▼
    ┌──────────────────────────┐
    │ LangGraph服务器 │
    │ (langgraph 开发/部署) │
    └──────────┬────────────────┘
    │ 检查点写入
    ▼
    ┌──────────────────────────┐
    │ PostgreSQL │ ← 状态持久性
    └──────────────────────────┘
    │ 跟踪流
    ▼
    ┌──────────────────────────┐
    │ LangSmith (或自托管) │ ← 可观察性
    └──────────────────────────┘
    ```控制,CrewAI 在首次演示时间上获胜,AutoGen 在多代理对话上获胜**(但正在转型中)。 对于任何需要在部署或崩溃中幸存下来的东西,LangGraph 是默认选择。## 7. 现实世界用例(LangGraph 的亮点)**客户支持自动化**:多轮工单会因人为升级而暂停,将上下文保留数天,并在客户回复时无缝恢复。**代码代理(长时间运行)**:跨数十个文件重构代码库的代理,每个文件后都有检查点,因此崩溃不会损失 4 小时的工作。 与我们的自托管 AI 编码工作流程配对以获得完整堆栈。**研究/报告生成**:多步骤研究工作流程(搜索→提取→综合→写入),每个阶段都会产生持久的工件。 故障在最后一个良好的检查点恢复。**人工批准的工作流程自动化**:人工智能计划操作,系统在“中断”时暂停,向用户显示计划,仅在批准后恢复。**多租户代理产品**:每个客户都会获得一个`thread_id`,状态完全隔离,您可以重播任何客户的会话进行调试。## 8. 陷阱(第三天你会遇到的事情)1. **设计太多细粒度节点** — 每个节点=一个检查点写入。 50 节点图运行缓慢。 将相关操作合并到单个节点中
    2. **忘记减速器** - 没有减速器的状态更新被*替换*,而不是*合并*。 新用户的错误来源#1
    3. **跳过写入操作的“中断”**——在没有人机循环检查点的情况下采取不可逆操作(发送电子邮件、充电卡)的代理最终会做坏事
    4. **从第一天起就不再使用 LangSmith** — 从 print 语句中调试 20 节点图是很痛苦的。 在出现问题之前连接 LangSmith
    5. **将 LangGraph 状态视为一个免费的数据库** — 保持状态精简。 通过 ID 引用大对象,将实际的 blob 存储在 S3 / Postgres 中## 9. 迁移:LangChain Agent → LangGraph如果您有一个正在运行的 LangChain `AgentExecutor` 或 `create_react_agent` 管道,则迁移到 LangGraph 是机械的:1.定义你的状态TypedDict(镜像你当前在步骤之间传递的内容)
    2. 将每个 LangChain 工具/步骤包装为 LangGraph 节点
    3.添加`Checkpointer`(从`MemorySaver`开始,稍后切换到Postgres)
    4. 添加边以对之前隐含在 LangChain 代码中的控制流进行建模回报:持久执行 + 人机交互 + 重放调试,并且大多数 LangChain 组件都保持不变。## 10. 何时不使用 LangGraph- **无状态单轮 LLM 调用** — 太过分了,只需使用 LLM SDK
    - **简单的 RAG(检索 → 答案)** — LangChain 的 `RetrievalQA` 链就是一行,很好
    - **纯对话式聊天机器人** — LangChain + 消息存储更简单
    - **团队的 Python 经验为零** — CrewAI 基于角色的抽象更平易近人## 长篇大论;博士LangGraph = **基于图的有状态代理运行时**,适用于需要承受崩溃、支持人工检查点并运行数小时的生产工作负载。 32.6k 星,v1.2.1,麻省理工学院。 与 LangChain(您可能已经使用过)自然配对。 当您需要控制时,请选择它,而不是 CrewAI;当您需要耐用性时,请选择单独的 LangChain;对于多代理对话之外的任何事情,请选择 AutoGen。使用 Postgres 启动一个 DigitalOcean Droplet
    ,运行第 3 节中的示例,您就会明白为什么在生产中运行真实代理的团队会被吸引到这里。---*想要在更大的背景下查看 LangGraph? 请参阅我们的 [AI Agent 工具链集合](/collections/),了解它如何与 MCP 服务器、AgentMemory 和代码执行沙箱配合使用 - 即将推出。*<!--自动引用-->
    ## 参考文献和来源- [LangGraph](https://github.com/langchain-ai/langgraph)
    - [LangChain](https://github.com/langchain-ai/langchain)
    - [CrewAI](https://github.com/crewAIInc/crewAI)
    - [AutoGen](https://github.com/microsoft/autogen)
    - [mem0](https://github.com/mem0ai/mem0)
    

    💬 留言讨论