作者：CSDN博客
LangGraph 介绍
作为一个长期关注语言模型应用框架的开发者，我一直在思考如何让智能代理的构建过程既高效又可靠。LangGraph 是近两年发展起来的一种低层次编排框架，它用有向图模型来描述代理的工作流，以节点和边的形式组织语言模型调用、工具调用及各种逻辑判断。相比传统的线性链式框架，LangGraph 为复杂、状态化、长时间运行的任务带来了灵活的控制结构和持久化能力，受到业界的广泛关注。
1.1 背景与发展历程
大型语言模型推动了代理系统的爆炸式增长，但早期应用多数采用 LangChain 这样的链式框架。这种框架适合简单的提示—模型—输出流程，却在循环、分支或多代理协作等复杂场景下捉襟见肘。开发者希望在保持灵活性的同时管理全局状态、持久化执行进度并安全地插入人工干预，LangGraph 正是在这样的需求中诞生的。
LangGraph 由 LangChain 团队推出，其灵感来自 Google 的 Pregel 与 Apache Beam 等分布式图计算模型。从 2023 年底的早期版本开始，它就强调了图式结构、持久化执行、流式输出和人机协同等能力。随着 LangGraph SDK 在 Python 和 JavaScript 中完善，越来越多公司（如 Klarna、Replit、Elastic）在生产环境采用它。2025 年，LangGraph 与 LangChain、LangSmith 等产品形成了完整的生态：LangGraph 负责底层编排，LangChain 提供高层组件，LangSmith 则提供可视化调试和部署平台。
1.2 基本概念与使用方式
1.2.1 图模型与状态
在 LangGraph 中，工作流由节点（Node）和边（Edge）组成。每个节点可以是调用语言模型的函数、工具函数，或其他逻辑步骤，节点之间通过有向边连接，定义执行顺序或条件分支。与之配套的是 全局状态对象，它在执行过程中被不断读取和更新，使代理拥有记忆能力。
1.2.2 Graph API 与 Functional API
LangGraph 提供两种构建方式：
Graph API：显式定义节点和边，适合构建复杂流程。例如创建一个 StateGraph，向其中添加节点，指定起止节点 START 和 END，并通过 add_edge 设置执行流向。这样的声明式方式可以清晰地展示整个图结构，方便可视化和调试。Functional API：把整个工作流封装为一个函数并由框架内部解析依赖关系，适合简短或由单个函数控制的流程。它隐藏了图的细节，让开发者专注于业务逻辑。
1.2.3 持久化执行与人机协同
持久化执行（Durable Execution）是 LangGraph 的核心能力之一。通过内置的持久化层，工作流会在关键步骤保存状态，允许在失败或暂停后从相同状态恢复。这对于需要人工审查或长时间运行的任务尤其重要。文档指出，只需配置检查点（Checkpointer）和线程标识符即可启用持久化，并在重新执行时自动恢复。
此外，LangGraph 支持 人机协同（Human‑in‑the‑Loop）。开发者可以在图中插入检查节点，暂停执行等待人工审批或修改状态，然后继续运行。这种机制让智能代理在关键决策上接受人类的指导，适用于风险较高的任务。
1.2.4 流式输出与时间旅行
LangGraph 内置了对 流式输出 的支持，可以逐 token 输出模型推理过程或工具调用结果，提高用户体验。同时，框架提供 时间旅行（Time Travel）功能，通过记录每一步状态，实现执行路径回溯和重试，方便调试和迭代。
1.3 使用示例代码
以下示例展示了如何使用 Python 的 Graph API 构建一个简单的计算代理，它接收用户的算数请求，选择合适的工具（加法、乘法、除法）完成计算，再返回结果。示例采用 LangChain 提供的工具装饰器，并使用 StateGraph 构建流程。- from typing import TypedDict, Literal
- from typing_extensions import Annotated
- import operator
- from langchain.tools import tool
- from langchain.chat_models import init_chat_model
- from langchain.messages import AnyMessage, SystemMessage, ToolMessage
- from langgraph.graph import StateGraph, START, END
- # 1. 初始化模型并绑定工具
- model = init_chat_model("claude-sonnet-4-5-20250929", temperature=0)@tooldefadd(a:int, b:int)->int:"""Adds `a` and `b`."""return a + b
- @tooldefmultiply(a:int, b:int)->int:"""Multiplies `a` and `b`."""return a * b
- @tooldefdivide(a:int, b:int)->float:"""Divides `a` by `b`."""return a / b
- # 将工具收集并绑定到模型
- tools =[add, multiply, divide]
- tools_by_name ={tool.name: tool for tool in tools}
- model_with_tools = model.bind_tools(tools)# 2. 定义状态结构，记录消息列表和调用次数classMessagesState(TypedDict):
- messages: Annotated[list[AnyMessage], operator.add]
- llm_calls:int# 3. 定义 LLM 节点：决定是否调用工具defllm_call(state: MessagesState)->dict:
- system_prompt = SystemMessage(content="You are a helpful assistant tasked with performing arithmetic on a set of inputs.")
- response = model_with_tools.invoke([system_prompt]+ state["messages"])return{"messages":[response],"llm_calls": state.get("llm_calls",0)+1}# 4. 定义工具节点：根据模型生成的 tool_calls 调用相应函数deftool_node(state: MessagesState)->dict:
- last_message = state["messages"][-1]
- results:list[ToolMessage]=[]for tool_call in last_message.tool_calls:
- tool_fn = tools_by_name[tool_call["name"]]
- observation = tool_fn.invoke(tool_call["args"])
- results.append(ToolMessage(content=observation, tool_call_id=tool_call["id"]))return{"messages": results}# 5. 定义条件逻辑：判断是否继续循环defshould_continue(state: MessagesState)-> Literal["tool_node", END]:# 如果最后一条消息包含工具调用，则转到工具节点；否则结束return"tool_node"if state["messages"][-1].tool_calls else END
- # 6. 构建 StateGraph
- builder = StateGraph(MessagesState)
- builder.add_node("llm_node", llm_call)
- builder.add_node("tool_node", tool_node)
- builder.set_entry_point("llm_node")
- builder.add_conditional_edges("llm_node", should_continue)
- builder.add_edge("tool_node","llm_node")# 工具调用后返回模型判断
- graph = builder.compile()# 7. 调用图
- initial_messages =[SystemMessage(content="2 + 3 * 4")]# 示例输入
- result_state = graph.invoke({"messages": initial_messages,"llm_calls":0})print(result_state["messages"][0].content)
下图展示了一个典型的 LangGraph 流程图示意：
1.4 源代码基本架构
在撰写本教程时，我仔细阅读了项目仓库的目录结构。LangGraph 仓库采用模块化设计，核心代码位于 libs/langgraph/langgraph 目录，辅以持久化、检查点和 SDK 等子模块。总体结构如下：
根目录：包含 README.md、LICENSE、AGENTS.md 等说明文件，以及 Makefile 等构建脚本。docs/：文档源码，包含脚本、模板、测试和覆盖站点的自定义样式。examples/：大量 Jupyter Notebook 示例，涵盖持久化、流式输出、分支、RAG、多人协作等场景。
- libs/：核心库集合。
langgraph/：框架核心代码，提供 graph, channels, pregel, runtime 等模块，定义状态图、节点、边、运行时以及各种并发模型。checkpoint/、checkpoint‑postgres/、checkpoint‑sqlite/：不同持久化实现，支持内存、SQLite、PostgreSQL 等存储。prebuilt/：预构建版本及工具，用于发布 npm 包或 PyPI 包。cli/：命令行工具和生成器，实现 LangGraph 项目模板和辅助脚本。sdk‑py/ 和 sdk‑js/：Python 与 JavaScript SDK，封装了一些便利方法和客户端。它们允许通过云服务运行 LangGraph 工作流。
.github/：存放 CI/CD 工作流、代码检查配置与贡献指南。
这种层次清晰的架构方便开发者根据需要查找特定实现。例如查看 langgraph/runtime.py 可以了解执行引擎如何调度节点；langgraph/checkpoint 子包则实现了工作流的持久化与恢复机制。
1.5 同类型框架介绍与对比
为了更全面地理解 LangGraph，我们需要将其置于更大的 AI 代理框架生态中对比。以下列举了几种常见的框架并简要分析其特点：
1.5.1 LangChain
LangChain 是最早流行起来的 LLM 应用框架，它通过“链”将提示、模型、工具和记忆等组件连接起来。在早期阶段，它帮助开发者快速构建聊天机器人、问答和 RAG 系统。然而，LangChain 的线性链式结构在动态决策或长时间运行任务中显得受限。与 LangGraph 相比，它更适合原型快速开发，而 LangGraph 则擅长复杂、状态化的多代理工作流。
1.5.2 Semantic Kernel
Semantic Kernel 是微软开源的多语言 SDK，采用插件和计划（Planner）模式管理智能体流程。它强调企业级集成与安全性，支持 .NET、Python 和 Java，并内置 Azure AI Search、Azure OpenAI 等服务。Semantic Kernel 提供自动规划能力和插件系统，适合 .NET 环境的开发者。与 LangGraph 相比，它更关注微软生态下的企业安全与治理，而 LangGraph 提供显式的图式控制与检查点机制。
1.5.3 AutoGen 与 CrewAI
AutoGen 是微软研究推出的多代理对话框架，通过自动生成代理对话脚本实现复杂任务协作，强调系统自动化、插件扩展和灵活对话模式。CrewAI 则基于管家型多代理理念，通过角色分工和协作来完成任务。这些框架与 LangGraph 一样支持多代理，但它们更偏重生成对话策略与自动协作，而 LangGraph 更专注于底层运行时、状态管理和持久化。
1.5.4 比较分析
表格总结了 LangGraph 与其他框架的差异：
| 框架 | 架构与控制流 | 状态管理 | 持久化与恢复 | 人机协同 | 典型使用场景 | | LangGraph | 图结构，显式节点与条件边，支持异步执行 | 全局状态对象，可在节点间读取与修改 | 自动检查点、支持内存/SQLite/Postgres 等存储 | 内置暂停与恢复机制 | 长时间运行任务、多代理协作、需人类审查的流程 | | LangChain | 线性链或简单分支 | 每个链保存有限记忆 | 无内置持久化；需要自定义 | 手动实现 | 快速原型、聊天机器人、RAG | | Semantic Kernel | 插件+计划模式，自动规划执行 | 支持内置记忆抽象 | 集成 Azure 平台的持久化与日志 | 部分模式支持人机协同 | 企业级 .NET 环境、多模态任务 | | AutoGen | 对话驱动的多代理协作 | 使用对话历史记录状态 | 可与 LLM 记忆服务集成 | 主要通过代理交互，缺乏持久化 | 学术研究、自动编程、复杂问题解决 | | CrewAI | 角色驱动的多代理系统 | 通过共享知识库维持状态 | 无检查点机制 | 通过角色配置与人工干预配合 | 多角色合作、任务分工 |
从对比中可以看出，LangGraph 在控制流的灵活性、状态持久化以及人机协同方面具有优势，特别适合构建需要容错、可回溯的复杂代理系统。另一方面，Semantic Kernel 在企业级安全与多语言支持方面占优，而 LangChain 则更适合快速迭代的原型开发。
1.6 选择 LangGraph 的优势与不足
优势
灵活的图式控制流：节点和边的组合可以实现循环、分支、并行等复杂流程，支持单代理、多代理、层次化或异步执行。内置持久化和检查点：通过配置检查点，工作流可在任意位置暂停并从同一状态恢复，大大增强了容错性和长时间运行能力。人机协同：允许在执行过程中插入人工审批节点，支持“时间旅行”回溯执行路径并纠正错误。内置流式输出：提供逐步输出模型推理和工具结果的能力，增强交互体验。生态集成：与 LangChain、LangSmith 等产品无缝连接，能够复用现有的提示、工具和记忆组件。
不足
学习成本较高：LangGraph 属于低层编排框架，需要理解图结构、状态管理及异步执行等概念；对于简单项目可能过于复杂。社区尚在成长：虽然已有不少示例和教程，但与 LangChain 比较，第三方生态和插件数量有限，文档仍在完善中。性能开销：开启持久化和高级功能（如同步检查点）会增加执行开销，需要在性能和可靠性之间权衡。语言支持有限：当前官方主要提供 Python 和 JavaScript 实现，其他语言生态（如 Java、C#）仍依赖社区实现。
1.7 发展现状与未来趋势
截至 2025 年底，LangGraph 已经成为构建复杂 AI 代理的重要基础设施之一。大量公司在生产环境使用 LangGraph 打造聊天客服、文档分析、生成式搜索等系统。官方推出了 LangGraph Studio，提供可视化编辑和调试界面；同时 LangGraph Platform 支持一键部署和管理工作流。整个生态从纯粹的开源库演变为包含 SaaS 平台和企业方案的完整产品链。
未来的发展趋势主要包括：
统一的代理平台：微软发布的 Agent Framework 将 AutoGen 与 Semantic Kernel 融合（2025 年公开预览版），意味着多框架融合与标准化正在发生。LangGraph 可能与其他框架共存并互相借鉴，例如提供插件化接口或兼容 Semantic Kernel 的调度策略。跨语言支持：社区正在开发其他语言的 LangGraph 实现，如 Rust、Go 等，以满足不同语言生态的需要。更强的可观测性与安全：伴随企业应用的增多，LangGraph 预计将加强审计记录、权限管理和安全隔离，满足合规要求。多模态与分布式执行：未来的代理系统需要同时处理文本、图像、语音等多模态信息，并在分布式环境中运行。LangGraph 的图结构和持久化机制天然适合扩展到这些场景。
1.8 总结
作为一名开发者，在深入研究 LangGraph 后，我被它的灵活性和可扩展性所吸引。它通过图结构解耦了流程控制和业务逻辑，提供了耐久执行、人机协同和流式输出等高级能力。这使得构建复杂的 AI 代理系统更加稳健、易于调试，并能够在生产环境中长期运行。当然，LangGraph 也不是银弹：它需要更高的学习成本，社区生态仍在成长。但在复杂工作流和企业级应用场景中，LangGraph 显然提供了一套强大的解决方案。
下图概括了 LangGraph 的核心组件以及它们之间的关系：
随着代理技术的快速进展，我相信 LangGraph 在未来几年仍会不断完善，与其他框架共同推动智能代理生态的发展。对于希望构建可靠、多代理、可回溯系统的开发者而言，LangGraph 是值得深入学习和应用的工具。
原文地址：https://blog.csdn.net/weixin_39856351/article/details/155852896 |
广告