LangChain 生态：从链到代理，开发者需要掌握的三大核心

前言

LangChain 现在是一个覆盖了模型接入、流程编排、多智能体协作的完整 LLM 应用开发生态。它旗下有几十个软件包、集成平台和观测工具，很容易让人迷失在文档海洋，但对实际开发而言，真正构成日常工作主线的只有三个框架：

LangChain：组件与链式编排；
LangGraph ：有状态循环工作流；
Deep Agents：多智能体分工协作。

本文将围绕这三者，理清它们各自解决什么问题、如何配合，以及该从哪一个开始，不涉及具体 api 使用。

一、LangChain

LangChain 负责提供基础的链条设计与构建功能，是核心的代理框架。它封装了 LLM 与工具的交互，提供灵活的代理结构，但不包含规划、记忆或文件系统，适合开发者自己定制逻辑。

1. 组件

LangChain 有六大核心组件：模型 I/O、检索器、链、Agent、记忆、Tools 工具调用。他们之间的耦合非常松散，各组件之间没有调用顺序，也没有固定的接口。开发者可以自由组合并设计他们。

1.1 模型 I/O

Model I/O 是指与 LLM 交互的完整输入输出流程。包括输入提示(Format)、调用模型(Predict)、输出解析(Parse)三个核心层次。分别对应着 Prompt Template、Model、Outpt Parse。

Prompt Template：提示词模板，通过模板管理大模型输入，将原始数据转化为大模型可以处理的格式。
Model：使用通用接口来调用不同的大语言模型，接收送进来的问题，基于问题生成回答或进行预测。
Output Parse：用来从模型的推理中提取信息，并按照预先设好的模板来规范化输出。

提示词模板

PromptTemplate 文本提示词模板：是针对文本生成模型的提示词模板，也是 LangChain 提供的最基础的模板，通过格式化字符串生成提示词，在执行invoke时将变量格式化到提示词模板中。创造文本提示词模板的方法有两种：PromptTemplate 实例化和 PromptTemplate.from_template；

ChatPromptTemplate 对话提示词模板：ChatpromptTemplate 是 LangChain 中专门用于结构化聊天对话提示的核心组件，它比普通 promptTemplate 更适合处理多角色、多轮次的对话场景。为与现代聊天模型的交互提供了一种上下文丰富和会话友好的方式。

模型独家调用

有时候在业务中可能只允许合作一家厂商，以阿里百炼平台千问为例：由于 LangChain 不支持大部分国内厂商，所以使用 openai 的接口规范(model_provider)，阿里是兼容的。

OpenAI 的 API 格式（请求体结构、参数命名、响应格式）设计得很清晰，逐渐成为行业事实标准。国内厂商为了降低用户迁移成本，主动提供了兼容层。当 LangChain 的 ChatOpenAI 初始化时，它底层使用的是 openai Python SDK。这个 SDK 允许自定义 base_url，只要厂商返回的数据格式和 OpenAI 一致，openai SDK 就能正常解析，LangChain 也就无感知。

输出解析

语言模型返回的内容通常都是字符串的格式(文本格式)，但在实际AI应用开发过程中，往往希望大模型可以返回更直观、更格式化的内容，以确保应用能够顺利进行后续的逻辑处理。此时，LangChain 提供的输出解析器就派上用场了。输出解析器(Output Parser)负责获取 model 的输出并将其转换为更合适的格式比如 json、yaml、xml 等，这在应用开发中极其重要。

解析器类型	适用场景	输出格式
StrOutputParser	简单文本输出	字符串
JsonOutputParser	JSON格式数据	字典/列表
PydanticOutputParser	复杂结构化数据	Pydantic模型对象
ListOutputParser	列表数据	Python列表
DatetimeOutputParser	时间日期数据	datetime对象
BooleanOutputParser	布尔值输出	True/False

1.2 检索器

检索器是一个接口，它根据非结构化查询返回文档。它比向量存储更通用，但实际生产业务中可能还是向量数据库+搜索分析引擎的用法更多一些。检索器不需要能够存储文档，只需返回(或检索)它们。检索器可以从向量存储创建，但其范围也足够广，可以包括维基百科搜索和 Amazon Kendra。检索器接受字符串查询作为输入，并返回文档列表作为输出。注意，所有向量存储都可以转换为检索器。

以下是 LangChain 中提供的检索器组件：

组件	作用	常用组件类
文档加载器	对各种格式的文档信息进行加载	Document（文档组件）、UnstructuredPDFLoader（PDF文档加载器）、UnstructuredFileLoader（文件文档加载器）、UnstructuredMarkdownLoader（markdown文档文本加载器）
文档分割器	将加载的文档分割成文档片段	RecursiveCharacterTextSplitter（递归字符文本分割器）
文本嵌入模型组件	将文本信息向量化	OpenAIEmbeddings（OpenAI文本嵌入模型）、HuggingFaceEmbeddings（HuggingFace文本嵌入模型）
向量数据库组件	将向量和元数据信息保存到向量数据库	VectorStore（向量数据库，不同向量数据库有不同的实现类）
文本检索器	根据用户提问在向量数据库中进行检索	VectorStoreRetriever（向量数据库检索器）

1.3 链

LangChain 的链（Chain）组件是将多个处理步骤按顺序串联的抽象，每个步骤的输出作为下一步的输入，实现复杂任务的流水线编排。它通过统一的接口（如 invoke、stream、batch）让 LLM 调用、提示词处理、数据转换等操作可以模块化组合复用。这是 LangChain 最直接的体现方式。

Runnable

定位：LangChain 中的抽象基类(ABC AbstractionBaseClass)
目标：为所有可执行组件提供统一的操作接口，统一接口+调用方法
核心理念：一切可执行的对象都应该有统一的调用方式

Runnable 是 LangChain 核心抽象接口(定义在langchain_core.runnables)统一组件调用方式，支持LCEL组合，适配同步/异步、流式、批量等场景，用于构建所有链组件(Chain)，它代表一个可以调用(运行)的流程单元。

LCEL(LangChain Express Language)

定位：专门用于组合 Runnable 组件的声明式语法
核心操作符：管道符 "|"
核心思想：使用管道操作符将多个 Runnable 对象像拼积木一样组合起来

等价于 Linux 中的管道符 | ，例如 ps -ef | grep tomcat，即上一个命令的返回值可以作为下一个命令的参数，将大模型调用进行管道编排，流式输出。我们称使用 LCEL 创建的 Runnable 为"链"，"链"本身也是 Runnable。

chain 结构

提示词模板+大模型+结果结构化解析器这三部分构成了 chain 结构，chain 结构包含以下几种：

顺序链 RunnableSequence：按 prompt | model | output_parser 的顺序组合
分支链 RunnableBranch：通过 RunnableBranch 类处理条件判断
串行链 RunnableSerializable：将多个链串联起来
并行链 RunnableParallel：同时运行多个链

1.4 Agent

在 LangChain 中通过 create_agent 创建 Agent，Agent 是一个决策引擎，根据上下文决定下一步做什么，处理 Tool 返回的结果并决定是否需要继续调用其他 Tool。Agent 的核心是推理+行动(Reason+Act)，也就是 ReAct 模式。

Agent = LLM + Memory + Tools + Planning + Action。

1.5 记忆

在 LangChain 中，给大语言模型添加记忆功能的方法如下:

在链执行前，将历史消息从记忆组件读取出来，和用户输入一起添加到提示词中，传递给大语言模型；
在链执行完毕后，将用户的输入和大语言模型输出，一起写入到记忆组件中；
下一次调用大语言模型时，重复这个过程。

简单聊天的记忆方案： RunnableWithMessageHistory 配合 BaseChatMessageHistory 使用。

RunnableWithMessageHistory

是 LangChain 推荐的最新记忆方案，优势包括：

LangChain 中所有可串联的组件(Prompt、Model、Parser、RunnableLambda等)都继承自Runnable基类
模块化：允许自由组合提示模板、模型和内存管理逻辑。
灵活性：支持自定义对话历史存储(如内存、数据库)和复杂对话流程。
兼容性：与LCEL和现代聊天模型无缝集成。
长期支持：在LangChain0.3.x 中稳定，且不会在 1.0 中移除。

BaseChatMessageHistory

用于保存聊天消息历史的基类，有以下常用的实现类：

组件名称	特性
InMemoryChatMessageHistory	基于内存存储的聊天消息历史组件
FileChatMessageHistory	基于文件存储的聊天消息历史组件
RedisChatMessageHistory	基于Redis存储的聊天消息历史组件
ElasticsearchChatMessageHistory	基于ES存储的聊天消息历史组件

1.6 Tools

LLM 本身不能实际调用工具；相反，它们会在响应中表达调用特定工具的意图(而不是以纯文本回应)。然后，应用程序应该执行这个工具，并报告工具执行的结果给模型。当 LLM 可以访问工具时，它可以在合适的情况下决定调用其中一个工具，这是一个非常强大的功能。MCP、Skills可说是 tools 的一种发展。

在 LangChain 中使用 @tool 装饰器将函数装饰为可识别的工具，并通过 bind_tools 方法与 LLM 进行绑定。

2. 集成 Integration

负责与外部工具或服务集成，例如与API、数据库或第三方模型交互，支持灵活扩展与适配。LangChain 目前维护了 1000+ 集成，覆盖模型、存储、工具、数据源等全链路。它的核心设计哲学是：不管底层提供商是谁，上层接口保持一致。

这意味着你可以把 ChatOpenAI 换成 ChatAnthropic，把 Pinecone 换成 Chroma，业务代码几乎不用改。

2.1 模型层集成

组件类型	作用	典型提供商
Chat Models	对话式大语言模型（多轮、system/human/ai 消息）	OpenAI、Anthropic、Google、Azure、DeepSeek、通义千问、Ollama
Embedding Models	文本向量化，用于语义检索	OpenAI、Cohere、HuggingFace、Ollama
LLMs (Legacy)	文本补全模型（非对话式，逐步被 Chat Models 取代）	OpenAI、AI21、Cohere

2.2 数据加载集成

负责把各种格式的数据源加载成 LangChain 的 Document 对象（包含 page_content 和 metadata）。

数据源类型	典型 Loader
文件格式	PyPDFLoader、UnstructuredWordDocumentLoader、CSVLoader
网页/网络	WebBaseLoader、ArxivLoader、YoutubeLoader
云存储	S3FileLoader、AzureBlobStorageContainerLoader
数据库	SQLDatabaseLoader、MongoDBLoader
协作平台	NotionDirectoryLoader、ConfluenceLoader

2.3 向量存储与检索集成

负责存储文本向量并提供语义检索能力。

组件类型	作用	典型提供商
Vector Stores	存储和查询向量嵌入	Pinecone、Chroma、Milvus、Qdrant、FAISS、PGVector、Redis
Retrievers	基于向量存储的检索策略封装	VectorStoreRetriever、MultiQueryRetriever、ParentDocumentRetriever

2.4 工具与外部服务集成

让 LLM 能够调用外部 API、执行代码、访问数据库等。

工具类型	典型代表
搜索	DuckDuckGoSearchRun、GoogleSearchRun、BingSearchRun
计算/代码	PythonREPLTool、ShellTool
数据库	SQLDatabaseTool、MongoDBTool
办公/协作	GmailToolkit、SlackToolkit、JiraToolkit
专业领域	WikipediaQueryRun、ArxivQueryRun

2.5 其他辅助集成

组件类型	作用	说明
Document Transformers	文档分块、过滤、翻译	RecursiveCharacterTextSplitter、Html2TextTransformer
Callbacks	回调钩子，用于日志、监控	LangSmith、Wandb、PromptLayer
Adapters	适配器模式，桥接不同格式	如 OpenAI 函数调用格式适配

2.6 按供应商分类：官方伙伴包 vs 社区包

除了按组件类型，官方还按提供商维护了两类包：

Partner Packages（官方伙伴包）

由 LangChain 团队与第三方厂商联合维护，独立发包 ，轻量稳定 。命名规范：langchain-<provider>，只包含该厂商相关组件，依赖干净，API 变更响应快，适合生产。

示例：langchain-openai、langchain-anthropic、langchain-google-genai、langchain-deepseek

langchain-community（社区集成包）

收录所有未拆分为独立包的第三方集成，大而全，一站式安装，适合快速原型，但依赖较杂。

二、LangGraph

LangGraph 管 "流程"，是外层的运行时。它把执行变成可管理的图结构，支持循环、并行和持久化，保障智能体执行的稳定与可控。

LangGraph = LangChain + 图编排 + 状态机。

为什么需要 LangGraph：由于 LangChain 是一条直线的，现实中很多业务需要返回，需要循环反复，不是流水线，这就需要写大量的、不优雅的"胶水代码"来强行实现循环，整个逻辑会变得一团糟。虽然 Agent ReAct 某种程度上解决了这个问题，但过程是黑箱不可控，很难对它的工作流程进行精细化的控制和干预。

1. 状态 State、节点 Nodes、边 Edges

State(状态)、Nodes(节点)、Edges(边)，组成 Graph(图)。

1.1 State

在 LangGraph 中，State 是一个贯穿整个工作流执行过程中的共享数据的结构，代表当前快照。

它存储了从工作流开始到结束的所有必要的信息(历史对话、检索到的文档、工具执行结果等)，在各个节点中共享，且每个节点都可以修改。状态包含两部分：一是图的模式(schema)，二是"归约函数"(reducer functions)。后者指明如何把更新应用到状态上。

Schema

通过 StateGraph 构建图时，可以指定输入输出的模式：

state_schema 是一切的基石，是图的完整内部状态，包含了所有节点可能读写的字段，必须指定，不能为空。是图的"全局状态空间"。
input_schema 定义图接受什么输入，是 state scheme 的子集。可选参数，如果不指定默认等于 state_scheme，限制图的输入接口，只能传入这些字段。
ouput_schema 定义图返回什么输出，是 state_schema 的子集。可选参数，如果不指定默认等于 state_scheme，限制图的输出接口，只返回这些字段。

Reduce

归约函数 Reduce 决定了节点产生的更新如何作用到State（覆盖、合并、添加等）。State 中的每个字段都拥有自己的独立归约函数，如果未显式指定，则默认所有对该字段的更新都会直接覆盖旧值。它是"字段级合并策略"，它让节点只需吐出"增量"，框架负责按规则把增量焊进全局 state。也就是说如果节点只 return 一个字段，只会改变这一个字段，不会改变整个 state。

default：未指定 Reducer 时使用覆盖更新
add_messages：用于消息列表追加
operator.add：将元素追加到现有元素中，支持列表、字符串、数值类型的追加
operator.mul：用于数值相乘
自定义 Reducer：支持用户自定义合并逻辑

1.2 Nodes

在 LangGraph 中，Node 是 LangGraph 中的一个基本处理单元，代表工作流中的一个操作步骤，可以是一个 Agent、调用大模型、工具或一个函数(说白了就是绑定一个 python 函数，具体逻辑可以干任何事情)。它们接受以下参数：

state：图的状态，存储需要读写修改的数据；
config：一个 RunnableConfig 对象，包含诸如 thread_id 之类的配置信息以及诸如 tags 之类的跟踪信息，存储不变的配置信息；
runtime：一个 Runtime 对象，包含运行时 context 以及其他信息，如 store 和 stream_writer 、数据库连接等运行时依赖。

定义好 node 函数后，使用 add_node 方法将这些节点添加到图中。如果在向图中添加节点时未指定名称，系统会为其分配一个与函数名相同的默认名称。

1.3 Edges

Edge 定义了节点之间的连接和执行顺序，以及不同节点之间是如何通讯的，一个节点可以有多个出边(指向多个节点)，多个节点也可以指向同一个节点(Map-Reduce)。边有以下几种：

普通边（固定边）：直接连接两个节点的边，无条件从一个节点跳转到下一个节点；
条件边：调用一个函数来决定接下来要到哪个(或哪些)节点。如果你想选择性地路由到一个或多个边(或选择性地终止)，你可以使用 add_conditional_edges 方法。此方法接受一个节点名称和一个在该节点执行后调用的"路由函数"。
入口点：当用户输入到达时，首先调用哪个节点。入口点是图启动时运行的第一个节点。你可以使用 add-edge 方法从虚拟 START 节点连到要执行的第一个节点，以指定图的入口。
条件入口点：当用户输入到达时，调用一个函数来决定首先调用哪个(或哪些)节点。条件入口点允许你根据自定义逻辑从不同的节点开始。你可以使用虚拟节点 START 的 add_conditional_edges 来实现此功能。

2. 高级 API

在实际开发中可能会遇到更复杂的情况，为了支持动态地决定下一步执行哪些节点，实现高级工作流控制，LangGraph 提供了 send 和 command 两种控制机制，以及 runtime context 运行时上下文。

2.1 Send

默认情况下，Nodes 和 Edges 是预先定义的，并对相同的共享状态进行操作。但是，在某些情况下，确切的边可能无法预先知道，或者你可能希望同时存在不同版本的 state。一个常见的例子是 map-reduce 设计模式。在此设计模式中，第一个节点可能生成一个对象列表，你可能希望将其他某个节点应用于所有这些对象。对象的数量可能无法预先知道(意味着边的数量可能无法知道)，并且下游 Node 的输入state 应该不同(每个生成的对象一个)。

为了支持这种设计模式，LangGraph 支持从条件边返回 Send 对象。Send 接受两个参数：第一个是节点的名称，第二个是要传递给该节点的状态(参数信息)。

2.2 Command

Command 只能路由到一个节点，并且可以更新当前状态、处理中断恢复、以及在嵌套图之间导航。常用于复杂的人机交互（human-in-the-loop）和多智能体协同工作中智能体与智能体之间交接执行权（handoffs）。

在节点中返回 command 来实现动态路由。

2.3 Runtime Context

运行时上下文。创建图时，可以为传递给节点的运行时上下文指定 context_schema。这对于向节点传递不属于图状态的信息很有用。例如，你可能希望传递模型名称或数据库连接等依赖项。

节点函数接收两个参数：state (图的状态)和 runtime (运行时上下文)，通过 runtime.context 访问上下文信息。

3. 高级特性

3.1 Streaming（流式处理）

LangGraph 里的"流式传输"功能，核心就是让AI应用(比如用大语言模型做的工具、对话机器人)能"实时输出结果"，不用等整个流程跑完，体验更流畅。大语言模型(LLM)回应通常有点慢，流式传输能让结果更透明、更流畅，用户能实时看到进度，开发者也方便调试，还能灵活适配各种需求。

能实现的效果：

实时看流程状态：比如知道 AI 现在在处理哪个步骤、当前的结果是什么(比如"正在细化主题"、"已生成笑话初稿");
实时看子流程结果：如果你的 AI 流程里嵌套了小流程(子图)，也能同步看到子流程的进度；
实时看 LLM 输出的每一个字：比如 AI 写笑话时，每个词、每句话实时蹦出来，不是最后一次性显示；
自定义实时消息：比如让 AI 干活时，实时发"进度30%"、"正在调用工具查数据"这种自定义提示；
调试用：能看到流程里的详细细节，方便找问题。

3.2 Persistence（状态持久化）

状态持久化指的是在程序运行时将瞬间的状态保存下来，以便后续需要的时候能够重新恢复执行，用于解决因为程序退出、重启等事件而丢失任务。在 LangGraph 如果使用了持久化，工作流执行的每个步骤结束后，系统会自动将当前整个图的状态(包括所有变量、历史消息、下一步要执行的节点等倩息)完整地保存下来，这份存档就是一个检查点(Checkpoint)，LangGraph 支持存储在内存、Redis、DB 等存储介质中。

检查点通过 thread_id(会话id，不是操作系统中的线程id)区分不同的会话，后续重新执行时会使用。使用检查点调用图时，必须在配置的可配置部分指定 thread_id。有两种记忆方式：

短期记忆 CheckPointer：启用后，在每个节点执行后自动保存状态，可以随时恢复到任意历史节点。它会把 state 保存到储存中（内存/数据库/文件），下次继续调用时，可以恢复 state，保存的是图的状态；
长期记忆 BaseStore：显式保存"用户偏好"、"背景事实"等高密度信息到 InMemoryStore、RedisStore 等，由 LLM 主动读写，Store 支持向量检索，支持命名空间隔离。支持长线程和会话的长期存储。

3.3 时间回溯

LangGraph 的时间旅行，是一个允许你"回到对话的某个历史状态点，并从那里重新执行"的功能。就是用来回溯、检查、修改一个工作流执行过程中的历史状态，并从某个历史节点重新执行，从而实现对智能体决策过程的调试、分析和路径探索。

它依赖 Checkpointer(检查点系统)，比如 MemorySaver、数据库持久化 saver 等把每一步执行的状态(state)保存下来。

普通对话：只能按顺序走下去。
有时间回溯：可以跳到某一步(比如第3次工具调用前)，从那个状态继续，甚至尝试不同的分支。

3.4 子图

在 LangGraph 中允许将一个完整的图作为另一个图的节点，适用于将复杂的任务拆解为多个专业智能体协同完成，每个子图都可以独立开发、测试并且可以复用。每个子图都可以拥有自己的私有数据，也可以与父图共享数据。

跨图状态交互标准架构：

父图状态（ParentState）：仅包含 user_query（用户输入）和 final_answer（最终结果），聚焦业务层；子图状态（SubgraphState）：包含 analysis_input（分析输入）、analysis_result（分析结果）、intermediate_steps（中间步骤），聚焦分析层；两者无重叠字段，完全独立，必须通过代理节点手动转换。

注意：当主图调用子图节点时，整个过程会触发两次状态合并，子图合并完成数据返回给主图后，主图再次合并，所以使用追加模式主图的数据会出现两次。

三、Deep Agents

构建在 LangGraph 之上的多智能体模式库，负责 "组织"，是最外层的工具包。它内置规划器、子代理、文件系统和持久存储，让智能体从 "能执行" 升级为 "能组织、能管理、能记忆" 的深度智能体。

1. 多智能体介绍

多 Agent 系统（Multi-Agent System, MAS）是由多个具备自主性、反应性、目标导向性的智能体（Agent）组成的协作体系，通过标准化通信与协同机制，共同完成单一智能体无法独立应对的复杂任务。简单解释，就是将复杂任务，拆解成多个子任务，分发给专长的 Agent 进行处理，最后综合结果，本质分而治之。多智能体有两种架构模式：

层级工作流 (Hierarchical / Orchestrator-Workers)：指挥官模式、主从模式，核心逻辑：中央集权。
协作工作流 (Collaborative / Network)：网状模式、专家会诊模式，核心逻辑：去中心化。

Deep agents 就是层级工作流架构。

2. Deep agents 核心架构

Deep Agents 的架构核心是主从代理，可以概括为三层：

层级	角色	职责
主代理（Main Agent）	协调者	理解用户意图，拆解任务，决定调用哪个子代理，汇总输出
子代理（Subagents）	领域专家	接收子任务，调用专属工具，返回结构化结果
工具层（Tools）	基础设施	子代理各自拥有的 API、数据库、检索器等

主代理与子代理之间通过 task 工具通信。主代理本质上是一个绑定了 SubAgentMiddleware 的 LangGraph，当主代理判断需要外部协助时，它会生成一个 task 调用，由框架路由到对应的子代理实例。主子代理之间上下文默认隔离，子代理本身也是 LangGraph（或 LangChain Runnable）。

DeepAgents 框架官方当前版本是不支持多级嵌套的，但是理论上可以通过 tools 属性将子代理作为工具通过 invoke 执行。或者通过 CompiledSubAgent 的方式编写嵌套逻辑。

无限嵌套结构：

你可以创建一个 Main Agent；
给它配置一个 Subagent A；
而这个 Subagent A 通过 tools 配置它自己的 Subagent A-1；
这种结构理论上支持多层嵌套（Agent -> Subagent -> Sub-Subagent）。

除了用户自定义的子代理之外，每个深度代理始终都能访问 general-purpose 子代理。它与主智能体共享相同的工具和模型（除非被覆盖）：

使用它自己的默认系统提示与配置文件覆盖应用
可以使用所有相同的工具。
使用相同的模型（除非有特别说明）
继承了主代理的技能（当技能被配置好后）

3. 智能规划与任务分解

DeepAgents 内置 write_todos 工具，使代理能够：

将复杂任务分解为离散的执行步骤
实时跟踪任务执行进度
根据新信息动态调整执行计划

注意：write_todos 不是 Python 原生的函数，而是 DeepAgents 框架内置的一个 "工具函数" ------ 你可以把它理解成：DeepAgent 自带的一个 "待办清单生成器"，专门让智能体把复杂任务拆成一条条可执行的待办事项，并且能把这些事项存起来。

4. 上下文与记忆管理

4.1 上下文管理

DeepAgents 内置文件系统工具集（ls、read_file、write_file、edit_file），使代理能够：

将大型上下文信息卸载到外部存储
有效防止上下文窗口溢出问题
处理可变长度的工具执行结果

这套文件系统工具集不是简单的 "本地文件操作"，而是 DeepAgents 封装的跨存储工具------你可以把它理解成：DeepAgent 自带的 "智能文件管家"，专门帮代理管理超出 "大脑容量" 的信息，支持本地文件、云存储（OSS/S3）等多种存储方式，还能和其他工具联动。

4.2 长期记忆能力

DeepAgents 利用 LangGraph 的 Store 功能，使代理能够：

为代理扩展跨线程(协程)持久内存
保存和检索历史对话信息
支持多会话间的知识共享

执行过程中，这份记忆还能跨场景用：比如你在电脑上和客户聊的需求，换手机登录后，代理还能查到档案本；多个同事（多代理）跟进同一个客户，都能共享这份档案 ------ 完全像个带 "永久档案柜" 的客服，不管过多久、换什么设备，都能记住之前的信息。

5. 兼容其他 Agent

LangChain 生态下的其他 Agent（比如 AgentExecutor、ReActAgent、StructuredChatAgent 等）可以挂载为 DeepAgents 的子代理，但不能直接挂 ------ 需要先把这些 Agent 封装成「符合 LangGraph StateGraph 规范的图」（核心是状态里包含 messages 键），再用 CompiledSubAgent 封装。

简单说：DeepAgents 认的是「LangGraph 格式的图」，不是直接认 LangChain Agent；但所有 LangChain Agent 都能转成 LangGraph 图，所以最终都能挂。

DeepAgents 调度子代理的核心要求只有一个：子代理的执行逻辑必须是「带有 messages 键的状态图」（不管这个图是直接用 StateGraph 写的，还是从其他 Agent 转来的）。这个 messages 键就是result 结构的核心字段 ------ DeepAgents 靠它传递对话、工具调用、执行结果，没有这个键就无法和主代理通信。

6. 流程人机交互 (HITL)

有些工具作可能比较敏感，需要人工批准才能执行。深度代理通过 LangGraph 的中断功能支持人机参与的工作流程。可以使用 interrupt_on 参数配置哪些工具需要批准。

7. 后端存储

DeepAgents 的 Backend 系统是为 Agent 构建的 "虚拟文件系统"，核心作用是定义 Agent 生成文件的最终存储位置，也是实现跨线程数据共享、落地长期记忆能力的核心载体。Backend 仅在 Agent 主动调用文件操作工具（如 write_file、edit_file、read_file）时才会被激活。需注意的是，Agent 的思考过程、对话上下文等临时状态仅存储在内存（State）中，不会自动写入 Backend，只有显式执行文件操作的内容才会进入该系统。

DeepAgents 提供了四种标准的后端实现，适用于不同的开发和生产场景：

后端类型	存储介质	适用场景	类比
StateBackend (默认)	内存 (State)	临时文件、中间运算结果。会话结束即销毁。	浏览器的"无痕模式"
FilesystemBackend	本地硬盘	本地开发、调试、需要直接查看生成文件的场景。	电脑的本地磁盘
StoreBackend	数据库 (KV Store)	生产环境、跨 Agent 共享数据、持久化记忆 (Redis/Postgres)。	云盘 (iCloud/OneDrive)
CompositeBackend	混合存储	生产环境最佳实践。区分"临时文件"和"重要记忆"。	系统盘 (C盘) + 数据盘 (D盘)

8. Middleware

Middleware 是 DeepAgents 的「流程拦截器」，可以在 Agent 执行的关键生命周期节点（如工具调用前 / 后、思考完成后、回复生成前）插入自定义逻辑，实现：

操作日志记录
权限校验 / 参数过滤
工具调用结果修改
异常捕获 / 兜底处理
自定义监控 / 告警

9. Agent Skills

DeepAgents 提供的 Skills（技能）机制，是为智能体（Agent）注入领域知识与专业能力的核心方式。Skills 本质是可复用、可插拔的 "能力包"，核心由指令文档（SKILL.md）及配套资源构成，能让 Agent 在运行过程中，根据任务场景的实际需求动态加载、调用对应的技能知识，无需修改 Agent 核心逻辑即可快速扩展专业能力。

9.1 核心概念

SKILL.md

技能的核心描述文件，是 Agent 学习和使用该技能的 "说明书"。文件整体分为两部分 ------ 头部的元数据（Frontmatter）（以 YAML 格式定义定义name 和 description）和正文的具体指令（以 Markdown 格式编写），Agent 会通过解析该文件掌握技能的使用方法、适用场景及操作流程。

渐进式披露

Skills 机制的核心优化策略，用于解决大模型上下文窗口有限的问题。Agent 启动时仅读取所有技能的元数据（轻量信息，占用极少上下文），仅记录 "技能名称、适用场景、触发关键词" 等基础信息；只有当用户任务匹配某一技能的触发条件时，Agent 才会加载该技能的详细指令内容，有效避免无关信息占用上下文，提升任务执行效率。

9.2 标准技能目录结构

一个完整的 DeepAgents 技能包遵循标准化的文件目录结构，不同文件各司其职，确保技能可复用、易维护，典型结构如下：

bash 复制代码

skill-xxx/                # 技能根目录（命名规范：skill-技能名，小写+短横线）
├── SKILL.md              # 核心：技能描述文件（必选）
├── requirements.txt      # 依赖声明文件（可选）
├── resources/            # 配套资源目录（可选）
│   ├── template/         # 模板文件（如报表模板、代码模板）
│   ├── examples/         # 示例文件（如技能使用的输入/输出示例）
│   └── config/           # 配置文件（如工具调用的默认参数、规则配置）
└── scripts/              # 辅助脚本目录（可选）
    └── helper.py         # 技能配套的辅助脚本（如复杂逻辑的封装、数据预处理）

总结

本文介绍了 LangChain 生态的三大核心相关概念和能力，它们的递进关系是：Chain（拼积木）→ Graph（画流程图）→ Agent（组团队）。从开发难度看，三者呈明显的阶梯分布。LangChain 的 LCEL 语法直观易懂，几行代码就能跑通一个链，上手门槛最低；LangGraph 需要理解状态管理和图节点设计，调试循环流程的成本更高，适合有一定 LangChain 基础的开发者；Deep Agents 涉及多代理协调、描述工程和状态隔离，架构复杂度最高，通常在有明确领域分工需求时才引入。

从 LangChain 开始，遇到线性链无法表达的流程时升级到 LangGraph，当单代理撑不起业务边界时再引入 Deep Agents。三者可以共存于一个项目，也可以独立使用------这正是 LangChain 生态的设计智慧：每一层都解决特定复杂度的问题，而不强迫你为简单需求背负沉重的架构。