LangGraph 与 LangChain 对比：多智能体开发的框架选择指南关键词LangChain, LangGraph, 多智能体开发, 大语言模型(LLM)应用框架, 对话式代理, 状态机编程, Agentic Workflow摘要随着大语言模型（LLM）如 GPT-4o、Claude 3.5 Sonnet、Qwen3 的普及，Agentic Workflow（智能体工作流）正在成为构建复杂 AI 应用的主流范式。而在 Agentic 开发领域，LangChain 生态无疑是最成熟、社区最活跃的代表之一——从 2022 年底的单智能体链式调用工具包，到 2024 年推出的LangGraph这一专注于状态机驱动的多智能体/复杂工作流框架，LangChain 的产品迭代恰好反映了 LLM 应用从“简单任务自动化”到“复杂协作决策系统”的发展历程。本文将以“一步步思考”的方式，从问题背景、核心概念、技术原理、代码实现、实际应用、最佳实践、行业趋势等多个维度，对LangChain（核心是LangChain Core的Chain/Agent）与LangGraph进行系统性、可落地、有深度的对比。我们会用生活化的例子（如“单人外卖员配送”vs“外卖配送调度团队协作网”）解释两者的本质区别；通过数学模型（状态转移矩阵、概率决策树）量化分析两者的适用场景；给出完整的 Python 代码示例（分别用 LangChain Agent、LangGraph 构建“客户投诉处理智能体协作系统”）；结合真实项目案例（电商客服、金融风控审核、代码审查自动化）总结最佳实践；最后梳理两者的发展历史，并展望 Agentic 开发领域的未来趋势。无论你是 LLM 应用开发的初学者（想快速上手构建简单代理），还是资深工程师（需要构建可解释、可调试、高并发的复杂多智能体系统），本文都能为你提供清晰的框架选择指南，避免踩坑，提高开发效率。正文1. 背景介绍：为什么需要 Agentic 框架？LangChain 和 LangGraph 是怎么来的？1.1 问题背景：LLM 应用的三次浪潮与 Agentic 范式的兴起在进入正式对比之前，我们得先搞清楚：为什么会有 LangChain 这样的工具包？为什么又要推出 LangGraph？这背后其实是 LLM 应用开发的三次技术浪潮。1.1.1 第一次浪潮：“直接调用 LLM API”的零代码/低代码时代（2022年Q1-Q3）LLM 刚火的时候，开发一个 AI 应用特别简单：只需要写几行代码（甚至不用代码，用 OpenAI Playground、HuggingFace Spaces），输入一段提示词（Prompt），就能得到输出。比如：用 GPT-3.5 写邮件：输入“帮我写一封给导师的请假邮件，理由是外婆生病住院，需要回去照顾3天”用 Stable Diffusion 画图：输入“一只戴着帽子的柴犬坐在海边看日落，风格是宫崎骏的动画”这一阶段的应用核心是**“提示词工程”**，几乎不需要框架，直接调用 API 即可。但很快，开发者就发现了问题：功能太单一：只能做“输入-输出”的单步任务，没法做多步任务（比如：先搜索“外婆家到医院的路线”，再写请假邮件，再查机票价格，最后生成行程表）提示词太长太乱：多步任务的提示词需要包含所有步骤的规则、上下文信息，容易超过 LLM 的 Token 窗口限制（2022年 GPT-3.5 的 Token 窗口只有 4k），输出也不稳定没有记忆功能：每次调用 API 都是独立的，没法记住之前的对话历史或任务状态（比如：用户问“昨天你帮我查的柴犬价格是多少？”，直接调用 API 根本不知道“昨天查过柴犬价格”这件事）没法调用外部工具：LLM 的知识是静态的（截止到训练数据的截止日期），没法获取实时信息（比如天气、股票价格），也没法执行具体的操作（比如订机票、发邮件、查询数据库）1.1.2 第二次浪潮：“链式调用+工具增强”的单智能体时代（2022年Q4-2023年Q4）为了解决第一次浪潮的问题，LangChain于 2022 年 10 月由 Harrison Chase 创立——它的核心思想是：把 LLM 应用拆分成一个个“组件”（Component），然后用“链条”（Chain）把组件串联起来。这些组件包括：LLM/Chat Model：大语言模型/对话模型（比如 OpenAI 的gpt-4o、Anthropic 的claude-3.5-sonnet、HuggingFace 的qwen3-7b-chat）Prompt Template：提示词模板（用来动态生成提示词，避免重复写代码）Memory：记忆组件（用来存储对话历史、任务状态，支持 LLM 记住上下文）Tool：工具组件（用来调用外部 API、执行 Python 代码、查询数据库等）Chain：链条组件（把上面的组件串联起来，形成一个可执行的工作流）Agent：代理组件（比 Chain 更高级，能根据 LLM 的推理结果自主选择工具、自主调整步骤，而不是硬编码的串联）举个“单人外卖员配送”的生活化例子：没有框架的直接调用 API：相当于外卖员每次只接一单，而且不知道怎么规划路线，也不知道怎么联系商家和用户，完全靠用户的一句话（提示词）指导——效率极低，还经常出错LangChain 的 Chain：相当于给外卖员配了一张“硬编码的路线图”（比如：先取商家 A 的餐，再送用户 B，再取商家 C 的餐，再送用户 D）——外卖员必须严格按照路线图走，不能调整（比如路上堵车了也不能绕路，用户 B 临时改地址了也不能处理）LangChain 的 Agent：相当于给外卖员配了一个“智能手机导航+语音助手”——导航会根据实时路况自主调整路线，语音助手会根据用户和商家的消息自主决定下一步操作（比如：用户 B 临时改地址，语音助手会先查新地址的位置，再重新规划路线，再联系用户确认）这一阶段的应用核心是**“链式调用+工具增强+自主决策”**，LangChain 几乎垄断了单智能体应用开发的市场——截至 2024 年 6 月，LangChain 在 GitHub 上的 Star 数已经超过了100k，拥有超过1000 个官方/社区贡献的组件，覆盖了几乎所有主流的 LLM、工具、数据库。但随着应用场景越来越复杂，开发者又发现了 LangChain（特别是Chain/Agent）的新问题：Chain 的逻辑太僵化：硬编码的串联没法处理分支、循环、并行、状态回溯等复杂逻辑（比如：外卖员取餐发现商家没做好，需要等待30分钟，这时候 Chain 就没法处理——因为 Chain 是线性的，不能循环）Agent 的逻辑太黑盒：自主决策的过程不可解释、不可调试——你不知道 Agent 为什么选择这个工具，为什么生成这个步骤，如果出错了，很难定位问题（比如：外卖员突然绕了很远的路，你根本不知道是导航坏了，还是语音助手理解错了用户的意思）多智能体协作难实现：Chain/Agent都是单智能体的设计，没法支持多个智能体之间的协作、竞争、通信、同步（比如：外卖平台需要多个外卖员协作配送，需要调度员智能体分配订单，需要导航员智能体规划路线，需要客服智能体处理用户投诉——这在 LangChain 的单智能体框架下很难实现）状态管理混乱：Memory组件虽然能存储一些信息，但没有统一的状态管理机制——每个 Chain/Agent 的状态都是独立的，状态的更新、同步、持久化都很麻烦（比如：用户 B 临时改地址的状态，调度员智能体、导航员智能体、客服智能体都需要知道，但用 LangChain 的 Memory 很难实现这种多智能体之间的状态同步）可扩展性差：随着应用复杂度的增加，Chain/Agent 的代码会变得越来越臃肿，很难维护和扩展（比如：一个简单的客户投诉处理智能体，可能需要几十个组件，代码行数超过 1000 行）1.1.3 第三次浪潮：“状态机驱动+多智能体协作”的复杂系统时代（2024年Q1至今）为了解决第二次浪潮的问题，LangChain 团队于 2024 年 1 月推出了 LangGraph 的第一个 Beta 版本，并于 2024 年 6 月推出了LangGraph 1.0 正式版。LangGraph 的核心思想是：把 LLM 应用（特别是复杂的多智能体应用）建模成一个有限状态机（FSM）或有向无环图（DAG）**（实际上，LangGraph 支持有环的图，也就是循环状态机），其中：节点（Node）：代表一个“动作”（Action）——可以是调用 LLM、调用工具、执行自定义代码、更新状态等边（Edge）：代表“动作之间的转移条件”（Transition Condition）——可以是无条件转移、基于状态值的条件转移、基于 LLM 推理结果的条件转移等状态（State）：代表“整个系统的全局状态”——是一个统一的、结构化的对象，所有节点都可以读取和更新状态智能体（Agent）：在 LangGraph 中，智能体本质上就是“一个状态机的子图”——多个智能体可以通过共享状态或发送消息的方式进行协作还是举“外卖配送调度团队协作网”的生活化例子：LangGraph 的状态机：相当于整个外卖平台的“调度系统”——有一个全局的“调度状态”（包括所有待分配的订单、所有外卖员的位置和状态、所有商家的备餐状态等）LangGraph 的节点：相当于调度系统的“各个部门”——比如：订单接收节点：接收用户的订单请求，更新调度状态外卖员分配节点：根据调度状态（订单的位置、外卖员的位置和状态）自主选择合适的外卖员路线规划节点：为外卖员规划最优路线，更新调度状态备餐监控节点：监控商家的备餐状态，更新调度状态配送监控节点：监控外卖员的配送状态，更新调度状态投诉处理节点：如果用户或商家有投诉，触发投诉处理子图（也就是另一个智能体）LangGraph 的边：相当于调度系统的“工作流程规则”——比如：订单接收节点 → 外卖员分配节点（无条件转移）外卖员分配节点 → 路线规划节点（如果成功分配了外卖员）外卖员分配节点 → 等待节点（如果没有合适的外卖员）等待节点 → 外卖员分配节点（等待5分钟后无条件转移）备餐监控节点 → 配送监控节点（如果商家已经备餐完成）备餐监控节点 → 等待节点（如果商家还没备餐完成）配送监控节点 → 结束节点（如果订单已经配送完成）配送监控节点 → 投诉处理节点（如果用户或商家有投诉）LangGraph 的多智能体协作：相当于调度系统的“各个部门之间的协作”——所有部门都共享同一个“调度状态”，任何一个部门更新了状态，其他部门都能立即看到；如果某个部门遇到了复杂问题（比如投诉处理），可以触发另一个专门的部门（投诉处理子图/智能体）来处理这一阶段的应用核心是**“状态机驱动+多智能体协作+可解释可调试+统一状态管理”**，LangGraph 完美解决了 LangChain（特别是Chain/Agent）的所有问题——截至 2024 年 9 月，LangGraph 在 GitHub 上的 Star 数已经超过了25k，拥有超过100 个官方/社区贡献的节点和工具，覆盖了几乎所有主流的多智能体协作场景。1.2 目标读者本文的目标读者包括：LLM 应用开发的初学者：想了解 LangChain 和 LangGraph 的基本概念，快速上手构建简单的单智能体或多智能体应用LangChain 的老用户：想了解 LangGraph 相对于 LangChain 的优势，知道什么时候该继续用 LangChain，什么时候该切换到 LangGraph资深的 AI/软件工程师：想深入了解 LangChain 和 LangGraph 的技术原理（包括状态机、图论、提示词工程、工具调用机制等），构建可解释、可调试、高并发、可扩展的复杂多智能体系统AI 产品经理：想了解 Agentic 开发领域的技术现状和未来趋势，为产品规划提供技术参考AI 研究者：想了解 LangChain 和 LangGraph 的实现细节，为自己的研究工作提供参考1.3 核心问题或挑战在本文中，我们将重点解决以下几个核心问题或挑战：LangChain 和 LangGraph 的核心概念分别是什么？它们的本质区别是什么？LangChain 的Chain/Agent和 LangGraph 的StateGraph/CompiledGraph分别是怎么工作的？什么时候该用 LangChain？什么时候该用 LangGraph？如何分别用 LangChain 和 LangGraph 构建一个完整的、可落地的应用？使用 LangChain 和 LangGraph 时，有哪些最佳实践和常见问题？LangChain 和 LangGraph 的发展历史是什么？它们的未来趋势是什么？2. 核心概念解析：从“单人外卖员”到“外卖配送调度团队协作网”在这一章节中，我们将用生活化的例子（如“单人外卖员配送”vs“外卖配送调度团队协作网”）解释 LangChain 和 LangGraph 的核心概念，并通过概念核心属性维度对比表格、ER 实体关系图、交互关系图来梳理它们之间的关系。2.1 核心概念：LangChain 生态的核心组件首先，我们来回顾一下 LangChain 生态的核心组件——注意，LangChain 生态现在已经分成了多个独立的包：LangChain Core：LangChain 生态的核心库，包含了所有基础组件的定义（如BaseLLM、BaseChatModel、BasePromptTemplate、BaseMemory、BaseTool、BaseChain、BaseAgent、AgentExecutor等）LangChain Community：包含了社区贡献的组件（如各种 LLM 的封装、各种工具的封装、各种数据库的封装等）LangChain OpenAI：包含了 OpenAI 官方组件的封装（如ChatOpenAI、OpenAIEmbeddings等）LangChain Anthropic：包含了 Anthropic 官方组件的封装（如ChatAnthropic等）LangChain Google：包含了 Google 官方组件的封装（如ChatGoogleGenerativeAI等）LangChain Hub：包含了 LangChain 官方维护的提示词模板库（可以直接拉取使用）LangSmith：LangChain 官方维护的 LLM 应用开发平台（提供了调试、监控、评估、部署等功能）在本文中，我们主要关注LangChain Core的核心组件——因为 LangGraph 也是基于 LangChain Core 构建的。2.1.1 组件 1：LLM/Chat Model（大语言模型/对话模型）生活化比喻：LLM/Chat Model 就像是“外卖员的大脑”——负责思考、推理、决策、生成文本。核心定义：LLM：文本生成模型（Text Generation Model），输入是一段纯文本，输出是一段纯文本（比如 OpenAI 的text-davinci-003、HuggingFace 的qwen3-7b）Chat Model：对话生成模型（Chat Generation Model），输入是一个“消息列表”（List of Messages），每个消息有一个角色（Role）——可以是system（系统提示词）、user（用户输入）、assistant（助手输出）、tool（工具输出），输出是一个“助手消息”（Assistant Message）（比如 OpenAI 的gpt-4o、Anthropic 的claude-3.5-sonnet、HuggingFace 的qwen3-7b-chat）文本示意图：纯文本输入 → LLM → 纯文本输出 消息列表输入 → Chat Model → 助手消息输出示例代码：# 安装依赖# pip install langchain-openai python-dotenvfromdotenvimportload_dotenvfromlangchain_openaiimportChatOpenAIfromlangchain_core.messagesimportSystemMessage,HumanMessage# 加载环境变量（需要在 .env 文件中设置 OPENAI_API_KEY）load_dotenv()# 初始化 Chat Modelllm=ChatOpenAI(model="gpt-4o-mini",temperature=0.7)# 构造消息列表messages=[SystemMessage(content="你是一只戴着帽子的、会说话的柴犬，说话要可爱、幽默，用‘汪汪’结尾。"),HumanMessage(content="你今天想去哪里玩呀？"),]# 调用 Chat Modelresponse=llm.invoke(messages)print(response.content)# 输出示例：我今天想去海边玩！可以捡贝壳、追海鸥，还能躺在沙滩上晒太阳呢！汪汪～
LangGraph 与 LangChain 对比：多智能体开发的框架选择指南
发布时间：2026/5/25 9:25:20
LangGraph 与 LangChain 对比：多智能体开发的框架选择指南关键词LangChain, LangGraph, 多智能体开发, 大语言模型(LLM)应用框架, 对话式代理, 状态机编程, Agentic Workflow摘要随着大语言模型（LLM）如 GPT-4o、Claude 3.5 Sonnet、Qwen3 的普及，Agentic Workflow（智能体工作流）正在成为构建复杂 AI 应用的主流范式。而在 Agentic 开发领域，LangChain 生态无疑是最成熟、社区最活跃的代表之一——从 2022 年底的单智能体链式调用工具包，到 2024 年推出的LangGraph这一专注于状态机驱动的多智能体/复杂工作流框架，LangChain 的产品迭代恰好反映了 LLM 应用从“简单任务自动化”到“复杂协作决策系统”的发展历程。本文将以“一步步思考”的方式，从问题背景、核心概念、技术原理、代码实现、实际应用、最佳实践、行业趋势等多个维度，对LangChain（核心是LangChain Core的Chain/Agent）与LangGraph进行系统性、可落地、有深度的对比。我们会用生活化的例子（如“单人外卖员配送”vs“外卖配送调度团队协作网”）解释两者的本质区别；通过数学模型（状态转移矩阵、概率决策树）量化分析两者的适用场景；给出完整的 Python 代码示例（分别用 LangChain Agent、LangGraph 构建“客户投诉处理智能体协作系统”）；结合真实项目案例（电商客服、金融风控审核、代码审查自动化）总结最佳实践；最后梳理两者的发展历史，并展望 Agentic 开发领域的未来趋势。无论你是 LLM 应用开发的初学者（想快速上手构建简单代理），还是资深工程师（需要构建可解释、可调试、高并发的复杂多智能体系统），本文都能为你提供清晰的框架选择指南，避免踩坑，提高开发效率。正文1. 背景介绍：为什么需要 Agentic 框架？LangChain 和 LangGraph 是怎么来的？1.1 问题背景：LLM 应用的三次浪潮与 Agentic 范式的兴起在进入正式对比之前，我们得先搞清楚：为什么会有 LangChain 这样的工具包？为什么又要推出 LangGraph？这背后其实是 LLM 应用开发的三次技术浪潮。1.1.1 第一次浪潮：“直接调用 LLM API”的零代码/低代码时代（2022年Q1-Q3）LLM 刚火的时候，开发一个 AI 应用特别简单：只需要写几行代码（甚至不用代码，用 OpenAI Playground、HuggingFace Spaces），输入一段提示词（Prompt），就能得到输出。比如：用 GPT-3.5 写邮件：输入“帮我写一封给导师的请假邮件，理由是外婆生病住院，需要回去照顾3天”用 Stable Diffusion 画图：输入“一只戴着帽子的柴犬坐在海边看日落，风格是宫崎骏的动画”这一阶段的应用核心是**“提示词工程”**，几乎不需要框架，直接调用 API 即可。但很快，开发者就发现了问题：功能太单一：只能做“输入-输出”的单步任务，没法做多步任务（比如：先搜索“外婆家到医院的路线”，再写请假邮件，再查机票价格，最后生成行程表）提示词太长太乱：多步任务的提示词需要包含所有步骤的规则、上下文信息，容易超过 LLM 的 Token 窗口限制（2022年 GPT-3.5 的 Token 窗口只有 4k），输出也不稳定没有记忆功能：每次调用 API 都是独立的，没法记住之前的对话历史或任务状态（比如：用户问“昨天你帮我查的柴犬价格是多少？”，直接调用 API 根本不知道“昨天查过柴犬价格”这件事）没法调用外部工具：LLM 的知识是静态的（截止到训练数据的截止日期），没法获取实时信息（比如天气、股票价格），也没法执行具体的操作（比如订机票、发邮件、查询数据库）1.1.2 第二次浪潮：“链式调用+工具增强”的单智能体时代（2022年Q4-2023年Q4）为了解决第一次浪潮的问题，LangChain于 2022 年 10 月由 Harrison Chase 创立——它的核心思想是：把 LLM 应用拆分成一个个“组件”（Component），然后用“链条”（Chain）把组件串联起来。这些组件包括：LLM/Chat Model：大语言模型/对话模型（比如 OpenAI 的gpt-4o、Anthropic 的claude-3.5-sonnet、HuggingFace 的qwen3-7b-chat）Prompt Template：提示词模板（用来动态生成提示词，避免重复写代码）Memory：记忆组件（用来存储对话历史、任务状态，支持 LLM 记住上下文）Tool：工具组件（用来调用外部 API、执行 Python 代码、查询数据库等）Chain：链条组件（把上面的组件串联起来，形成一个可执行的工作流）Agent：代理组件（比 Chain 更高级，能根据 LLM 的推理结果自主选择工具、自主调整步骤，而不是硬编码的串联）举个“单人外卖员配送”的生活化例子：没有框架的直接调用 API：相当于外卖员每次只接一单，而且不知道怎么规划路线，也不知道怎么联系商家和用户，完全靠用户的一句话（提示词）指导——效率极低，还经常出错LangChain 的 Chain：相当于给外卖员配了一张“硬编码的路线图”（比如：先取商家 A 的餐，再送用户 B，再取商家 C 的餐，再送用户 D）——外卖员必须严格按照路线图走，不能调整（比如路上堵车了也不能绕路，用户 B 临时改地址了也不能处理）LangChain 的 Agent：相当于给外卖员配了一个“智能手机导航+语音助手”——导航会根据实时路况自主调整路线，语音助手会根据用户和商家的消息自主决定下一步操作（比如：用户 B 临时改地址，语音助手会先查新地址的位置，再重新规划路线，再联系用户确认）这一阶段的应用核心是**“链式调用+工具增强+自主决策”**，LangChain 几乎垄断了单智能体应用开发的市场——截至 2024 年 6 月，LangChain 在 GitHub 上的 Star 数已经超过了100k，拥有超过1000 个官方/社区贡献的组件，覆盖了几乎所有主流的 LLM、工具、数据库。但随着应用场景越来越复杂，开发者又发现了 LangChain（特别是Chain/Agent）的新问题：Chain 的逻辑太僵化：硬编码的串联没法处理分支、循环、并行、状态回溯等复杂逻辑（比如：外卖员取餐发现商家没做好，需要等待30分钟，这时候 Chain 就没法处理——因为 Chain 是线性的，不能循环）Agent 的逻辑太黑盒：自主决策的过程不可解释、不可调试——你不知道 Agent 为什么选择这个工具，为什么生成这个步骤，如果出错了，很难定位问题（比如：外卖员突然绕了很远的路，你根本不知道是导航坏了，还是语音助手理解错了用户的意思）多智能体协作难实现：Chain/Agent都是单智能体的设计，没法支持多个智能体之间的协作、竞争、通信、同步（比如：外卖平台需要多个外卖员协作配送，需要调度员智能体分配订单，需要导航员智能体规划路线，需要客服智能体处理用户投诉——这在 LangChain 的单智能体框架下很难实现）状态管理混乱：Memory组件虽然能存储一些信息，但没有统一的状态管理机制——每个 Chain/Agent 的状态都是独立的，状态的更新、同步、持久化都很麻烦（比如：用户 B 临时改地址的状态，调度员智能体、导航员智能体、客服智能体都需要知道，但用 LangChain 的 Memory 很难实现这种多智能体之间的状态同步）可扩展性差：随着应用复杂度的增加，Chain/Agent 的代码会变得越来越臃肿，很难维护和扩展（比如：一个简单的客户投诉处理智能体，可能需要几十个组件，代码行数超过 1000 行）1.1.3 第三次浪潮：“状态机驱动+多智能体协作”的复杂系统时代（2024年Q1至今）为了解决第二次浪潮的问题，LangChain 团队于 2024 年 1 月推出了 LangGraph 的第一个 Beta 版本，并于 2024 年 6 月推出了LangGraph 1.0 正式版。LangGraph 的核心思想是：把 LLM 应用（特别是复杂的多智能体应用）建模成一个有限状态机（FSM）或有向无环图（DAG）**（实际上，LangGraph 支持有环的图，也就是循环状态机），其中：节点（Node）：代表一个“动作”（Action）——可以是调用 LLM、调用工具、执行自定义代码、更新状态等边（Edge）：代表“动作之间的转移条件”（Transition Condition）——可以是无条件转移、基于状态值的条件转移、基于 LLM 推理结果的条件转移等状态（State）：代表“整个系统的全局状态”——是一个统一的、结构化的对象，所有节点都可以读取和更新状态智能体（Agent）：在 LangGraph 中，智能体本质上就是“一个状态机的子图”——多个智能体可以通过共享状态或发送消息的方式进行协作还是举“外卖配送调度团队协作网”的生活化例子：LangGraph 的状态机：相当于整个外卖平台的“调度系统”——有一个全局的“调度状态”（包括所有待分配的订单、所有外卖员的位置和状态、所有商家的备餐状态等）LangGraph 的节点：相当于调度系统的“各个部门”——比如：订单接收节点：接收用户的订单请求，更新调度状态外卖员分配节点：根据调度状态（订单的位置、外卖员的位置和状态）自主选择合适的外卖员路线规划节点：为外卖员规划最优路线，更新调度状态备餐监控节点：监控商家的备餐状态，更新调度状态配送监控节点：监控外卖员的配送状态，更新调度状态投诉处理节点：如果用户或商家有投诉，触发投诉处理子图（也就是另一个智能体）LangGraph 的边：相当于调度系统的“工作流程规则”——比如：订单接收节点 → 外卖员分配节点（无条件转移）外卖员分配节点 → 路线规划节点（如果成功分配了外卖员）外卖员分配节点 → 等待节点（如果没有合适的外卖员）等待节点 → 外卖员分配节点（等待5分钟后无条件转移）备餐监控节点 → 配送监控节点（如果商家已经备餐完成）备餐监控节点 → 等待节点（如果商家还没备餐完成）配送监控节点 → 结束节点（如果订单已经配送完成）配送监控节点 → 投诉处理节点（如果用户或商家有投诉）LangGraph 的多智能体协作：相当于调度系统的“各个部门之间的协作”——所有部门都共享同一个“调度状态”，任何一个部门更新了状态，其他部门都能立即看到；如果某个部门遇到了复杂问题（比如投诉处理），可以触发另一个专门的部门（投诉处理子图/智能体）来处理这一阶段的应用核心是**“状态机驱动+多智能体协作+可解释可调试+统一状态管理”**，LangGraph 完美解决了 LangChain（特别是Chain/Agent）的所有问题——截至 2024 年 9 月，LangGraph 在 GitHub 上的 Star 数已经超过了25k，拥有超过100 个官方/社区贡献的节点和工具，覆盖了几乎所有主流的多智能体协作场景。1.2 目标读者本文的目标读者包括：LLM 应用开发的初学者：想了解 LangChain 和 LangGraph 的基本概念，快速上手构建简单的单智能体或多智能体应用LangChain 的老用户：想了解 LangGraph 相对于 LangChain 的优势，知道什么时候该继续用 LangChain，什么时候该切换到 LangGraph资深的 AI/软件工程师：想深入了解 LangChain 和 LangGraph 的技术原理（包括状态机、图论、提示词工程、工具调用机制等），构建可解释、可调试、高并发、可扩展的复杂多智能体系统AI 产品经理：想了解 Agentic 开发领域的技术现状和未来趋势，为产品规划提供技术参考AI 研究者：想了解 LangChain 和 LangGraph 的实现细节，为自己的研究工作提供参考1.3 核心问题或挑战在本文中，我们将重点解决以下几个核心问题或挑战：LangChain 和 LangGraph 的核心概念分别是什么？它们的本质区别是什么？LangChain 的Chain/Agent和 LangGraph 的StateGraph/CompiledGraph分别是怎么工作的？什么时候该用 LangChain？什么时候该用 LangGraph？如何分别用 LangChain 和 LangGraph 构建一个完整的、可落地的应用？使用 LangChain 和 LangGraph 时，有哪些最佳实践和常见问题？LangChain 和 LangGraph 的发展历史是什么？它们的未来趋势是什么？2. 核心概念解析：从“单人外卖员”到“外卖配送调度团队协作网”在这一章节中，我们将用生活化的例子（如“单人外卖员配送”vs“外卖配送调度团队协作网”）解释 LangChain 和 LangGraph 的核心概念，并通过概念核心属性维度对比表格、ER 实体关系图、交互关系图来梳理它们之间的关系。2.1 核心概念：LangChain 生态的核心组件首先，我们来回顾一下 LangChain 生态的核心组件——注意，LangChain 生态现在已经分成了多个独立的包：LangChain Core：LangChain 生态的核心库，包含了所有基础组件的定义（如BaseLLM、BaseChatModel、BasePromptTemplate、BaseMemory、BaseTool、BaseChain、BaseAgent、AgentExecutor等）LangChain Community：包含了社区贡献的组件（如各种 LLM 的封装、各种工具的封装、各种数据库的封装等）LangChain OpenAI：包含了 OpenAI 官方组件的封装（如ChatOpenAI、OpenAIEmbeddings等）LangChain Anthropic：包含了 Anthropic 官方组件的封装（如ChatAnthropic等）LangChain Google：包含了 Google 官方组件的封装（如ChatGoogleGenerativeAI等）LangChain Hub：包含了 LangChain 官方维护的提示词模板库（可以直接拉取使用）LangSmith：LangChain 官方维护的 LLM 应用开发平台（提供了调试、监控、评估、部署等功能）在本文中，我们主要关注LangChain Core的核心组件——因为 LangGraph 也是基于 LangChain Core 构建的。2.1.1 组件 1：LLM/Chat Model（大语言模型/对话模型）生活化比喻：LLM/Chat Model 就像是“外卖员的大脑”——负责思考、推理、决策、生成文本。核心定义：LLM：文本生成模型（Text Generation Model），输入是一段纯文本，输出是一段纯文本（比如 OpenAI 的text-davinci-003、HuggingFace 的qwen3-7b）Chat Model：对话生成模型（Chat Generation Model），输入是一个“消息列表”（List of Messages），每个消息有一个角色（Role）——可以是system（系统提示词）、user（用户输入）、assistant（助手输出）、tool（工具输出），输出是一个“助手消息”（Assistant Message）（比如 OpenAI 的gpt-4o、Anthropic 的claude-3.5-sonnet、HuggingFace 的qwen3-7b-chat）文本示意图：纯文本输入 → LLM → 纯文本输出 消息列表输入 → Chat Model → 助手消息输出示例代码：# 安装依赖# pip install langchain-openai python-dotenvfromdotenvimportload_dotenvfromlangchain_openaiimportChatOpenAIfromlangchain_core.messagesimportSystemMessage,HumanMessage# 加载环境变量（需要在 .env 文件中设置 OPENAI_API_KEY）load_dotenv()# 初始化 Chat Modelllm=ChatOpenAI(model="gpt-4o-mini",temperature=0.7)# 构造消息列表messages=[SystemMessage(content="你是一只戴着帽子的、会说话的柴犬，说话要可爱、幽默，用‘汪汪’结尾。"),HumanMessage(content="你今天想去哪里玩呀？"),]# 调用 Chat Modelresponse=llm.invoke(messages)print(response.content)# 输出示例：我今天想去海边玩！可以捡贝壳、追海鸥，还能躺在沙滩上晒太阳呢！汪汪～
