~ / writing / n°036

2026 了，别再闭着眼上 LangChain

X-ARTICLE 2026 · 06 · 06 9 min · 3,602 字

两年前，做 LLM 对话应用时，我见过太多后端顺手就把 LangChain 拉进来。

那会儿数字人、RAG、聊天机器人都热，大家要把 prompt、模型、工具、知识库、记忆这些东西串起来，最自然的动作就是：先装 LangChain。

那几年很多 demo 都是这么搭出来的。

当时这不是错。甚至可以说，LangChain 赢得很合理。

问题是，2026 年了，如果你新项目还是一上来就默认 LangChain，我会先问一句：你到底是在做一个 LLM 小功能，一个 RAG 应用，还是一个长跑的 agent 系统？

LangChain 没死。死掉的是”什么都先上 LangChain”的默认反射。

当年它确实是标配，不用装作没发生过

2023 到 2024 年，LangChain 有一种”教程宇宙中心”的感觉。

你搜 LLM 应用，十篇里八篇绕不开它。做 RAG，有它。做对话机器人，有它。做数字人后端编排，也经常有人顺手用它把模型、记忆、工具调用串起来。

注意，我说的是”顺手用”，不是”数字人专用”。它不是数字人的框架，它只是赶上了那一波 LLM 对话应用一起爆发。

那个时间点，底层 SDK 还没今天这么成熟。早期很多能力散在各处，工具调用、流式输出、结构化结果、检索接入，都需要人自己缝。

LangChain 当时的价值，就是先给大家一套词和一套脚手架：model、prompt、memory、tool、retriever、chain。

它把一堆还没定型的工程动作，先摆成了一个能跑的架子。

在混沌期，能跑起来就是巨大价值。

它最早的胜利，也埋下了后来被骂的点

LangChain 被吐槽，很多时候不是因为它”不够强”。恰恰相反，是它太早把一堆模式抽象成了框架。

demo 期很爽。

你接一个模型，挂一个 retriever，再串一个 chain，好像三两下就能把”智能问答系统”端出来。给老板演示，给客户看原型，给自己验证想法，这都很舒服。

但一到生产，你开始关心另一批事：调用栈到底怎么走？模型原始输入输出是什么？中间哪一步改了 prompt？类型为什么又变了？版本升级后为什么同一段代码不一样了？

这时候很多人会冒出同一个念头：我是不是直接调 SDK 更清楚？

这就是抽象税。

抽象本身不是坏事。坏的是你为了省十行胶水代码，换来一个你 debug 不动的黑盒。

我见过最典型的场景是：系统真的出问题时，业务方问”为什么模型这么答”，开发者不是去看模型输入，而是先在框架层里翻半天。

这就很尴尬。

框架如果让 demo 更快，但让生产排错更慢，那它就不是省时间，只是把时间赊到了后面。

网上那些 “why we no longer use LangChain” 类吐槽文，大多也是这个脉络。不能把它写成”所有人都弃用了 LangChain”，那是胡说。但它们说明了一件事：生产团队会重新算这笔抽象税。

不过也得说句公道话：LangChain 1.0 已完全重写，部分抽象税被 LangGraph runtime 消化了。但这段历史教训仍然成立——抽象税不是 bug，是框架演化中必然经历的结算。

2026 年，底层 SDK 和协议长大了

LangChain 当年补的是”缺胶水”的空。

但 2026 年，这个空没那么大了。

现在主流模型 SDK 已经原生支持 tool use、structured output、streaming。

再加上 MCP——Model Context Protocol，模型上下文协议——想解决的是工具和数据源怎么以统一方式接进模型应用里。但 MCP 不解决编排和状态，那正是 LangGraph 押注的方向。

这会直接压缩 LangChain 最早那部分”胶水价值”。

如果你只是包一两个 LLM 调用，做一个客服摘要、表单抽取、文案改写、简单知识库问答，我现在更倾向于直接用 provider SDK（OpenAI、Anthropic 这几家原生接口），加一点自己写的小胶水。

这套做法没那么”框架感”，但好处是每一步都在你手里。

模型吃了什么，你知道。工具怎么调，你知道。失败怎么重试，你知道。日志怎么打，你也知道。

很多生产系统真正需要的不是一个宏大的 chain，而是一个薄薄的 orchestrator。

今天还把所有 LLM 小功能都塞进重框架里，很多时候不是工程能力强，是对底层变化没更新。

但 LangChain 没原地等死，它换了战场

这也是我不赞成简单说”LangChain 过气”的原因。

LangChain 公司自己其实早就换打法了。

现在它的重心，不再只是让你用 Chain 写所有东西，而是 LangGraph 和 LangSmith。

LangGraph 是状态化 agent 编排框架——实际上 LangChain 1.0 底层就是 LangGraph runtime，不是替代关系，是换发动机。agent 在这里不是一句”AI 自己干活”的营销词，而是一个会多轮调用模型、工具、状态和人工反馈的系统。状态化的意思是，它不是跑完一轮就忘，而是能记住中间过程、恢复执行、处理长流程。

LangSmith 则更像追踪、评估和部署平台。tracing 是追踪每次调用链路，eval 是评估模型输出质量。做过生产 LLM 应用的人都知道，真正麻烦的不是让模型回一句话，而是知道它为什么回成这样，以及改了以后有没有变好。

这就是 LangChain 现在更像”平台入口”的地方。

它不是靠老 LangChain 那套抽象继续吃天下，而是把战场推到 agent engineering——把 agent 当工程系统来做，包括状态、持久化、评估、观测、人工介入。

数据上也能看出它没死。LangChain 仓库大约 138.6k stars，LangGraph 大约 34k stars。LangChain 官方 Series B 融资是 1.25 亿美元，估值 12.5 亿美元。

但这两个数字都别神化。

stars 不等于生产采用，融资也不等于框架好用。它们只能说明一件事：这个公司和生态还在，而且明显把赌注押到了 LangGraph、LangSmith 这条平台化路线上。

LangChain 不是死了，是从”默认脚手架”变成了”平台入口”。这两个身份，选型含义完全不同。

2026 该不该用？按场景，不按信仰

所以我现在对 LangChain 的判断很简单：别站队，先看场景。

如果你在做原型、教学、内部 demo，或者团队就是想快速摸一遍 LLM 应用链路，LangChain 仍然可以用。它的生态、教程、集成和样例还在，对快速摸清链路也有帮助。

如果你明确要进 LangSmith、LangGraph 这套全家桶，也可以认真评估。尤其是长跑 agent：多步骤、可恢复、有人类介入、需要状态持久化、需要评估和追踪，这时 LangGraph 值得看。

但如果你只是在生产里包一两个 LLM 调用，或者做一个边界清楚的 RAG 应用，我会更谨慎。

RAG 应用本质上常常是三件事：检索、拼上下文、调用模型。这里 LlamaIndex（偏知识库和索引方向）可能更对口；直接 SDK 加自己的检索层也经常够用。

如果你在做 prompt 或程序优化，DSPy（斯坦福团队，把 prompt 和模型调用当可优化程序）又是另一类东西。

如果你在做前端轻应用，Vercel AI SDK——更偏前端和轻量模型接入——也可能比 LangChain 更顺手。

换句话说，2026 年的 LangChain 不是”还能不能打”的问题。

它当然还能打，但不再是所有局都该它上场。

小功能用 SDK，小 RAG 看数据层，长跑 agent 再认真评 LangGraph。选不选 LangChain，按场景，不按信仰。

这可能才是它今天最真实的位置。

不是神坛上的默认答案。

也不是被时代淘汰的旧框架。

而是一个已经从脚手架转向平台入口的老玩家。你要用它，就别再用两年前的理由。

引用出处

DAVID YIN · 2026 · 06 · 06 · 杭州
← Older · N°037
公司一边叫你AI提效，一边让你出事自己扛？装什么瞎