本模块主要讨论

• LangGraph解决的到底是什么问题
• 它和LangChain是什么关系
• 什么场景用高层Agent，什么场景下该下沉到graph

LangGraph解决的到底是什么问题

官网文档给出来的介绍

LangGraph为任何长期、有状态的工作流或者代理提供低级基础设施，提供以下核心优势

• 持久执行：构建可在故障中持久存在并可长时间运行的代理，从中断处恢复
• 人工参与：通过在任何时候检查和修改代理状态，纳入人工监督
• 全面内存：创建具有短期工作内容和长期内存的有状态代理
• 用langsmith进行调试，可以追踪执行链路、捕获状态
• 生产就绪部署：通过可扩展的基础设施，部署复杂的agent系统，处理有状态、长时间运行工作流的独特挑战

一句话

LangGraph解决的是：

• 当LLM应用不再是“一次调用模型就结束”，而是变成“多步骤、有状态、有分支、可中断、可恢复”的系统时，如何把它稳定的编排和运行起来
• 官方把他定位成一个用于构建stateful、多actor应用的的编排框架，并强调durable execution、human in the loop， streaming和memory等能力

为什么需要它

可以把LLM应用分成两类

• 第一类：一次请求，一次返回，比如
  • 问答
  • 摘要
  • 改写
  • 简单工具调用

这种场景，通常一个prompt加一次模型调用即可，可以直接用langchain

• 第二类：长链路、强状态、多步骤，比如
  • 先解析需求，再查数据，再选布局，再渲染
  • 中间可能失败，要重试
  • 需要流式返回过程
  • 需要暂停、恢复、人工确认
  • 需要把中间结果持久化
  • 需要明确控制下一步去哪

这个时候就不只是怎么调模型，而是

• 状态放哪里、步骤怎么串、怎么分支、怎么循环、怎么恢复、怎么观测、怎么让系统长期可维护

这也就是LangGraph想解决的核心，他是一个low level orchestration framework，用来构建可控的agent和workflow，而不只是简单的prompt封装

LangGraph本质上提供了什么

从结构上看，它提供了

• State：共享状态
• Node：处理状态的步骤
• Edge：步骤之间的流转关系
• Runtime：执行、stream、checkpoint、resume这些运行时能力

LangGraph 不是“更强的 prompt 框架”，而是“给 LLM 应用加上工作流引擎和状态机能力”。

LangGraph和LangChain的关系

We will commonly use LangChain components throughout the documentation to integrate models and tools, but you don’t need to use LangChain to use LangGraph. If you are just getting started with agents or want a higher-level abstraction, we recommend you use LangChain’s agents that provide prebuilt architectures for common LLM and tool-calling loops

LangGraph is focused on the underlying capabilities important for agent orchestration: durable execution, streaming, human-in-the-loop, and more.

在本文档中，我们将普遍使用 LangChain 组件来集成模型和工具，但您无需使用 LangChain 即可使用 LangGraph。如果您刚开始接触代理或需要更高级别的抽象，我们建议您使用 LangChain 的代理，它们为常见的 LLM 和工具调用循环提供了预构建的架构。

LangGraph 专注于代理编排所需的基础功能：持久执行、流式处理、人工干预等。

这其实就是他们的关系

LangChain 更偏高层应用框架，LangGraph 更偏底层编排运行时。 官方明确写了，LangChain 的 agents 是基于 LangGraph 构建的，LangGraph 提供更细粒度的 orchestration 和 runtime control。

LangChain

更关注：

• 模型调用封装
• prompt 组织
• tools
• retrievers
• agents
• memory 等上层组件

也就是更偏：

“怎么更快搭一个 LLM 应用”

官方对 LangChain 的定位也是：提供组件和高级 abstractions，帮助快速构建 AI applications。

---

LangGraph

更关注：

• workflow / graph orchestration
• stateful execution
• durable execution
• streaming
• human-in-the-loop
• persistence / checkpointing

也就是更偏：

“当这个 LLM 应用变复杂以后，怎么把它跑稳、跑清楚、跑可控”

官方在 LangGraph Overview 里明确强调这些能力。

一个很常见的关系是

LangChain 负责“节点内部能力”

比如：

• 调模型
• 调 tool
• 做一个 agent
• 做 prompt chain

LangGraph 负责“节点之间怎么编排”

比如：

• 先 A 再 B
• 条件分支
• 循环
• checkpoint
• stream
• resume

所以很多真实项目不是二选一，而是：

LangChain 用来做能力单元，LangGraph 用来做运行时编排。

什么场景用高层 Agent，什么场景下该下沉到 graph

适合用高层 Agent 的场景

官方把 workflow 和 agent 区分得很清楚：workflow 更像预定义代码路径，agent 更像由 LLM 动态决定过程。

所以适合高层 agent 的，通常是：

特征

• 工具数量不多
• 中间状态不复杂
• 步骤顺序不需要强约束
• 允许模型自由决定下一步
• 主要目标是快速验证功能
• 不太需要 checkpoint、resume、人工审批

例子

• 查天气
• 简单客服
• 搜索后总结
• 几个工具的动态选择
• demo 级 agent 应用

这种场景，高层 agent 的优势是：

• 开发快
• 抽象高
• 少写控制流代码

---

适合下沉到 graph 的场景

当你遇到下面这些信号时，就该往 LangGraph 下沉了：

特征

• 明确是多阶段流程
• 有共享 state
• 有条件分支
• 有循环或局部 agent loop
• 需要 stream/invoke 两种执行方式
• 需要 checkpoint / persistence
• 需要取消、恢复、人工介入
• 需要强可观测性
• 需要把业务规则和模型能力分层

例子

• 多步骤业务审批/生成流程
• 复杂数据分析 agent
• 企业级客服编排
• 文档处理流水线
• 你这种“需求分析 → 大纲生成 → 布局/数据/模板链路 → 编辑分支”的系统

LangGraph 官方也把 human-in-the-loop、durable execution、memory 这些能力放在核心卖点里，这些都明显不是简单 agent 的诉求。

一个最实用的判断标准

用高层 agent，当你想的是：

“让模型自己决定怎么做比较方便。”

用 graph，当你想的是：

“这件事的流程我已经知道大致长什么样，我需要把它管住。”