当我们谈论大语言模型应用开发时链式调用Chain已经无法满足复杂业务场景的诉求。LangGraph作为LangChain生态中的图编排层正成为构建生产级Agentic Workflow的事实标准。本文将从架构设计、运行机制、状态管理与工程实践四个维度深入剖析LangGraph的技术内核。一、为什么需要LangGraph从Chain到Graph的范式跃迁在LLM应用开发的早期阶段LLMChain、SequentialChain等线性编排工具占据主导位置。开发者将提示模板、模型调用、输出解析器按顺序串联组成一条管道。这种方式在单轮对话、简单 RAG检索增强生成场景下表现良好但一旦涉及以下需求便捉襟见肘循环与回溯Agent 需要思考—行动—观察循环ReAct 范式需多次访问同一节点条件分支根据中间结果决定下一步走向路由决策而非死板地按顺序执行多角色协作规划器、检索器、批判器、执行器并行或交替参与人机协同HITL在关键节点暂停等待人类反馈再继续持久化与时间旅行长任务需要在断点处保存状态并能回溯到任意历史步骤。LangGraph 应运而生。它由 LangChain 团队于 2024 年推出定位为用于构建有状态、多角色 LLM 应用的编排框架。其核心理念借鉴了经典图论与 Pregel 分布式图计算模型将整个 Agent 流程抽象为一张有向图Directed Graph——节点代表计算单元边代表控制流走向状态在节点间流动并被持久化。核心定位LangGraph ≠ LangChain 替代品而是 LangChain 体系内专注于复杂控制流 状态管理的子项目。二、图结构剖析节点、边与条件路由下图是一张典型的 LangGraph 状态机示意图清晰展示了其工作流的拓扑结构┌─────┐ │START│ └─┬─┬─┘ │ │ ┌──────┘ └───────┐ ▼ ▼ ┌──────┐ ┌──────┐ │node1 │ │node2 │ └──┬───┘ └──┬───┘ │ │ ▼ ▼ ┌──────┐ ┌──────┐ │node3 │ │node4 │ └──┬───┘ └──┬───┘ │ │ └─────┐ ┌──────┘ ▼ ▼ ┌──────┐ │node5 │ └──┬───┘ ▼ ┌───┐ │END│ └───┘从图中我们可以看到 LangGraph 的几个关键结构特征元素含义工程作用START虚拟入口节点图执行起点注入初始状态END虚拟出口节点图终止条件标识流程结束node1node5业务节点封装具体计算逻辑LLM调用、工具执行等有向边控制流走向决定下一跳节点汇聚边多源汇合node3和node4同时指向node5体现 Join 语义分支边一源多目标START同时指向node1和node2实现并发/路由2.1 节点Node计算的原子单元节点是 LangGraph 中做事的地方。每个节点本质是一个纯函数或可调用对象签名为def my_node(state: State) - dict: # 读取当前状态 user_input state[messages][-1] # 执行计算LLM/工具/业务逻辑 response llm.invoke(user_input) # 返回状态增量 return {messages: [response]}关键设计原则有三节点无副作用节点只描述如何从输入状态计算到输出状态不直接修改全局变量返回增量而非全量节点返回的字典会被Reducer函数合并进全局状态避免并发冲突可组合性节点本身可以是一个 LangChain Runnable、Tool、Agent 或其他图支持图嵌套。2.2 边Edge与条件路由边定义节点间的转移关系LangGraph 支持三种边① 静态边Static Edge——固定下一个节点graph.add_edge(node1, node3)② 条件边Conditional Edge——根据运行时状态决策def route_after_planning(state): if state[plan_ready]: return execute else: return replan graph.add_conditional_edges( planner, route_after_planning, {execute: executor, replan: planner} # path map )条件边是 LangGraph 实现 Agent 行为的核心机制。ReAct、Plan-and-Execute、Router 等主流 Agent 范式本质上都是通过条件边实现循环跳转的。③ 入口边Entry Point——指定 START 后的第一跳graph.set_entry_point(node1)对应到上面图示START → node1与START → node2同时存在意味着这是一个并行分支起点也可能是条件路由结果这种结构非常适合多路并发执行后汇聚的场景例如多源信息并行检索向量库、SQL、Web Search后合并多个候选答案生成后选择最优多角色辩论Pro/Con 双方独立推理后由 Judge 决策。2.3 Pregel 风格的执行模型LangGraph 的运行时借鉴了 Google Pregel 的BSPBulk Synchronous Parallel超级步模型每个 superstep所有活跃节点被调度执行接收上一轮的状态节点并行运行相互独立的节点可以并发执行边连接顺序决定依赖消息传递节点向其下游节点发送消息状态增量同步屏障当所有节点完成本轮计算后进入下一 superstep终止判定当没有活跃节点指向下一节点时图进入终止状态。这种同步并行 消息驱动的模型天然适配分布式部署也使得 LangGraph 能够优雅地处理循环、汇合、分支等复杂拓扑。三、状态管理有状态应用的核心难题如果说图结构是 LangGraph 的骨架那**状态State**就是其灵魂。一个真实的 Agent 应用通常需要在多个节点间共享数据用户的原始问题与多轮对话历史中间推理步骤、工具调用记录检索到的文档片段任务执行计划与进度错误信息与回滚日志。3.1 Schema 定义TypedDict ReducerLangGraph 使用 Python 的TypedDict声明状态结构并通过Annotated字段指定归约函数Reducerfrom typing import TypedDict, Annotated, List from langgraph.graph import add_messages from langchain_core.messages import BaseMessage class AgentState(TypedDict): messages: Annotated[List[BaseMessage], add_messages] plan: str step_count: Annotated[int, lambda x, y: x y] # 自定义 reducer retry_count: intadd_messages是 LangGraph 内置的核心 Reducer它能智能合并消息列表同 ID 的消息会覆盖模拟消息更新新 ID 的消息会追加这恰好对应 OpenAI/Anthropic API 中assistant 消息先发出去再修正的模式。3.2 Checkpointer持久化与时间旅行对于长任务小时级甚至天级我们需要把状态写入持久化存储以便断点续传进程崩溃后能从最后状态恢复人机协同暂停在某个节点等待人类审核后再恢复时间旅行调试回滚到任意历史 superstep 重放执行。LangGraph 通过Checkpointer抽象提供这一能力from langgraph.checkpoint.memory import MemorySaver from langgraph.checkpoint.postgres import PostgresSaver # 内存版开发调试 memory_saver MemorySaver() # PostgreSQL 版生产环境 postgres_saver PostgresSaver.from_conn_string(DB_URL) graph builder.compile(checkpointerpostgres_saver) # 执行时通过 thread_id 关联会话 config {configurable: {thread_id: user-12345}} result graph.invoke({messages: [HumanMessage(你好)]}, config) # 时间旅行获取历史状态 state_history graph.get_state_history(config) for snapshot in state_history: print(snapshot.values, snapshot.next)这种设计让 LangGraph 天生具备生产级 Agent所需的可观测性、可恢复性与可审计性。3.3 Send / Map-Reduce 模式对于动态扇出场景节点运行时才知道需要分几个子任务LangGraph 提供了SendAPIfrom langgraph.constants import Send def route_to_workers(state): 根据待处理任务列表动态创建 worker return [Send(worker, {task: t}) for t in state[tasks]] graph.add_conditional_edges(supervisor, route_to_workers, [worker])配合 Reducer 模式可以实现经典的Map-Reduce编排supervisor 节点动态创建 N 个 worker 并行执行reducer 节点汇总所有结果。四、LangGraph 与 LangChain协作而非替代很多初学者会问我已经用了 LangChain为什么还需要 LangGraph 这里的关键是理解二者的职责分层维度LangChainLangGraph定位LLM 应用开发工具集LCEL Runnable、Chain、Tool、Retriever 等复杂工作流编排框架抽象层级单次调用的动作如 RAG Chain、Tool多步协作的剧本状态机控制流主要线性LCEL|操作符串行任意图结构含循环、分支、汇合状态管理通常无状态或由调用方管理内置 Schema、Reducer、Checkpointer持久化无内置内置 CheckpointerMemory/Postgres/SQLite人机协同需自行实现内置interrupt()API调试能力LangSmith TraceLangSmith 时间旅行 State History4.1 它们如何协作LangGraph 并不是要取代 LangChain而是站在 LangChain 肩膀上节点可以是一个RunnableLCEL 链复用所有 LangChain 组件状态中的messages字段直接兼容 LangChain Message 类型Retriever、Tool、Memory 等 LangChain 抽象都可以作为节点使用。一个典型组合是[LangChain Retriever] → 节点 [LangChain RAG Chain] → 节点 [LangChain Agent] → 节点 [LangGraph] → 编排框架串联上述节点4.2 LangGraph 的差异化优势总结起来LangGraph 提供了 LangChain 缺失的四项关键能力循环与回溯原生支持节点被多次访问如 ReAct 的思考—行动—观察循环细粒度控制条件边让 LLM 决定走向成为一等公民生产级持久化内置 Checkpointer 让长任务 崩溃恢复开箱即用时间旅行调试get_state_historyupdate_state让回到过去成为可能。对于简单场景如单轮 RAGLangChain LCEL 完全够用但只要涉及多步推理、Agent 协作、长流程管理LangGraph 几乎是当前最成熟的选择。五、底层运行机制源码层面的执行流程理解了概念之后让我们深入 LangGraph 源码层看看一次graph.invoke()背后发生了什么5.1 编译期StateGraph → CompiledGraphfrom langgraph.graph import StateGraph, END builder StateGraph(AgentState) builder.add_node(agent, call_model) builder.add_node(tools, tool_node) builder.add_conditional_edges(agent, should_continue, {continue: tools, end: END}) builder.add_edge(tools, agent) builder.set_entry_point(agent) graph builder.compile() # ← 关键编译compile()内部完成拓扑校验检测环路、孤立节点、缺失入口构建通道Channels每个状态字段对应一个 Channel绑定 Reducer生成 Pregel 任务图将节点映射为可并行执行的任务绑定 Checkpointer建立状态持久化通道。5.2 运行期PregelLoop 主循环CompiledGraph.invoke()内部启动PregelLoop其主循环伪代码如下while not done: # 1. 准备本轮输入从 Channel 读取活跃任务的状态 tasks prepare_tasks(next_nodes, config) # 2. 并行执行任务节点函数调用 for task in tasks: writes task.run(state) # 节点返回状态增量 # 3. 应用 Reducer将写入合并进 Channel apply_writes(writes, config) # 4. 计算下一轮活跃节点 next_nodes route(conditional_edges, current_state) # 5. 检查终止条件next 为空或指向 END done not next_nodes5.3 关键设计模式Producer-Consumer节点是 ProducerChannel 是 Consumer 队列Event-driven通过eventsAPIgraph.stream_events订阅 token 级别事件实现流式输出Idempotent Tasks每个任务通过(task_id, channel_version)标识支持重试与幂等。六、典型应用场景6.1 多轮 ReAct Agent最经典的场景是 ReActReason Act循环graph.add_conditional_edges( agent, should_continue, {continue: tools, end: END} ) graph.add_edge(tools, agent) # 循环回 agentLLM 在agent节点判断是否需要调用工具如果需要则跳到tools执行完后再回到agent。这正是 ReAct 论文的工程实现。6.2 Plan-and-Execute对于复杂任务先规划后执行能显著提升准确率START → planner → executor → [反思/补充] → END ↑___________|planner节点生成步骤列表executor节点逐步执行每步结果反馈给planner决定下一步。6.3 多 Agent 协作Multi-Agent SupervisorLangGraph 官方示例中的主管-工人模式supervisor → [worker_A, worker_B, worker_C] → supervisor主管 Agent 分配任务给专业 Worker汇总结果后决定继续委派还是终止。6.4 人机协同工作流def approval_node(state): # 触发 interrupt等待人类决策 human_decision interrupt({plan: state[plan]}) return {decision: human_decision}在关键决策点暂停把审批动作交给人类特别适用于金融交易确认内容发布前审核医疗诊断复核。七、总结与展望LangGraph 之所以在 2024-2026 年迅速走红本质是因为它击中了 LLM 应用从 Demo 走向生产的关键痛点痛点LangGraph 方案复杂控制流难表达有向图 条件边长任务易崩溃Checkpointer 断点续传调试 Agent 像黑盒State History 时间旅行多 Agent 难协作Send API 并行 Reducer关键节点需人类把关interrupt() Command API从架构演进角度看LangGraph 代表了一种趋势LLM 应用正在从Prompt Engineering走向Workflow Engineering。提示词只是冰山一角真正决定系统质量的是背后那张编排图——节点如何划分、状态如何流动、错误如何恢复、人类如何参与。