为什么很多人都放弃LangChain了？

或许从诞生那天起，LangChain 就注定是一个口碑两极分化的产品。

看好 LangChain 的人，欣赏它丰富的组件、灵活的集成能力；不看好的人，则觉得它注定失败——在这个技术更迭以周为单位计算的年代，想靠 LangChain 包打天下，根本行不通。

夸张的说法也不是没有：

「在我的咨询工作中，我花了 70% 的精力用来劝退那些想用 LangChain 或 LlamaIndex 的人。光这一项，就解决了他们 90% 的问题。」

最近，一篇对 LangChain 的“吐槽文”再次引发了热议：

作者 Fabian Both，是 AI 测试工具 Octomind 的深度学习工程师。他们的团队使用多 LLM 驱动的 AI Agent，来自动创建和修复 Playwright 中的端到端测试。

这是一个跨度超过一年的故事——从最初选择 LangChain，到后来与它“顽强斗争”，最终在 2024 年，团队终于决定和它说再见。

看看他们到底经历了什么：

从 2023 年初开始，团队在生产环境使用 LangChain 超过 12 个月，然后在 2024 年将其彻底移除。

在 2023 年，LangChain 看起来确实是最佳选择——组件和工具琳琅满目，人气飙升。它承诺“一个下午就能让开发者从想法变成可运行代码”。但随着需求越来越复杂，麻烦也接踵而至。

LangChain 最终从生产力的源泉，变成了阻力的根源。

当 LangChain 的不灵活性逐渐暴露，团队不得不深入其内部结构，试图改善底层行为。但问题在于，LangChain 刻意把许多细节抽象化了，导致很难轻松编写所需的底层代码。

AI 和 LLM 领域的变化有多快，人所共知。每周都有新概念、新想法冒出来。而 LangChain 这种围绕多种新兴技术搭建的抽象框架，设计本身就很难经得起时间的考验。

起初，当需求简单且符合 LangChain 的使用假设时，它确实能帮上忙。但那些高级抽象很快就让代码变得难以理解，维护过程令人头疼。当团队花在理解、调试 LangChain 上的时间，和花在写功能上的时间一样多时，这已经是个危险信号了。

LangChain 的抽象问题有多严重？一个“把英语单词翻译成意大利语”的简单例子就能说清楚。

先看一个只用 OpenAI 包的 Python 示例：

代码清晰明了：一个类、一个函数调用，其余全是标准 Python 代码。

再看看 LangChain 的版本：

乍看差不多，但仔细看就发现问题了：

现在有了三个类和四个函数调用。关键是，LangChain 一口气引入了三个新的抽象概念：

• Prompt 模板
  ：给 LLM 提供 Prompt；

• 输出解析器
  ：处理 LLM 的输出；

• 链
  ：用 LCEL 语法重写了 Python 的 | 操作符。

一句话评价：LangChain 只是增加了代码复杂性，却看不到任何实际好处。

这种代码在早期原型阶段或许还能用，但在生产环境中，每个组件都必须被充分理解，才能确保它不会在实际使用中意外“崩掉”。开发者必须被迫遵循给定的数据结构，围绕着这些抽象来设计应用程序。

再看一个 Python 中不同的抽象对比——从 API 获取 JSON。

用内置的 http 包：

用 requests 包：

差距一目了然。这才是好的抽象应该有的感觉——简化代码，降低认知负荷。

当然，这些例子都很简单。但核心道理是相通的：好的抽象能让代码更简洁、更容易理解，而 LangChain 的抽象，却要求开发者为理解这些抽象付出额外的成本。

说到底，LangChain 试图通过隐藏细节、用更少的代码完成更多的事。但如果这种“省事”是以牺牲简单性和灵活性为代价，那抽象本身也就失去了价值。更糟的是，LangChain 还喜欢在抽象之上再叠抽象，开发者常常要从嵌套抽象的角度去思考如何正确使用 API。结果就是：不得不去理解庞大的堆栈跟踪、调试自己根本没写过的框架代码，而不是去实现新功能。

实际应用中，团队大量使用 AI Agent 来执行不同类型的任务——发现测试用例、生成 Playwright 测试、自动修复等等。

当打算从单一的 Sequential Agent 架构向更复杂的架构迁移时，LangChain 就变成了瓶颈。比如，生成 Sub-Agent 并让它们与原始 Agent 互动，或是让多个专业 Agent 互相协作，这些在 LangChain 里都变得异常困难。

另一个例子：团队需要根据业务逻辑和 LLM 输出，动态调整 Agent 可用的工具。但 LangChain 没有提供从外部观察 Agent 状态的方法，逼得团队只能缩小实现范围，去适应 LangChain Agent 有限的能力。

一旦我们删除了它，就不再需要把需求硬塞进 LangChain 的框子里了。我们只需编写代码即可。

那么，不用 LangChain 该用什么呢？答案是：也许根本不需要框架。

LangChain 在早期确实提供了 LLM 功能，让团队能专注于构建应用。但事后看来，如果没有框架，长期发展可能更好。

LangChain 那一长串的组件清单，容易给人造成一种错觉：构建一个 LLM 驱动的应用非常复杂。但实际上，大多数应用的核心组件就那么几样：

• 用于 LLM 通信的客户端

• 用于函数调用的函数/工具

• 用于 RAG 的向量数据库

• 用于跟踪、评估等的可观察性平台

Agent 领域正在快速演变，带来了许多令人兴奋的可能性。但在 Agent 的使用模式真正稳定下来之前，还是建议保持简单。今天 AI 领域的很多开发工作，本质上依然是实验和原型驱动的。

以上是 Fabian Both 的亲身经历，但 LangChain 也并非全无是处。

另一位开发者 Tim Valishev 表示，他还会再坚持用 LangChain 一段时间：

我真的很喜欢 Langsmith：

- 开箱即用的可视化日志
- Prompt playground，能立即根据日志修复 Prompt，并看效果
- 从日志中轻松构建测试数据集，一键运行简单测试
- 测试分数历史记录
- Prompt 版本控制

而且它对整个链的流式传输支持得很好，手动实现这些功能确实挺花时间的。

何况，完全依赖各家 API 也不现实——每家的大模型厂商 API 都不一样，根本做不到“无缝切换”。