LangGraph 介绍

LangGraph 是什么？

在正式学习 LangGraph 之前，我们先一起回顾一下 LangChain 所学的内容，梳理完 LangChain 的知识体系后，我们再从它存在的局限性入手，自然过渡到 LangGraph 的学习。

首先回顾我们之前的 LangChain 内容。LangChain 核心给我们建立了链式编程思维，也可以理解为链式的开发编程习惯。在 LangChain 中，我们学习了聊天模型、各类工具等核心内容；除此之外还掌握了大量基础组件，比如文档加载器、检索器等等。同时我们还学到很多进阶用法：聊天模型可以绑定工具、可以绑定结构化输出格式，既支持普通一次性文本返回，也支持流式返回等能力。

借助 LangChain 的链式编程思维，我们能够把工具、各类组件、检索器等模块串联起来，形成一条完整执行链路，从入口输入到末端输出自动运行，这就是 LangChain 教会我们的核心开发模式。

接下来我们用 RAG 案例，把 LangChain 的能力完整串一遍，同时引出它的局限性。首先我们回顾 RAG 的完整流程，主要分为两大核心阶段：

第一阶段是离线数据存储 ：先对原始文档进行拆分切块，再通过 Embedding 向量化处理，最后把向量化后的文档存入向量数据库，完成知识库的离线构建。

第二阶段是在线检索生成 ：用户输入问题后，先对问题做 Embedding 向量化，再拿着向量去向量数据库中做相似度匹配检索，拿到相关文档片段；最后把用户问题 + 检索到的文档上下文一起交给大语言模型，由大模型整合信息生成最终答案并输出。

在 LangChain 里，我们实现 RAG 检索流程，本质就是用链式思维，把检索器等组件串联成一条线性链路，从而搭建出最基础的 AI 应用 Demo。

但这种基础 RAG Demo 有明显短板： 它只能处理和知识库文档相关的问题，如果用户提问和文档内容无关，系统就无法合理应对。

举个具体例子：假设我们的向量知识库中存放的是公司员工手册、员工行为规范 ，或是学校的学生手册、校园管理制度这类内容。这时用户询问上班时间、上课时间这类和知识库相关的问题，RAG 可以正常检索作答；但如果用户问「1+1 等于几」这类无关问题，这套基于 LangChain 链式开发的 RAG 系统就无法合理处理。因为线性链式流程是预先定义好的固定步骤，只能按顺序执行，遇到超出预设范围的问题，只会检索出无关内容，容易产生 AI 幻觉，给出不标准、不靠谱的答案。

这就暴露了 LangChain 链式编程的第一个局限性 ：流程是线性、预先固化的步骤，很难处理分支、循环这类复杂业务场景。

那该如何解决？ 我们可以在原有流程中新增问题类型分类 步骤：先识别用户问题归属，若是和知识库相关的问题，就走正常的检索生成链路；若是无关的通用问题，就分流到全新的处理逻辑中。这种带分支判断 的流程，单纯靠 LangChain 线性链式思维根本实现不了，而这正是 LangGraph 的核心优势 ------ 它可以轻松处理分支、循环，以及流程中需要反复迭代的复杂业务场景。

接下来我们再讲 LangChain 链式编程的第二个局限性 ，换一个用户信息收集、AI 自动订票的场景来理解。

假设我们要开发一个 AI 订票系统，需要收集用户姓名、手机号、身份证号三类必填信息，常规链式流程分为三步：用户输入信息 → 解析用户信息 → 执行订票。

如果用户只输入了姓名和手机号，缺失身份证号，链式流程在解析阶段识别到信息不全后，无法自动回退、无法主动引导用户补充信息 ，只会直接判定订票任务失败。但实际业务中我们需要的逻辑是：识别到信息缺失后，循环引导用户补充缺失信息，补齐所有资料后再进入订票环节，而且整个过程支持人工介入交互、人工补全信息。

这种需要循环交互、人工介入干预 的灵活工作流，LangChain 线性链式模式完全无法支撑，遇到异常只能直接失败，适配不了真实复杂的 AI 业务场景；而 LangGraph 刚好可以完美解决这类问题，支持流程循环、人工介入、灵活调度工作流。

总结来说：LangChain 链式编程存在两大核心局限

流程线性固化，难以实现分支、循环等复杂流程逻辑；
遇到信息缺失、异常场景时无法循环交互、无法人工介入，只能直接任务失败，适配不了复杂 AI 服务的开发需求。

之前我们简单提过：LangChain 是链式线性思维，LangGraph 是图示化思维 。LangChain 是一条直线式执行，从头到尾按固定顺序运行；而 LangGraph 基于图结构设计，天然支持分支分流、循环迭代、人工介入，能承载各种复杂的业务流程编排。

大家也不用觉得学 LangChain 没有用处，恰恰相反，LangChain 为我们打下了坚实的基建基础：我们学过的各类组件、工具定义、聊天模型用法、工具绑定、结构化输出等能力，都可以直接复用在 LangGraph 开发中 。LangChain 更多是帮我们建立基础的 AI 编程思维，适合写简单 Demo；而现在我们要把思维升级，从链式线性思维进阶到图示化工作流思维，用来开发企业级、复杂化的 AI 应用系统。

以往学习 LangChain，我们更多是聚焦「怎么写代码、怎么把组件串成链路」，产出的大多是只能本地运行的简单 Demo，满足不了当下复杂 AI 项目的落地需求。而学习 LangGraph，核心目标是学会构建现代化、复杂化的企业级 AI 应用 ：依托 LangChain 打下的组件和模型使用基础，搭配图示化编程思维、LangGraph 自带的核心能力，再加上AI 系统部署相关知识，把开发好的复杂 AI 应用封装成微服务，支持前端、其他业务服务远程调用，真正实现项目上线落地。

后续我们会结合大量实战案例，讲解 LangGraph 的核心能力、图示化开发思想以及系统部署落地，帮助大家真正具备独立搭建复杂 AI 应用系统的能力，不只是停留在写 Demo 的层面，而是拔高思维、站在工程化的角度去做 AI 项目开发。

认识智能服务（Agent Server）

现在我们已经明确，学习 LangGraph 的核心目标 ，就是如何搭建现代化、复杂化的企业级 AI 应用系统。

在正式学习 LangGraph 的知识点和核心能力之前，我们先要搞清楚一个前提：一套现代化的复杂 AI 应用系统，到底需要具备哪些基础核心能力 。比如有的 AI 应用可以长时间连续对话、拥有持久记忆；有的支持人工中途介入，像我们之前举的 AI 订票场景，能引导用户一步步补全个人信息。以往我们都是用简单 Demo 给大家做演示，接下来我们就深入拆解成熟 AI 应用必备的底层能力。后续我们每学一个 LangGraph 核心知识点，都能对应落地实现 AI 应用里的某一项具体能力，做到学以致用、一一对应！

首先我们来看一下什么是智能服务 Agent Server 。大家要记住：Agent Server 就是我们所说的现代化复杂 AI 应用系统 。它底层依托大模型，通过流程编排能力搭建而成，在 LangGraph 体系中统一称作 Agent Server，也可以翻译成智能服务。不同行业对这类应用的叫法可能不一样，但本质都是基于大模型和编排能力开发的智能化 AI 应用系统。

我们日常其实已经接触过很多这类成熟 AI 产品，比如 ChatGPT 原生模型、DeepSeek 客户端，还有各类 AI 绘画、AI 创作工具。拿 DeepSeek 客户端举例，它并不是直接调用原生大模型，而是在底层封装了一层业务逻辑，再去调用模型能力，本身就是一套标准的现代化 AI 应用，在 LangGraph 范畴里完全可以看作是 Agent Server。

接下来我们以西安周末两日户外旅行规划为例，分析成熟 Agent Server 的核心能力。

当我们向 AI 提出需求后，能清晰看到它的思考逻辑：先提炼需求关键词，锁定目的地西安、两日行程、户外优先三大核心条件；再结合西安本地文旅特点做筛选，优先匹配户外类景点；最后按照天数拆分每日行程，规划游玩安排。

从这个思考过程能总结出 Agent Server 的第一个核心应用能力：任务分解 。它可以把一句简单的用户需求，自动拆解成多个子任务：筛选目的地特色、按户外要求过滤景点、根据天数排布行程。任务拆解得越细致，最终给出的方案就越精准、贴合需求 。

查询目的地天气，根据天气选择室内或户外游玩方案；
匹配对应景点资源；
依据景点位置就近预订酒店；
结合景点和酒店位置，规划每日出行路线，甚至细化地铁、骑行、打车等交通方式；
给出出行衣物、证件等必备建议。后续我们自己基于 LangGraph 开发应用时，就可以主动把这些子任务编排进流程图里，不用依赖提示词引导，系统就能自动完成全流程规划。

第二个核心能力：会话记忆与会话隔离 。大家使用 DeepSeek 能明显感受到：在同一个对话窗口 里，关闭页面重新打开后，AI 能记住我们之前聊过的西安旅行需求；但新建一个对话窗口 ，AI 就没有任何历史记录，完全不知道之前的沟通内容。这就是成熟 AI 应用必备的单次会话记忆 和会话隔离 能力：单个会话内保留完整聊天记录，新建会话开启全新上下文，避免历史信息冗余干扰。而我们用 LangGraph 开发时，还可以进一步升级，实现跨会话记忆 ，即便新建对话窗口，也能调取过往所有聊天信息，功能比普通商用 AI 更灵活。

第三个核心能力：中途反馈与人工介入 。就像之前订票场景中信息缺失、引导用户补充资料一样；旅行规划也可以设置中途确认环节，AI 先反问确认目的地、出行天数，得到我们的明确回复后，再继续细化行程方案。这种流程中途等待人工反馈、人工干预调整 的能力，是复杂 AI 应用不可或缺的。

第四个核心能力：超长持久记忆 。哪怕我们关闭电脑、间隔十天半个月，再次打开对话，AI 依然能记住之前约定的西安旅行规划。后续如果需要调整行程、修改安排，无需重复描述需求，直接基于历史对话优化即可。这种长时间不丢失记忆的特性，是商用级 AI 服务的关键标配。

梳理完 Agent Server 的四大基础能力后，我们还要认清开发这类复杂 AI 应用面临的四大核心难题 ：第一，状态丢失 。很难长久保存会话关键信息、聊天记录，容易出现长时间对话后遗忘历史需求的问题，就像写长文章突然关机，内容全部丢失。第二，难以调试 。AI 就像黑盒，给出错误结果时（比如规划西安旅行却推荐北京景点），无法直观定位是哪一个流程、哪一步逻辑出了问题，排查难度极大。第三，无法中途干预 。固定线性流程走到头，不支持人工中途指导、补充信息、调整方向，只能任务直接失败。第四，部署困难。企业级 AI 应用需要对外提供接口，还要适配流式输出、思考过程与最终结果分事件返回等复杂协议，接口封装、协议定制、线上落地部署的门槛很高。

如果想要开发能 24 小时稳定运行的智能客服、旅行规划助手这类应用，这四大难题必须全部解决，而LangGraph 就是为解决这些问题而生的解决方案 。

所以什么是 Agent Server？它是更聪明的 AI 助手想象一个虚拟的 "小助手"，它不仅能回答问题，还能：

记住和你聊过的所有事情
执行一连串任务（比如：查天气 → 推荐穿搭 → 提醒带伞）
中途可以等你给出反馈
运行很长时间不会 "忘记"

Agent Server 例子：

分镜 1：我说 "帮我规划周末旅行"，Agent Server 界面显示回应。
分镜 2：Agent Server 第一步 "查天气"，屏幕显示天气预报界面。
分镜 3：Agent Server 第二步 "找景点"，屏幕展示景点列表和图片。
分镜 4：Agent Server 第三步 "订酒店"，屏幕显示酒店预订页面。
分镜 5：Agent Server 第四步 "规划路线"，屏幕呈现地图路线图。
分镜 6：Agent Server 第五步 "打包建议"，屏幕列出物品清单。

所以构建 Agent Server 时遇到的四大难题是什么？

难题	描述	就像...
状态丢失	AI 处理长任务时容易 "忘记" 前面步骤	写长文章时电脑突然关机
难以调试	不知道 AI 为什么做出某个决定	黑盒子，看不到内部
无法干预	不能中途给 AI 指导	自动驾驶不能接管
部署困难	复杂 Agent Server 难以上线运行	手工制作 vs 工厂生产

**回顾并思考一下：**如果你要造一个能连续工作 24 小时的 AI 客服，上述哪个问题最头疼？

解决方案：LangGraph -- Agent Server 的 "操作系统"

LangGraph 是一个强大且灵活的 "Agent Server 操作系统内核"。 它不关心我们具体用什么模型或提示词，而是**为我们解决构建复杂、可靠、可交互的 Agent Server 时所面临的状态管理、流程编排、持久化和人工监督等底层工程难题。**如果我们需要构建超越简单问答的、具备复杂逻辑和长期记忆的 AI 应用，LangGraph 就是为此设计的工具。

简单来说，LangGraph 是一个专门用于构建和管理 Agent Server 的底层框架。

市面上将 LangGraph 定义为「强大且灵活的 Agent Server 操作系统内核」，我们不用死记专业定义，只需理解它的核心定位： LangGraph 不绑定具体大模型、不限制提示词写法，专门解决构建复杂、可靠、可交互的 Agent Server 所遇到的状态管理、流程编排、数据持久化、人工监督 四大工程难题。

状态管理：统一保存会话关键信息、聊天记录、流程节点数据；
流程编排：把复杂业务拆分成多个子任务，用图示化方式固定执行流程；
持久化存储：将用户信息、会话记录持久化存入数据库，实现超长记忆；
人工监督：原生支持流程中途人工介入、人工反馈调整。

只要你想开发超越简单问答、具备复杂业务逻辑和长期记忆的 AI 应用，LangGraph 就是必备的底层框架。我们可以用一个通俗的类比理解：如果把 Agent Server 智能应用比作一家公司，大模型是干活的员工，各类工具组件是办公设备 ，而 LangGraph 就是统筹全局的项目经理和标准化流程系统，负责把所有资源合理组织、调度编排。简单来说，LangGraph 就是专门用来搭建和管理复杂 AI 智能应用的底层开发框架。

除此之外，LangGraph 还有三大核心超能力，也是我们后续的重点讲解内容：下面我们简单看看！

LangGraph 的三大超能力

记忆大师

突破传统 AI 单次对话无记忆的局限，无论时隔多久、新建多少会话，都能长久记住用户信息和历史对话；

python 复制代码

# 传统AI：每次对话都是新的开始
AI回答("你好") → "你好！"
AI回答("我叫小明") → "很高兴认识你！"
AI回答("我叫什么？") → "我不知道你的名字"

# LangGraph Agent Server：记住一切
Agent Server("你好") → "你好！"
Agent Server("我叫小明") → "记住你叫小明！"
Agent Server("我叫什么？") → "你叫小明！"

无论过了多久，会话了多少次，LangGraph 都可以记住！

流程指挥官

用图示化思维拆解复杂任务，把大流程拆成标准化小步骤，替代 LangChain 线性链式思维，支持分支、循环流转；

把复杂任务分解成小步骤：

容错卫士

支持故障自动恢复、流程断点续跑；原生集成人工介入能力；对接 LangSmith 实现可视化调试；提供生产级部署方案，适配有状态、长时间运行的 AI 工作流。

LangGraph 还提供了以下关键基础设施，保障 Agent Server 的执行过程：

持久执行：构建能从故障中恢复、长时间运行的 Agent Server。
人工介入：允许在流程中随时检查和修改 Agent Server 状态。
强大的调试能力：与 LangSmith 集成，提供可视化追踪和深度洞察。
生产就绪的部署：为有状态、长时工作流提供可扩展的部署方案。

LangGraph 在现实中的应用

LangGraph 并非理论层面的框架，目前已经在各大互联网公司生产级落地使用，LinkedIn、Uber、GitLab、Klarna 等企业都在用它搭建智能应用。

公司	相关产品 / 服务	主要功能 / 定位	核心技术 / 备注
LinkedIn	LinkedIn AI 代理（如 LinkedIn Coach）	提供个性化工作推荐、人脉拓展、职业发展建议等。	目前主要在探索和测试阶段，旨在提升平台互动体验。
Uber	Uber AI Solutions（智能体解决方案）	为企业提供构建自主、目标驱动的多智能体 AI 可协调处理复杂任务，并能根据数据服务的框架、工具和数据服务。	强调其智能体 AI 可协调处理复杂任务，是其主要技术方向。
Klarna	1. AI 支付与购物助手2. Agentic Product Protocol	1. 处理支付、退款等客服任务，已进行数百万次对话。2. 一个让 AI 智能体能发现和比较线上产品的开放数据协议。	其 AI 助手明确由 LangGraph 构建，是智能体技术在生产环境中的典型应用案例。
GitLab	1. GitLab Duo2. CodeRider	一套覆盖软件开发生命周期（需求、编码、测试、部署等）的 AI 助手套件。	其中 CodeRider 是一款深度集成 GitLab 的 AI 编程工具，基于 LangGraph 开发。
...	...	...	...

除了表格中的概述，各公司的智能体产品在设计和应用上各有侧重：

Klarna 是瑞典的一家金融公司，它的 AI 助手是将 LangGraph 应用于生产业务的典范。它已经处理了超过 250 万次对话，自动化了约 70% 的重复性客服任务，将平均问题解决时间缩短了 80%。该助手是一个多智能体系统，能自主路由请求、处理不同任务（如支付、退款等），并显著提升了服务效率。
GitLab 的 AI 产品线非常丰富，其 CodeRider 产品特别值得关注。它基于 LangGraph 构建，不仅提供代码补全、解释等基础功能，更能胜任复杂任务的全流程智能开发，例如自动分解任务、漏洞解释、合并请求摘要等数十种功能，旨在扮演虚拟开发团队的角色。

学习 LangGraph 之后，我们可以自主搭建各类个性化 AI 应用：带记忆的个人学习助手、能处理复杂咨询的智能客服、多步骤自动化数据分析工具、拥有独立记忆的游戏 NPC 等等，发挥想象力就能落地对应的产品。

最后简单介绍 LangGraph 生态： 它属于 LangChain 产品家族，可与 LangSmith、LangGraph 部署平台无缝联动，形成开发、调试、线上部署的完整闭环；既可以和 LangChain 搭配使用，也能脱离 LangChain 独立部署开发，灵活性极强。

LangGraph 生态系统

LangGraph 是 LangChain 产品家族的一部分。可以与 LangSmith（用于追踪、评估、监控）、LangGraph 部署平台（用于轻松部署和扩展 Agent Server）以及 LangChain（提供大量集成和组件）结合使用，形成完整的开发、调试、部署工作流。

LangGraph 与 LangChain 顺利集成，但也可以在没有 LangChain 的情况下使用。

LangGraph 的核心概念

接下来我们开始讲解 LangGraph 中的核心基础概念。

正式讲概念之前，我们先把 AI 生态里容易混淆的几个名词做清晰区分：很多同志听过 Agent 、Agent Server ，还有工作流（Workflow） ，首先要搞懂 Agent 和工作流的本质区别 。先给大家一个定论：LangGraph 本质上属于工作流框架 ，不属于原生 Agent；先把这个结论记下来，再逐层拆解概念，最后再讲工作流里的节点、边、状态这些核心要素。

常见概念区分

Agent

Agent 也常被译作智能体、代理 。它的定义是：能够感知外部输入环境、自主做决策 、自己规划行动路径、还能主动调用工具，最终达成用户目标。Agent 最核心的特征 ：由大模型动态控制整个流程的走向 ，没有固定预设步骤。

我们用 DeepSeek 举例理解：DeepSeek 不是只做旅游规划的专用助手，它能处理生活、工作、专业各类问题，通用性极强，它本身就是典型的 Agent【DeepSeek 更像一个"Agent Server"，但对外呈现时被简化成"一个Agent"。】 。当我们给它需求：帮我规划西安周末两日户外游，它没有固定写死的流程，而是自己感知需求、自主拆解任务 ：先锁定目的地西安、再匹配户外场景、再按两天时间拆分每日行程，整个思考和执行路径，都是大模型实时动态决定的，不是我们提前规定好的。

再举个例子：让智能助理安排下周上海出差，它可能先查天气、再查航班、预订酒店、提醒带证件；也可能省略查天气，直接订酒店和行程。步骤不固定、顺序不固定、可多可少 ，完全由大模型根据场景自主判断，这就是标准的 Agent 行为。

补充区分：Agent ≠ Agent Server

Agent 是智能决策的能力本身；Agent Server 是最终落地的智能化应用系统、服务端产品，在 LangGraph 体系里，我们做的复杂 AI 应用，都可以叫 Agent Server。看懂这些名词定义，后续看文档、看教程就不会混淆。

bash 复制代码

┌─────────────────────────────────────────────┐
│           Agent Server（服务系统）            │
│  ┌──────────────────────────────────────┐   │
│  │  网络层（API / HTTP / WebSocket）      │   │
│  ├──────────────────────────────────────┤   │
│  │  服务治理（限流/鉴权/负载均衡/日志）     │   │
│  ├──────────────────────────────────────┤   │
│  │  状态管理（会话/缓存/持久化）           │   │
│  ├──────────────────────────────────────┤   │
│  │  ┌────────────────────────────────┐  │   │
│  │  │      Agent（决策核心）           │  │   │
│  │  │  - 推理 / 规划                  │  │   │
│  │  │  - 记忆 / 工具调用              │  │   │
│  │  │  - LangGraph 节点与边           │  │   │
│  │  └────────────────────────────────┘  │   │
│  └──────────────────────────────────────┘   │
└─────────────────────────────────────────────┘


第1步：构建 Agent
   ↓
写 LangGraph 图定义
定义节点、边、工具、记忆逻辑
本地测试决策能力
   ↓
第2步：封装成 Agent Server
   ↓
加 FastAPI/Flask 接口
加会话管理、数据库
加部署配置（Docker/K8s）
加监控和日志
   ↓
第3步：对外服务

所以说：Agent（智能体）是一个能够感知环境输入、自主决策、规划行动路径，并可调用工具或执行操作以达成目标的自主性软件实体。

其核心在于：由大语言模型（LLM）动态控制流程走向

维度	普通 LLM 应用	Agent
LLM 的角色	"一次回答者"	"循环决策者"
流程控制者	开发者（代码写死流程）	LLM（动态决定流程）
典型模式	用户提问 → LLM 回答 → 结束	设定目标 → LLM 思考 → 执行动作 → 观察结果 → LLM 再思考 → 再执行 → 循环直到完成
有没有"闭环"	❌ 没有	✅ 有（思考-行动-观察循环）

想象你有一个超级聪明的程序员助手，你只需要说一句："把这个项目的单元测试覆盖率提升到 80%."然后他就自己去看代码、写测试、运行构建、检查结果...... 直到达标为止 ------ 中间不需要你插手.这个 "能独立完成任务" 的程序，就是我们说的 Agent（智能体）.

想象一个私人助理机器人：

你说："帮我安排下周去上海的差旅."
它不会傻傻地只回复 "好的"，而是会：a. 查天气 → 决定带什么衣服b. 查航班 / 高铁时间 → 比较价格c. 预订酒店 → 发送日程到你的手机d. 提醒你带身份证

整个过程没有固定的流程图，它自己 "想" 出来的步骤 ------ 这就是典型的 Agent 行为

工作流

Workflow（工作流）是一个将复杂过程分解为定义明确、顺序执行的任务流程，并在其中自动化传递数据与任务的状态，用户完成特定目标。如果说 Agent 是聪明的执行者，那工作流就是它的行动蓝图 ------ 它定义了 "先做什么、后做什么、在什么条件下跳转或终止"。

其核心在于：预设的、可重复的流程路径.

比如公司的报销流程

提交发票 → 领导审批 → 财务审核 → 财务结算 → 归档完成

或者一个自动化客服工单系统

用户提交问题 → 系统自动分类 → 分配给对应客服 → 客服处理 → 用户评价 → 工单关闭

这个固定路径，整个过程沿着预设的流程运行，就是典型的工作流行为.

LangGraph 是实现的就是工作流！

可以一句话对比：

Agent：聪明的自主决策者，流程随机、灵活开放，大模型自己说了算；
工作流：固定的行动蓝图，流程提前预设、步骤死板、按规定顺序执行。

工作流和 Agent 区别

从概念上来讲，工作流的流程固定，步骤预设，适合明确流程的任务. Agent 是由大模型 (LLM) 动态控制流程走向，灵活度高.

类型	英文名	特点	适用场景
工作流	Workflow	流程固定，代码驱动，步骤预设	明确流程的任务，如客服工单处理
智能体	Agent	动态决策，LLM 控制流程走向	开放问题求解，如科研推理

Workflow 像是 "炒菜机器人"------ 按步骤进行炒菜。比如放油 → 炒蛋 → 加盐 → 出锅，即使鸡蛋坏了，也不会停下来.

Agent 像是 "米其林主厨"------ 他会思考："今天食材新鲜吗？客人忌口吗？要不要换做法？"

自主决定菜单
调整火候和配料
品尝后返工改进

但无论是 Workflow 还是 Agent，对于他们做出来的 AI 应用，在 LangChain 中，可以统称为 Agent Server!

工作流

工作流介绍

工作流具有预先确定的代码路径，并设计为按特定顺序运行。当需要设计更高复杂性的 AI 应用时，工作流为定义明确的任务提供可预测性和一致性。

例如，现在需要研发一款主打城市通勤的智能电动自行车，具有导航、社交、防盗等功能。在开始研发前，需要进行多维度分析，如：

市场分析：用户关注续航里程、车身重量、防盗能力，并对 "骑行社交"（组队、分享路线）有新兴兴趣。
竞品分析：传统品牌车型智能化不足；互联网品牌车型续航和线下售后服务是其短板。
技术分析：评估更轻量化的电池材料与车身设计以提升续航和便携性，并开发基于 GPS 和移动网络的智能防盗系统与社交功能 App 的集成。
最终汇总分析结果。

则我们可以将多维度分析设定为具体的流程（工作流），从而达到先分析再汇总的特定运行顺序。如下图所示：

在 LangGraph 中，工作流基于 LLM，以及添加到其中的各种增强功能（如工具调用、结构化输出和短期记忆）而实现：

（图示：In → [LLM 大脑] → Out；LLM 连接 Retrieval（书籍图标）、Memory（大脑图标）、Tool（扳手图标））

再次强调：LangGraph 是一个强大且灵活的 "Agent Server 操作系统内核"。它不关心我们具体用什么模型或提示词，而是为我们解决构建复杂、可靠、可交互的 Agent Server 时所面临的状态管理、流程编排、持久化和人工监督等底层工程难题。

LangGraph 与工作流的关系

重点结论：

LangGraph 是一个用于构建图式工作流和 Agent 的框架。

我们之前学的 LangChain 链式调用，属于线性工作流------从头到尾按顺序执行，无法分支、无法循环、无法中途干预。

LangGraph 在此基础上做了三个核心升级：

图式结构：由节点和边组成，像数据结构里的图，天然支持分支、循环、并行
持久化状态：可以随时保存和恢复执行状态
动态路由：可以让 LLM 在运行时决定走哪条边（这是实现 Agent 的关键）

简单理解：LangChain 链 = 一条直路走到黑；LangGraph = 允许你画地图、设红绿灯、甚至让司机自己选路。后者既能做确定性工作流，也能做真正的 Agent。

理解图计算

如何实现工作流逻辑？图计算是一种用节点和边来表示复杂系统的方法。在 AI 领域，它特别适合构建多步骤、有状态的智能工作流。

工作流分为链式工作流 和图式工作流 ，LangGraph 核心就是图式工作流 。其中图计算就是 用节点和边来描述复杂系统结构，特别适合搭建多步骤、有状态流转的 AI 智能工作流。

我们用全国快递配送系统 类比，最容易理解：整个快递配送网就是一张图；各地揽收站、分拣中心、配送站，都是节点；站点之间的陆运、空运运输路线，就是边。

想象一个快递配送系统，下图展示了包裹从输入（揽收站）到输出（配送站）的过程：

配送站、揽收站、分拣中心 = 节点（Node）
运输路线 = 边（Edge）
包裹信息 = 状态（State）
完整配送网 = 图（Graph）

快递包裹先到家门口揽收站 → 2. 转运到城市分拣中心 → 3. 跨城运输到目的地分拣中心 → 4. 下发到本地配送站 → 5. 配送员送货上门。整个网络由节点（站点）和边（运输路径）构成，和 LangGraph 里的图结构完全对应。

换到我们的 AI 旅游推荐助手 场景：

输入：用户的旅游需求问题

输出：完整旅游方案我们把整个任务拆成多个子任务，每一个子任务就是一个节点：

节点 1：识别出行目的地
节点 2：解析用户游玩要求（如户外优先）
节点 3：筛选匹配景点
节点 4：整合生成最终行程方案

边就是节点之间的流转关系：规定好只能从节点 1 传到节点 2、节点 2 传到节点 3，不能随意跳转，就像快递不能从配送站再退回揽收站一样，路径提前定好。

实现工作流的核心概念

**LangGraph 三大核心概念：**状态、节点、边

State（状态）- 快递的 "包裹信息"

State 就像快递包裹上的标签，记录着包裹的当前位置、目的地、配送状态等信息。在整个配送过程中，所有站点都能查看和更新这个信息。

状态特性：

共享性：所有节点（快递站点）都能读取和修改
持久性：在整个工作流（快递运输）执行期间持续存在
结构化：有明确的字段定义

代码示例：

python 复制代码

from typing import TypedDict

class PackageState(TypedDict):
    # 包裹基本信息
    package_id: str        # 包裹id
    origin: str            # 始发站
    destination: str       # 目的地

    # 配送状态
    status: str            # "待揽收", "运输中", "派送中", "已签收"
    history: list[str]     # 流转历史
    total_distance: int    # 总里程

    # 配送详情
    priority: str          # "普通", "加急"

所有配送站点共享的包裹信息卡就是 LangGraph 中的 State!

Nodes（节点）- 快递站点

节点就像快递配送网络中的各个站点，每个站点负责特定的处理步骤。例如：

揽收站：接收包裹，初始化信息
分拣中心：根据目的地分类包裹
派送站：最终配送至收件人

节点特征：

单一职责：每个节点只做一件事
输入输出：接收状态，返回状态更新
独立性：节点间不直接通信，通过 State 交互

代码示例（节点只不过是函数）：

python 复制代码

def receive_package(state: PackageState):
    """揽收站"""
    return {
        "status": "已揽收",
        "history": [f"在{state['origin']}揽收"]
    }

def sort_package(state: PackageState):
    """分拣中心：根据目的地分拣"""
    destination = state["destination"]
    if "北京" in destination:
        next_station = "北京分拣中心"
    elif "上海" in destination:
        next_station = "上海分拣中心"
    else:
        next_station = "其他地区分拣中心"

    return {
        "status": "已分拣",
        "history": [f"分拣至{next_station}"]
    }

def final_delivery(state: PackageState):
    """派送站"""
    return {
        "status": "已签收",
        "history": [f"已送达{state['destination']}"]
    }

Edges（边）- 快递运输路线

边定义了包裹在站点之间的流动路径，就像快递公司的运输路线图。对于路线，一般类型有：

开始 / 结束路线：流程的开始和结束点（包裹的开始站，与结束站）

固定路线：包裹可以从揽收站→分拣中心（所有包裹都走这条路），而不能从配送站→揽收站，而是配送站→家。

条件路线：根据目的地选择不同的分拣中心

实际上在 LangGraph 中，边就定义了节点之间的连接关系，决定了工作流的执行顺序。边的类型有：

固定边：总是从 A 到 B
条件边：根据状态决定下一步
以及图的开始和结束点，标志了工作流的入口和出口。

因此，LangGraph 通过节点（每个处理步骤）、边（步骤之间的连接）和状态（保存执行过程），就可以构建出一个任务工作流（图）。