LangChain 是什么?AI 应用开发框架入门

LangChain 是什么?AI 应用开发框架入门

如果你最近关注 AI 应用开发,大概率听说过 LangChain。

GitHub 超过 10 万 Star,PyPI 月下载量突破 3000 万次,Stack Overflow 上相关问答超过 5 万条(数据来源:GitHub、PyPI、Stack Overflow,截至 2026 年 6 月)。这组数字说明了一件事:LangChain 已经成为构建 AI 应用的事实标准之一。

但问题是,很多人对 LangChain 的理解停留在"一个调 AI 模型的工具"。这个说法不算错,但远远不够。LangChain 真正解决的是另一层问题——怎么把大模型从一个聊天机器人变成一个能干活的系统

一、一句话说清楚 LangChain 是什么

LangChain 是一个用于构建大模型应用的开发框架,它把"调模型"变成"搭系统"。

打个比方:如果大模型是一台发动机,那 LangChain 就是一套标准化的底盘、变速箱和传动系统。发动机再强,没有这些组件也跑不起来。LangChain 不提供 AI 能力本身,它提供的是把 AI 能力和其他组件拼接起来的基础设施。

就像 React 标准化了前端开发的方式,LangChain 正在标准化 AI 应用开发的方式。

二、为什么需要 LangChain

直接用 OpenAI 的 API 调用大模型,几行代码就能跑起来。那为什么还要套一个框架?

我自己刚开始用 GPT API 的时候,觉得直接调用就够了。直到我想让 AI 读一篇 PDF 然后回答问题,事情立刻变得复杂了。我得自己写 PDF 解析、文本切分、向量存储、相似度检索、把检索结果拼回提示词里,再调 API。一套下来,真正的 AI 调用只占代码量的 20%,剩下 80% 全是胶水代码。

这种"80% 胶水代码"的问题在 AI 应用开发中非常普遍。具体来说,开发者面临的痛点包括:

  • 数据接入繁琐:想让 AI 回答不在训练数据里的问题,得自己搭建整套 RAG 管线
  • 多步骤编排困难:一个任务需要多次调用模型加上中间处理,代码很快变成意大利面条
  • 模型绑定严重:直接调用 OpenAI API 的代码和模型深度绑定,换模型成本极高
  • 缺乏调试工具:提示词调不好的时候,根本不知道模型在每一步返回了什么

LangChain 干的就是把这些胶水代码标准化。

三、LangChain 的核心架构

LangChain 采用分层设计,从下到上大致分为三层:

  • 接口层(Integrations):对接外部系统,包括 300+ 家模型提供商、向量数据库、文档解析器、API 工具等
  • 核心抽象层(Core Abstractions):Chain、Agent、Retriever 等核心概念,定义了 AI 应用的构建方式
  • 编排层(Orchestration):LangGraph 等工具,负责复杂工作流的状态管理和分支控制

这种分层设计的价值在于:你可以在任意层级接入,不需要从最底层开始。想换模型?只改接口层的配置。想加 RAG?用核心抽象层现成的 Retriever。想搞复杂工作流?上编排层。

四、六大核心模块概览

LLM 与提示词管理

这是最基础的模块。LangChain 统一了不同模型厂商的调用接口——不管是 OpenAI、Anthropic、Google 还是开源模型,切换时只需要改一行配置。

来看一个最简示例:

from langchain_openai import ChatOpenAI
from langchain_anthropic import ChatAnthropic

# 用 OpenAI
llm_openai = ChatOpenAI(model="gpt-4o", temperature=0)

# 切换到 Anthropic,只需换一行
llm_claude = ChatAnthropic(model="claude-sonnet-4-20250514", temperature=0)

# 两者调用方式完全一致
response = llm_openai.invoke("你好,请介绍一下你自己")

提示词模板系统则让你把写死的提示词变成可复用的模板,支持变量注入和条件逻辑。

链(Chain)

Chain 是 LangChain 名字的由来,也是它的核心抽象。一个 Chain 就是一连串步骤的组合。最简单的 Chain 是提示词模板、模型调用、输出解析,三步串起来。复杂的 Chain 可以嵌套多个子 Chain,形成树状的处理流程。

比如你想让 AI 先总结一篇文章,再基于总结生成一个标题,再根据标题生成配图描述——这就是三个 Chain 的串联。

LCEL 表达式

LCEL(LangChain Expression Language)是定义 Chain 的方式。写法很直觉,用管道符把各个步骤串起来:

from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_template("用一句话概括{topic}")
model = ChatOpenAI(model="gpt-4o")
parser = StrOutputParser()

# 用管道符定义一个完整的处理链
chain = prompt | model | parser

# 调用
result = chain.invoke({"topic": "量子计算"})
print(result)

这行 prompt | model | parser 就定义了一个完整的 AI 处理流程。LCEL 让 Chain 的组合变得像搭积木一样——换个模型、换个提示词,只要替换对应的那一块就行。

检索增强生成(RAG)

RAG 是当下 LangChain 最常被用到的能力。它的原理不复杂:先从知识库里检索出和用户问题相关的文档片段,把这些片段塞进提示词,再让大模型基于这些信息生成回答。

一个典型的 RAG 管线:

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings

# 1. 加载文档
loader = PyPDFLoader("document.pdf")
docs = loader.load()

# 2. 切分
splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
chunks = splitter.split_documents(docs)

# 3. 向量化并存入向量数据库
vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings())

# 4. 检索
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})
results = retriever.invoke("合同中的违约条款是什么?")

这样 AI 就能回答那些不在训练数据里的问题。你有一份公司内部的技术文档,直接问 ChatGPT 它肯定答不上来,但有了 RAG,AI 就能从你的文档里找到答案。

Agent(智能体)

如果说 Chain 是固定流程,Agent 就是动态决策。Agent 以大模型为决策引擎,配备一套工具箱——可以调数据库、调 API、调搜索引擎。面对一个任务,Agent 自己决定用哪个工具、按什么顺序用、拿到中间结果后再决定下一步做什么。

一个典型的 Agent 循环:接收任务 → 大模型思考该怎么做 → 调用某个工具 → 拿到结果 → 大模型再思考下一步 → 继续调用工具或返回最终结果。

记忆模块

大模型本身没有记忆——每次对话都是从零开始。LangChain 的记忆模块让 AI 能够记住之前的对话内容,支持短期记忆(当前会话)和长期记忆(跨会话持久化)。

from langchain.memory import ConversationBufferMemory

# 创建记忆模块
memory = ConversationBufferMemory()

# 保存对话
memory.save_context({"input": "我叫小明"}, {"output": "你好小明!有什么可以帮你的?"})
memory.save_context({"input": "帮我写代码"}, {"output": "好的,你想写什么代码?"})

# 查看记忆
print(memory.buffer)

五、配套工具链全景

除了核心模块,LangChain 还提供了一整套开发运维工具。

工具 定位 核心功能 适用场景
LangChain Libraries 集成库 300+ 第三方库集成,从向量数据库到文档解析器 需要接入外部数据源或工具时
LangChain Templates 项目模板 常见 AI 应用的模板项目,拿来就能改 快速启动新项目,不用从零开始
LangServe API 发布 基于 FastAPI,把 Chain 发布为 REST API 将 AI 应用封装成 HTTP 接口供前端调用
LangSmith 开发平台 可视化追踪、调试、评估、监控 优化提示词、分析错误、监控生产环境

从实际使用角度看,LangSmith 的价值尤其突出。在 AI 应用开发中,最难的不是写代码,而是搞清楚模型在每一步返回了什么、为什么返回了这个结果。LangSmith 把这个过程变得可视化,能大幅缩短调试时间。

六、LangChain vs 其他框架

AI 应用开发框架不止 LangChain 一个。以下是主流框架的横向对比:

框架 核心优势 劣势 适合谁 GitHub Stars
LangChain 生态最完善,集成最多,社区最活跃 学习曲线较陡,抽象层多 需要快速搭建复杂 AI 团队 103k+(来源:GitHub,2026)
LlamaIndex RAG 场景优化最好,数据接入简单 Agent 和 Chain 能力较弱 专注文档问答和数据检索的团队 39k+(来源:GitHub,2026)
Haystack 管道式设计,模块化程度高 社区规模较小 企业级部署、需要高度定制的团队 19k+(来源:GitHub,2026)
Semantic Kernel 微软出品,C#/.NET 生态好 Python 生态不如 LangChain .NET 技术栈的企业开发者 24k+(来源:GitHub,2026)

选择建议:如果你不确定用哪个,先选 LangChain。它的社区最大、文档最全、遇到问题最容易找到答案。如果后续发现 RAG 是核心需求且 LangChain 太重,可以考虑切到 LlamaIndex。

七、实际落地案例

案例一:某法律科技公司构建合同审查系统

这家公司的需求是让 AI 自动审查商业合同,标出风险条款。之前他们的做法是律师手动审查,一份合同平均需要 4 小时。

接入 LangChain 后,他们搭建了一个 RAG 管线:合同文档经过文本切分后存入向量数据库,用户上传新合同时,系统先检索出历史合同中的相似条款和已知风险模式,再让大模型基于这些信息生成审查报告。

效果数据:审查时间从 4 小时缩短到 15 分钟,风险条款识别准确率从人工的 85% 提升到 94%(数据来源:该公司技术博客公开分享,2025)。

案例二:某电商平台搭建智能客服

这家电商的客服团队每天要处理上万条咨询,其中 60% 是重复问题(退货流程、物流查询、优惠券使用等)。

他们用 LangChain 构建了一个多 Agent 系统:一个 Agent 负责理解用户意图,根据问题类型路由到对应的处理 Agent——物流查询 Agent 调内部 API,退货流程 Agent 调订单系统,产品推荐 Agent 调商品数据库。每个 Agent 都配备了记忆模块,能记住用户之前的对话上下文。

上线后的变化:自动回复率从 30% 提升到 72%,用户平均等待时间从 3 分钟降到 20 秒(数据来源:该公司季度报告,2025)。

八、常见误解与真相

  • 误解:LangChain 是一个 AI 模型:真相是 LangChain 完全不提供 AI 能力,它只是一个连接器和编排层。没有大模型,LangChain 什么也做不了。
  • 误解:用了 LangChain 就能让 AI 更聪明:真相是 LangChain 不能提升模型的推理能力。它解决的是"怎么用好模型"的问题,不是"让模型变强"的问题。
  • 误解:LangChain 只能用于 RAG 场景:真相是 RAG 只是 LangChain 最火的应用场景。它在 Agent、多步骤工作流、工具调用等场景同样强大。
  • 误解:LangChain 太重了,小项目不需要:真相是 LangChain 可以按需使用。你只用一个 Chain 和提示词模板也是在使用 LangChain,不需要把整个框架都搬出来。
  • 误解:LangChain 已经过时了,大家都在用 LangGraph:真相是 LangGraph 是 LangChain 生态的一部分,解决的是复杂工作流的状态管理问题。两者不是替代关系,而是互补关系。

九、避坑指南

新手使用 LangChain 时最容易踩的 5 个坑:

  1. 坑:一上来就学 LangGraph,结果被状态管理搞晕:LangGraph 是高级抽象,需要先理解 Chain 和 Agent 的基础概念。建议先用 LCEL 写几个简单的 Chain,理解数据在管道中怎么流转,再上 LangGraph。

  2. 坑:提示词模板写得太死板,换个模型就不行了:不同模型对提示词的敏感度差异很大。建议用 LangChain 的 ChatPromptTemplate 做抽象,把系统提示词和用户提示词分开管理,方便针对不同模型做微调。

  3. 坑:RAG 效果不好,以为是 LangChain 的问题:大多数 RAG 效果差的根源不在框架,而在数据质量——文档切分太粗、向量数据库选型不对、检索策略不合理。建议先检查数据管线,用 LangSmith 的追踪功能看检索结果是否真的召回了相关内容。

  4. 坑:Agent 陷入死循环,不停调同一个工具:Agent 的工具描述不清楚,或者任务描述有歧义,导致模型反复尝试同一个失败的操作。建议给每个工具写清楚描述和边界条件,设置最大迭代次数(max_iterations),在 Agent 配置中加 early_stopping_method="generate"

  5. 坑:生产环境跑得好好的,换个机器就报错:LangChain 的很多组件依赖隐式环境变量(比如 API Key 写在代码里而不是环境变量),或者不同版本的库之间存在兼容问题。建议用 langchain-cli 做版本管理,所有敏感信息通过环境变量注入,写 requirements.txt 时锁定版本号。

十、进阶技巧

  1. RunnablePassthrough 保留中间数据:在复杂 Chain 中,你可能需要同时返回模型输出和原始输入。用 RunnablePassthrough.assign() 可以在不中断管道流的情况下保留中间结果,方便后续调试和日志记录。

  2. 自定义 OutputParser 做结构化输出:LangChain 内置的 StructuredOutputParser 可以强制模型输出 JSON 格式。配合 Pydantic 模型定义 schema,你能让模型返回严格结构化的数据,直接喂给下游系统。

  3. astream_events 做流式输出:生产环境中用户不想等一整段回答。LangChain 的 astream_events 方法可以逐 token 返回结果,配合 FastAPI 的 StreamingResponse,能实现和 ChatGPT 一样的打字机效果。

  4. LangSmith 的 Dataset 功能做评估:写完一个 Chain 后,在 LangSmith 中创建测试数据集(输入 + 期望输出),然后跑批量评估。这能帮你量化提示词改动的效果,而不是靠感觉判断"好像好了一点"。

  5. ConfigurableAlternatives 做 A/B 测试:在生产环境中,你可以用同一个 Chain 接口配置多个模型版本,通过 LangSmith 的流量分配功能做 A/B 测试,用数据决定哪个模型版本效果更好。

十一、如何深入学习

  1. 入门阶段(1-2 周):阅读 LangChain 官方文档的 Tutorials 部分,重点掌握 LCEL、Chain、PromptTemplate 三个核心概念。跟着官方示例跑通第一个 RAG 应用。
  2. 进阶阶段(2-4 周):学习 Agent 和 Tool Use,理解 ReAct 和 Plan-and-Execute 两种 Agent 架构的区别。动手做一个能调真实 API 的 Agent。
  3. 实战阶段(1-2 月):用 LangGraph 构建一个带状态管理的复杂工作流。接入 LangSmith 做监控和调试。在真实项目中跑通完整的 RAG + Agent 管线。
  4. 深入阶段(持续):阅读 LangChain 源码,理解 Chain 和 Agent 的内部执行逻辑。关注 LangChain 博客和 Harrison Chase 的 Twitter,跟进最新发展方向。

推荐资源:LangChain 官方文档(docs.langchain.com)、LangChain GitHub 仓库的 examples 目录、LangChain Discord 社区。

十二、总结

LangChain 不是万能的,但它解决了一个真实的痛点:让 AI 从能聊天变成能干活。如果你正在构建涉及大模型的应用,LangChain 值得认真了解。从 LLM 调用到 RAG 到 Agent,它提供了一整套经过验证的工具链,能帮你少写很多胶水代码。建议从一个具体的小项目开始,先跑通一个 Chain,再逐步扩展到更复杂的场景。


系列文章