在构建大型语言模型（LLM）应用时，你是否也曾面临过这样的困境：希望开发一个能够预订机票、查询天气，并在多次对话中记住用户偏好的AI助手？一开始你选择了LangChain，认为它是LLM应用的完美选择。但三周后，你却在状态管理、循环逻辑中苦苦挣扎，怀疑自己是不是在制造一台复杂而低效的“鲁布·戈德堡机械”。许多开发者并没有意识到，选择错误的LLM框架会将一个原本两周的项目变成长达两个月的噩梦。LangChain 和 LangGraph 都承诺简化 LLM 的开发，但它们的设计目标却截然不同。一个擅长线性工作流，而另一个则擅长复杂的交互式系统。选择错误，你将花费更多时间与框架作斗争，而不是构建功能。那么，你应该选择哪一个呢？答案取决于你的应用程序行为的一个关键问题。
LangChain：线性工作流的利器
核心关键词：线性工作流，链式操作，DAG（有向无环图）
LangChain 的核心是一个通过执行一系列链式操作来构建 LLM 驱动应用程序的框架。 可以把它想象成一个有向无环图 (DAG)，其中的任务以特定的、向前移动的顺序执行，绝不会在同一链中重新访问之前的步骤。 这种结构使得 LangChain 非常适合你知道应用程序需要按照预定流程执行的任务。
例如，构建一个文档问答系统。使用 LangChain，可以定义一个包含以下步骤的链：
- 文档加载 (Document Loading): 使用 LangChain 提供的文档加载器（如
TextLoader,PDFLoader）从不同的数据源（例如文本文件、PDF 文件、网页）加载文档。 - 文本分割 (Text Splitting): 将加载的文档分割成更小的文本块，因为 LLM 通常有输入长度限制。LangChain 提供了多种文本分割器，例如
CharacterTextSplitter和RecursiveCharacterTextSplitter，允许你根据不同的策略（例如字符、分隔符、递归等）分割文本。 - 嵌入 (Embedding): 将分割后的文本块转换为向量嵌入。嵌入是将文本转换为数字表示的过程，它可以捕捉文本的语义信息。LangChain 可以与各种嵌入模型集成，例如 OpenAI 的
text-embedding-ada-002模型或 Hugging Face 的 Sentence Transformers 模型。 - 向量存储 (Vector Storage): 将文本嵌入存储在向量数据库中。向量数据库是一种专门用于存储和检索向量嵌入的数据库。LangChain 可以与各种向量数据库集成，例如 Chroma、FAISS 和 Pinecone。
- 检索 (Retrieval): 当用户提出问题时，使用 LLM 将问题转换为嵌入，然后在向量数据库中搜索与问题嵌入最相似的文本嵌入。检索到的文本块被认为是与问题最相关的上下文。
- 生成 (Generation): 将问题和检索到的上下文传递给 LLM，以生成答案。可以提示 LLM 使用上下文来回答问题，并引用来源。
每个步骤都依赖于前一个步骤的结果，形成一个清晰、线性的数据流。这种模式在处理订单管理、数据分析管道、客服机器人等场景中非常有效，因为这些场景通常需要按照固定的流程执行任务。例如，一个电商平台的订单处理流程可能包括：
- 验证订单信息
- 检查库存
- 生成发货单
- 发送支付请求
- 更新库存信息
- 发送订单确认邮件
每个步骤都需要按照顺序执行，并且依赖于前一个步骤的结果。LangChain 可以轻松地将这些步骤串联起来，构建一个高效的订单处理系统。
然而，LangChain 的线性结构也存在局限性。当应用需要处理复杂的交互、循环反馈或状态管理时，LangChain 可能会变得难以维护和扩展。例如，在一个需要用户多次澄清意图的智能客服机器人中，如果用户对答案不满意，需要提供更多信息，这时就需要机器人回到之前的步骤，重新处理信息。这种循环反馈在 LangChain 中实现起来比较困难。
LangGraph：复杂交互和状态管理的专家
核心关键词：复杂交互，状态管理，图结构，循环反馈
与 LangChain 不同，LangGraph 专注于构建具有复杂交互和状态管理的 LLM 应用。它将应用程序建模为一个图结构，其中节点代表不同的状态或操作，边代表状态之间的转换。这种灵活的结构允许应用在不同的状态之间自由切换，处理循环反馈，并维护长期记忆。
LangGraph 的核心概念是“图”和“状态”。一个图定义了应用程序的整体结构，而状态则表示应用程序在特定时刻的状态。节点可以执行各种操作，例如调用 LLM、访问数据库或执行自定义代码。边定义了状态之间的转换规则，可以基于条件进行跳转。
想象一下，你需要构建一个旅游规划助手。用户可以提出不同的需求，例如“我想去一个海岛度假”，或者“我想在欧洲进行一次文化之旅”。助手需要与用户进行多次交互，不断 уточнять 用户的偏好，才能给出最终的行程建议。使用 LangGraph，可以将这个应用建模为一个包含以下状态的图：
- 用户输入 (User Input): 接收用户的输入。
- 意图识别 (Intent Recognition): 使用 LLM 识别用户的意图，例如“海岛度假”或“文化之旅”。
- 偏好 уточнить (Preference Elicitation): 根据用户的意图，向用户询问更多关于偏好的信息，例如预算、时间、同行人数等。
- 行程规划 (Itinerary Planning): 根据用户的意图和偏好，生成行程建议。
- 行程修改 (Itinerary Modification): 允许用户修改行程建议，例如调整酒店、景点或交通方式。
- 确认 (Confirmation): 确认用户是否满意行程建议。
状态之间的转换规则可以基于用户的输入和 LLM 的输出进行定义。例如，如果用户说“我想去海岛度假”，则状态从“用户输入”转移到“意图识别”，然后转移到“偏好 уточнить”。如果用户说“我需要调整酒店”，则状态从“行程规划”转移到“行程修改”，然后再次回到“行程规划”。
LangGraph 的图结构非常适合处理这种复杂的交互式场景。它可以轻松地处理循环反馈，维护用户状态，并根据不同的条件进行跳转。与 LangChain 相比，LangGraph 在处理复杂逻辑方面具有更大的灵活性。
例如，在一个客户服务流程中，如果客户对解决方案不满意，可以返回到之前的步骤，由不同的客服代表处理。LangGraph 可以通过图结构轻松实现这种流程跳转，并记录整个客户服务过程的状态。
如何选择：你的应用程序行为是关键
核心关键词：应用程序行为，线性 vs 复杂，评估标准
选择 LangChain 还是 LangGraph 的关键在于理解你的应用程序行为。如果你的应用程序只需要按照固定的流程执行任务，那么 LangChain 是一个不错的选择。但如果你的应用程序需要处理复杂的交互、循环反馈或状态管理，那么 LangGraph 可能是更好的选择。
以下是一些可以帮助你做出选择的评估标准：
- 复杂度： 应用程序的逻辑是否复杂？是否需要处理多个状态和状态之间的转换？
- 交互性： 应用程序是否需要与用户进行多次交互？用户是否可以随时更改他们的偏好？
- 状态管理： 应用程序是否需要维护长期记忆？是否需要记住用户的偏好和历史记录？
- 可维护性： 应用程序是否容易维护和扩展？是否容易添加新的功能和修改现有的逻辑？
如果你的应用程序复杂度较低，交互性较弱，不需要进行复杂的状态管理，那么 LangChain 可能更适合。 如果你的应用程序复杂度较高，交互性较强，需要进行复杂的状态管理，那么 LangGraph 可能更适合。
实际上，LangChain 和 LangGraph 并不是互斥的。在某些情况下，可以将它们结合使用，以充分利用它们的优势。例如，可以使用 LangChain 构建一个简单的文档处理管道，然后使用 LangGraph 将管道集成到一个更复杂的交互式应用程序中。
案例分析：LangChain 与 LangGraph 在不同场景下的应用
核心关键词：案例分析，文档问答，智能客服，代码生成
为了更好地理解 LangChain 和 LangGraph 的区别，我们来看几个具体的案例：
- 文档问答系统 (LangChain): 如前所述，文档问答系统是一个典型的线性工作流应用。可以使用 LangChain 构建一个简单的文档问答系统，从加载文档到生成答案，每个步骤都按照固定的顺序执行。
- 智能客服机器人 (LangGraph): 智能客服机器人通常需要处理复杂的交互和状态管理。用户可能会提出各种各样的问题，机器人需要理解用户的意图，收集相关信息，并提供合适的解决方案。使用 LangGraph 可以将机器人建模为一个图结构，其中节点代表不同的对话状态，边代表状态之间的转换规则。
- 代码生成助手 (LangGraph): 假设我们需要构建一个代码生成助手，它可以根据用户的描述生成代码。用户可以逐步 уточнить 代码的需求，例如添加新的功能或修改现有的逻辑。使用 LangGraph 可以将代码生成助手建模为一个包含以下状态的图：
- 用户描述 (User Description): 接收用户的代码描述。
- 代码生成 (Code Generation): 使用 LLM 根据用户的描述生成代码。
- 代码评估 (Code Evaluation): 使用 LLM 评估生成的代码是否符合用户的需求。
- 代码修改 (Code Modification): 允许用户修改生成的代码。
状态之间的转换规则可以基于用户的输入和 LLM 的输出进行定义。例如，如果用户说“添加一个新功能”，则状态从“用户描述”转移到“代码生成”，然后转移到“代码评估”。如果用户说“代码不正确”，则状态从“代码评估”转移到“代码修改”，然后再次回到“代码生成”。
在代码生成场景下，LangGraph 的优势在于它可以处理用户的逐步 уточнить 请求，并根据用户的反馈不断改进生成的代码。与 LangChain 相比，LangGraph 在处理这种迭代式开发场景中具有更大的灵活性。
总结：根据需求选择最合适的框架
核心关键词：总结，需求导向，灵活组合，持续学习
选择 LangChain 还是 LangGraph 取决于你的具体需求。LangChain 擅长构建线性的、流程化的应用，而 LangGraph 则更适合处理复杂的、交互式的应用。在某些情况下，可以将它们灵活组合，以充分利用它们的优势。
无论是选择 LangChain 还是 LangGraph，都需要不断学习和实践。LLM 技术正在快速发展，新的框架和工具层出不穷。只有持续学习，才能掌握最新的技术，并构建出更加强大的 LLM 应用。
希望本文能够帮助你更好地理解 LangChain 和 LangGraph 的区别，并为你的 LLM 项目选择最合适的框架。记住，没有“银弹”，只有根据需求选择最合适的工具。