为什么都放弃了LangChain？

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

看好它的人，欣赏其丰富的工具箱、组件以及易于集成的特性；不看好它的人，则认为这条路走不远——在这个技术迭代快到离谱的时代，指望 LangChain 来搞定一切，根本行不通。

更夸张的评价也有，比如：「在我的咨询工作里，70% 的精力都花在说服客户别用 LangChain 或 LlamaIndex，这一下子解决了他们 90% 的问题。」

最近，一篇深度吐槽 LangChain 的技术文章再次引发热议。

作者 Fabian Both 是 AI 测试工具 Octomind 的深度学习工程师。他的团队利用多个 LLM 的 AI Agent 来创建并修复 Playwright 端的端到端测试。这篇文章记录了一个持续一年多的故事——从最初选择 LangChain，到与之顽强抗争，最终在 2024 年彻底告别。

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

「LangChain 曾是最佳选择」

团队在生产环境中与 LangChain 共处了超过 12 个月——从 2023 年初开始使用，到 2024 年彻底移除。回顾彼时，LangChain 看起来确实是最佳选择。它拥有令人印象深刻的组件和工具，人气水涨船高。LangChain 承诺「让开发者一个下午就从想法变成可运行的代码」，但随着业务需求变得复杂，问题也逐渐浮出水面。

LangChain 从生产工具，变成了阻力，而不是驱动力。

随着其不灵活性日益突出，团队不得不深入 LangChain 的内部，试图改进系统的底层行为。但 LangChain 故意将许多细节抽象得极其模糊，导致我们根本无法轻松编写所需要的底层代码。众所周知，AI 和 LLM 领域日新月异，每周都有新概念和新想法诞生。围绕如此多样的新兴技术构建的抽象层，其框架设计显然很难经得起时间的考验。

LangChain 为什么如此抽象

起初，当团队的需求恰好符合 LangChain 的使用假设时，它确实能派上用场。但很快，它的高级抽象就让代码变得愈发难以理解，维护过程令人头疼。当团队用在理解和调试 LangChain 上的时间，和用在构建功能上的时间一样多时，这绝非好兆头。

LangChain 抽象方法的问题，可以通过一个简单的示例——将英文单词翻译成意大利语——来直观说明。

下面是一个仅使用 OpenAI 包的 Python 版本：

这段代码一目了然，只有一个类加一个函数调用，其余部分都是标准 Python 处理流程。

对比之下，LangChain 的版本是这样的：

代码量大致相当。但关键区别在于——LangChain 引入了三个新的抽象概念：

• Prompt 模板：用来给 LLM 提供 Prompt
• 输出解析器：用来处理 LLM 的输出
• 链：LangChain 的 LCEL 语法，覆盖了 Python 的 | 操作符

结果就是，代码复杂性上升了，但并没有带来任何明显的收益。这种写法对于早期原型也许尚可，但在生产环境中，每个组件都必须扎实理解，才不至于在实际使用条件下意外崩溃。你必须严格遵守给定的数据结构，并围绕这些抽象来设计应用。

再来看另一个抽象对比：从 API 中获取 JSON。使用内置的 http 包：

使用 requests 包：

高下立判。这才是好抽象应该带给人的感受。

当然，这些都是很小的例子，但足以说明问题——好的抽象能简化代码，减少理解代码所需的认知负荷。LangChain 试图通过隐藏细节，用更少的代码完成更多的工作，这本意是好的。但如果这种简化是以牺牲简单性和灵活性为代价，那么抽象本身就失去了价值。更糟糕的是，LangChain 习惯在抽象之上叠抽象，开发者不得不从层层嵌套的抽象思考如何正确调用 API。结果就是，面对庞大的堆栈跟踪，花大量时间调试自己根本没写过的框架内部代码，而不是实现新功能。

LangChain 对开发团队的影响

在 Octomind 的系统中，AI Agent 被大量用于发现测试用例、生成 Playwright 测试以及自动修复等任务。当团队计划从单一的 Sequential Agent 架构转向更复杂的架构（比如生成 Sub-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 彼此不同，无法做到「无缝切换」。