LangGraph

LangGraph 是用于构建和运行有状态 Agent 与复杂工作流的低层编排框架。它把执行过程表示为由状态、节点和边组成的图，让开发者明确控制每一步做什么、下一步去哪里，以及任务怎样保存、暂停和恢复。

LangGraph 由 LangChain 团队开发，但可以不依赖 LangChain 的高层 Agent API 单独使用。节点中既可以调用大语言模型，也可以执行普通程序、访问服务或等待人工处理。

图的三个核心部分

LangGraph 的 Graph API 主要围绕三个概念组织：

• 状态（State）：当前任务共享的数据，例如用户消息、检索结果、工具错误和执行进度；
• 节点（Node）：读取当前状态、执行操作并返回状态更新的函数；
• 边（Edge）：决定节点之间的固定顺序或条件分支。

可以把一个简单知识问答图表示为：

开始
  ↓
判断问题类型
  ├─ 普通对话 → 直接回答 → 结束
  └─ 知识问题 → 检索资料 → 根据资料回答 → 结束

“判断问题类型”“检索资料”和“根据资料回答”是节点；箭头和条件分支是边；问题、判断结果和检索资料属于状态。

节点不一定包含模型。固定规则、数据库访问、HTTP 请求和人工审批同样可以成为节点。因此，使用 LangGraph 并不自动意味着系统拥有自主决策能力；一个完全由程序规定路线的图仍然可以只是工作流。

为什么使用图式编排

简单 Agent 可以使用一个模型与工具调用循环完成任务。当执行过程开始出现多个阶段、条件分支、循环、并行任务或人工审批时，只靠一个循环往往难以清楚表达完整规则。

LangGraph 适合把以下部分放在同一执行结构中：

• 模型进行的动态判断；
• 程序规定的确定性步骤；
• 工具调用及结果验证；
• 错误处理和降级路径；
• 人工确认或修改状态；
• 多个 Agent 或子流程之间的转交；
• 长任务的检查点和恢复。

这类图式组织方式与 AI Agent 工程范式的演进中所说的 Graph 工程相对应：图负责协调 Agent 循环、确定性程序和人工节点，但不会替代各节点内部的提示词、工具和业务逻辑。

状态与持久化

状态表示一次执行当前已经知道的信息。为图配置 Checkpointer 后，框架可以在执行过程中保存检查点，使任务能够：

• 在进程中断后从已保存状态继续；
• 暂停并等待人工输入；
• 保留一次会话中的短期状态；
• 查看或调试先前的状态变化。

持久化不是定义 StateGraph 后自动获得的能力。应用仍需选择和配置 Checkpointer，并为不同任务或会话提供稳定标识。长期用户记忆也不是普通图状态的自然延伸，需要单独设计保存、读取和更新规则，相关概念参见 Agent 状态与记忆。

与 LangChain 的关系

LangChain和 LangGraph 位于不同抽象层：

当前 LangChain Agent 构建在 LangGraph 之上，但使用 LangGraph 并不要求同时使用 LangChain。开发者可以在节点内通过任意 SDK 或 HTTP 接口调用模型，也可以使用 LangChain 提供的统一模型和工具组件。

可以把 LangChain 理解为提供常用 Agent 组件和预制循环，把 LangGraph 理解为提供组织、运行和恢复整个流程的结构。这个比喻用于区分职责，并不表示两者必须一起使用。

适用场景

LangGraph适合以下情况：

• 任务包含多个明确阶段和条件分支；
• 需要混合模型决策与确定性业务规则；
• 需要人工确认后再继续执行；
• 需要保存检查点、恢复长任务或管理会话状态；
• 需要控制多个 Agent 或子流程之间的协作；
• 需要对执行路径、状态变化和失败位置进行追踪。

对于一次模型调用、简单信息提取或标准工具调用 Agent，直接使用模型 SDK 或 LangChain 高层 Agent 可能更简洁。图的价值来自流程本身的复杂度和控制需求，而不是节点数量。

使用边界

LangGraph负责运行和编排，不会替应用决定正确的业务架构。开发者仍需设计：

• 状态中允许保存什么信息；
• 敏感凭据是否应该进入可持久化状态；
• 每条分支的进入条件；
• 循环的步数、时间和成本上限；
• 中断后哪些外部操作可以安全重试；
• 工具执行成功后怎样验证真实结果；
• 哪些节点必须等待人工确认。

本文依据 LangGraph 官方文档于 2026 年 9 月 15 日核实。具体接口和内置能力可能随版本变化，使用时应继续查阅 LangGraph 官方概览和 Graph API 文档。