目录
[一、LangGraph 介绍](#一、LangGraph 介绍)
[LangGraph 是什么？](#LangGraph 是什么？)
[agent 和 agent server 的区别?](#agent 和 agent server 的区别?)
[Agent Server 例子：](#Agent Server 例子：)
[构建 Agent Server 时遇到的四大难题](#构建 Agent Server 时遇到的四大难题)
[解决方案：LangGraph -- Agent Server 的 "操作系统"](#解决方案：LangGraph -- Agent Server 的 “操作系统”)
[二、LangGraph 的三大超能力](#二、LangGraph 的三大超能力)
[三、LangGraph 在现实中的应用](#三、LangGraph 在现实中的应用)
[四、LangGraph 生态系统](#四、LangGraph 生态系统)
[五、LangChain 和 LangGraph 对比](#五、LangChain 和 LangGraph 对比)
一、LangGraph 介绍
LangGraph 是什么？
认识智能服务 (Agent Server)
我们在 LangChain 的专栏中已经学习过了 LangChain，我们已经知道 AI 世界是如何初步搭建的。实际我们已经用过：
- ChatGPT 原生模型：对话式 AI，一问一答
- DeepSeek 客户端：类似的对话助手
- 一些 AI 工具：比如 AI 画画、AI 写文章等
在 LangChain 篇章中，我们接入 LLM 构建的 AI 系统有以下特点：
- 单次对话，"记不住" 太多上下文
- 主要是问答模式
- 相对简单的任务
什么是 Agent Server ？
它是更聪明的 AI 助手，想象一个虚拟的 "小助手"，它不仅能回答问题，还能：
- 记住和你聊过的所有事情
- 执行一连串任务（比如：查天气→推荐穿搭→提醒带伞）
- 中途可以等你给出反馈
- 运行很长时间不会 "忘记"
agent 和 agent server 的区别?
Agent 是 AI 智能体 本体，Agent Server 是跑它的后台服务载体。
Agent 就是那个具备思考、调用工具、规划多步任务逻辑的 AI 智能体，是一套业务逻辑。用 LangGraph 写出来的流程图、状态流转、工具调用、记忆判断，这些全部属于 Agent 本身。它定义了遇到问题该怎么思考、下一步调用什么工具、怎么保存对话状态，相当于 "小助手的大脑和行为逻辑"。脱离运行环境，它只是一套代码逻辑。
Agent Server 是专门用来托管运行 Agent 的后台服务程序。它给 Agent 提供运行环境，负责持久化保存 Agent 的会话状态、记忆、任务进度，接收外部发来的请求，驱动 Agent 逻辑一步步执行，还支持任务中途暂停，等待人类反馈之后再继续跑。相当于给这个 "小助手大脑" 搭了一个常驻后台运行的服务器容器。
做个通俗类比 : Agent 好比写好的机器人程序，规定机器人看见什么要做什么事。Agent Server 就是机器人的主机服务器，一直通电开机维持机器人程序运行，保存机器人的记忆和任务进度，接收外界指令，还可以中途停下来等人类下达新指令。
落实到代码层面，我们后面写 LangGraph 代码，定义节点、边、状态，产出的就是 Agent。把这个 Agent 封装部署成对外可访问的后台服务，能够持久存储会话、支持人机中断交互，这个部署出来的服务实例就是 Agent Server。
没有 Agent Server 的时候，Agent 只能单次运行，每次请求结束状态就丢掉，很难做到长时间会话、中途等待用户反馈。部署到 Agent Server 之后，Agent 的状态可以持久落库，任务可以跨轮次继续执行，支持人机交互断点。
Agent Server 例子：
分镜 1：我说 "帮我规划周末旅行"，Agent Server 界面显示回应。
分镜 2：Agent Server 第一步 "查天气"，屏幕显示天气预报界面。
分镜 3：Agent Server 第二步 "找景点"，屏幕展示景点列表和图片。
分镜 4：Agent Server 第三步 "订酒店"，屏幕显示酒店预订页面。
分镜 5：Agent Server 第四步 "规划路线"，屏幕呈现地图路线图。
分镜 6：Agent Server 第五步 "打包建议"，屏幕列出物品清单。
构建 Agent Server 时遇到的四大难题
思考一下： 如果我们要造一个能连续工作 24 小时的 AI 客服，上述哪个问题最头疼？
解决方案：LangGraph -- Agent Server 的 "操作系统"
LangGraph 是一个强大且灵活的 "Agent Server 操作系统内核"。它不关心我们具体用什么模型或提示词，而是为我们解决构建复杂、可靠、可交互的 Agent Server 时**所面临的状态管理、流程编排、持久化和人工监督等底层工程难题。**如果我们需要构建超越简单问答的、具备复杂逻辑和长期记忆的 AI 应用，LangGraph 就是为此设计的工具。
如果把 Agent Server 比作一个公司，那么：
- AI 模型 = 员工（干活的人）
- 工具 = 办公设备（电脑、电话）
- LangGraph = 项目经理 + 流程系统
简单来说，LangGraph 是一个专门用于构建和管理 Agent Server 的底层框架。
二、LangGraph 的三大超能力
记忆能力
伪代码:
- 传统 AI 每一次调用模型，上下文不会自动保存，模型没有持久记忆，当提问 "我叫什么？" 时，获取不到之前对话里的名字信息。
- 而 LangGraph Agent Server 部分框架自带状态存储，对话信息会保存在状态中，多次交互之间不会丢失信息，可以读取历史对话内容给出正确回复。
无论过了多久，会话了多少次，LangGraph 都可以记住！
流程指挥能力
把复杂任务分解成小步骤：
流程图节点顺序：开始 → 理解需求 → 执行步骤 1 → 检查结果 → 执行步骤 2 → 等待反馈 → 继续执行 → 结束
容错能力
LangGraph 还提供了以下关键基础设施，保障 Agent Server 的执行过程：
- **持久执行：**构建能从故障中恢复、长时间运行的 Agent Server。
- **人工介入：**允许在流程中随时检查和修改 Agent Server 状态。
- **强大的调试能力：**与 LangSmith 集成，提供可视化追踪和深度洞察。
- **生产就绪的部署：**为有状态、长时工作流提供可扩展的部署方案。
三、LangGraph 在现实中的应用
LangGraph 为生产级代理提供支持，受到 LinkedIn、Uber、Klarna、GitLab 等公司的信赖。
除了表格中的概述，各公司的智能体产品在设计和应用上各有侧重：
- Klarna 是瑞典的一家金融公司，他的 AI 助手是将 LangGraph 应用于生产级业务的典范。它已经处理了超过 250 万次对话，自动化了约 70% 的重复性客服任务，将平均问题解决时间缩短了 80%。该助手是一个多智能体系统，能自主路由请求、处理不同任务（如支付、退款等），并显著提升了服务效率。
- GitLab 的 AI 产品线非常丰富，其 CodeRider 产品特别值得关注。它基于 LangGraph 构建，不仅提供代码补全、解释等基础功能，更能胜任复杂任务的全流程智能开发，例如自动分解任务、跨文件编辑代码、执行终端指令等。而 GitLab Duo 则是一个更广泛的 AI 功能套件，包含代码建议、漏洞解释、合并请求摘要等数十种功能，旨在扮演虚拟开发团队的角色。
思考一下，我们可以构建什么？
- 个人学习助手（记住你的学习进度）
- 智能客服（处理复杂咨询）
- 数据分析助手（多步骤分析）
- 游戏 NPC（有记忆的虚拟角色）
四、LangGraph 生态系统
**LangGraph 属于 LangChain 大家族，专门用来写会思考、会循环、会分步干活的 AI 智能体。**整套生态可以拆成核心代码库、配套工具、存储部件、现成模板、观测调试这几块。
核心库就是 langgraph，这是最基础的东西。我们在这里定义节点、跳转逻辑、全局状态。节点可以是调用大模型、调用工具、做计算。状态就像一个共享记事本，所有节点都能读、能改里面的数据。它允许循环，做完一步可以跳回前面重新思考，这是普通链式组件做不到的。同时支持人介入，跑到一半可以停下等我们输入信息。但要记住，只单纯用这个库本地跑，数据全在内存里，程序一关，所有进度全部消失。
然后是检查点组件 Checkpointer。可以理解成游戏存档。每跑完一个节点，它就把当前完整状态存一份快照。出错可以回退到之前任意存档点重跑，调试的时候非常方便。本地测试可以用 SQLite，正式环境一般接 PostgreSQL 数据库。它只管存档，不对外提供网络接口。
langgraph‑prebuilt 是现成的工具箱。很多通用智能体模式官方已经写好了，不用从零画流程图。比如 ReAct 思考调用工具的智能体、主管分配任务的多智能体模板，直接导入就能用，只需要改少量参数适配自己业务。
记忆相关组件 Memory。全局 State 存的是本次任务临时数据，Memory 负责抽出来长期记忆，比如记住用户的偏好、历史习惯。记忆独立出来，不会把所有东西都堆在流程图状态里面。
调试工具 LangSmith，相当于智能体的日志后台。每一次大模型调用、工具调用、节点输入输出，全部记录下来。能看清智能体每一步到底在想什么，哪里出错，消耗多少 token，还可以拿历史会话复现 bug，做效果评估。
LangGraph Studio 是本地可视化工具。加载你的代码之后，图形展示流程图，你可以单步执行，手动修改状态内容，观察每一步会走向哪个分支，不用疯狂打印日志排查问题。
LangGraph Cloud 是官方托管平台。你上传自己写好的 LangGraph 代码，云端帮你跑起来，自动处理存档、数据库，不用自己搭服务器，直接拿接口调用。
作为 LangChain 产品家族的一部分。可以与 LangSmith（用于追踪、评估、监控）、LangGraph 部署平台（用于轻松部署和扩展 Agent Server）以及 LangChain（提供大量集成和组件）结合使用，形成完整的开发、调试、部署工作流。
五、LangChain 和 LangGraph 对比
那为什么 LangChain 没有像 LangGraph 这么多功能？
LangChain 不是做不到，而是底层设计目标一开始就不一样，LangChain 的定位是流水线，LangGraph 定位是流程图引擎，二者底层模型不一样。
LangChain 最早出来的时候，目标是快速拼简单 AI 应用，比如 RAG 文档问答、文本摘要。它的核心是 Chain，流水线模式，数据只能单向往前流。好比工厂传送带，零件从开头送进去，一步一步经过各个工位，一直走到末尾就结束，传送带不能倒回去，不能分叉绕圈。框架本身不支持流程跳回前面。
**它没有一个全局共享的 "状态黑板"。**Chain 每一步之间只传递上一步的输出，中间产生的零散信息没有统一地方存放。对话历史、工具返回结果、临时业务数据全部要自己手动传来传去，很容易丢数据、上下文错乱。
**原生不支持中途停下来等人。**流水线一旦启动就要一口气跑完整个链路。想要中途暂停，等待人输入确认，再接着跑剩下逻辑，LangChain 没有原生机制，全部要自己写额外逻辑控制。而且进程一旦结束，所有内存里的中间进度直接清空，没有存档能力。
那为什么官方不直接把这些功能塞到 LangChain 里面？
第一，架构改动会彻底推翻旧 Chain 整套逻辑。传送带模型天生就不适合循环回跳、全局状态、断点存档。硬塞进去旧 API 全部破坏，老项目全部不能用，兼容性直接报废。
第二，会增加普通场景的负担。很多场景就只是简单 RAG、单轮问答，不需要循环、存档、断点。如果全部内置状态、快照这些能力，简单任务也会带上额外开销，学习难度也会变高。官方选择拆成两个库：简单任务继续用 LangChain 组件，复杂 Agent 编排单独交给 LangGraph 做。
**而 LangGraph 相当于换了一套底层模型，它是一张图，有节点、有边，还有一块所有人都能读写的全局状态黑板。**可以设置条件边，跑完工具发现信息不足，直接跳回思考节点再来一轮，框架原生支持循环。Checkpointer 原生提供存档快照，任务跑一半可以原生 interrupt 暂停，等用户输入之后，从存档点继续执行，不需要我们手写大量胶水代码。
也要分清，LangGraph 不是凭空造新东西，它大量复用 LangChain 的组件：提示词模板、各种大模型封装、工具封装、检索器，这些 LangChain 组件都可以直接拿到 LangGraph 节点里面用。二者是互补，不是互相替代。