LangChain
构建 LLM Agent 应用的工程平台 — 提供模型、工具、向量库的统一抽象层,让你专注业务逻辑而非对接细节。
🎯 为什么需要它
LLM 生态极度碎片化 — OpenAI、Anthropic、Google、本地模型各有一套 API;Chroma、FAISS、Pinecone 等向量库接口各异;搜索、数据库、文件系统等工具需要逐一对接。如果你直接写原生 SDK 调用,换模型或换向量库时需要重写大量胶水代码。
LangChain 的价值主张:提供一套标准抽象(Runnable、ChatModel、Tool、Retriever),让你用统一的接口对接 700+ 集成,核心业务逻辑不随底层更换而改变。
💡 一句话判断
如果你的项目需要对接 3 个以上 LLM/向量库/工具,且业务流程涉及多步 Agent 编排,LangChain 能显著减少胶水代码。
如果只是单个 LLM 调用 + 简单 function calling,直接用原生 SDK(OpenAI / Anthropic Python SDK)更轻量、更可控。
📦 包生态全景
LangChain 已从早期的单体包拆分为模块化体系,按需安装:
| 包名 | 职责 | 何时安装 |
|---|---|---|
langchain-core | 核心抽象层(Runnable、LCEL、消息类型、工具协议) | 自动依赖,不需单独装 |
langchain | 高层编排(create_agent、链组合、预构建组件) | 始终需要 |
langgraph | 有状态图编排(循环、分支、多人协作、持久化检查点) | 复杂 Agent 工作流 |
langchain-community | 第三方集成(向量库、工具、检索器) | 需要社区集成时 |
langchain-openai | OpenAI 一等公民集成 | 用 GPT 系列时 |
langchain-anthropic | Anthropic Claude 集成 | 用 Claude 时 |
langsmith | 可观测性 / 调试 / 评估平台(SaaS + 自托管) | 生产环境调试 |
关键关系:langchain-core 是地基;langchain 和 langgraph 建在其上;集成包提供具体实现。新项目建议同时安装 langchain + langgraph。
✅ 核心优势
1. 生态覆盖最广 — 700+ 集成
从 LLM 提供商(OpenAI、Anthropic、Google、Ollama、AWS Bedrock)到向量库(Chroma、FAISS、Pinecone、Qdrant、pgvector 等 40+)到工具(搜索、SQL、文件系统、Slack、GitHub 等数百个),覆盖面远超任何竞品。换提供商只需改一行 import。
2. LangGraph — 最成熟的有状态 Agent 编排
LangGraph 提供基于图的工作流引擎,支持循环(Agent 自循环调用工具)、分支、持久化检查点、人机协同(human-in-the-loop)、时间旅行调试。这是目前开源生态中最完整的有状态 Agent 运行时。
3. LCEL — 优雅的链组合语法
LangChain Expression Language 用 | 管道符组合组件,支持并行、重试、fallback、流式输出、批量处理:
chain = prompt | model | parser
result = chain.invoke({"topic": "LangChain"})
4. v1.0 稳定性承诺
2025 年 10 月发布 v1.0,承诺到 v2.0 之前不引入破坏性变更。API 趋于稳定,历史遗留的频繁 breaking changes 问题基本解决。
5. LangSmith 可观测性
配套的 LangSmith 平台提供 Agent 决策追踪、Token 用量统计、延迟分析、Prompt 评估对比。对生产环境调试 Agent 至关重要。
⚡ 性能表现
LangChain 的性能问题不在模型推理(那是提供商的事),而在框架开销:
实测数据:移除 LangChain 的收益
| 阶段 | 使用 LangChain | 原生 SDK | 节省 |
|---|---|---|---|
| Token 计数 | 500ms | 0ms | 500ms |
| 日志记录 | 1500ms | 50ms | 1450ms |
| 序列化 | 800ms | 100ms | 700ms |
| 网络请求 | 1200ms | 500ms | 700ms |
| 数据库 | 1500ms | 400ms | 1100ms |
| 总计 | 8000ms | 3400ms | 4600ms (57%) |
有开发者移除 LangChain 的默认 Memory 包装后,API 延迟立即下降 1.3 秒。另一案例中,替换默认 Memory 实现后,OpenAI 调用成本降低 28%。
流式场景的内存问题
LangGraph 的 stream_mode: ['messages', 'updates'] 在多 Agent 场景下,每个 token 生成一个 AIMessageChunk 对象(含完整元数据),单次运行可产生 10,000+ chunk 对象,触发 1–1.5 GB 内存尖峰。
建议
- 生产环境关闭不用的计算(token 计数、复杂度评分等默认启用的功能)
- 流式输出只用
stream_mode="messages",避免多模式叠加 - Memory 用 LangGraph 的状态图管理,别用
ConversationBufferMemory - 对延迟敏感的场景,考虑核心路径用原生 SDK,LangChain 只做外围编排
🚀 快速上手
1. 安装
# 最小安装(含 OpenAI 集成)
pip install -qU langchain "langchain[openai]"
# 如果用 Claude
pip install langchain langchain-anthropic
# 完整安装(含 LangGraph)
pip install langchain langgraph langchain-openai
2. 现代写法:create_agent(v1.x 推荐)
from langchain.agents import create_agent
def get_weather(city: str) -> str:
"""Get weather for a given city."""
return f"It's always sunny in {city}!"
agent = create_agent(
model="openai:gpt-4o",
tools=[get_weather],
system_prompt="You are a helpful assistant",
)
result = agent.invoke(
{"messages": [{"role": "user", "content": "What's the weather in SF?"}]}
)
print(result["messages"][-1].content_blocks)
3. LCEL 链组合(经典管道写法)
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
chain = (
ChatPromptTemplate.from_template("Tell me about {topic}")
| ChatOpenAI()
| StrOutputParser()
)
result = chain.invoke({"topic": "LangChain"})
print(result)
4. RAG 基础示例
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
# 准备文档和向量库
docs = ["LangChain is a framework for LLM apps.",
"LangGraph handles stateful agent workflows."]
vectorstore = FAISS.from_texts(docs, OpenAIEmbeddings())
retriever = vectorstore.as_retriever()
# 构造 RAG 链
template = "Answer based on context: {context}\n\nQuestion: {question}"
prompt = ChatPromptTemplate.from_template(template)
rag_chain = (
{"context": retriever, "question": RunnablePassthrough()}
| prompt
| ChatOpenAI()
)
result = rag_chain.invoke("What is LangGraph for?")
print(result.content)
5. LangGraph 状态图 Agent(复杂工作流)
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI
model = ChatOpenAI(model="gpt-4o")
agent = create_react_agent(model, tools=[get_weather])
# 流式输出
for event in agent.stream(
{"messages": [{"role": "user", "content": "Weather in Tokyo?"}]},
stream_mode="messages",
):
print(event)
🛠️ 版本锁定建议
所有 LangChain 包需保持在同一 minor 版本系列内,否则会出现隐晦的运行时错误:
langchain==1.3.0
langchain-core==1.4.0
langchain-openai==0.3.x # provider 包版本独立
📦 适用场景
✅ 最佳场景
| 场景 | 为什么适合 |
|---|---|
| 多模型 / 多提供商切换 | 标准接口,换提供商只改一行代码 |
| 复杂 Agent 工作流(LangGraph) | 循环、分支、持久化、人机协同的最佳实现 |
| 企业级 RAG 系统 | 统一的 Retriever 接口 + 40+ 向量库支持 |
| 多工具集成(搜索 + DB + API) | 700+ 预构建集成,@tool 装饰器标准化工具定义 |
| 需要可观测性的生产系统 | LangSmith 提供 Agent 全链路追踪和评估 |
❌ 不推荐场景
| 场景 | 更好的选择 | 原因 |
|---|---|---|
| 单个 LLM 调用 + function calling | 原生 SDK | LangChain 抽象反而增加复杂度和延迟 |
| 纯 RAG 检索优化 | LlamaIndex | 检索精度更高,300+ 数据连接器 |
| 简单多角色 Agent 协作 | CrewAI | 抽象更直觉,代码量更少 |
| 延迟敏感的高吞吐 API | 原生 SDK | 框架开销 1–5 秒不可接受 |
| JS/TS 前端为主的项目 | Vercel AI SDK | JS 生态实际下载量已 5x 超过 LangChain JS |
⚠️ 已知坑
网上的教程大多是 v0.1/v0.2 时代的,import 路径已失效。例如 from langchain.chat_models import ChatOpenAI 在 v0.3+ 已不存在,必须用 from langchain_openai import ChatOpenAI。旧版 .run() 方法也已废弃,需改为 .invoke()。
LangChain 的依赖树庞大,容易与 NumPy、Pandas 等数据科学库产生版本冲突。Docker 镜像更大,冷启动更慢。务必用虚拟环境隔离,并锁定版本。
langchain==1.3.0 搭配 langchain-core==0.3.x 会产生莫名其妙的运行时错误。所有 langchain-* 核心包必须锁定在同一 minor 系列。Provider 包(如 langchain-openai)版本独立。
LangGraph 流式有 "values"、"updates"、"messages" 三种模式,行为在 0.4.0+ 变更过。Token 用量元数据在单独的 chunk 中到达(无 content 属性),用 hasattr(chunk, "content") 过滤会静默丢失。
700+ 集成中大量是社区贡献的,测试覆盖不足。上游 API 变更时连接器可能静默失败。对生产环境的关键集成,建议自己封装或贡献修复。
v0.3 迁移到 Pydantic v2,如果项目其他依赖仍在用 Pydantic v1,会产生 ValidationError 和 model_rebuild() 失败。Python 3.12.4+ 会暴露额外的兼容性问题。
ConversationBufferMemory 不会自动裁剪历史,会超出 Token 限制。默认 Memory 包装增加 ~1.3s 延迟和 ~28% 的 Token 成本。生产环境用 LangGraph 的状态图替代。
部分场景下工具调用会静默失败,无错误日志、无追踪记录。建议始终配合 LangSmith 使用,并手动添加工具调用的 try/except。
版本迁移时间线
🚗️ 竞品对比
| 框架 | 定位 | 优势 | 劣势 | 推荐场景 |
|---|---|---|---|---|
| LangChain + LangGraph | 通用 Agent 编排平台 | 生态最广(700+);LangGraph 是最成熟的有状态 Agent 运行时 | 框架开销大;历史债务重;过度抽象 | 复杂多步 Agent、需要多提供商支持 |
| LlamaIndex | RAG / 数据检索 | 检索精度最高;300+ 数据连接器;LlamaParse 文档解析 | Agent 编排能力弱于 LangGraph | 纯 RAG、知识库问答 |
| CrewAI | 角色制多 Agent 协作 | 最直觉的角色/任务抽象;上手最快 | Python-only;复杂工作流不如 LangGraph | 多角色 Agent 团队协作 |
| Microsoft Agent Framework | 企业 .NET/Azure AI | 原生 C# 支持;Azure 深度集成;MIT | 社区小;Python 支持滞后 | .NET/Azure 技术栈的企业 |
| Haystack | 生产级 RAG 管道 | 管道可声明式序列化;EU 合规;企业功能完整 | 非线性工作流弱;集成少于 LangChain | 有合规要求的企业 RAG |
| OpenAI Agents SDK | 轻量 OpenAI Agent | 最简单;OpenAI 功能集成最深 | 锁定 OpenAI;无多提供商支持 | 快速原型 / 全 OpenAI 栈 |
| Vercel AI SDK | 前端 AI 集成 | JS/TS 生态下载量 5x LangChain JS;React/Next.js 深度集成 | Python 支持弱;Agent 编排能力有限 | Next.js / React 项目 |
📈 市场格局趋势
2026 年的主流模式是组合使用而非二选一:LlamaIndex 做检索层 + LangGraph 做编排层,这是目前生产系统最常见的搭配。
值得注意:"SDK-First" 趋势正在壮大 — 越来越多资深工程师主张先用原生 SDK 构建,遇到真正的编排需求时再引入框架。
微软在 2026 年 4 月发布了 Agent Framework 1.0 GA,统一了 Semantic Kernel 和 AutoGen。AutoGen 已进入维护模式。
🌎 生态社区
| 指标 | 数据 |
|---|---|
| GitHub Stars(Python + JS) | ~136,700 + ~27,000 = ~163,700 |
| 月下载量 | 90M+(全生态 50+ PyPI 包) |
| 贡献者 | 2000+ |
| Reddit 社区 | r/LangChain ~34K 成员 |
| 企业用户 | Uber、Klarna、LinkedIn、Cisco、Coinbase、Workday |
| 融资 | Sequoia + Benchmark 领投 |
| 商业产品 | LangSmith(可观测性)、LangGraph Platform(托管部署)、LangGraph Cloud |
社区情绪走势
被广泛引用的数据:"45% 的 AI 团队使用 LangChain,但只有 12% 保留在生产中"。虽然精确度存疑,但反映了核心叙事 — LangChain 在原型阶段很强大,但迁移到生产需要投入额外精力。
💡 引入评估
LangChain 是当前 LLM 框架中生态最大、功能最全的选择,LangGraph 是复杂有状态 Agent 工作流的最佳实现。但它的代价是显著的框架开销、历史债务和过度抽象。
推荐引入的情况:项目需要对接 3+ 提供商 / 向量库 / 工具,或工作流涉及循环、分支、持久化等复杂 Agent 编排。
不推荐引入的情况:简单 LLM 调用、延迟敏感的 API、纯 RAG 检索(用 LlamaIndex)、JS 前端为主(用 Vercel AI SDK)。
关键建议:新项目直接从 v1.x 开始,不要看 2024 年之前的教程。核心路径可混合原生 SDK + LangChain 编排。务必配合 LangSmith 做可观测性。