LangChain 核心组件详解：概念、功能、相互关系与实战场景
2026-03-17

本文在「组件是什么」的基础上，进一步拆解每个组件的职责边界、彼此如何衔接、数据流如何流动，并逐一对智能问答、文档摘要、多步骤推理 Agent、RAG、自动化工作流五大场景，说明各组件的具体用法与价值。

一、总体架构：六类组件如何咬合

LangChain 不是一个「模型包装器」，而是一套分层、可组合的应用骨架。六个核心模块按职责解耦，又通过统一接口（Runnable）彼此串联：

1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────┐
│  应用入口 / 编排层                                            │
│   Chains(LCEL)  ←→  Agents(决策)  ←→  Memory(状态)          │
├─────────────────────────────────────────────────────────────┤
│  能力供给层                                                  │
│   Models + Prompts + OutputParsers   (Model I/O)             │
│   Indexes: Loader→Splitter→Embedding→VectorStore→Retriever  │
│   Tools / Toolkits          (Agent 可调用的外部能力)         │
├─────────────────────────────────────────────────────────────┤
│  横切关注层                                                  │
│   Callbacks  (日志/追踪/流式/监控，贯穿以上所有)             │
└─────────────────────────────────────────────────────────────┘

关键设计原则：所有组件都实现统一的 Runnable 协议，因此可以用管道符 | 任意组合，且自动获得流式输出、异步、批处理、可观测四大能力。

二、核心组件分类详解

组件类别 1：Model I/O（模型输入输出层）

这是与 LLM 交互的最底层，三个子组件各司其职：

子组件 职责 典型实现
Models 统一封装各类模型，屏蔽厂商差异 ChatOpenAI、ChatAnthropic、Ollama、HuggingFacePipeline
Prompts 管理可复用、可参数化的提示词模板 PromptTemplate、ChatPromptTemplate、FewShotPromptTemplate
Output Parsers 把模型自由文本转成结构化对象 StrOutputParser、PydanticOutputParser、JsonOutputParser

相互关系：Prompt 填入变量 → 产出标准化提示 → Model 生成文本 → Output Parser 解析成程序可用结构。三者通常组合成一条最基础的链。

价值：把「硬编码提示词 + 手写解析」变成声明式配置，换模型、调提示、改输出格式时互不干扰。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import PydanticOutputParser
from pydantic import BaseModel, Field

class Person(BaseModel):
    name: str = Field(description="姓名")
    age: int = Field(description="年龄")

parser = PydanticOutputParser(pydantic_object=Person)
prompt = ChatPromptTemplate.from_template(
    "从文本抽取人物信息：\n{text}\n{format_instructions}"
)
chain = prompt.partial(format_instructions=parser.get_format_instructions()) | ChatOpenAI() | parser
print(chain.invoke({"text": "张三今年28岁"}))
# -> Person(name='张三', age=28)

组件类别 2：Chains（链 / 流程编排层）

链 = 把多个 Runnable 按顺序或条件组合的执行管道。

  • LLMChain（基础）：Prompt | Model | Parser。
  • SequentialChain（顺序）：多个子链串成一条流水线。
  • RouterChain（路由）：根据输入特征动态分发给不同子链。
  • LCEL（现代写法）：用 | 组合，推荐默认方案。

相互关系：链是「粘合剂」，把 Model I/O、Memory、Retriever、Agent 等全部串起来。一个复杂应用本质上就是一条精心编排的链。

价值：让多步骤逻辑可复用、可测试、可组合；LCEL 还能自动优化执行（并行分支、流式透传）。

1
2
3
4
5
6
7
from langchain_core.runnables import RunnableParallel, RunnablePassthrough

# 并行分支：同时做「摘要」和「关键词提取」
summary_chain = ChatPromptTemplate.from_template("摘要：{doc}") | lm
keyword_chain = ChatPromptTemplate.from_template("提取关键词：{doc}") | lm
parallel = RunnableParallel(summary=summary_chain, keywords=keyword_chain)
print(parallel.invoke({"doc": "一段很长的文本..."}))

组件类别 3：Memory（记忆层）

职责：在多次交互之间维持上下文状态，让应用「记得」之前的对话或中间结果。

类型 策略 适用
ConversationBufferMemory 全量保存历史 短对话、调试
ConversationBufferWindowMemory 仅保留最近 N 轮 长对话省 token
ConversationSummaryMemory 用模型把历史压缩成摘要 超长对话
VectorStoreRetrieverMemory 历史向量化后检索相关片段 长期记忆

相互关系：Memory 通常作为链的输入来源（把历史拼进 Prompt）或输出落点（把新对话写回）。在 Agent 中，Memory 是「连续任务」的前提。

价值：没有 Memory，模型每一次调用都是「失忆」的；Memory 让应用具备连续性与个性化。

组件类别 4：Indexes / Retrieval（索引与检索层 = RAG 引擎）

让模型能「读取」私有/外部数据，是 RAG 的核心。五个环节构成完整数据管线：

  1. Document Loaders（加载器）：从 PDF、Word、网页、数据库、Notion 等读取原始文档。
  2. Text Splitters（切分器）：按字符/递归/按语义把长文档切成 chunk（兼顾上下文与向量化上限）。
  3. Embeddings（嵌入模型）：将文本映射为高维向量。
  4. Vector Stores（向量库）：存储向量并支持相似度检索，如 FAISS、Chroma、Milvus、pgvector。
  5. Retrievers（检索器）：给定 query 返回 top-k 最相关 chunk，可叠加重排（rerank）。

相互关系：Loaders → Splitters → Embeddings → VectorStore 是「离线建库」阶段；Retriever 是「在线查询」阶段，其输出作为 Prompt 的上下文喂给 Model。

价值：突破模型训练数据的时间/私有性边界，让回答基于「你的数据」并附带引用溯源。

1
2
3
4
5
6
7
8
9
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings

docs = PyPDFLoader("manual.pdf").load()
chunks = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50).split_documents(docs)
vectorstore = FAISS.from_documents(chunks, OpenAIEmbeddings())
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

组件类别 5：Agents & Tools（智能体与工具层）

职责：当任务无法用「写死的链」完成（步骤未知、需外部信息/动作）时，由模型作为决策大脑，自主选择并调用工具。

  • Tools（工具）：任意 Python 函数，经 @tool 装饰后暴露名称、描述、参数 schema 给模型。
  • Agent（代理）：基于 ReAct / Function Calling 策略，循环执行「思考 → 选工具 → 调用 → 观察结果 → 再思考」，直到给出最终答案。
  • Toolkits（工具包）：预置工具集合，如 SQL、CSV、Search、Shell、PubMed 等。

相互关系：Agent 是 Chains 的「动态升级版」——链是固定的执行图，Agent 是由模型在运行时动态编排的执行图。Tools 是 Agent 的「手脚」，Memory 是 Agent 的「记忆」。

价值：把应用从「预设流程」升级为「自主解决问题」，能处理开放式、多分支、需要实时数据的任务。

1
2
3
4
5
6
7
8
9
10
11
12
from langchain_core.tools import tool
from langchain.agents import create_tool_calling_agent, AgentExecutor

@tool
def calculator(expr: str) -> str:
    """计算数学表达式，如 '3*7+2'"""
    return str(eval(expr))

tools = [calculator]
agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
executor.invoke({"input": "帮我算 (12+8)*5 是多少？"})

组件类别 6：Callbacks（回调 / 横切层）

职责：在不侵入业务代码的前提下，在链/Agent 运行的关键节点（开始、结束、token、错误）插入钩子。

  • 用途：日志收集、性能监控（LangSmith）、流式 token 推送、成本统计、调试追踪。
  • 典型实现：ConsoleCallbackHandler、LangChainTracer、自定义 BaseCallbackHandler。

相互关系：Callbacks 是「横切」于所有其他组件的观察层，任何 Runnable 执行时都能挂上回调而不改主逻辑。

价值：生产环境可观测性的基石——没有它，线上一次失败你连「模型调了几次、哪一步吞了异常」都无从得知。

三、组件相互关系总览（数据流视角）

一次典型「带检索的 Agent 对话」的数据流：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
用户输入
  │
  ├─ Memory ────────► 取出历史上下文
  │
  ▼
Agent(决策)
  ├─ 需要外部知识？─► Retriever(Indexes) 检索私有文档 ─► 拼入 Prompt
  ├─ 需要计算/查库？─► Tools 执行 ─► 结果回灌
  │
  ▼
Prompt 组装 (含历史 + 检索内容 + 工具结果)
  │
  ▼
Model 生成
  │
  ▼
Output Parser 解析为结构化结果 / 文本
  │
  ├─► 写回 Memory（供下一轮使用）
  └─► Callbacks 记录全程日志

一句话：Chains/Agent 是骨架，Model I/O 是肌肉，Indexes 是知识，Memory 是记忆，Tools 是手脚，Callbacks 是神经监测。

四、五大实战场景：组件用法与价值

场景 A：智能问答系统（Q&A Bot）

目标：回答用户关于某领域（产品、政策、内部制度）的提问。

组件组合：Memory（多轮）+ Indexes/Retriever（知识）+ Model I/O（作答）+ Callbacks（监控）。

具体用法与价值：

  • 用 Retriever 从知识库召回相关片段，避免模型「编造」（幻觉），提升准确率。
  • Memory 让追问（”那它的价格呢？”）能关联到上文主题。
  • Callbacks 统计高频问题，反哺知识库补全。
1
2
3
4
5
qa_chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | ChatPromptTemplate.from_template("基于以下资料回答问题：\n{context}\n问题：{question}")
    | llm | StrOutputParser()
)

场景 B：文档摘要生成（Summarization）

目标：把长篇文档（报告、论文、会议记录）压缩为要点摘要，或按角色生成不同版本。

组件组合：Indexes（Loaders/Splitters，处理超长文档）+ Chains（Map-Reduce 摘要）+ Output Parsers（结构化输出）。

具体用法与价值：

  • 超长文档超出上下文窗口时，用 Text Splitter 切块，先 Map 逐块摘要，再 Reduce 合并——解决「文档太长塞不进模型」的硬限制。
  • 可并行生成「一句话版 / 三段版 / 中英双语版」多份摘要（配合 RunnableParallel）。
1
2
from langchain.chains import MapReduceDocumentsChain, ReduceDocumentsChain
# map_step 逐块摘要 -> combine_step 合并，适合百页文档

场景 C：多步骤推理 Agent（Multi-step Reasoning Agent）

目标：完成开放式、步骤不可预知的复杂任务，如”查上个月销售额最高的产品，并生成对比图表说明”。

组件组合：Agents + Tools（SQL/Python/Search）+ Memory + Callbacks。

具体用法与价值：

  • 模型自主决定：先查数据库（SQL Tool）→ 再画图表（Python Tool）→ 最后写说明（LLM），中间可反复迭代。
  • 相比写死链，Agent 能应对”用户临时改需求””某步骤失败需换路径”等不确定性。
  • 务必设置边界：max_iterations、工具白名单、超时，防止失控循环烧 token。

场景 D：数据检索增强生成 RAG

目标：让模型基于企业私有/实时数据作答，且可溯源。

组件组合：完整 Indexes 管线（Loader→Splitter→Embedding→VectorStore→Retriever）+ Model I/O + Memory（可选长期记忆）。

具体用法与价值：

  • 突破训练数据时限与私有性，回答”我们公司 Q2 退款政策是什么”。
  • 检索质量决定上限：切分粒度（chunk 大小/重叠）、Embedding 选型、重排 rerank 比换大模型更影响效果。
  • 可返回引用来源（文档名+页码），增强可信度与可审计性。
1
2
建库：Loader → Splitter → Embedding → VectorStore
查询：Query → Retriever(top-k) → 拼 Prompt → LLM → 带引用的答案

场景 E：自动化工作流编排（Workflow Orchestration）

目标：把”抓取→清洗→分析→生成报告→推送”等多环节自动化，如每日竞品监控简报。

组件组合：Chains（串联固定步骤）+ Agents（处理异常/动态分支）+ Tools（API/爬虫/邮件）+ Callbacks（流程日志与告警）。

具体用法与价值：

  • 固定步骤用 SequentialChain/LCEL 保证稳定可复现；偶发的不确定步骤交 Agent 兜底。
  • Callbacks 在每一步记录耗时与状态，失败自动告警，相当于给工作流装了”黑匣子”。
  • 整体从”人肉跑脚本”升级为”声明式、可观测、可重试”的自动化管线。

五、场景—组件对照表

场景 必用组件 可选增强 核心价值
智能问答 Retriever + Model I/O Memory、Callbacks 降幻觉、可多轮
文档摘要 Loaders/Splitters + Chains Map-Reduce、Parallel 突破上下文长度
多步推理 Agent Agent + Tools Memory、Callbacks 应对不确定性
RAG 完整 Indexes + Model I/O Rerank、引用 私有/实时知识
工作流编排 Chains + Tools Agent、Callbacks 自动化+可观测

六、最佳实践与总结

  1. 优先 LCEL：新项目一律用 Runnable 管道，旧版 LLMChain 逐步淘汰。
  2. RAG 重检索轻模型：80% 的效果问题出在切分/召回，调参顺序优先于换模型。
  3. Agent 设边界：max_iterations、工具白名单、超时、成本预算，缺一不可。
  4. 可观测先行：接入 LangSmith 或自建 Callbacks，否则线上问题等于盲飞。
  5. 避免 over-engineering：单轮问答一条链足矣，别一上来就上 Agent。
  6. Memory 选型看长度：短对话用 Buffer，长对话用 Summary 或 Window。

本质总结：LangChain 用「分层解耦 + 统一 Runnable 接口」，把 AI 应用拆成可替换、可组合的积木。Models 给智能，Prompts 给指令，Parsers 给结构，Chains 给流程，Memory 给连续，Indexes 给知识，Agents 给行动，Callbacks 给眼睛——理解每块职责与衔接点，才能在大而全的文档之外，真正搭出稳健的生产级系统。