LangGraph

LangGraph 是由 LangChain, Inc. 开发的开源 Python 和 JavaScript 框架，用于构建有状态的多步 AI 代理工作流。该框架于 2025 年 10 月 22 日发布了稳定的 1.0 版本，它将代理逻辑建模为有向图，其中节点代表计算步骤，边代表条件转换。与简单的基于链的框架不同，LangGraph 将持久化执行、状态持久化和人工审查视为一等运行时关注点，而不是由开发者事后拼凑的附加功能。

在核心层面，LangGraph 提供了四个生产原语：能够在服务器重启和网络故障中存活的有状态检查点（checkpointing）、用于在等待批准时暂停代理执行的内置人在回路中断模式、支持循环和条件分支的基于图的工作流控制，以及涵盖短期工作状态和长期跨会话持久化的内存层。LangGraph 与模型无关：它支持 OpenAI、Anthropic、Google、Mistral 以及任何可通过 API 访问的 LLM。LangGraph Platform（前身为 LangSmith Deployment）在开源运行时之上增加了托管云托管、队列编排和 LangSmith 可观测性。

LangGraph 在 2026 年 4 月的实际功能

LangGraph 1.0 GA 提供了一个运行时，处理了大多数代理框架留给开发者的基础设施问题。通过 Python TypedDict 定义的状态在图节点之间流动；每次转换都会在可配置的后端（本地开发使用 SQLite，生产环境使用 Postgres 或 Redis）中保存检查点。如果工作进程在图执行中途崩溃，下一次执行将从最后保存的检查点恢复，而不是从头开始。这种行为是框架原生的，而非可选插件。

人在回路控制通过中断原语实现。节点可以暂停执行，并将挂起的状态呈现给外部系统（Slack 审批机器人、Web UI、人工审查队列）。代理线程会阻塞而不占用服务器资源，并在人类发送响应命令时恢复。这种模式对于高风险工作流尤为有价值：财务审批、医疗记录更新、内容审核升级。

LangGraph 还通过 LangSmith 提供了一个时间旅行调试界面。由于每次状态转换都会保存检查点，开发者可以从任何节点重放任何历史图执行，检查代理的推理过程，在运行中途修改状态，并分叉出备用的执行分支。Focused Labs 的 Austin Vance 已经在十多个生产行业中部署了 LangGraph，他直接总结了这种可观测性的价值：

"当客户报告代理行为异常时，我可以调出追踪记录，并看到在第 7 步，代理收到了模棱两可的搜索结果。" - Austin Vance, Focused Labs, dev.to, 2025

该框架支持多代理拓扑结构：协调专用子代理的主管代理、跨独立任务扇出的并行分支，以及父图调用子图的层次图。Klarna 的客户支持 AI 处理着跨越多个国家的 8500 万活跃用户，它使用 LangGraph 和 LangSmith 来管理这些工作流，将客户问题解决时间缩短了 80%。

LangGraph 与 CrewAI 和 Temporal 的定位对比

与 CrewAI 和 Temporal 的比较揭示了两种截然不同的设计理念。

LangGraph vs. CrewAI: CrewAI 围绕角色定义组织代理：每个代理都有一个 Role、Goal 和 Backstory 字符串，框架将协调过程拟人化。任务输出作为隐式上下文向前传递给序列或层次结构中的下一个代理。没有显式的状态对象，也没有原生的检查点层。CrewAI 优先考虑低配置启动，而不是运行时保证。相比之下，LangGraph 暴露了一个带有类型化模式和显式 reducer 函数的 StateGraph，用于合并并发分支输出。开发者必须从图拓扑和状态转换的角度来思考。这需要更高的学习成本，但能产生确定性、可检查的执行，而不是涌现式的角色扮演。常见的生产模式是为了速度在 CrewAI 中进行原型设计，然后在出现可靠性和可审计性需求时迁移到 LangGraph。正如一篇框架对比文章所言："虽然 LangGraph 要求你以图和状态机的方式思考，但 CrewAI 让你以人类的方式思考。"

LangGraph vs. Temporal: Temporal 是一个早于 LLM 时代的通用持久化工作流引擎。它在工作流引擎级别序列化执行历史，在工作进程重启时确定性地重新执行记录的步骤。这保证了任何代码（不仅仅是 LLM 调用）的精确一次（exactly-once）执行语义。LangGraph 的检查点作用域不同：它在图节点之间保存代理状态，但节点内部的状态不会持久化。Temporal 没有原生的 LLM 概念（没有提示模板、没有工具调用包装器、没有人在回路原语）。对于构建同时涉及实际业务副作用（支付、数据库写入、外部 API 调用）的代理的团队，截至 2026 年的推荐架构是双层堆栈：Temporal 作为外部持久化执行包装器，LangGraph 作为内部 LLM 推理循环。LangGraph 是 LLM 原生的。Temporal 是基础设施原生的。它们越来越多地被结合使用，而不是作为替代品。

代理循环的日常实际情况

使用 LangGraph 构建意味着预先将状态模式定义为 Python 数据类或 TypedDict，然后将节点编写为读取和写入该状态的普通 Python 函数。边可以是静态的（始终从节点 A 到节点 B）或条件的（检查状态并路由到 B、C 或终止）。支持循环，这对于重试逻辑和迭代优化循环至关重要。

对于任何超越玩具示例的项目，开发循环都需要 LangSmith。如果没有追踪检查，调试代理为何走错分支或进入无限循环将极其耗时。LangSmith 是一个具有独立定价的独立产品，但集成非常紧密，团队将其视为 LangGraph 的生产可观测性方案。

部署选项包括在本地运行 LangGraph 服务器、在 Kubernetes 上自托管，以及使用 LangGraph Platform 的托管云。托管云显著降低了 DevOps 开销，但在 LLM API 费用之上增加了按分钟计算的计算成本。

"在将代理部署到十几个不同行业的生产环境后，它是唯一一个将最困难的问题视为一等关注点的框架。" - Austin Vance, Focused Labs, dev.to, 2025

一个反复出现的痛点是样板代码的密度。在任何 LLM 逻辑运行之前，定义状态模式、编写 reducer 函数、映射边缘条件以及配置检查点后端是一项重大投资。社区讨论不断浮现出相同的模式：开发者编写简单的直接 API 脚本，这对于原型来说工作得更快，但在需要恢复、人工审查或多代理协调时就会碰壁。这种开销在生产规模上是值得的。但对于只运行一次的脚本来说则不然。

LangGraph 是为谁构建的

LangGraph 专为在受监管、高风险或长期运行的生产环境中部署 AI 代理的工程团队而构建，在这些环境中，正确性比首次演示的时间更重要。例如 Klarna 等公司的财务团队需要确定性的审批链。Uber 等公司的开发者平台团队运行大规模代码迁移管道，中途重启会破坏状态。LinkedIn 的招聘系统需要在自然语言搜索、候选人匹配和外呼消息之间进行协调，而不会在会话之间丢失上下文。

它也适用于任何已经在使用更简单框架时碰壁的团队：在网络错误时静默失败的代理、在部署重启时从头开始的工作流、需要人类在代理继续之前审查中间决策的多步流程。

LangGraph 不是什么

LangGraph 不是一个低代码工具。开源框架中没有可视化工作流构建器。构建和调试 LangGraph 应用程序需要熟练掌握 Python，熟悉图论和状态机，最好还熟悉 LangSmith 的追踪界面。基于图的心智模型在概念上不同于顺序脚本，并且有记录表明其学习曲线陡峭。

它不适合简单的线性工作流。如果你的代理只调用一个工具、格式化响应并返回，那么类型化状态、检查点配置和图拓扑的开销是不合理的。对于单步用例，具有最少编排的直接 API 调用构建和维护起来更快。

它也不是一个孤立的安全保证。2026 年 3 月，CVE-2025-67644 披露了 LangGraph 的 SQLite 检查点实现中存在 SQL 注入漏洞（CVSS 7.3），允许通过元数据过滤器操作对检查点数据库运行任意 SQL。该补丁已在 langgraph-checkpoint-sqlite 3.0.1 中发布。在 SQLite 检查点上自托管的团队应验证他们使用的是已修补的版本。

最后，LangGraph 不是 Temporal。对于必须保证副作用（收取付款、写入监管账本）精确一次执行的工作流，Temporal 的执行模型提供了更强的保证。到 2026 年的生产共识是，当同时需要 LLM 推理和事务持久性时，将 LangGraph 嵌套在 Temporal 内部。