LangChain Component Architecture 深度解析：从模型、工具到 Agent 的组件化架构-开发者社区

学习 LangChain 时，很容易陷入一个个 API：

ChatOpenAI()

create_agent()

@tool

Retriever()

VectorStore()

看起来每个组件都很重要，但如果只记 API，很难真正理解：

LangChain 到底是如何把这些组件组合成一个 AI 应用的？

LangChain 官方的Component Architecture给出了一个非常重要的视角：

LangChain 并不是一个“大而全的 AI 黑盒”，而是一套可以组合的 AI 应用组件。

这些组件从数据处理、Embedding、存储、检索，到模型生成、Tools、Agents、Memory 等逐层组合，最终形成完整的 AI 应用。

一、先看整体架构

LangChain 官方将主要组件组织成多个层次：

AI Application │ ┌─────▼────────┐ │ Agent │ │Orchestration │ └─────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ Models Tools Memory │ │ │ └────────────┼────────────┘ │ Retrieval │ Vector Stores │ Document Processing │ Raw Data

官方文档进一步把组件连接过程概括为：

输入处理 ↓ Embedding & Storage ↓ Retrieval ↓ Generation ↓ Orchestration

也就是：

数据 → 知识 → 检索 → 生成 → 编排。

这其实就是理解 LangChain 架构最重要的一张图。

二、LangChain 不是一个“模型调用库”

很多初学者第一次接触 LangChain，会认为：

LangChain = 调用 GPT 的 Python SDK。

其实这只是其中非常小的一部分。

LangChain 的组件体系至少涉及：

Models Tools Agents Memory Retrievers Document Processing Vector Stores

官方文档也是按照这些类别组织组件的。

因此更准确的理解是：

LangChain │ ┌───────────────┼────────────────┐ │ │ │ Model Retrieval Agent │ │ │ │ Vector Store │ │ │ │ │ Document Processing │ │ │ └──────────── Tools ─────────────┘

它真正解决的问题是：

如何把 LLM、数据、工具和控制逻辑组合成 AI 应用。

三、第一层：Document Processing

任何 AI 应用的第一步通常不是调用 LLM。

而是：

先把现实世界的数据变成机器可以处理的结构。

例如：

PDF 网页 Word 数据库 Markdown HTML 图片 API ↓ Document Processing ↓ Structured Documents

LangChain 在这一层提供：

Document Loaders
Text Splitters
Document Transformers

官方把这一类归为Document processing，主要用于数据摄取，例如 PDF 处理、网页抓取等。

四、为什么 Document Processing 很重要？

假设我们有一本 PDF：

AI Engineering.pdf

不能简单把整个 PDF：

pdf → LLM

通常需要经过：

PDF ↓ Loader ↓ Document ↓ Splitter ↓ Chunks

例如：

原始 PDF ↓ Document Loader ↓ Document ↓ Text Splitter ↓ Chunk 1 Chunk 2 Chunk 3 ...

这些 Chunk 后面才能进入：

Embedding

然后：

Vector Store

最终用于：

Retriever

所以 RAG 的起点其实不是 Vector DB。

而是：

Document Processing。

五、第二层：Embedding

处理好的文本需要进一步转换成机器可以进行语义比较的向量。

Text ↓ Embedding Model ↓ Vector

例如：

"LangChain 是 AI 应用开发框架"

经过 Embedding 后：

[0.023, -0.18, 0.71, ...]

Embedding 的意义并不是生成答案。

它解决的是：

如何把文本转换成可以进行语义相似度计算的表示。

LangChain 为 Embedding Model 提供统一接口，例如：

embed_documents(...)embed_query(...)

这样不同 Provider 的 Embedding Model 也可以使用相似的调用方式。

六、第三层：Vector Stores

有了向量，还需要把它保存起来。

于是出现：

Embedding ↓ Vector Store

例如：

Chroma Pinecone FAISS

官方把 Vector Stores 定义为用于语义搜索的组件，可以保存 Embedding 并支持相似度搜索。

典型流程：

Documents ↓ Embedding ↓ Vector Store ↓ Similarity Search

七、Vector Store 和 Retriever 不一样

这是 RAG 初学者非常容易混淆的两个概念。

可以简单理解为：

Vector Store ↓ 负责“存”和“搜” Retriever ↓ 负责“怎么取”

例如：

Vector Store │ └── similarity_search()

而 Retriever 则提供一个更高层的检索接口：

docs=retriever.invoke(query)

所以：

Vector Store ↓ Retriever ↓ Application

这是一种非常典型的组件解耦。

八、第四层：Retriever

Retriever 的任务非常明确：

根据用户的问题找到相关信息。

例如用户问：

LangGraph 和 LangChain 有什么关系？

Retriever：

Query ↓ Retriever ↓ 相关文档 ↓ Top K Documents

然后把这些文档交给模型：

User Question ↓ Retriever ↓ Relevant Context ↓ LLM ↓ Answer

这就是最基本的 RAG。

九、RAG：组件组合的典型案例

如果把前面的组件全部连接起来：

用户问题 │ ▼ Retriever │ ▼ Vector Store │ ▼ Relevant Documents │ ▼ Prompt │ ▼ Model │ ▼ Answer

而知识库构建过程：

PDF / Web / Docs ↓ Document Loader ↓ Text Splitter ↓ Embedding Model ↓ Vector Store

这就是：

RAG 不是一个组件，而是一组组件组成的架构模式。

这是理解 LangChain Component Architecture 非常重要的一点。

十、第五层：Models

到了这里，才真正进入：

Model。

LangChain 中的 Model 不仅仅指聊天模型。

可以包括：

Chat Models LLMs Embedding Models

其中 Chat Model 主要负责：

Input ↓ Model ↓ AI Response

例如：

response=model.invoke("What is LangChain?")

但在实际 AI 应用中，Model 通常不会独立存在。

它会和：

Prompt Tools Retriever Structured Output Memory

一起工作。

十一、Model 是“智能能力”，但不是完整 Agent

这是一个非常重要的认知。

很多人看到：

LLM

就认为：

LLM = Agent。

其实完全不是。

可以把它们分成：

Model ↓ 产生下一步输出 Agent ↓ 决定下一步做什么 ↓ 调用 Tool ↓ 观察结果 ↓ 继续调用 Model ↓ 直到任务完成

因此：

Model 提供智能能力，Agent 负责利用这种能力完成任务。

这也正好和上一篇 Providers & Models 的内容连接起来。

十二、第六层：Tools

如果 Model 只能生成文字，那么它的能力其实非常有限。

例如用户问：

今天上海天气怎么样？

模型本身未必知道实时天气。

这时候需要：

Model ↓ Tool ↓ Weather API ↓ Result ↓ Model

Tool 本质上就是：

让 AI 可以访问外部世界的能力接口。

LangChain 官方把 Tools 定义为外部能力，例如：

API
Database
Web Search
Data Access
Computation

等。

十三、Tool 是 Agent 的“手”

可以用一个非常直观的比喻：

Model = 大脑 Tool = 手 Memory = 记忆 Agent = 协调这些能力完成任务的机制

例如：

用户 ↓ Agent ↓ Model ↓ 决定： “我需要搜索网页” ↓ Web Search Tool ↓ 返回结果 ↓ Model ↓ 继续推理

于是：

Agent │ ├── Model │ ├── Tools │ └── Memory

开始形成一个真正意义上的 AI Agent。

十四、第七层：Memory

Agent 还面临一个问题：

之前发生了什么？

例如：

User: 我叫张三。 Agent: 你好，张三。 User: 我刚才叫什么？

如果没有上下文保存：

Agent ↓ 不知道

因此需要：

Memory

官方把 Memory 归类为上下文保存机制，包括：

Message history
Custom state

用于：

Conversations
Stateful interactions

等场景。

十五、Memory 不等于“长期记忆”

这里需要特别注意。

在 AI 应用工程中：

Memory

是一个很大的概念。

可能包括：

Conversation History ↓ 短期上下文 State ↓ 任务执行状态 Long-term Memory ↓ 跨会话信息

所以不能简单理解成：

Memory = 聊天记录。

更准确的理解是：

Memory / State 负责让 AI 应用能够持续获得过去的信息和当前执行状态。

十六、第八层：Agents——真正的“编排层”

到了这里，前面的组件开始组合起来。

Agent 可以理解为：

一个能够根据当前状态进行决策，并调用模型和工具完成任务的编排机制。

官方把 Agents 放在Orchestration and reasoning这一层，典型用途包括非确定性工作流和决策。

整体结构可以理解为：

Agent │ ┌───────────┼───────────┐ │ │ │ Model Tools Memory │ │ │ └───────────┼───────────┘ │ State │ Result

十七、为什么 Agent 被称为 Orchestration？

因为 Agent 本身未必完成具体工作。

它主要负责：

协调不同组件。

例如：

用户： 帮我分析一下这家公司最近的市场情况。

Agent 可能执行：

1. 调用 Search Tool ↓ 2. 搜索公司资料 ↓ 3. 调用网页读取 Tool ↓ 4. 提取信息 ↓ 5. 调用 Model 分析 ↓ 6. 发现信息不足 ↓ 7. 再次搜索 ↓ 8. 综合结果 ↓ 9. 输出报告

所以 Agent 的核心价值不是：

“生成一段文字”

而是：

“决定下一步行动”

十八、这也是 Agent 与 Workflow 的重要区别

可以进一步理解：

Workflow

路径基本提前确定：

A ↓ B ↓ C ↓ D

例如：

用户输入 ↓ 分类 ↓ 检索 ↓ 生成 ↓ 输出

Agent

路径由模型根据当前情况决定：

Model / | \ / | \ Tool Tool Tool \ | / \ | / Model ↓ 下一步决策

所以：

Workflow 强调预先定义路径，Agent 强调运行时动态决策。

这也是为什么官方把 Agent 放在 Orchestration 层。

十九、把所有组件放到一起

现在可以重新看 LangChain 的整体架构：

User │ ▼ ┌───────┐ │ Agent │ └───┬───┘ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ Model Tools Memory │ │ │ │ ▼ │ │ APIs / DB / Web │ │ │ │ │ └──────────┬──────────────┘ │ ▼ Retriever │ ▼ Vector Store │ ▼ Embedding Model ▲ │ Document Processing ▲ │ PDF / Web / DB

这张图基本可以作为：

LangChain Component Architecture 的核心心智模型。

二十、组件之间不是简单的“上下级”

这里还有一个非常重要的架构理解：

LangChain 的组件不是简单的树状结构，而是可以自由组合的模块。

例如：

Model

可以单独使用：

User → Model

也可以：

User ↓ Prompt ↓ Model

也可以：

User ↓ Retriever ↓ Prompt ↓ Model

还可以：

User ↓ Agent ├── Model ├── Retriever ├── Search Tool ├── Database Tool └── Memory

因此：

组件是积木，而 Agent / RAG 是由这些积木组合出来的架构模式。

二十一、这也是 LangChain 的核心设计哲学

如果把 LangChain 的组件化思想抽象出来，可以得到：

Small Components ↓ Standard Interfaces ↓ Composition ↓ Application Patterns ↓ Complex AI Applications

也就是说：

小组件 → 标准接口 → 组合 → 应用。

而不是：

一个超级 AI 类 ↓ 什么都做

这种设计对于 AI 应用尤其重要，因为模型和基础设施变化非常快。

二十二、为什么“标准接口”如此重要？

例如 Model：

model.invoke()

Retriever：

retriever.invoke()

Tool：

tool.invoke()

不同组件虽然内部实现不同，但通过统一抽象，可以组合起来。

例如：

Retriever ↓ Prompt ↓ Model

甚至：

Tool ↓ Model ↓ Tool

这种组合能力是 LangChain 的核心价值之一。

二十三、Component Architecture 和 LCEL 有什么关系？

如果你之前学习过 LangChain，会遇到：

LCEL（LangChain Expression Language）

它的核心思想也是：

把 Runnable 组件组合起来。

例如：

chain=prompt|model|parser

可以理解为：

Prompt ↓ Model ↓ Parser

这其实就是 Component Architecture 的代码表达。

也就是说：

架构思想 ↓ 组件 ↓ 标准接口 ↓ 组合 ↓ LCEL

因此，学习组件架构以后再理解 LCEL，会容易很多。

二十四、但是现代 LangChain 不应该只理解为 LCEL

这一点非常重要。

早期 LangChain 的学习重点经常是：

Prompt ↓ LLM ↓ Parser ↓ Chain

然后通过 LCEL：

prompt|model|parser

组合。

而现在 LangChain 的重点已经越来越偏向：

Models Tools Agents Retrieval Memory

以及和 LangGraph 的协同。

官方当前文档也明确指出，LangChain 的 Agent 实现使用 LangGraph primitives；如果需要更深层次的控制，可以直接使用 LangGraph。

因此：

LCEL 更像“组件组合表达式”，Agent / LangGraph 则进一步解决复杂运行时编排问题。

二十五、LangChain 与 LangGraph 的关系

可以把两者理解成：

LangChain ↓ 提供 AI 应用组件 │ ├── Models ├── Tools ├── Retrievers ├── Prompts └── Agents │ ▼ LangGraph │ ├── State ├── Nodes ├── Edges ├── Persistence └── Human-in-the-loop

简单 Agent：

LangChain Agent

就可以快速完成。

复杂 Agent：

复杂状态 多步骤 循环 分支 人工介入 持久化

则可以进一步进入：

LangGraph

这也是当前 LangChain 体系值得掌握的整体关系。

二十六、一个完整 AI 应用到底需要多少组件？

并不是越多越好。

例如一个最简单的聊天应用：

User ↓ Model ↓ Response

只需要：

Model

一个 RAG：

User ↓ Retriever ↓ Model ↓ Response

背后增加：

Document Processing Embedding Vector Store

一个 Tool Agent：

User ↓ Agent ├── Model └── Tools

一个复杂 Agent：

User ↓ Agent ├── Model ├── Tools ├── Retriever ├── Memory ├── Subagents └── State

因此：

架构复杂度应该由任务决定，而不是由框架决定。

二十七、从工程角度看：不要为了 LangChain 而 LangChain

这是学习 LangChain 非常容易踩的坑。

例如一个简单的：

输入 ↓ Prompt ↓ LLM ↓ 输出

如果直接调用模型 SDK 就能很好解决，那么没必要为了“使用 LangChain”增加大量抽象。

真正需要 LangChain 的时候，通常是：

多个模型 + 多个工具 + Retriever + Structured Output + Agent + 复杂上下文

这时候组件化和统一接口的价值才会明显体现出来。

二十八、一个非常实用的架构思维

以后设计 AI 应用时，可以先问五个问题：

1. 我需要什么 Model？

推理？ 生成？ Embedding？

2. AI 需要什么外部能力？

Web？ 数据库？ 搜索？ 代码执行？ API？

对应：

Tools

3. AI 需要什么知识？

企业知识库？ PDF？ 网页？ 数据库？

对应：

Retrieval

4. AI 是否需要记住状态？

对应：

Memory / State

5. 下一步是否需要动态决策？

如果需要：

Agent

如果路径完全确定：

Workflow

这样设计 AI 应用，会比一上来问：

“我要不要用 LangChain？”

更加有效。

二十九、用一张表记住 LangChain Components

Component	核心问题	典型作用
Models	AI 如何思考/生成？	Chat、Reasoning、Embedding
Tools	AI 如何调用外部能力？	API、搜索、数据库
Document Processing	数据如何进入系统？	Loader、Splitter、Transformer
Embeddings	文本如何变成语义向量？	Semantic Representation
Vector Stores	向量放在哪里？	相似度搜索
Retrievers	如何找到相关信息？	RAG
Memory	如何保存上下文？	Conversation、State
Agents	如何决定下一步？	Dynamic Orchestration

这些正对应 LangChain 官方当前的主要组件分类。

三十、最终理解：LangChain 是一套“AI 应用积木”

如果只记住一句话，我建议记住：

LangChain 的核心不是某一个 Agent，也不是某一个 LLM，而是一套具有统一接口、可以自由组合的 AI 应用组件。

可以把整个体系浓缩成：

AI Application │ Agent │ ┌──────────────┼──────────────┐ │ │ │ Model Tools Memory │ │ │ └──────────────┼──────────────┘ │ Retrieval │ Vector Store │ Embeddings │ Document Processing │ Raw Data

而这些组件通过统一接口进行组合：

Components ↓ Interfaces ↓ Composition ↓ RAG / Agent / Workflow ↓ AI Application

这就是LangChain Component Architecture最核心的思想。

三十一、从 Component Architecture 进一步理解 Agent

如果把你前面学习的内容串起来：

Providers & Models ↓ “AI 大脑从哪里来？” ↓ Component Architecture ↓ “AI 应用由哪些积木组成？” ↓ Tools / Retrieval / Memory ↓ “AI 能做什么？” ↓ Agent ↓ “AI 如何决定下一步？” ↓ LangGraph ↓ “如何控制复杂 Agent 的状态和执行过程？”

所以你的 LangChain 学习路线其实可以形成一条非常清晰的主线：

Model ↓ Components ↓ Runnable / Composition ↓ Tools ↓ Agent Loop ↓ LangGraph ↓ Deep Agents

这比单独记忆几十个 LangChain API 更重要。

真正需要掌握的不是“LangChain 有哪些类”，而是：

如何把 Model、Tool、Knowledge、Memory 和 Orchestration 组合成一个可靠的 AI 应用。