引言

LangChain曾经是LLM应用开发框架的代名词。2023年的GitHub Star曲线一路飙升,投资人趋之若鹜,开发者言必称"用LangChain搭一个"。然而三年过去,当我们冷静审视这个框架时,会发现一个尴尬的现实:生产环境中坚持使用原生LangChain的团队越来越少

这不是一篇唱衰文,而是一个早期采用者的诚实反思。

野心的轨迹

LangChain的愿景从未变小过——它想成为"AI应用开发的标准基础设施":

LangChain    → LLM应用的Spring Framework
LangGraph    → 有状态Agent编排引擎
LangSmith    → 可观测性与评测平台
LangServe    → 一键部署API
LangCloud    → 托管服务

这套全家桶覆盖了从开发、调试到部署的全链路。问题在于,每个环节都有更强的专门工具

框架的过度抽象

LangChain最被诟病的问题是抽象层次过多。来看一个简单的RAG实现:

# LangChain方式
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain_openai import ChatOpenAI

loader = PyPDFLoader("doc.pdf")
documents = loader.load()
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(documents)
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3")
vectorstore = Chroma.from_documents(chunks, embeddings)
llm = ChatOpenAI(model="gpt-5")
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=vectorstore.as_retriever())
result = qa_chain.invoke({"query": "文档说了什么?"})
# 直接用原生库
import chromadb
from openai import OpenAI

client = OpenAI()
db = chromadb.PersistentClient(path="./chroma")
collection = db.get_or_create_collection("docs")

# 读取→切块→嵌入→存储→检索→生成
# 每一步都可控、可调试、可替换

LangChain的抽象增加了认知负担,但没有减少代码量。更严重的是,当你需要深入调试某个环节时,多层抽象让你很难定位问题。

LangGraph:方向对了但迟了

LangGraph是LangChain团队对"有状态Agent"需求的回应,采用了图结构来编排Agent工作流:

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]
    next_agent: str

def researcher(state: AgentState):
    # 调用搜索工具
    return {"messages": [search_result], "next_agent": "writer"}

def writer(state: AgentState):
    # 撰写报告
    return {"messages": [report], "next_agent": END}

workflow = StateGraph(AgentState)
workflow.add_node("researcher", researcher)
workflow.add_node("writer", writer)
workflow.set_entry_point("researcher")
workflow.add_conditional_edges("researcher", lambda s: s["next_agent"])
workflow.add_edge("writer", END)

app = workflow.compile()

设计思路是对的——显式的状态图比隐式的Chain更适合复杂Agent场景。但问题在于,2025年CrewAI、AutoGen已经在这一领域建立了生态壁垒,LangGraph来得太晚。

核心矛盾的三个层面

1. 抽象vs控制力

框架的核心价值是降低复杂度,但LLM应用的特殊性在于——每一步都需要精细控制。Prompt的细微差别可能导致输出质量天差地别,而LangChain的Chain抽象把Prompt封装在层叠的对象内部,让调优变得困难。

2. 集成广度vs深度

LangChain号称支持100+个集成,但很多集成停留在"能跑通demo"的水平:

集成类型 数量 生产可用 问题描述
LLM Provider 25+ 8 多数未跟上Provider API更新
Vector Store 30+ 10 高级过滤、索引优化等功能缺失
Document Loader 40+ 15 边缘case处理粗糙
Tool 50+ 20 错误处理不完善

3. 框架锁定vs灵活组合

一旦深度使用LangChain,迁移成本极高。你的业务代码里充斥着BaseRetrieverRunnableChain这些LangChain专有接口。而2026年的最佳实践是组合小而专的库

推荐替代方案:
- LLM调用:直接用各Provider的官方SDK
- 向量存储:直接用Chroma/Qdrant/Milvus的SDK
- 工作流编排:LangGraph或自研状态机
- 可观测性:LangSmith(这个确实好用)或OpenTelemetry
- 评测:自建评测集 + DeepEval/RAGAS

LangSmith:被低估的亮点

在批评之外,必须承认LangSmith是LangChain生态中真正有价值的产出。它提供的Tracing、评测、Prompt管理功能在2026年依然有竞争力:

from langsmith import Client

client = Client()

# 自动追踪每次LLM调用
@client.trace
def my_rag_pipeline(question: str):
    docs = retrieve(question)
    answer = generate(question, docs)
    return answer

# 创建评测集
dataset = client.create_dataset("rag_eval_v1")
client.create_examples(
    inputs=[{"question": "什么是RAG?"}],
    outputs=[{"answer": "检索增强生成..."}],
    dataset_id=dataset.id
)

# 运行评测
results = client.run_on_dataset(
    dataset_name="rag_eval_v1",
    llm_or_chain_factory=my_rag_pipeline,
    evaluation="auto",
)

LangSmith的独立可用性意味着你可以在不使用LangChain框架的情况下享受它的可观测性能力。

2026年的合理定位

LangChain不是"该不该用"的问题,而是"在哪里用"的问题:

适合LangChain的场景:

  • 快速原型验证
  • 技术探索期的demo搭建
  • 团队缺乏LLM工程经验时的起步工具

不适合LangChain的场景:

  • 高并发生产服务
  • 需要精细控制Prompt和推理参数的场景
  • 对延迟和成本敏感的线上业务

总结

LangChain的历史贡献不可否认——它在LLM应用的混沌早期提供了一套可用的脚手架,教育了整个市场。但框架的成功取决于解决的问题比制造的多,而LangChain的抽象税在2026年显得愈发沉重。

如果你的团队还在深度依赖LangChain,建议逐步解耦:先从LangSmith独立化开始,然后评估每个集成是否有原生替代方案,最终保留框架中真正有价值的部分,抛弃那些"为抽象而抽象"的层。

好的框架让你忘记它的存在,而不是时刻提醒你正在使用它。