一、引言
大语言模型正在改变应用开发的方式,但很多开发者真正面对的问题并不是"模型不够强",而是:如何把模型、数据、工具、记忆和业务流程可靠地连接起来。 如果只是简单调用一次模型,它往往只能输出一段文本;而一旦我们希望它读取本地文档、查询数据库、记住多轮对话、调用外部 API,甚至完成更复杂的自动化任务,开发复杂度就会迅速上升。
LangChain 正是为了解决这类问题而出现的开发框架。它通过模块化设计,把模型调用、提示词模板、记忆管理、检索增强、工具调用和工作流编排等能力抽象成可复用的组件,让开发者能够像搭积木一样构建 AI 应用。 从最早的链式调用,到如今更强调状态管理、图工作流和智能体编排,LangChain 生态已经逐步从"胶水框架"演进为面向生产级应用的基础设施。
二、为什么要使用 LangChain
LangChain 的出现背景,可以理解为:大模型 API 已经足够强,但要把模型真正接入业务系统,还缺很多"工程化中间层"。直接调用一次模型很容易,可一旦涉及多轮对话、私有数据、外部工具、复杂流程和质量评估,开发成本就会快速上升。
| 开发痛点 | 具体表现 | LangChain 解决方式 |
|---|---|---|
| 模型接口不统一 | OpenAI、Claude、本地模型、国产模型接口差异大,换模型要改很多代码 | 提供统一模型接口,切换模型成本更低 |
| 上下文与记忆管理复杂 | LLM 本身无状态,多轮对话需要自己维护历史、截断、拼接 | 内置 Memory 组件,管理对话历史和上下文 |
| 私有数据接入困难 | 模型无法直接访问企业文档、数据库、内部系统 | 通过 Retrieval / RAG 连接文档和向量数据库 |
| 复杂流程难编排 | 搜索、总结、生成报告等任务需要多步协作 | 用 Chain、图工作流或 Agent 编排多步骤流程 |
| 工具调用成本高 | 调用搜索、数据库、API、代码执行等需要大量胶水代码 | 提供 Tools 和 Agent 能力,降低工具集成门槛 |
| 调试与观测不足 | 链式调用、Agent 决策过程不透明,问题难排查 | 配合 LangSmith 等工具进行日志、追踪和评估 |
从机制层面看,它解决的是几类关键问题
-
状态管理问题
大模型 API 通常是无状态的,每次请求都是独立的。LangChain 通过记忆组件把对话历史、检索上下文、中间结果管理起来,让应用具备"上下文感知"能力。
-
数据连接问题
模型训练数据有截止时间,也无法直接访问私有系统。LangChain 把文档加载、文本分块、向量化、检索、重排等环节抽象成组件,方便搭建 RAG 系统。
-
流程编排问题
很多真实任务不能靠一次模型调用完成,比如"检索资料 → 生成草稿 → 校验事实 → 输出报告"。LangChain 把这些步骤组织成链或图,使流程更清晰、可维护。
-
工具与外部系统集成问题
要让模型真正"做事",需要调用数据库、搜索、API、代码执行器等。LangChain 提供了工具调用和 Agent 决策机制,让模型可以根据目标选择下一步动作。
-
工程可观测与迭代问题
大模型应用不是写完就结束,还需要看每次调用用了哪些上下文、工具、提示词,以及回答质量如何。LangChain 生态提供了调试、评估和监控能力,帮助持续优化。
是否一定要用 LangChain?
不一定。如果只是简单问答、单次模型调用,直接调用 API 就够了。但如果你要做 RAG 知识库、多轮对话机器人、Agent 工作流、企业数据接入、多模型切换,LangChain 能明显减少重复代码,把常见模式沉淀成可复用组件。
放在你的博客里,可以这样概括一句:
LangChain 并不是让模型"更聪明",而是让开发者更容易把模型、数据、工具和业务流程可靠地连接起来。它解决的是大模型应用从"能跑起来"到"可维护、可扩展、可落地"的工程化问题。
三、工作原理
LangChain 并不是一个"更聪明的大模型",而是一套 LLM 应用编排框架。它把模型、提示词、记忆、检索、工具和执行流程拆成独立模块,再通过链、图或智能体把它们组合起来。
从工作机制上看,LangChain 的运转可以分成三层:模型 I/O 层、数据连接层和编排控制层。
1. 模型 I/O:统一调用模型
LangChain 首先抽象了不同大模型的调用方式。无论是 OpenAI、Claude、本地模型,还是其他兼容接口,都可以通过统一的方式接入。
一个典型的模型调用流程是:
- Prompt Template 把用户输入、系统指令、检索结果等拼成完整提示;
- LLM / Chat Model 接收提示并生成原始文本;
- Output Parser 把模型输出解析成结构化结果,比如 JSON、列表或自定义对象。
这一步解决的是"如何稳定地让模型接收输入并返回可用输出"的问题。
2. 数据连接:把外部知识接入模型
大模型本身不知道你的私有文档、内部数据库或实时信息。LangChain 通过检索增强生成(RAG)来补充这部分能力。
典型流程是:
- Document Loader 加载 PDF、网页、数据库记录或本地文件;
- Text Splitter 把长文档切分成适合模型处理的片段;
- Embedding Model 将文本片段转换成向量;
- Vector Store 存储向量,并提供相似度检索;
- Retriever 在用户提问时召回最相关的上下文,再注入到提示词中。
这样,模型回答就不再只依赖训练数据,而是可以基于你提供的外部知识生成结果。
3. 记忆管理:让应用拥有上下文
LLM 默认是无状态的,每次请求都是独立的。LangChain 通过 Memory 组件维护状态,使应用能记住之前的对话或中间结果。
常见方式包括:
- Buffer Memory:保存最近几轮对话历史;
- Summary Memory:对长对话进行摘要,减少上下文长度;
- Vector Store Memory:把历史对话向量化,按需检索相关片段。
这些记忆会在下一次调用模型前被注入到提示词中,从而让模型具备上下文感知能力。
4. 链与图:把多步任务串起来
Chain 是 LangChain 中非常核心的概念。它把多个组件按顺序连接起来,让前一步的输出成为下一步的输入。
比如一个知识库问答链可能是:
用户问题 → 检索相关文档 → 拼接提示词 → 调用模型 → 解析输出
更复杂的工作流还可以使用 LCEL 声明式管道,或者用 LangGraph 构建有状态图,实现条件分支、并行执行、循环和错误恢复。
5. 工具与 Agent:让模型能"执行动作"
如果只需要固定流程,使用 Chain 就够了;但如果任务路径不固定,比如需要先搜索、再查数据库、最后生成报告,就可以使用 Agent。
Agent 的运行循环通常是:
- 模型根据用户目标决定下一步行动;
- 调用某个工具,比如搜索、数据库查询、API 请求或代码执行;
- 观察工具返回结果;
- 继续规划下一步,直到得到最终答案。
这里,模型充当的是"推理引擎",而工具提供真实世界的能力。LangChain 负责把模型决策、工具调用和状态管理串成一个闭环。
6. 可观测与调试
实际开发中,Agent 或 RAG 链路出问题往往不容易排查。LangChain 通过回调机制和 LangSmith 等工具,可以记录提示词、模型调用、检索结果、工具执行和响应时间,从而支持调试、评估和持续优化。
一句话总结
LangChain 的工作机制可以概括为:用标准化接口接入模型,用检索连接外部数据,用记忆维护状态,用链和图编排流程,用 Agent 和工具扩展执行能力。 它把"调用一次模型"升级成"构建一个可感知、可规划、可执行、可观测的 AI 应用"。
四、LangChain 应用场景有哪些?
LangChain 的应用场景主要集中在五类:基于私有数据的 RAG 知识库问答、带记忆和多轮上下文的智能客服、能调用工具和业务系统的 Agent 自动化流程、文档摘要与信息抽取等文本处理任务,以及面向金融、法律、医疗等行业的垂直应用。它的价值不是替代大模型,而是把模型、数据、工具和业务流程连接起来,让大模型真正进入实际业务。
1. 企业/个人知识库问答(RAG)
这是 LangChain 最典型的应用场景。通过加载 PDF、Word、网页、数据库记录等文档,切分、向量化后存入向量数据库,用户提问时先检索相关片段,再交给大模型生成回答。
典型场景包括:
- 企业内部制度、产品手册、技术文档问答
- 客服知识库检索
- 法律、医疗、金融等专业领域问答
- 个人笔记、博客、论文资料检索
RAG 的价值在于让模型回答"有据可依",减少幻觉,同时可以持续更新知识,而不必重新训练模型。
2. 智能客服与多轮对话助手
LangChain 可以通过记忆组件管理对话历史,让助手理解"上一句在说什么",并结合知识库、数据库或业务 API 回答用户问题。
适合用于:
- 电商客服:订单查询、退换货政策、物流状态
- SaaS 产品助手:功能咨询、使用引导、故障排查
- 内部办公助手:HR 政策、报销流程、IT 支持
- 多轮问答机器人:支持追问、指代消解和上下文延续
3. 大模型智能体(Agent)与自动化流程
当任务不是简单问答,而是需要多步骤执行时,就可以用 Agent。LangChain 能让模型根据目标选择工具、调用 API、读取数据库、执行代码,再根据结果继续决策。
常见应用包括:
- 自动化办公:整理会议纪要、生成周报、安排日程
- 业务流程自动化:贷款审批、采购对账、退款处理
- 运维自动化:告警聚合、根因分析、执行修复脚本
- 数据分析助手:自然语言生成 SQL、查询数据、生成报告
4. 文本处理、内容创作与代码助手
LangChain 也很适合处理结构化文本任务。它可以把长文档总结成摘要,从文本里抽取实体、关键词,或者按固定格式输出结果。
典型场景:
- 文档摘要:会议记录、研报、新闻、论文总结
- 信息抽取:从投诉、工单、简历中提取结构化字段
- 内容创作:营销文案、短视频脚本、邮件草稿
- 代码助手:API 文档查询、代码生成、调试建议、测试用例生成
5. 垂直行业与多模态应用
在医疗、法律、金融、制造等行业,LangChain 可以结合私有数据、行业规则和外部工具,构建更专业的应用。
例如:
- 医疗:病历摘要、诊疗指南检索、患者问答
- 法律:合同审查、法规检索、案例匹配
- 金融:财报分析、风险预警、投研报告生成
- 制造:质量检测报告分析、设备告警处理
- 多模态:PDF 图文解析、会议录音转写、视频字幕与摘要
五、RAG 知识库实战
RAG 的核心思路是:先把私有文档切分成小块,再向量化存入知识库;用户提问时,先从知识库检索相关片段,最后把片段和问题一起交给大模型生成答案。 LangChain 很适合用来搭建这类系统,因为它把文档加载、文本切分、向量化、向量存储、检索和模型调用都封装成了可组合的组件。
1. 安装依赖
bash
pip install langchain langchain-openai langchain-community faiss-cpu pypdf
如果你使用的是 OpenAI 兼容接口,需要配置环境变量:
bash
export OPENAI_API_KEY="your-api-key"
2. 文件切分
文件切分的目的是把长文档拆成适合检索和放入上下文窗口的小片段。LangChain 中最常用的是 RecursiveCharacterTextSplitter,它会优先按段落、换行、句子等自然边界切分,并在相邻片段之间保留一定重叠,避免信息被截断。
python
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
# 1. 加载 PDF
loader = PyPDFLoader("knowledge.pdf")
documents = loader.load()
# 2. 文本切分
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=800, # 每个片段长度
chunk_overlap=150, # 片段之间重叠,避免边界信息丢失
)
chunks = text_splitter.split_documents(documents)
print(f"共切分为 {len(chunks)} 个片段")
print(chunks[0].page_content)
print(chunks[0].metadata)
chunk_size 和 chunk_overlap 会影响检索效果:
chunk_size太小,片段可能信息不完整;chunk_size太大,可能混入过多无关内容;chunk_overlap能缓解切分边界处的语义断裂。
3. 构建向量知识库
切分完成后,需要把每个文本片段转换成向量,并存入向量数据库。这里使用 FAISS 作为本地向量存储。
python
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(
documents=chunks,
embedding=embeddings,
)
如果你想持久化知识库,可以保存并重新加载:
python
vectorstore.save_local("faiss_index")
# 下次直接加载
vectorstore = FAISS.load_local(
"faiss_index",
embeddings,
allow_dangerous_deserialization=True,
)
4. 知识库检索
有了向量知识库后,就可以把它转成检索器。用户提问时,检索器会返回最相关的文档片段。
python
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})
query = "LangChain 适合哪些应用场景?"
docs = retriever.invoke(query)
for i, doc in enumerate(docs, 1):
print(f"片段 {i}:")
print(doc.page_content)
print("来源:", doc.metadata)
print("-" * 40)
5. 构建 RAG 问答链
检索只是第一步,最终还需要把检索结果注入提示词,让大模型基于资料回答问题。这里使用 LangChain 的 LCEL 方式组装一条 RAG 链。
python
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
llm = ChatOpenAI(model="gpt-4o", temperature=0)
prompt = ChatPromptTemplate.from_messages([
("system", "你是一个知识库助手。请仅根据以下资料回答问题。"
"如果资料中没有相关信息,请明确说明无法回答。\n\n"
"资料:\n{context}"),
("human", "{question}"),
])
def format_docs(docs):
return "\n\n".join(doc.page_content for doc in docs)
rag_chain = (
{"context": retriever | format_docs, "question": lambda x: x["question"]}
| prompt
| llm
| StrOutputParser()
)
result = rag_chain.invoke({
"question": "LangChain 的主要作用是什么?"
})
print(result)
6. 完整流程小结
这条 RAG 链的执行顺序是:
- 用户输入问题;
- 检索器从向量知识库中召回相关片段;
format_docs把片段拼接成上下文字符串;- 提示词模板把上下文和问题组装成完整提示;
- 大模型基于上下文生成答案;
- 输出解析器返回最终文本。
如果你要把它写进博客,可以重点强调:RAG 不是让模型"记住"所有知识,而是让模型在回答时先查资料。 这也是它比单纯调用大模型更适合企业知识库、产品文档问答、内部制度查询等场景的原因。
六、常见配置
env
# =====================
# 模型 API 密钥
# =====================
# OpenAI API 密钥(用于调用 GPT 系列模型)
OPENAI_API_KEY=sk-your-openai-key
# OpenAI 接口地址(默认官方地址,使用代理或兼容接口时可修改)
OPENAI_BASE_URL=https://api.openai.com/v1
# DeepSeek API 密钥(用于调用 DeepSeek 模型)
DEEPSEEK_API_KEY=sk-your-deepseek-key
# DeepSeek 接口地址(默认官方地址)
DEEPSEEK_BASE_URL=https://api.deepseek.com/v1
# 通义千问 / 阿里云百炼 API 密钥(用于调用 Qwen 系列模型)
DASHSCOPE_API_KEY=your-dashscope-key
# 阿里云百炼兼容模式接口地址
ALIYUN_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
# 智谱 GLM API 密钥(用于调用 ChatGLM 系列模型)
ZHIPUAI_API_KEY=your-zhipu-key
# 智谱 GLM 接口地址
ZHIPUAI_BASE_URL=https://open.bigmodel.cn/api/paas/v4
# =====================
# 模型参数
# =====================
# 默认使用的模型名称(根据实际 API 提供商修改)
LLM_MODEL=gpt-4o
# 模型温度,取值范围 0~1,越低输出越稳定,越高越随机
LLM_TEMPERATURE=0.2
# 模型单次请求最大生成 Token 数
LLM_MAX_TOKENS=2048
# 模型请求超时时间(秒)
LLM_REQUEST_TIMEOUT=30
# =====================
# 数据库 / 向量库
# =====================
# 关系型数据库连接地址(如 PostgreSQL、MySQL)
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
# Chroma 向量数据库持久化存储路径
CHROMA_PERSIST_DIR=./chroma_db
# FAISS 向量索引存储路径
FAISS_INDEX_DIR=./faiss_index
# Milvus 向量数据库连接地址
MILVUS_URI=http://localhost:19530
# Qdrant 向量数据库连接地址
QDRANT_URL=http://localhost:6333
# Qdrant 向量数据库 API 密钥(如未开启鉴权可留空)
QDRANT_API_KEY=
# =====================
# RAG 相关
# =====================
# 嵌入模型名称(用于将文本转换为向量)
EMBEDDING_MODEL=text-embedding-3-small
# RAG 文本切分大小,每个片段的字符数
RAG_CHUNK_SIZE=800
# RAG 文本切分重叠大小,相邻片段之间的重叠字符数,避免边界信息丢失
RAG_CHUNK_OVERLAP=150
# RAG 检索时返回的最相关片段数量
RAG_TOP_K=3
# =====================
# Agent / 工具
# =====================
# SerpAPI 密钥(用于 Google 搜索工具)
SERPAPI_API_KEY=your-serpapi-key
# Tavily API 密钥(用于 Tavily 搜索工具,适合 Agent 使用)
TAVILY_API_KEY=your-tavily-key
# 默认搜索引擎,可选 serpapi 或 tavily
SEARCH_ENGINE=serpapi
# =====================
# 应用通用配置
# =====================
# 应用运行环境,可选 development / production
APP_ENV=development
# 应用服务端口
APP_PORT=8000
# 日志级别,可选 DEBUG / INFO / WARNING / ERROR / CRITICAL
LOG_LEVEL=INFO
# 是否启用 LangSmith 链路追踪(用于调试和观测)
LANGCHAIN_TRACING_V2=false
# LangSmith API 密钥(启用追踪时必填)
LANGCHAIN_API_KEY=
# LangSmith 项目名称
LANGCHAIN_PROJECT=langchain-demo
七、竞品分析
| 框架 / 平台 | 定位 | 优势 | 局限 | 适合场景 |
|---|---|---|---|---|
| LangChain | LLM 应用编排框架 | 生态丰富、组件多、支持 RAG / Agent / 工具调用 / 工作流 | 概念较多,新手上手成本略高 | 通用 LLM 应用、RAG、Agent、复杂工作流 |
| LlamaIndex | 数据索引与检索框架 | 对 RAG、数据连接、索引策略支持更强 | Agent 和通用编排能力相对弱一些 | 文档问答、知识库、复杂检索增强 |
| Semantic Kernel | 微软推出的 LLM 编排 SDK | 与 .NET / Azure OpenAI 生态结合紧密 | Python 社区生态不如 LangChain | .NET 应用、Azure OpenAI 项目 |
| Haystack | 开源 NLP / RAG 框架 | RAG 管道清晰,适合搜索和问答系统 | Agent 和通用工作流能力较弱 | 企业搜索、文档问答、信息抽取 |
| Dify | 低代码 AI 应用平台 | 可视化编排、部署快、适合快速搭建应用 | 自定义代码能力不如 SDK 灵活 | 快速原型、内部工具、低代码 AI 应用 |
| Flowise | 可视化 LangChain 编排工具 | 拖拽式搭建链和工作流,学习成本低 | 复杂业务逻辑仍需代码扩展 | 快速演示、教学、简单工作流编排 |
八、总结
LangChain 已经从早期的"模型调用胶水层"演进为 LangChain + LangGraph + LangSmith 的三层体系:LangChain 负责模型、工具、检索和提示词集成,LangGraph 负责有状态工作流和 Agent 编排,LangSmith 负责追踪、评估与生产观测。
它的真正价值不在于封装了多少组件,而在于提供了一套构建 AI 应用的工程语言:模型负责推理,检索提供知识,工具承担执行,图管理流程,观测支撑迭代。 简单场景不必强行上复杂编排,一次问答或固定流程 RAG 用轻量调用更合适;复杂场景里,它的优势才真正显现,尤其是需要分支、循环、状态持久化、人工介入和多智能体协作的生产级应用。
作者: 王新焱
博客: https://blog.csdn.net/qq_34402069
时间: 2026年10月19日