Langchain报告

起源

LangChain，这个在大型语言模型（LLM）应用开发领域迅速崭露头角的框架，于2022年10月，由一位名叫 Harrison Chase 的开发者，在他当时供职的机器学习初创公司 Robust Intelligence 工作期间，作为一个开源项目正式发起。Chase 毕业于哈佛大学，主修统计学和计算机科学。在创立 LangChain 之前，他曾在 Robust Intelligence 负责领导机器学习团队，专注于机器学习模型的测试与验证工作；更早些时候，他还曾在金融科技领域的初创公司 Kensho 领导过实体链接（entity linking）团队。LangChain 的创立，其初衷就是为了简化和加速基于大型语言模型（LLM）的应用的开发过程，它以开源的 Python 和 TypeScript 包的形式，为开发者们提供了一套便捷的工具集。

该项目一经推出，便迅速获得了业界的广泛关注和开发者的积极响应，其受欢迎程度也与日俱增。在代码托管平台 GitHub 上，它很快就吸引了数百名来自世界各地的贡献者参与其中。在像 Twitter 这样的社交媒体平台上，围绕 LangChain 的讨论也异常热烈。其官方的 Discord 服务器也始终保持着高度的活跃度，吸引了大量开发者在线交流心得、解决问题。与此同时，LangChain 团队还在像旧金山和伦敦这样的全球科技中心城市，举办了多次线下技术交流活动，进一步推动了社区的建设和发展。

核心使命与愿景

LangChain 最初的宣传标语是“连接 LLM 与外部的计算和数据源”。这个提法虽然早于后来在人工智能领域广为流行的“代理 (agent)”这一术语，但它却非常精准地描述了 LangChain 的核心功能和价值所在。自项目启动以来，LangChain 的核心使命始终如一，那就是：尽可能地简化那些需要构建具备上下文感知能力和代理（agentic）能力的应用的开发过程。创始人 Harrison Chase 坚信，代理（agents）将是人工智能领域的下一波浪潮。他预见到，人工智能系统将从目前常见的、主要起辅助作用的“副驾驶 (copilot)”形态，逐渐转变为更具自主决策和行动能力的系统。这种转变将释放出更大的杠杆效应和自动化潜力，从而使得人类能够将更多的精力专注于那些更高层次的任务和更具战略性的思考。

LangChain 致力于成为一个通用的接口层，使其能够适用于几乎所有类型的大型语言模型（LLM）。它为开发者们构建基于 LLM 的应用程序，提供了一个集中的、统一的开发环境，并大力支持将这些 LLM 应用与各种外部的数据源（例如文档库、数据库等）以及现有的软件工作流进行无缝的集成。其最终的目标，是让开发者们能够更轻松、更高效地构建出那些能够进行复杂推理的、并且能够充分理解和利用上下文信息的智能应用程序。

在大语言模型应用开发中的重要性

随着像 ChatGPT 这样的生成式人工智能技术的迅速普及和广泛应用，LangChain 在推动这项新兴技术变得更易于被广大开发者和初创企业所采用方面，发挥了至关重要的作用。大型语言模型（LLM）虽然本身功能非常强大，但它们的知识通常受限于其训练数据的时间和范围，在处理一些特定公司的内部信息，或者需要理解非常细微的行业背景知识时，往往会显得力不从心。LangChain 通过提供一系列模块化的构建块和可重用的组件，极大地简化了将 LLM 连接到各种外部数据源（例如公司内部的文档、结构化的数据库等），并使其能够与周围的环境进行有效交互的复杂过程。

LangChain 的重要性主要体现在以下几个方面：

• 简化复杂性：它将与语言模型进行交互时那些常见的步骤和核心概念，抽象为一系列模块化的组件（例如函数和对象类）。这些组件可以像积木一样被灵活地“链接”起来，用于创建各种复杂的应用程序。这样做的好处是，能够显著减少开发者在执行复杂自然语言处理 (NLP) 任务时所需的代码量，并降低对底层技术细节的理解深度要求。
• 促进实验与原型设计：其模块化的设计方法，允许开发者和数据科学家们能够非常方便地、动态地比较不同提示词（prompts）的效果，甚至可以在不同的基础模型之间进行切换和评估，而通常只需要对代码进行最少的修改。这使得无论是经验丰富的专家，还是刚刚入门的新手，都能够快速地进行各种实验和原型设计。
• 赋能数据感知和代理能力：LangChain 的核心价值主张之一，就是帮助开发者构建出那些能够超越简单的 API 调用、真正具备数据感知能力和代理（agentic）行为的应用程序。它通过提供一系列强大的工具，来帮助开发者处理与聊天模型的交互、集成检索增强生成 (RAG) 的技术，以及提供安全的 API 交互机制等，从而有效地简化了复杂应用程序从开发、到生产化、再到最终部署的整个生命周期管理过程。

尽管 LangChain 所采用的这种高度抽象的方法，可能会在一定程度上限制那些专业程序员对应用程序进行非常精细的、底层定制的程度，但它无疑极大地降低了构建基于 LLM 的应用程序的门槛，有力地推动了生成式 AI 技术的普及和相关领域的创新。

LangChain 的核心架构与设计哲学

模块化与可组合性：LangChain 的基石

LangChain 的核心设计哲学，在于通过模块化和可组合性这两种强大的特性，来简化大型语言模型 (LLM) 的集成和管理过程。它为一系列关键的组件，例如 LLM 本身、各种文档加载器、嵌入模型、向量存储方案、以及检索器等等，都提供了一套标准的接口和多种不同的实现方式。这种高度模块化的设计，使得任何第三方技术提供商都可以通过简单地实现这些预定义的接口，来轻松地将其自家的技术融入到 LangChain 庞大且不断发展的生态系统之中。

LangChain 的整体架构，主要是围绕着组件 (components) 和链 (chains) 这两个核心概念来构建的。组件是那些可被重用的、独立的模块，它们各自负责执行一些特定的任务，例如处理输入的数据、生成特定格式的文本、访问外部的信息源，或者管理复杂的工作流程等等。这些被精心设计的、独立的抽象组件之间，通常是互不依赖的，并且它们也不与任何特定的模型提供商进行绑定，这就确保了整个框架的灵活性和未来的可扩展性。开发者们可以将这些像“乐高积木”一样的组件，根据自己的需求灵活地组合起来，从而构建出更为复杂的链和功能强大的应用程序。

这种独特的设计理念，为开发者们带来了诸多显著的益处：

• 灵活性与适应性：开发者可以根据他们具体的应用需求，非常方便地即插即用不同的模型、不同类型的内存机制、各种预置的链，以及形形色色的代理。
• 简化集成：LLM 可以被轻松地与其他各种外部的工具和服务（例如数据库、搜索引擎、以及各种应用程序接口 API 等）进行集成。
• 提高效率：通过使用那些预先构建好的组件和经过验证的工作流，可以显著地加速开发过程，从而缩短产品从概念到上市所需的时间。
• 可扩展性：基于 LangChain 构建的 LLM 程序，可以相对容易地进行扩展，以处理日益增长的工作负载和数据量。

LangChain 表达式语言 (LCEL)：声明式构建应用

LangChain 表达式语言 (LangChain Expression Language, LCEL) 是一种强大的声明式语言，它专门用于将 LangChain 核心中那些可运行的组件 (Runnables) 组合成线性的序列，或者更复杂的有向无环图 (DAG)。LCEL 的设计覆盖了在构建 LLM 应用时所遇到的大多数常见模式，并为开发者们提供了一种比传统方式更为简洁、也更具 Pythonic 风格的方法，来构建他们自定义的链。

LCEL 的主要特性和优势包括：

• 一流的流式支持 (Streaming Support)：使用 LCEL 构建的链，能够实现最佳的首个令牌响应时间 (time-to-first-token)。例如，你可以将 LLM 输出的令牌，直接以流的方式传递给一个同样支持流式处理的输出解析器，从而能够以与 LLM 提供商输出原始令牌几乎相同的速率，来获得那些已经被解析过的、增量式的输出块。
• 异步支持 (Async Support)：任何使用 LCEL 构建的链，都可以同时通过同步 API（例如，当你在 Jupyter Notebook 中进行原型设计时可能会用到）和异步 API（例如，当你在一个 LangServe 服务器中部署应用时可能会用到）来进行调用。这使得相同的代码可以无缝地用于原型设计和生产环境，并且通常具有出色的性能表现，能够在同一个服务器中高效地处理大量的并发请求。
• 优化的并行执行 (Optimized Parallel Execution)：当一个 LCEL 链中存在一些可以并行执行的步骤时（例如，需要同时从多个不同的检索器中获取相关文档），LangChain 会自动地在同步和异步两种接口中，都对这些步骤进行并行执行，以尽可能地降低整体的延迟。
• 重试和回退 (Retries and Fallbacks)：你可以为 LCEL 链的任何一个部分，轻松地配置重试机制和回退方案。这对于提高链在规模化应用中的可靠性来说，是一种非常有效的方法。
• 访问中间结果 (Access to Intermediate Results)：对于那些更为复杂的链来说，能够在最终输出产生之前，就访问到中间各个步骤所产生的结果，通常是非常有用的。这可以用于向最终用户实时地展示当前正在发生的事情（例如，告知用户系统正在执行哪个步骤），或者仅仅是为了方便开发者调试整个链的执行过程。LCEL 支持以流的方式传输这些中间结果，并且每一个 LangServe 服务器也都支持这一功能。
• 输入和输出模式 (Input and Output Schemas)：每一个 LCEL 链都会自动地拥有一个从其链结构本身推断出来的 Pydantic 和 JSONSchema 模式。这些模式可以用于对输入和输出的数据进行验证，并且也是 LangServe 的一个核心组成部分。
• 声明式与命令式混合：开发者既可以完全以声明式的方式来使用 LCEL，也可以根据需要，将其与一些命令式的代码（例如自定义的 Python 函数）进行灵活地混合使用。

LCEL 通过提供一套标准化的调用接口（例如 invoke, batch, stream 等方法），以及内置的对重试、回退、模式定义和运行时可配置性等方面的强大支持，极大地简化了构建和部署复杂 LLM 应用的过程。

LangChain 的抽象层次与核心接口

LangChain 的核心，可以说就是 Runnable 接口。这是许多 LangChain 组件以及整个 LCEL 的基础性抽象。这个接口为各种不同类型的组件（例如提示、聊天模型、LLM、输出解析器、检索器、工具等等）定义了一套统一的交互方式。这些标准的方法包括 stream（用于以流的方式返回响应的各个部分）、invoke（用于在单个输入上调用整个链）、以及 batch（用于在一系列不同的输入上批量调用链）等等。

这种统一接口的设计，带来了高度的模块化和卓越的可组合性。例如，一个聊天模型的输出（通常是一个 ChatMessage 对象）可以直接通过管道操作符 (|) 传递给一个输出解析器，而这个输出解析器则会负责将模型的原始输出，转换为一种特定的、更易于后续处理的格式（例如一个普通的字符串，或者一个结构化的数据对象）。

LangChain 还提供了一些方法，允许开发者在运行时对链内部的机制进行配置。例如，通过 configurable_fields，开发者可以在运行时动态地配置可运行对象的某些特定字段（比如模型的采样温度参数 temperature）；而通过 configurable_alternatives，则允许在运行时将链中的某个特定步骤替换为预先定义好的备选方案。这些特性都进一步增强了链的灵活性和其对不同场景的动态适应能力。

通过这些经过精心设计的抽象和接口，LangChain 旨在尽可能地实现模块化和简化，从而使得开发者能够将更多的精力专注于应用程序的核心业务逻辑，而不必过多地去关注底层实现的各种复杂性。这种优秀的设计哲学，是 LangChain 能够快速地适应飞速发展的 LLM 生态系统，并获得如此广泛应用的关键因素之一。

第三章：LangChain 关键组件深度解析

LangChain 的强大功能，源于其内部一系列经过精心设计的核心组件。这些组件协同工作，使得开发者能够构建出复杂且功能丰富的、基于大型语言模型 (LLM) 的应用程序。

大语言模型 (LLMs) 与聊天模型 (Chat Models)

在 LangChain 的体系中，大型语言模型 (LLMs) 和聊天模型 (Chat Models) 是整个应用程序的核心驱动力。它们负责理解用户的输入、生成相应的响应，并进行复杂的推理过程。LangChain 为各种不同类型的 LLM 提供了一个标准化的接口，这使得开发者可以非常轻松地在不同的模型之间进行切换和使用，而这些模型可能来自不同的提供商（例如 OpenAI, Anthropic, Hugging Face, Google VertexAI, AWS 等等）。

• LLM 接口：通常情况下，LLM 接口主要处理文本类型的输入，并返回文本类型的输出。LangChain 中的 LLM 类，为所有不同来源的模型都提供了一个统一的标准接口。
• 聊天模型接口：与 LLM 接口不同，聊天模型接口通常会处理一个由多条聊天消息组成的列表作为其输入，并返回一条聊天消息作为其输出。这些聊天消息都具有明确指定的角色（例如，System 系统消息, Human 用户消息, AI 助手消息, Tool 工具调用消息等）。LangChain 提供了许多具体的聊天模型实现，例如 ChatOpenAI, ChatAnthropic 等。
• 标准化参数：LangChain 为聊天模型定义了一些标准化的构造参数，例如 model (用于指定模型的具体名称), temperature (用于控制采样温度，影响输出的随机性), timeout (用于设置请求的超时时间), max_tokens (用于限制生成的最大令牌数量), stop (用于指定默认的停止序列), api_key (用于提供给模型提供商的 API 密钥), 以及 base_url (用于指定请求发送的端点地址) 等。
• 输入类型：这些模型可以接受多种不同类型的输入，包括单个的字符串，或者一个由多条聊天消息组成的列表。对于需要处理多模态输入的场景（例如，同时输入文本和图片），通常会使用一个由字典组成的列表，其中每个字典都包含了关于输入类型和其具体内容（例如图片的位置或 Base64 编码）的信息。
• 工具调用 (Tool Calling)：一些先进的聊天模型支持所谓的“工具调用”功能。这意味着模型可以在其输出的消息中，返回一个对某个预定义工具的调用请求。这个工具调用请求通常是一个包含了工具名称、调用该工具所需的参数，以及一个唯一的调用 ID 的字典。

这种标准化的接口和参数设计，使得在 LangChain 应用程序中替换或试验不同的 LLM 变得非常简单和方便。开发者通常无需大幅修改现有的代码，就能够轻松地利用不同模型的独特特性和优势。

提示 (Prompts) 与提示模板 (Prompt Templates)

提示（Prompts）是引导大型语言模型 (LLM) 生成我们期望的响应的关键指令。LangChain 提供了强大的提示管理功能，其中包括了提示模板（Prompt Templates）这一重要工具，以简化和规范化提示的创建与使用过程。

• PromptTemplate：PromptTemplate 类用于将提示的构建过程进行形式化和结构化，从而避免了开发者需要手动地去硬编码那些包含上下文信息和用户查询的复杂字符串。它允许你预先定义一些输入变量，并在运行时根据这些变量的实际值来动态地生成最终的提示内容。例如，一个像 PromptTemplate.from_template("告诉我一个关于{topic}的笑话") 这样的模板，就可以根据传入的 topic 变量的值，来生成一个具体的、关于特定主题的笑话请求提示。
• ChatPromptTemplate：这个类是专门为聊天模型而设计的。它允许你创建一个包含一系列具有不同角色的消息（例如系统消息、用户消息、AI 助手消息等）的提示模板。例如：

  from langchain_core.prompts import ChatPromptTemplate
  
  prompt_template = ChatPromptTemplate.from_messages([
      ("system", "你是一个乐于助人的 AI 助手。"),
      ("user", "告诉我一个关于{topic}的笑话。")
  ])
  

• MessagesPlaceholder：在 ChatPromptTemplate 中，MessagesPlaceholder 可以被用作一个占位符。它用于在运行时动态地插入一段聊天历史记录，或者其他一些预先准备好的消息序列。
• 少样本提示 (Few-shot Prompting)：提示模板中还可以包含一组具体的示例，用以指导模型的响应方向和风格，这种技术被称为少样本提示。
• 高级提示设计：在 LangChain 中，提示并不仅仅是简单的命令传输。通过将其与上下文记忆机制和动态生成技术相结合，开发者可以设计出能够适应各种复杂对话场景的、高度智能的提示系统。这样做不仅能够显著提高模型响应的准确性和相关性，还能够极大地增强最终的用户体验。

可以说，有效的提示工程（Prompt Engineering）对于一个 LLM 应用程序的整体性能来说至关重要，而 LangChain 通过其提供的这些强大的提示管理工具，极大地简化了这一复杂的过程。

链 (Chains)：核心编排机制

链（Chains）是 LangChain 名称的由来，也是其整个框架中最核心的编排机制。它们负责将大型语言模型 (LLM) 与其他各种组件（例如提示模板、其他的链、外部工具等等）巧妙地结合起来，通过执行一系列预先定义好的函数或操作，来创建出功能强大且逻辑清晰的应用程序。

LLMChain：基础的链实现

LLMChain 是 LangChain 中最为基础、也是最常被使用到的一种链类型。

• 工作机制：它通常会接收用户的输入，然后使用一个 PromptTemplate 将这个输入格式化为一个特定的、符合模型期望的提示。接着，它会将这个格式化后的提示传递给一个 LLM (或者一个聊天模型) 进行处理。最后，它还可能会通过一个 OutputParser (输出解析器) 来对 LLM 返回的原始输出进行格式化，以便得到更易于后续处理的结果。
• 组件构成：一个典型的 LLMChain 通常会包含以下几个核心组件：一个 PromptTemplate (用于构建提示)、一个 LLM (或 ChatModel，用于实际的语言处理)，以及一个可选的 OutputParser (用于处理模型的输出)。
• 示例：一个简单的 LLMChain 可以被设计成接收一个特定的主题作为输入，然后围绕这个主题生成一个相关的笑话。

顺序链 (Sequential Chains)：多步骤工作流

顺序链（Sequential Chains）通过将多个独立的链的输出，作为下一个链的输入，来将它们巧妙地组合在一起，从而实现更为复杂的多步骤工作流。

• SimpleSequentialChain：这是最简单的一种顺序链形式。在这种链中，每一个子链都只有一个输入和一个输出，并且前一个子链的输出会直接作为后一个子链的输入。
• SequentialChain：这是一种更为通用的顺序链。它允许其包含的子链拥有多个输入和多个输出。开发者可以明确地指定哪些先前链的输出，应该被用作后续链的哪些输入。
• 应用场景：当需要将一个复杂的任务分解为一系列连续的、相互依赖的子任务，并且每一个子任务的输出都是下一个子任务的输入时，顺序链就显得非常有用。

其他类型的链

除了上述两种比较基础的链之外，LangChain 还支持许多其他类型的、功能更为复杂的链，例如：

• RouterChain (路由链)：它负责根据当前的输入或上下文，来动态地选择下一个应该被调用的链。它通常会包含一组目标链 (Destination Chains)，以及一个在没有特定路由匹配时会被执行的默认链 (Default chain)。
• CombineDocumentChain (文档合并链)、SummarizationChain (摘要链)、GenerationChain (生成链) 等等，这些都是针对特定的文档处理和内容生成任务而设计的专用链。

链的这种模块化设计，使得开发者能够以一种非常灵活和可扩展的方式，来构建出具有复杂应用逻辑的应用程序。它允许我们将不同的功能单元像积木一样连接起来，从而形成一个连贯的、端到端的处理流程。而 LangChain 表达式语言 (LCEL) 的引入，则进一步增强了链的构建能力和执行效率，为其带来了像流式处理、异步执行以及并行优化等许多高级的特性。

索引 (Indexes) 与检索器 (Retrievers)：赋能 RAG

索引 (Indexes) 和检索器 (Retrievers) 是 LangChain 中实现检索增强生成 (Retrieval Augmented Generation, RAG) 这一重要架构模式的关键组件。它们使得大型语言模型 (LLM) 能够有效地访问和利用存储在外部知识库中的海量信息。

• 索引 (Indexes)：在 LangChain 的语境下，索引可以被理解为一个结构化的数据库，它专门用于组织和存储外部信息，以便在处理用户的语言查询时，能够高效地检索到相关的数据。LangChain 将所有需要被 LLM 访问的外部文档，都统称为“索引”。
  • 文档加载器 (Document Loaders)：LangChain 提供了多种多样的文档加载器，它们可以从各种不同的来源导入数据，例如文件存储服务 (如 Dropbox, Google Drive)、网页内容 (如 YouTube 视频字幕, PubMed 论文)、协作工具 (如 Airtable, Notion) 以及各种数据库 (如 Pandas DataFrames, MongoDB) 等等。这些文档加载器通常会返回一个由 Document 对象组成的列表，其中每一个 Document 对象都包含了页面的实际内容 (通常是一个字符串) 和一些相关的元数据信息。
  • 文本分割器 (Text Splitters)：为了提高后续处理的速度并减少计算资源的需求，通常情况下，我们需要将那些比较大型的文本文档分割成一些更小的、在语义上相对完整的块 (chunks)。LangChain 中的 TextSplitters (例如 RecursiveCharacterTextSplitter) 就专门负责执行这项任务。
  • 向量存储 (Vector Stores)：那些被分割好的文本块，通常会被转换成向量嵌入 (numerical representations，即用数字向量来表示文本的语义)，并存储在专门的向量数据库之中。向量存储方案支持高效的相似性搜索，也就是说，它可以根据一个查询向量，快速地找到与之最相似的那些已存储的文本块向量。LangChain 目前已经集成了超过 50 种不同的向量存储方案，包括像 FAISS, Chroma, Pinecone, Qdrant, Elasticsearch 等广受欢迎的选择。
  • 嵌入模型 (Embedding Models)：嵌入模型专门负责将文本块转换为其对应的向量嵌入。LangChain 支持多种不同的嵌入模型提供商，例如 OpenAI, Hugging Face 等。
• 检索器 (Retrievers)：检索器会与之前构建好的索引协同工作。它会根据用户当前的查询输入，从索引中获取到那些与之最相关的文档或数据片段，从而确保 LLM 在生成最终响应时，能够拥有充分的、准确的上下文信息。
  • 标准接口：LangChain 的检索器接口设计得非常简单：它的输入通常是一个查询字符串，而其输出则是一个由 Document 对象组成的列表。其核心的方法是 _get_relevant_documents。
  • 向量存储作为检索器：大多数向量存储方案，都可以通过调用其 as_retriever() 方法，来直接被用作一个检索器。
  • 高级检索模式：
    • EnsembleRetriever (集成检索器)：它允许你组合多个不同类型的检索器的结果，例如，你可以同时使用一个传统的 BM25 检索器和一个基于向量存储的检索器，并且还可以对它们各自返回的结果进行加权处理，或者使用像 RRF (Reciprocal Rank Fusion) 这样更复杂的算法来进行重新排序，以期获得更优的综合检索效果。
    • MultiVectorRetriever (多向量检索器)：这种检索器允许用户为每一个原始文档创建多个不同的向量表示（例如，可以基于文档的摘要、或者基于一些针对该文档提出的假设性问题来生成这些向量）并进行索引，同时仍然保留与原始源文档的链接。
    • ParentDocumentRetriever (父文档检索器)：它会将由文本分割器生成的那些较小的文档块链接到它们所属的原始源文档上进行索引，同时也保留与源文档的链接。这样做的好处是，在检索时，它既能利用小文档块进行精确匹配，又能确保在需要时能够返回完整的上下文信息。
    • 与关系型或图数据库的集成：检索器也可以构建在像关系型数据库或图数据库这样的结构化数据存储之上。在这种情况下，通常需要借助一些查询分析技术（例如，将自然语言的查询转换为 SQL 查询语句）来从用户的自然语言输入中构造出结构化的查询，以便从数据库中提取信息。

通过索引和检索器这两个强大的组件，LangChain 应用程序能够有效地从各种外部数据源中提取出与当前任务最相关的信息，并将其提供给 LLM 作为生成响应的上下文。这正是 RAG 架构的核心思想。像 MLflow 这样的机器学习运维工具，现在也开始支持对 LangChain RAG 系统的日志记录、运行追踪和便捷部署等功能。

代理 (Agents)：赋予 LLM 决策与行动能力

LangChain 中的代理 (Agents) 是一种更为高级的抽象概念。它会使用一个大型语言模型 (LLM) 作为其核心的决策引擎，来动态地选择并执行一系列的操作，以最终完成用户所指定的某个特定任务。与在链 (Chains) 中那种预先硬编码好的、固定的动作序列不同，代理的行动路径是动态生成的，它是由 LLM 根据当前所处的具体情况和其可用的工具集，来自主地进行决定的。

代理的核心工作机制

一个代理通常会按照以下流程来工作：

1. 接收和预处理输入：代理首先会接收来自用户的查询或指令，并且可能会使用一个预先定义好的提示模板，来对这个原始输入进行初步的预处理和格式化。
2. 需求分析与推理：作为代理“大脑”的 LLM，会仔细地分析这个经过处理的输入，以及当前所处的上下文环境，来确定为了生成期望的最终输出，都需要满足哪些具体的需求和条件。
3. 决定行动与工具选择：基于上一步的需求分析结果，LLM 会决定下一步应该采取什么样的行动。这通常会涉及到从一系列可用的工具中，选择一个或多个最合适的工具来进行调用。
4. 执行行动：代理会执行上一步所选定的工具。这些工具会与外部的环境进行交互（例如，调用一个 API、查询一个数据库、或者在互联网上进行搜索等），并返回其执行的结果（通常被称为“观察” (observation)）。
5. 分析输出与迭代：代理（实际上是其核心的 LLM）会分析从工具执行后得到的输出结果。如果当前的任务尚未完成，或者还需要更多的信息才能做出最终决策，那么它就会重复执行从第 2 步到第 4 步的过程，并且在新的迭代中，它可能会选择调用不同的工具，或者采取一些不同的行动。这个“思考-行动-观察”的循环，可能会进行多次迭代。
6. 生成最终响应：一旦 LLM 判断已经获得了足够的信息，或者当前的任务已经被成功完成，代理就会生成最终的响应，并将其呈现给用户。

代理的关键组件

一个典型的 LangChain 代理，通常会包含以下几个关键的组成部分：

• 大型语言模型 (LLM)：它扮演着代理的“大脑”或推理引擎的角色，负责理解用户的输入、规划完成任务所需的步骤，以及决定在每一步应该使用何种工具。
• 工具 (Tools)：这些是代理可以调用的、用于与外部世界进行交互的资源或函数。它们可以用来执行各种特定的任务，例如进行网络搜索、执行数学计算、查询数据库、调用外部的 API 等等。每一个工具通常都会有其明确的名称、功能描述以及输入参数的模式，以便 LLM 能够正确地理解其功能和使用方法。LangChain 提供了许多预置的常用工具（例如 Google Search, Tavily Search, DuckDuckGo, Wikipedia 等），并且也支持开发者轻松地创建和集成他们自定义的工具。
• 提示模板 (Prompt Template)：一个经过精心设计的提示模板，对于代理的性能来说至关重要。它会为 LLM 提供清晰的指令、必要的上下文信息、当前可用的工具列表及其详细描述，以及关于如何进行思考和采取行动的格式要求。
• 代理执行器 (AgentExecutor)：这是实际运行代理的核心逻辑所在。它会接收一个预先配置好的代理（包含了 LLM 和提示模板）、一个工具集，以及来自用户的输入。然后，它会协调并驱动代理进行“思考-行动-观察”的循环，直到代理最终决定完成任务，或者达到了预设的最大迭代次数。AgentExecutor 还负责管理代理与工具之间的交互，并处理诸如解析错误、返回中间步骤的执行结果、限制迭代次数以及设置超时等重要的功能。
• 内存 (Memory)：这是一个可选的组件，它用于存储先前交互过程中的信息。这使得代理能够进行有状态的对话，并在后续的决策过程中，考虑到之前的上下文，从而做出更连贯、更相关的响应。

不同类型的代理

LangChain 提供了多种预先定义好的代理类型，以适应不同 LLM 的能力特点和各种不同的任务需求：

• OpenAI Functions Agent / OpenAI Tools Agent：这些是专门为了与那些支持函数调用 (function calling) 或工具调用 (tool calling) 功能的 OpenAI 模型（例如 GPT-3.5-turbo, GPT-4 等）配合使用而设计的。在这种模式下，模型本身就可以在其生成的响应中，明确地指示应该调用哪个特定的函数或工具，以及调用时需要传递哪些参数。
• XML Agent：这种代理类型比较适用于那些擅长处理 XML 格式的推理和输出的模型（例如 Anthropic 公司开发的 Claude 模型）。
• JSON Chat Agent：这种代理类型则适用于那些更擅长读取和生成 JSON 格式数据的模型。
• Structured Chat Agent：当你的应用场景中，需要使用那些具有多个输入参数的复杂工具时，这种代理类型会比较适用。
• ReAct Agent：这是一种更为通用的代理类型，它适用于那些不一定支持原生工具调用的 LLM。它通过一个被称为“思考 (Thought) - 行动 (Action) - 观察 (Observation)”的循环，来进行推理和决策。
• Self-Ask with Search Agent：这种代理会将一个复杂的问题，首先分解为一系列更小的、可以独立回答的子问题，然后使用搜索工具来逐个查找这些子问题的答案，最后再将这些答案组合起来，形成对原始复杂问题的最终解答。

LangGraph 在代理中的作用

虽然 AgentExecutor 提供了一种标准化的、相对简单的方式来运行代理，但对于那些更为复杂、需要进行更精细控制的代理系统来说，LangChain 引入了一个更为强大的工具——LangGraph。LangGraph 是一个用于构建可控的、具有状态的代理的低级别编排框架。它允许开发者将代理的行为建模为一个图 (graph) 的结构，其中，图中的节点 (nodes) 代表了各种计算单元（例如一次 LLM 的调用，或者一次工具的执行），而图中的边 (edges) 则代表了这些计算单元之间的转换逻辑和控制流程。

LangGraph 的主要优势在于：

• 可靠性与可控性：通过引入像审核检查和人工介入批准这样的机制，可以更好地引导和控制代理的行为。LangGraph 还能够持久化那些长时间运行的工作流的上下文信息，确保其在意外中断后也能够恢复。
• 低级与可扩展性：它提供了更为底层的原语，从而摆脱了那些可能会限制定制化能力的、相对僵硬的抽象层，允许开发者能够设计出可扩展的、甚至包含多个智能体的复杂系统。
• 一流的流式支持：它支持令牌级别的流式传输，以及对中间步骤执行结果的流式传输，这使得用户能够实时地了解到代理进行推理和采取行动的整个过程。
• 状态管理：LangGraph 提供了非常强大的状态管理机制，这对于构建那些需要进行多轮交互的、有状态的对话代理来说，至关重要。
• 复杂工作流：它能够帮助开发者构建出包含条件分支、循环执行以及并行处理等复杂逻辑的代理工作流。

许多知名的公司，例如 Klarna, Elastic, Uber, Replit 等，都已经在他们的生产环境中使用 LangGraph 来构建功能强大的代理应用程序。LangGraph 可以独立使用，也可以与 LangChain 生态系统中的其他产品（例如，用于进行评估和提供可观察性的 LangSmith，以及用于部署的 LangGraph Platform）进行无缝的集成。

总而言之，LangChain 中的代理，通过巧妙地结合 LLM 强大的推理能力和各种工具所提供的与外部世界进行交互的能力，实现了对那些超越简单问答范围的复杂任务的处理。而 LangGraph 的出现，则为构建更高级、更可控、也更可靠的代理系统，提供了坚实的基础和灵活的框架。

内存 (Memory)：维持对话历史与上下文

在构建像聊天机器人这样需要进行多轮交互的应用程序时，内存 (Memory) 组件扮演着至关重要的角色。它使得基于大型语言模型 (LLM) 的应用程序能够“记住”用户在先前交互过程中所说的内容，从而能够在后续的对话中保持上下文的连贯性，并据此做出更相关、更合理的响应。

内存管理的重要性

大型语言模型 (LLM) 本身是无状态的，这意味着它们的每一次调用都是相互独立的，不会自动保留前一次调用的任何信息。如果没有一个有效的内存机制，LLM 就无法回忆起之前的对话内容，这会导致对话缺乏连贯性，甚至可能出现答非所问的情况。内存组件正是为了解决这个问题而设计的，它负责存储和加载聊天历史，从而使得链 (Chains) 或代理 (Agents) 能够有效地利用这些历史信息来进行后续的交互。

LangChain 中的内存机制

LangChain 提供了多种不同的内存管理方式，以适应各种不同的应用场景和需求：

• 消息传递 (Message Passing)：最简单的一种内存形式，就是直接将聊天历史中的消息（通常是一个由多个消息对象组成的列表）作为上下文的一部分，传递给链或模型进行处理。每一个消息对象通常会包含消息的实际内容，以及该消息的角色（例如 "user" 表示用户说的，"assistant" 表示 AI 助手说的，"system" 表示系统设定的指令，"tool" 表示工具调用的结果等）。
• 内置消息历史类 (Message History Classes)：LangChain 提供了一些内置的消息历史类，它们专门用于存储和加载聊天消息。这些类通常可以与各种持久化的存储方案（例如数据库、文件系统等）进行集成，以便在不同的会话之间或应用重启后，仍然能够保留聊天历史。
• RunnableWithMessageHistory：这是一个非常方便的包装器 (wrapper)，它可以为任何一个 Runnable 对象（例如一个链）自动地添加聊天历史管理的功能。它通常需要一个工厂函数 (factory function) 作为参数，这个工厂函数会根据给定的会话 ID (session ID) 来返回一个相应的消息历史对象。同时，你还需要指定在提示模板中，用户的输入和历史消息应该分别使用哪个键名 (key name) 来进行标识。
• LangGraph 中的状态管理：对于使用 LangGraph 构建的、更为复杂的代理系统，它通过其内置的状态 (State) 和检查点 (Checkpointer) 机制，来有效地管理内存，特别是那些生命周期较短的、与单个对话线程相关的短期内存。状态对象可以包含当前对话的聊天历史、用户已上传的文件信息、从外部检索到的相关文档等等。这些状态信息可以通过检查点机制被持久化到数据库中，从而允许对话线程在任何时候都能够被安全地恢复。

处理长对话与上下文窗口限制

大型语言模型 (LLM) 和聊天模型通常都有一个有限的上下文窗口大小。如果对话的历史记录过长，直接将其全部塞入到模型的提示 (prompt) 之中，不仅可能会超出模型的最大输入限制，还可能会因为引入了过多的、可能不那么相关的信息，而分散模型的注意力，从而影响其生成响应的质量。为了解决这个问题，LangChain 提供了一些有效的策略来管理和修剪过长的聊天历史：

• 修剪消息 (Trimming Messages)：一种简单直接的方法是，只加载和存储最近的 N 条消息，或者根据一个预设的令牌数量上限，来对历史记录的长度进行限制。LangChain 提供了一个名为 trim_messages 的工具，它允许你指定希望保留的令牌数量，以及在处理边界情况（例如，如何处理被截断的消息）时应该采用的策略。
• 摘要内存 (Summarization Memory)：对于那些非常长的对话，另一种有效的策略是，动态地将较早的对话内容进行摘要处理，然后将这个精炼的摘要作为上下文信息提供给模型，而不是将完整的、冗长的历史记录都传递过去。在一些 LangGraph 的示例中，就展示了如何通过扩展 MessagesState 来包含对话摘要，并创建一个专门的节点来负责生成摘要内容，以及移除那些已经被摘要过的旧消息。
• 向量化内存 (Vector-based Memory)：这种方法会将对话的片段或者对话的摘要，首先进行向量化嵌入处理，然后将这些向量存储在向量数据库之中。当需要回忆历史信息时，可以根据当前对话的内容，从向量数据库中检索出那些与之最相关的历史片段，并将它们作为上下文提供给模型。

内存类型与设计考量

LangChain 的设计允许开发者采用非常灵活的内存策略。在 LangGraph 的上下文中，内存可以被进一步划分为不同的类型：

• 短期内存 (Short-term Memory)：这通常指的是与单个对话线程相关的内存，它可以通过 LangGraph 的状态 (State) 和检查点 (Checkpointer) 机制来进行有效的管理，主要用于在同一个对话线程内部保持上下文的连贯性。
• 长期内存 (Long-term Memory)：这种内存可以跨越多个不同的对话线程进行共享。它可以通过 LangGraph 提供的存储 (Stores) 机制来进行保存和调用，并且通常会组织在一些自定义的命名空间之下，以便于管理。长期内存还可以被进一步细分为：
  • 语义内存 (Semantic Memory)：它主要用于保留一些特定的事实、概念和知识。这可以表现为一个持续更新的“用户画像”或“知识图谱”，或者一个不断积累的相关文档集合。
  • 情景内存 (Episodic Memory)：它主要用于回忆过去发生过的特定事件或执行过的特定行动。这种类型的记忆，常常可以通过在提示中加入一些相关的历史示例（即少样本提示）来实现。
  • 程序性内存 (Procedural Memory)：它主要用于记住执行某些特定任务时所需要遵循的规则和流程。这种类型的记忆，通常可以通过修改代理的提示（例如，引入“反思”机制或使用元提示 (meta-prompts)）来实现。

在设计应用程序的内存机制时，开发者需要仔细考虑 LLM 上下文窗口的限制、不同内存策略可能带来的性能影响，以及特定应用场景对记忆能力的需求。例如，一个简单的问答机器人可能只需要基本的对话历史记录就足够了；而一个复杂的个人助理，则可能需要更为复杂的长期记忆能力和个性化的信息存储与检索机制。

其他关键组件

除了上面详细介绍的那些核心组件之外，LangChain 还包含了一系列同样非常重要的支持性组件。它们共同构成了 LangChain 这个强大而灵活的 LLM 应用开发框架的完整生态系统。

回调 (Callbacks)

回调机制允许开发者在 LangChain 的各个组件（例如链、模型、工具等）执行过程中的一些特定的时间点，插入他们自定义的辅助代码。这对于实现多种不同的功能都非常有用，例如：

• 流式输出 (Streaming Outputs)：从 LLM 中以流的方式逐步获取输出结果，从而能够更快地向用户展示响应，提升用户体验。
• 追踪 (Tracing)：详细记录应用程序执行过程中的每一个中间步骤，这对于后续进行调试和理解应用的内部运行逻辑非常有帮助。
• 日志记录 (Logging)：记录下应用运行过程中发生的各种事件和可能出现的错误信息，便于问题排查和系统监控。
• 监控 (Monitoring)：收集关于应用性能的各种指标数据，例如调用的频率、响应的延迟、消耗的成本等等。
• 与其他工具的集成：通过回调机制，可以方便地将 LangChain 应用与其他的监控系统、日志平台或分析工具进行集成。

LangChain 提供了一个灵活的回调系统，开发者可以根据需要实现自定义的回调处理器，来响应链在执行过程中的不同阶段（例如，开始执行时、执行结束时、发生错误时等等）。

文档加载器 (Document Loaders)

正如在 3.4 节（索引与检索器）中所提到的那样，文档加载器专门负责从各种不同的数据来源（例如文件系统、数据库、API 接口、网页内容等等）加载数据，并将其转换为 LangChain 内部统一使用的 Document 对象格式。LangChain 内置了大量的、可以直接使用的文档加载器，并且也支持开发者根据自己的特定需求，来创建自定义的加载器。

输出解析器 (Output Parsers)

输出解析器负责将大型语言模型 (LLM) 返回的原始输出（通常是一个字符串）转换为一种更结构化、或者更易于后续程序使用的格式。例如，它们可以将 LLM 生成的一个 JSON 格式的字符串，解析为一个 Python 中的字典对象；或者从一段非结构化的文本中，提取出一些特定的实体信息。LangChain 提供了多种不同类型的输出解析器，并且也允许开发者根据需要，来自定义解析的逻辑。虽然随着现代 LLM 本身对结构化输出（例如 OpenAI 模型的函数调用/工具调用功能）的原生支持能力不断增强，对于某些非常复杂的输出解析器的需求可能会有所减少，但它们在处理那些非结构化的、或者需要按照特定格式进行解析的输出时，仍然具有非常重要的价值。

工具 (Tools)

正如在 3.5 节（代理）中所详细介绍的那样，工具是代理用来与外部世界进行交互的各种函数或接口。LangChain 提供了一套标准化的方式来定义和使用这些工具，并且也集成了许多预先构建好的、可以直接使用的工具。工具的设计使其能够被代理（在其核心 LLM 的指导下）进行调用，其输入通常是由 LLM 生成的，而其执行后的输出结果，则会返回给 LLM，以便其进行下一步的分析和决策。

所有这些核心组件和支持性组件，共同构成了 LangChain 强大而灵活的模块化生态系统。它们使得开发者能够根据自己的具体需求，灵活地组合和扩展各种功能，从而构建出满足特定场景要求的大型语言模型应用程序。

第四章：LangChain 的发展里程碑与演进

LangChain 自2022年10月作为一个开源项目正式启动以来，经历了非常快速的发展和持续的演变。它不断地推出新的功能和进行架构上的调整，以努力适应日益增长的、对大型语言模型 (LLM) 应用开发的需求。

LangChain 的诞生与早期发展 (2022年 - 2023年初)

LangChain 是由 Harrison Chase 在2022年10月正式发起的。最初，它只是他在当时供职的机器学习初创公司 Robust Intelligence 工作时，利用业余时间进行的一个开源项目。然而，这个项目一经推出，便凭借其核心的理念——即连接 LLM 与外部的数据和计算资源——迅速地在开发者社区中流行了起来。其在代码托管平台 GitHub 上的贡献者数量也快速增长，在像 Twitter 这样的社交媒体上，围绕 LangChain 的讨论热度也持续不减。其官方的 Discord 服务器也一直非常活跃，吸引了大量的开发者在线交流。同时，LangChain 团队还在像旧金山和伦敦这样的全球科技中心城市，举办了多次线下技术交流会，进一步推动了社区的建设和发展。

在这一时期，LangChain 的主要工作重心，是致力于提供一套基础的构建模块，以帮助开发者能够快速地上手并构建出他们自己的 LLM 应用程序。其核心目标是简化 LLM 与各种外部数据源之间的连接过程，以及构建一些相对简单的应用链条。

融资与公司化运营 (2023年)

到了2023年4月，LangChain 项目正式进行了公司化运营，成立了 LangChain Inc. 这家公司。几乎在同一时间，该公司就宣布获得了由知名的风险投资机构 Benchmark 领投的、总额高达1000万美元的种子轮融资。令人瞩目的是，仅仅在一周之后，LangChain 又宣布完成了由另一家顶级的风险投资公司红杉资本 (Sequoia Capital) 领投的、超过2000万美元的新一轮融资，据称其当时的估值至少达到了2亿美元。根据 Tracxn 这家市场数据追踪公司提供的信息，LangChain 在这两轮融资中总共筹集了约3500万美元的资金，其中2023年4月4日获得了来自 Benchmark 的1000万美元投资，而在2024年2月15日进行的 A 轮融资中，则从红杉资本等投资者那里获得了2500万美元的资金。另一家市场数据公司 Dealroom 的数据也证实了红杉资本在2024年2月领投了 LangChain 的2500万美元 A 轮融资，当时的估值为2亿美元。

这笔巨额资金的成功注入，为 LangChain 项目的进一步发展提供了强大的支持。它使得 LangChain 能够有效地扩展其核心团队，加速产品的迭代速度，并能够更好地服务于其日益增长的庞大用户群体。

LangChain 核心产品与功能的演进

LangSmith：可观测性与评估平台

LangChain 团队敏锐地认识到，对于那些需要投入到生产环境中运行的 LLM 应用程序来说，对其进行有效的可观测性监控和持续的性能评估，是至关重要的迫切需求。因此，他们在2023年初就开始着手开发 LangSmith 这个平台。LangSmith 的设计目标，主要是为了解决在 LLM 应用开发和运维过程中所面临的两个关键问题：即可观测性 (observability)，它能够帮助开发者精确地定位到 LLM 应用程序在哪个环节出了问题；以及评估 (evaluation)，它能够有效地防止应用性能的回归，并确保持续地改进和提升应用程序的整体表现。

LangSmith 的主要功能包括：

• 调试追踪 (Debugging Traces)：它能够提供非常详细的执行追踪信息，让开发者可以一步一步地清晰地看到链 (Chains) 和代理 (Agents) 内部的运行情况和数据流动。
• 数据集收集 (Dataset Collection)：它允许用户方便地创建和管理用于进行模型或应用评估的数据集。
• 测试与评估 (Testing and Evaluation)：它支持自动化的评估流程、人工反馈的收集和整理，以及回归测试等功能。
• 提示管理 (Prompt Management)：它提供了一个名为 Prompt Hub 的功能，用于集中管理和版本化应用程序中所使用的各种提示 (prompts)。
• 监控 (Monitoring)：它能够帮助用户跟踪应用程序的运行成本、响应延迟以及输出质量等关键指标，并提供高级的过滤和异常检测功能。
• 数据标注队列 (Data Annotation Queues)：这项功能于2023年10月推出，它为进行数据标注工作提供了便利。
• UI 内运行评估器：在2025年3月的一次更新中，LangSmith 进一步简化了评估的设置过程，用户现在可以直接在其用户界面 (UI) 中定义和配置评估器，而无需编写任何额外的代码。
• OpenTelemetry 支持：同样在2025年3月，LangSmith 宣布了对完整的、端到端的 OpenTelemetry (OTel) 标准的支持，这进一步增强了其在可观测性方面的能力。
• 告警功能 (Alerts)：这项于2025年4月推出的新功能，允许用户针对诸如错误率、运行延迟以及用户反馈分数等关键指标，设置实时的通知和告警。

LangSmith 提供了不同的定价层级，以满足不同用户的需求。其中包括一个免费的开发者计划、一个针对团队用户的 Plus 计划，以及一个专为企业级需求设计的 Enterprise 计划。后者通常会提供像自托管 (self-hosting) 选项和更高级别的技术支持等服务。

LangServe：便捷部署工具

在2023年10月，LangChain 推出了 LangServe 这个实用的部署工具。它可以将那些使用 LangChain 表达式语言 (LCEL) 编写的代码，方便地作为生产就绪的 API 服务进行托管和部署。这大大简化了将 LangChain 应用程序部署到实际生产环境中的过程。

LangGraph：灵活的代理编排框架

到了2023年的初夏时节，LangChain 团队逐渐意识到，对于那些真正需要在生产环境中稳定运行的用例而言，之前提供的一些预先构建好的、相对高级的链 (Chains) 和代理 (Agents)，在灵活性和可靠性方面可能还存在一些不足。为了让开发者能够对他们应用程序的“认知架构”拥有更多、更精细的控制权，LangChain 随后推出了 LangGraph 这个更为强大的框架。LangGraph 是一个非常灵活的编排框架，它允许开发者以图 (graph) 的形式来构建和定义代理的行为。通过这种方式，开发者可以实现从需要精确定义的、固定的工序流程，到更为自主的、能够根据环境变化进行自适应调整的复杂代理等各种不同程度的自主性。

LangGraph 的关键特性包括：

• 可靠性与可控性：它支持引入像审核检查和人工介入批准这样的机制，从而能够更好地引导和控制代理的行为。
• 低级与可扩展性：它提供了更为底层的、描述性的原语，使得开发者能够更容易地进行定制，并能够构建出包含多个智能体的、可扩展的复杂系统。
• 一流的流式支持：它能够支持令牌级别的流式传输，以及对中间执行步骤结果的流式传输，这使得用户能够实时地了解到代理进行推理和采取行动的整个过程。
• 状态管理与持久化：它能够持久化那些长时间运行的工作流的上下文信息，确保其在意外中断后也能够安全地恢复。
• 与 LangChain 生态的紧密集成：它能够与 LangChain 生态系统中的其他核心组件，例如 LangSmith（用于评估和提供可观测性）以及 LangChain 的核心库，进行无缝的集成。

LangGraph 于2024年1月正式对外推出，并迅速地被像 Klarna, Elastic, Uber, Replit 这样的许多知名公司，应用到了他们的实际生产环境之中。

LangChain 表达式语言 (LCEL)

LangChain 表达式语言 (LCEL) 大约在2023年的第三季度被正式引入。它提供了一种声明式的方式，来帮助开发者定义和组合各种动作链。目前，LCEL 已经成为了在 LangChain 中构建链和应用程序的推荐方式，它因其对流式处理、异步操作以及并行执行等高级功能的内置支持而备受开发者的青睐。

包拆分与版本迭代 (langchain, langchain-core, langchain-community)

随着 LangChain 生态系统的爆炸式增长（据称，截至2024年初，它已经拥有了超过70个不同的模型提供商集成，以及总计超过700个不同的集成点），为了进一步提高整个框架的稳定性和模块化程度，LangChain 在2023年12月对其包的结构进行了一次重要的重构。

主要的包拆分情况如下：

• langchain-core：这个包包含了那些驱动 LangChain 生态系统其余部分运行的基础抽象和核心运行时。这些抽象被设计得尽可能地模块化和简洁，例如它定义了像语言模型、文档加载器、嵌入模型、向量存储、检索器等核心组件的统一接口。这个包的依赖项非常少，其主要目标是提供一个稳定可靠的基础。截至2025年5月，langchain-core 的版本为 0.1.x 系列。
• langchain-community：这个包主要用于存放那些由广大的社区成员维护的、各种第三方的集成。
• langchain (主包)：这个包则主要包含了那些构成应用程序“认知架构”的核心组件，例如各种类型的链 (Chains)、代理 (Agents) 以及检索策略 (Retrieval Strategies) 等。这些组件通常不特定于某一个具体的集成，而是具有一定的通用性，可以与各种不同的集成协同工作。
• 合作伙伴包 (Partner packages)：一些特定的集成（例如 @langchain/openai, @langchain/anthropic 等）被进一步拆分成了独立的、仅依赖于 @langchain/core 的轻量级包。

这次重构的主要目标，是为那些核心的抽象提供一个更为稳定和可靠的基础 (即 langchain-core 包)，同时允许那些来自社区贡献的、以及特定于某个提供商的集成，能够在它们各自独立的包中，以更快的速度进行迭代和更新。而 langchain 这个主包，则更专注于提供那些通用的应用逻辑和核心功能。

LangChain 一直在以非常快的速度进行着迭代和更新。例如，在2025年4月发布的一个 Python 版本更新中，就改进了其内容块 (content blocks) 的处理方式和重试逻辑，并增加了一些新的集成点，以及对代理的更智能化的支持。这种持续不断的演进，充分反映了 LangChain 从最初致力于帮助开发者快速入门和进行原型构建，到如今更加侧重于支持开发者创建高质量的、可靠的、并且能够真正投入到生产环境中运行的复杂应用程序的转变。

第五章：LangChain 生态系统与集成

LangChain 的一个核心优势，就在于其拥有一个庞大且在不断增长的生态系统。这包括了与众多主流的大型语言模型 (LLM) 提供商的紧密集成、对各种不同类型的数据存储方案的支持，以及大量由社区贡献的实用工具和第三方库。

与主流大语言模型 (LLM) 提供商的集成

LangChain 的设计目标之一，就是提供一个通用的、标准化的接口，以便能够与几乎所有类型的大型语言模型 (LLM) 进行顺畅的交互。这使得开发者可以在不同的模型之间轻松地进行切换和选择，而通常无需对他们的代码进行大幅度的修改。这样做的好处是，可以非常方便地进行各种实验，并对不同模型在特定任务上的效果进行比较。

据称，截至2025年初，LangChain 已经集成了超过70家不同的模型提供商。在其官方文档中，列出了一系列核心的集成包，这些包的命名通常会遵循 langchain-<provider> 这样的形式，例如：

• OpenAI (langchain-openai)
• Google VertexAI (langchain-google-vertexai) 以及 Google Generative AI (Gemini) (langchain-google-genai)
• Anthropic (langchain-anthropic)
• AWS (langchain-aws)
• Cohere (langchain-cohere)
• Hugging Face (langchain-huggingface)
• MistralAI (langchain-mistralai)
• Ollama (用于在本地运行各种开源模型)
• Azure AI (langchain-azure-ai)
• 以及众多其他的提供商，例如 Fireworks, IBM, Deepseek, NVIDIA AI Endpoints, Together AI, Sambanova 等等。

这些集成包通常会封装与特定 LLM 的 API 进行通信的底层逻辑，并将其适配到 LangChain 所定义的标准的 LLM 或 ChatModel 接口之上，从而为开发者提供一个统一的、与模型无关的调用方式。

与各类数据存储和工具的集成

除了与 LLM 本身进行集成之外，构建一个有用的、功能强大的 LLM 应用程序，通常还需要能够连接到各种外部的数据源和调用各种外部的工具。LangChain 在这方面也提供了非常广泛的集成支持。

向量数据库 (Vector Stores)

向量数据库在构建 RAG (Retrieval Augmented Generation，检索增强生成) 应用程序中扮演着核心的角色。它们专门用于存储和高效检索文档的向量嵌入（vector embeddings）。LangChain 目前已经集成了超过50种不同的向量数据库方案，其中包括了许多云托管的服务和可以在本地部署的解决方案。一些常见的集成包括：

• Chroma (langchain-chroma)
• Pinecone (langchain-pinecone)
• Postgres (通常通过其 pgvector 扩展来实现向量存储和检索功能, langchain-postgres)
• Milvus (langchain-milvus)
• Elasticsearch (langchain-elasticsearch)
• Qdrant (langchain-qdrant)
• Redis (langchain-redis)
• Weaviate (langchain-weaviate)
• FAISS (一个非常流行的、可以在本地使用的向量相似性搜索库)
• MongoDB (langchain-mongodb)
• Google Cloud Databases (例如 AlloyDB, Cloud SQL for PostgreSQL, Firestore, Memorystore for Redis, Spanner 等，它们也开始提供向量存储和检索的能力)

这些丰富的集成选项，为开发者在构建 RAG 应用程序时，进行文档的加载、分割、嵌入表示和高效检索等操作，提供了极大的便利和灵活性。

文档加载器 (Document Loaders)

LangChain 提供了大量的文档加载器，它们可以用于从各种不同的数据来源导入数据，例如：

• 文件存储服务：如 Dropbox, Google Drive, Microsoft OneDrive 等。
• 网页内容：例如可以加载 YouTube 视频的字幕、PubMed 等学术数据库中的论文内容，或者通过像 CheerioWebBaseLoader 这样的加载器来抓取特定 URL 的网页内容。
• 协作工具：如 Airtable, Trello, Figma, Notion 等。
• 数据库：例如可以从 Pandas DataFrames 或 MongoDB 中加载数据。
• 企业级系统：在2025年的一些更新中，LangChain 还增加了对像 Snowflake Cortex, Databricks Lakehouse, SAP, Salesforce, ServiceNow 等企业级系统的原生插件或连接器支持，使得从这些系统中提取数据变得更加容易。

其他工具和服务

LangChain 还集成了许多其他类型的、能够增强 LLM 应用能力的工具和服务，例如：

• API 包装器 (API Wrappers)：用于方便地调用各种外部 API，例如获取新闻资讯、查询电影信息、获取天气预报等等。
• Bash Shell：允许 LLM 应用执行本地的 shell 脚本。
• 网页抓取子系统和模板：提供了一些用于进行网页内容抓取和信息提取的工具。
• 搜索引擎：例如集成了 Tavily Search, DuckDuckGo Search 等搜索引擎的 API，使得 LLM 能够进行实时的网络搜索。
• 计算工具：例如像 LLMMathChain 这样的链，可以利用 LLM 来进行一些数学运算。

开源社区与贡献

LangChain 之所以能够取得如此巨大的成功，并在短时间内就发展成为一个功能如此丰富的框架，在很大程度上要归功于其背后那个异常活跃的开源社区。

• GitHub 活跃度：langchain-ai/langchain 这个主代码仓库在 GitHub 上拥有超过 10.7 万的星标、1.74 万的复刻次数，以及将近 3600 名来自全球各地的贡献者。而像 LangGraph 这样的新兴子项目，其代码仓库也已经获得了超过 1.24 万的星标和 2100 次的复刻。此外，一些由社区自发创建和维护的项目，例如关于提示工程的知识库，也获得了数千个星标的认可。
• 贡献指南与治理：LangChain 项目遵循的是 MIT 许可证。这是一种非常宽松的开源许可证，它允许用户自由地使用、修改和分发代码，只需要在分发时保留原始的许可和版权声明即可。该项目也制定了相应的贡献指南，积极鼓励社区成员参与到项目的建设之中，包括贡献代码、报告发现的问题、以及改进官方的文档等等。
• 社区支持渠道：LangChain 拥有多个活跃的社区支持渠道，包括其官方的 Discord 服务器、GitHub 仓库中的 Discussions 板块、以及 Reddit 网站上的 r/LangChain 子版块等等。这些平台为广大的开发者们提供了一个进行交流、提问、寻求帮助以及分享经验的良好场所。
• 第三方集成：正如前面提到的，langchain-community 这个包专门用于存放那些由社区成员维护的、各种第三方的集成。这进一步地扩大了 LangChain 的生态系统范围，使其能够支持更多小众或新兴的工具和服务。

这种开放的、由社区驱动的模式，以及其广泛的集成能力，使得 LangChain 能够快速地适应大型语言模型 (LLM) 领域中不断涌现的新技术和新需求，并为开发者们提供了构建各种多样化智能应用的、内容极其丰富的工具集。

第六章：LangChain 在 LLM 框架领域的定位

LangChain 作为 LLM 应用开发框架，并非孤军奋战。市场上存在其他具有相似或特定侧重点的框架，理解 LangChain 与它们之间的异同，有助于更清晰地定位其在行业中的角色和优势。

LangChain 与主要竞品框架的比较

LangChain 与 LlamaIndex

LlamaIndex (其前身为 GPT Index) 这个框架，主要专注于数据的索引、摄入和检索过程，它尤其擅长于帮助开发者构建 RAG (Retrieval Augmented Generation，检索增强生成) 类型的应用程序。它提供了一系列强大的工具，用于将大型语言模型 (LLM) 与大规模的文本数据集进行连接，并能够自动化文档的组织、查询以及摘要生成等过程。

• 核心差异：
  • LlamaIndex：它更侧重于数据索引和信息检索这两个核心环节，为 RAG 应用场景提供了经过优化的、端到端的流水线。其核心组件通常包括数据连接器 (Data Connectors)、索引和存储机制 (Indexing and Storage)、嵌入向量生成 (Embedding Generation)、查询引擎 (Query Engine)、数据检索 (Data Retrieval)、后处理 (Post-processing) 以及响应合成 (Response Synthesis) 等。其设计相对来说比较简洁，也更容易上手，尤其适合那些需要进行高效信息检索和复杂文档管理的场景。
  • LangChain：它的功能则更为广泛和通用，它支持开发者构建各种不同类型的 LLM 应用程序，包括聊天机器人、复杂的代理系统、多步骤的逻辑链条等等，而不仅仅是局限于 RAG 这一种应用模式。LangChain 的模块化设计，使其在构建那些需要复杂工作流编排和集成多种不同工具的应用时，更具灵活性和可扩展性。
• 适用场景：
  • 如果你的主要需求是构建一个高效的文档检索系统，或者一个基于现有知识库的问答系统，那么 LlamaIndex 凭借其在 RAG 领域的专注和优化，可能会是一个更直接、也更高效的选择。
  • 而如果你需要构建的是一个更为复杂的、涉及到多步骤推理、需要调用外部工具，或者需要具备代理（agentic）行为的应用程序，那么 LangChain 则提供了更为全面和强大的工具集。
• 集成与生态：两者都支持与多种不同的 LLM 和向量存储方案进行集成。相较而言，LangChain 在集成的数量和广度上可能会更胜一筹，而 LlamaIndex 则在其核心的 RAG 功能上，可能会做得更深入和更专注。

许多开发者在实践中发现，LangChain 和 LlamaIndex 并非是完全互斥的，它们有时甚至可以很好地结合起来使用。例如，你可以利用 LlamaIndex 来进行高效的数据索引和信息检索，然后将检索到的相关信息，再整合到 LangChain 的代理 (Agents) 或链 (Chains) 之中，进行后续的、更为复杂的处理和逻辑编排。

LangChain 与 Microsoft Semantic Kernel

Microsoft Semantic Kernel 是一个旨在将人工智能 (AI) 功能（例如 LLM 的调用）像普通的、常规的代码块一样，无缝地集成到现有应用程序之中的工具包。它目前支持 C#, Java 和 Python 这三种主流的编程语言。Semantic Kernel 特别强调为企业级的解决方案提供支持，它通过一种被称为“插件 (Plugins)”的机制来实现功能的扩展，并通过其内置的“规划器 (Planner)”来有效地处理那些需要多步骤决策和自动化执行的复杂业务流程。

• 核心差异：
  • Semantic Kernel：它更注重于与企业现有的代码库和技术栈进行平滑的集成，并且提供了跨多种编程语言的 SDK。其独特的“规划器 (Planner)”抽象，使其非常适合用于处理那些需要进行结构化的、多步骤决策的关键任务型企业级应用。它强调设计的模块化和未来的可移植性，允许开发者能够相对容易地更换底层的语言模型。
  • LangChain：它主要基于 Python 和 JavaScript 这两种语言进行开发，并拥有一个更为广泛的、与各种开源 LLM 进行集成的生态系统。其强大的“代理 (Agents)”和新引入的 LangGraph 框架，为构建复杂的自主系统提供了强大的能力，但在企业级的治理和多语言支持方面，可能不如 Semantic Kernel 那样深入和完备。
• 适用场景：
  • 对于那些已经大量投入到微软技术栈（例如 .NET, Azure 等）之中，或者对系统有严格的治理要求，并且需要与现有业务流程进行深度集成的企业来说，Semantic Kernel 凭借其自身的特性和微软的生态优势，可能会更具吸引力。它非常适合用于构建那些需要支持动态的、自适应工作流的模块化系统。
  • 而对于那些以 Python 为主要开发语言的 AI/ML 社区，以及那些需要进行快速原型设计、希望能够利用广泛的开源集成资源，并致力于构建高度自定义代理的应用程序来说，LangChain 通常会是首选的框架。它更适合于那些相对线性的、可以预先定义好工作流程的场景，这些场景能够充分受益于 LangChain 的简单性和最少的配置要求。
• 性能与可扩展性：据称，Semantic Kernel 更适合于那些需要同时运行多个复杂工作流的大规模、自适应的系统。而 LangChain 则在处理那些规模较小、流程相对顺序化的工作流时表现良好，但在处理那些长时间运行的代理时，开发者需要特别关注内存的监控和管理。

LangChain 与 Haystack (deepset.ai)

Haystack 是一个专注于帮助开发者构建能够利用语言模型来进行高级搜索的系统的框架。它特别擅长于从各种文档存储方案（例如 Elasticsearch, OpenSearch, 以及各种 SQL 数据库等）中进行高效的信息检索，并且支持像 BM25（一种经典的稀疏向量检索算法）和稠密段落检索 (Dense Passage Retrieval, DPR) 等先进的检索技术。

• 核心差异：
  • Haystack：它主要是为搜索应用场景而设计的，特别强调从大规模的文档集合中，高效、准确地检索出所需的信息。其模块化的架构设计，允许它能够与多种不同的技术进行集成，例如 OpenAI 的模型、Chroma 向量数据库、以及 Hugging Face Transformers 库等等。
  • LangChain：它的功能则更为通用，更侧重于将大型语言模型 (LLM) 像积木一样链接起来，以执行各种不同类型的任务，而搜索和检索仅仅是其众多功能之中的一个组成部分。
• 适用场景：
  • 如果你的项目的核心目标是构建一个强大的语义搜索系统，或者一个能够基于现有的大型文档库进行智能问答的系统，那么 Haystack 凭借其在该领域专门优化的工具和预设的流水线，可能会是一个更好的选择。
  • 而如果你的应用程序需要进行复杂的逻辑推理、执行多步骤的操作、与外部的 API 进行交互，或者需要构建一个对话式的 AI 代理，那么 LangChain 则提供了更为广泛和全面的功能集。
• 性能：由于其在文档存储和 RAG（检索增强生成）能力方面的专门优化，Haystack 在执行检索任务时，通常能够表现出更快的速度。而 LangChain 则可能在那些需要进行复杂推理和多步骤处理的场景中，展现出其独特的优势。

与 LlamaIndex 类似，Haystack 强大的检索能力，有时也可以与 LangChain 卓越的编排能力进行巧妙的结合，从而能够充分发挥它们各自的优势，构建出更为强大的应用程序。

下表对这些主流的 LLM 编排框架的关键特性进行了总结：

表 1：LLM 编排框架对比

LangChain 的优势与竞争差异化因素

LangChain 之所以能够在竞争激烈的 LLM 框架市场中脱颖而出，并保持其领先地位，主要凭借其全面的功能特性、强大而灵活的模块化设计、庞大且不断增长的集成生态系统、异常活跃的开发者社区，以及快速的创新和迭代能力。

• 生态系统的广度与适应速度：LangChain 的核心竞争力之一，就在于其能够以极快的速度集成新兴的大型语言模型 (LLM)、各种外部工具以及最新的技术范式。据称，它拥有超过700个不同的集成点，涵盖了从模型提供商到向量数据库，再到各类 API 工具的广泛范围。这种快速的适应能力，使其成为了开发者们探索和实验最新 LLM 技术的前沿阵地。虽然这种快速的迭代有时可能会导致其 API 接口出现一些不稳定性，或者官方文档的更新略有滞后，但它也确保了用户能够通过一个相对统一的接口，接触到最前沿的技术和工具。这对于那些需要进行研发活动，或者需要利用多种不同工具来构建复杂应用的场景来说，尤为重要。
• LCEL 提供的声明式构建能力：LangChain 表达式语言 (LCEL) 为构建和组合那些可运行的组件，提供了一种非常强大且具有声明式风格的方式。它不仅简化了链 (Chains) 的定义过程，还内置了对诸如流式处理、异步执行、并行化、自动重试以及回退机制等高级功能的良好支持，这些都显著地提升了开发效率和最终应用程序的性能表现。
• LangGraph 提供的精细化代理控制：对于那些需要构建复杂、可控且高度可靠的代理系统 (Agentic Systems) 的开发者来说，LangGraph 提供了比标准 AgentExecutor 更为底层、也更为灵活的编排能力。它允许开发者将代理的行为建模为一个图 (graph) 的结构，从而能够实现对状态管理、控制流程以及多个智能体之间交互的精细化控制。这对于构建生产级别的代理应用程序来说，至关重要。
• LangSmith 提供的商业级可观测性：LangChain Inc. 公司巧妙地将其开源的框架 (LangChain) 与其商业化的可观测性平台 (LangSmith) 相结合，形成了一种非常有效的商业模式。随着开发者们使用 LangChain 构建出日益复杂的应用程序，他们对调试、监控和评估工具的需求也随之水涨船高，而 LangSmith 恰好能够满足这一需求。在这种模式之下，开源的框架能够推动技术的广泛采用和社区的繁荣，而商业化的工具则能够为公司提供可持续的收入来源，进而又能够反哺开源项目和商业工具的持续发展和完善。
• 强大的社区支持：LangChain 拥有一个庞大且非常活跃的开源社区。这个社区不仅贡献了大量的集成代码和功能特性，还提供了极其丰富的教程、代码示例和问题解答。这极大地降低了新用户的学习门槛，并能够有效地加速问题的解决过程。

所有这些因素共同构成了 LangChain 的核心竞争力，使其能够在大型语言模型 (LLM) 应用开发这一热门领域保持其领先地位，并成为了许多开发者和企业的首选框架。

第七章：批判性评估：挑战、批评与未来展望

尽管 LangChain 在推动大型语言模型 (LLM) 应用开发方面取得了显著的成就，并且受到了广泛的关注和采用，但它在快速发展的过程中，也不可避免地遇到了一些挑战，并受到了一些来自开发者社区的批评。与此同时，随着 LLM 技术本身的飞速进化，LangChain 未来的发展方向也备受业界的关注和期待。

当前面临的挑战与社群反馈

LangChain 在其高速发展的过程中，确实遇到了一些问题，开发者社群中也相应地出现了一些批评的声音：

• 复杂性与抽象层过多：一部分开发者认为，LangChain 引入了过多的抽象层次，这使得理解和修改其底层的代码变得相对困难。对于那些需要构建高度定制化或非常复杂的系统的开发者而言，这些抽象层有时反而可能成为一种障碍，他们可能会觉得不如直接调用底层的 LLM SDK 来得更加直接和高效。
• API 不稳定性与频繁的破坏性更新：由于框架本身的快速迭代，以及对各种新功能和集成的大量引入，LangChain 的 API 接口在过去的一段时间里，曾一度表现得不够稳定。频繁的更新有时会引入一些破坏性的变更，这给那些已经在生产环境中使用 LangChain 的开发者们带来了一定的维护成本和困扰。
• 文档质量参差不齐：官方文档的更新速度，有时可能跟不上代码库的迭代速度，这导致部分文档内容出现过时，或者缺乏对某些关键细节的清晰说明。在这种情况下，开发者们可能不得不花费额外的时间去阅读源代码，才能真正理解某些功能的具体行为。
• 生产环境适用性疑虑：一些开发者认为，LangChain 可能更适合用于进行快速的原型验证 (Proof of Concept, PoC) 和功能演示。而在真实的生产环境中，其额外的抽象层可能会带来一些潜在的性能开销，或者在管理和维护上增加一定的复杂性。著名的开发者 Kieran Klaassen 甚至曾发表过一篇引起广泛讨论的文章，称“LangChain 是优秀 AI 项目的坟墓”，这在一定程度上反映了部分开发者在尝试将基于 LangChain 构建的项目投入到实际生产时，所遇到的挫败感。
• 令牌使用效率：也有一些批评指出，LangChain 在进行 API 调用时，可能存在令牌 (tokens) 使用效率不高的问题。这可能会导致用户在使用基于 LangChain 的应用时，需要支付更高的运营成本（因为许多 LLM 服务是按令牌数量收费的）。
• 与现有工具集成的难度：过高的抽象有时也可能会使得 LangChain 与开发者们现有的、一些常用的 Python 工具和脚本进行集成时，变得有些困难和不便。
• 依赖冲突与学习曲线：由于其庞大的生态系统和频繁的更新迭代，有时可能会出现 langchain、langchain-community 以及其他一些依赖库之间的版本冲突问题。对于初学者而言，这种快速的迭代和不断增加的包结构，也可能会使得学习曲线变得相对陡峭。

需要指出的是，许多这类批评，实际上是任何一个正处于高速发展阶段、并且试图引领技术前沿的框架，都可能会共同面临的“成长的烦恼”。大型语言模型 (LLM) 领域本身就处于一个变化极快的时期，新的技术、新的模型层出不穷。LangChain 努力地去快速整合这些最新的进展，以保持其工具包的全面性和前沿性，这自然会在一定程度上牺牲掉 API 接口的短期稳定性，或者官方文档的即时完善度。LangChain 团队近期所进行的一些重要的架构调整，例如对包结构进行拆分（将核心的抽象、社区的集成和应用层的逻辑进行分离），以及引入更为稳定、更具声明式风格的接口（例如 LangChain 表达式语言 LCEL），都可以看作是他们在积极努力地缓解这些问题。而 LangGraph 的推出，则提供了更为底层的原语和更强的控制力，这也是为了努力弥合原型开发与生产部署之间的鸿沟，并满足那些经验丰富的开发者对进行精细化控制的迫切需求。

LangChain 的未来：适应不断进化的 LLM 能力

大型语言模型 (LLM) 技术正以前所未有的速度向前发展，模型的自身能力也在不断地增强，例如它们能够处理的上下文窗口变得越来越大，并且也开始具备了更强的、原生的工具使用能力。所有这些变化，都对像 LangChain 这样的编排框架未来的角色和定位，提出了新的思考和挑战。

• 核心价值的演变：随着 LLM 本身能够处理更长的上下文信息，并能够更智能地去使用各种外部工具，LangChain 在某些方面的“胶水”作用（例如，仅仅是简单地连接 LLM 与工具，或者管理一些较短的上下文信息），对于那些相对简单的任务而言，其必要性可能会有所减弱。未来，LangChain 的核心价值可能会更多地转向以下一些方面：
  • 复杂工作流的编排：专注于编排那些涉及到多个 LLM 协同工作、包含多个智能代理 (Agents) 交互，或者具有复杂逻辑序列的应用程序。在这方面，新推出的 LangGraph 框架将扮演至关重要的角色。
  • 多样化数据源的管理：致力于集成和管理来自不同企业内部系统和各种异构数据源的数据，以便为 LLM 提供全面、准确且与特定任务高度相关的上下文信息。
  • 强大的评估与部署基础设施：通过像 LangSmith, LangServe 这样的配套工具，为 LLM 应用的整个生命周期——从最初的开发、到严格的测试和评估、再到最终的生产环境部署和持续的监控——提供全方位的支持。
  • “认知架构”的构建：LangChain 的创始人 Harrison Chase 曾多次强调，LangChain 的使命是帮助开发者构建出具备上下文感知能力和代理（agentic）能力的应用程序，并特别关注这些应用程序的“认知架构” (cognitive architecture)。这意味着 LangChain 将会致力于提供那些能够帮助开发者构建出更智能、更自主的系统的工具和方法论。
• 对模型上下文协议 (MCP) 等标准的接纳：Harrison Chase 也曾公开讨论过像模型上下文协议 (Model Context Protocol, MCP) 这样的新兴标准。他认为，当需要将一些工具提供给那些不受开发者直接控制的、可能来自第三方的代理 (Agents) 使用时，这类标准化的协议将会非常有用。这或许暗示了未来可能会出现一些标准化的工具使用接口，而 LangChain 凭借其广泛的集成能力，可以在采纳这些新兴标准，或者在不同的代理/工具生态系统之间提供桥接和转换方面，发挥其独特的作用。
• 持续的工具化努力：Chase 认为，LLM 应用开发领域目前仍处于一个相对早期的阶段，开发者们仍然需要大量的、各种不同类型的工具，来帮助他们创建出真正具有颠覆性的应用程序。因此，LangChain 将会继续在这一方向上进行投入和探索，不断地推出新的组件和功能。

LangChain 未来的发展，将紧密地围绕着如何帮助开发者构建出更高质量、更可靠、也更智能的 LLM 应用程序而展开。从最初主要关注于帮助开发者进行快速的原型构建，到如今更加侧重于对生产级应用的支持，再到未来可能更多地聚焦于构建复杂的代理系统，LangChain 始终在努力地适应并积极引领着 LLM 应用开发领域的新趋势和新方向。

对 LLM 编排和代理式 AI 的更广泛影响

LangChain 不仅仅是一个实用的工具框架，它对开发者们如何思考和构建基于大型语言模型 (LLM) 的应用程序，产生了非常深远的影响，并且有力地推动了相关技术领域的发展。

• 普及关键架构模式：LangChain 极大地普及了像链式调用 (Chaining)、检索增强生成 (Retrieval Augmented Generation, RAG) 以及代理式架构 (Agentic Architectures) 等重要概念和核心模式。它提供了一套相对易于理解和使用的抽象层，使得这些原本可能显得非常复杂的架构模式，能够被更广泛的开发者群体所接受和熟练应用。
• 推动 LLMOps 的发展：LangChain 应用程序通常具有一定的复杂性，这也催生了对专门针对 LLM 的运维 (LLMOps) 工具的迫切需求。这些应用程序包含了一些独特的组件，例如精心设计的提示词 (prompts)、复杂的链 (chains) 结构、以及需要进行状态管理的代理 (agents) 等等。所有这些都需要进行有效的版本控制、严格的性能评估、精确的成本管理，并确保其在运行过程中的安全性和与预期行为的一致性。LangSmith 是 LangChain 团队在 LLMOps 领域进行的一个早期尝试，但整个领域仍然需要更为成熟和完善的解决方案，来应对诸如评估非确定性输出的准确性、追踪复杂推理过程的每一步、管理提示可能发生的“漂移” (prompt drift) 等独特的挑战。LangChain 在实际应用中所遇到的这些问题，也反过来推动了整个 LLMOps 领域的研究和发展。
• 加速多代理系统的探索：通过像 LangGraph 这样的新工具，LangChain 也促进了对多代理系统 (Multi-Agent Systems) 的研究和应用。在多代理系统中，多个自主的或半自主的智能体 (agents) 会协同工作，以共同解决一些非常复杂的问题。这为我们开辟了许多新的可能性，但也同时带来了在智能体之间的通信、协作、冲突解决以及资源管理等方面的一系列新挑战。虽然 LangGraph 为构建这类系统提供了一个灵活的框架，但关于如何设计出高效、稳健的多代理交互模式，以及如何管理其内部复杂的“社会动力学” (social dynamics) 等问题，仍然是亟待进一步探索和研究的新领域。

LangChain 的整个演进过程，不仅清晰地反映了大型语言模型 (LLM) 技术自身的发展轨迹，也深刻地影响着开发者们构建智能应用程序的方式，以及整个 AI 应用生态系统的成熟和发展。

第八章：结论与战略建议

LangChain 的重要性总结

LangChain 自从问世以来，凭借其独特的优势和快速的迭代，已经迅速成长为大型语言模型 (LLM) 应用开发领域的核心框架之一。它的出现，极大地降低了构建复杂 LLM 应用程序的技术门槛。通过其精心设计的模块化架构、内容丰富的预构建组件，以及对像链式调用 (Chaining)、检索增强生成 (RAG) 和代理 (Agent) 等关键架构模式的优雅抽象和高效封装，LangChain 使得开发者们能够更快速地将他们脑海中的创新想法转化为可实际运行的原型，并逐步地将这些原型推向真正的生产环境部署。LangChain 的核心贡献在于，它为开发者提供了一个统一的、标准化的接口，来与各种多样化的 LLM、形形色色的数据源以及功能各异的外部工具进行顺畅的交互。并且，通过像 LangChain 表达式语言 (LCEL) 和 LangGraph 这样的创新性工具，它进一步赋予了开发者构建出高度可定制和可控的智能应用程序的强大能力。其背后那个异常活跃的开源社区，以及框架本身快速的迭代周期，都保证了 LangChain 能够紧密地跟上 LLM 技术飞速发展的前沿步伐。

采用 LangChain 的战略考量

对于那些正在考虑是否要在其项目中采用 LangChain 的开发者和技术团队来说，应该基于项目的具体需求、团队自身的技术能力和经验，以及对长期维护成本等因素，进行一次全面而审慎的综合评估：

• 何时选择 LangChain：
  • 快速原型验证与实验：LangChain 提供了极其丰富的预构建组件和大量的集成选项，这使得它非常适合用于快速地搭建和测试各种新的 LLM 应用想法。
  • 复杂工作流的编排：当你的应用程序需要将多个 LLM 的调用、多种外部工具的使用、复杂的数据检索过程以及一系列逻辑判断步骤巧妙地串联起来时，LangChain 所提供的链 (Chains)、代理 (Agents) 和 LangGraph 框架，能够为你提供非常强大的编排能力。
  • 利用广泛的生态系统：如果你的项目需要集成多种不同的 LLM、各种类型的向量数据库，或者其他一些第三方的服务，那么 LangChain 庞大且仍在不断增长的集成库，可以显著地减少你的开发工作量。
  • 构建标准化的 RAG 或代理应用：对于像 RAG（检索增强生成）和基于代理的这类常见的应用模式，LangChain 已经提供了相对成熟的模板和核心组件，可以帮助你快速上手。
• 何时考虑替代方案或自定义构建：
  • 对特定领域的性能有极致要求：对于某些高度优化的、应用领域相对狭窄的任务（例如，纯粹的、高性能的向量检索，或者特定类型的专业搜索），一些专门为此目的而设计的框架（例如 LlamaIndex 或 Haystack）可能会提供更好的性能表现，或者更为简洁的实现方式。
  • 希望避免不必要的抽象开销：如果你的团队对底层的 LLM SDK 已经非常熟悉，并且希望对应用程序的每一个实现细节都拥有完全的、精确的控制权，那么你可能会觉得 LangChain 所提供的抽象层在某些情况下是多余的，甚至可能会引入一些不必要的复杂性或潜在的性能损耗。
  • 与特定企业技术栈的深度绑定需求：例如，在一个高度依赖于微软技术栈（例如 .NET, Azure 等）的企业环境中，Microsoft Semantic Kernel 可能会因为其对 C# 和 Java 的原生支持，以及与 Azure 云服务的紧密集成，而更受青睐。
  • 对 API 稳定性和文档质量有极高要求，且无法容忍快速迭代所带来的不确定性：虽然 LangChain 团队正在积极地努力提升这些方面，但对于某些对系统稳定性要求极高的生产环境来说，其快速迭代的特性可能仍然需要开发者进行谨慎的评估和权衡。
• 采用 LangChain 的关键实践：
  • 深入理解核心组件：特别是像 LangChain 表达式语言 (LCEL) 和 LangGraph 这样的较新的核心组件，它们代表了 LangChain 未来的主要发展方向，并且能够为开发者带来更高的灵活性和更强的控制力。
  • 重视测试与可观测性：鉴于 LLM 应用程序本身所具有的非确定性，以及 LangChain 框架本身的复杂性，投入足够的精力来进行自动化的测试，并积极利用像 LangSmith 这样的工具来进行应用的追踪、调试和评估，对于保证最终应用程序的质量来说至关重要。
  • 关注社区动态与版本更新：LangChain 的社区非常活跃，其版本迭代也相对较快。保持对项目最新进展的关注，有助于你及时利用到框架的新功能，并能够规避一些潜在的兼容性问题。
  • 从小处着手，逐步迭代：对于那些计划构建复杂应用程序的开发者来说，建议从一些相对简单的链 (Chains) 或代理 (Agents) 开始入手，然后逐步地增加其复杂性，并在这个过程中充分利用像 LangSmith 这样的工具来进行细致的调试和持续的优化。

LLM 应用开发的总结性思考

LangChain 的迅速崛起和持续演进，可以说是整个大型语言模型 (LLM) 应用开发领域，从最初的探索期逐步迈向更为成熟的工程化阶段的一个生动缩影。它不仅为开发者们提供了一套非常实用的工具集，更重要的是，它推广了一系列用于构建智能应用程序的、行之有效的设计模式和核心理念。展望未来，随着 LLM 自身能力的持续增强（例如，它们能够处理的上下文窗口变得越来越长、原生调用外部工具的能力越来越强、以及在多模态信息处理方面的表现越来越出色等），像 LangChain 这样的编排框架所扮演的角色，也必将不断地发生演化。

对于那些相对简单的任务而言，其作为“胶水”代码的需求可能会有所减少。但是，对于构建那些复杂的、需要执行多个步骤的、并且需要与企业内部各种异构系统进行深度集成的高级智能应用程序，以及对于探索和实现多代理协作系统这样的前沿领域来说，类似 LangChain 这样的框架仍将扮演着不可或缺的关键角色。它们未来的发展重点，可能会更多地聚焦于提供更为强大的“认知架构”构建能力、更为可靠的生产环境支持体系（例如在评估、监控、部署等方面提供更完善的工具），以及与不断扩展的、日益繁荣的 AI 生态系统的无缝集成。与此同时，整个行业对 LLMOps（即针对大型语言模型的运维）的需求也将持续增长，以有效地应对 LLM 应用程序在可靠性、可维护性、安全性以及成本效益等方面所面临的各种独特挑战。LangChain 及其相关的核心工具（例如 LangSmith 和 LangGraph），正处在这一技术浪潮的前沿。它们未来的发展，无疑将继续对整个 LLM 应用开发的未来走向，产生深远而积极的影响。