为什么都放弃了LangChain？

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

看好 LangChain 的人欣赏它丰富的工具和组建和易于集成等特点，不看好 LangChain 的人，认为它注定失败 —— 在这个技术变化如此之快的年代，用 LangChain 来构建一切根本行不通。

夸张点的还有：

「在我的咨询工作中，我花了 70% 的精力来说服人们不要使用 langchain 或 llamaindex。这解决了他们 90% 的问题。」

最近，一篇 LangChain 吐槽文再次成为热议焦点：

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

这是一个持续一年多的故事，从选择 LangChain 开始，随后进入到了与 LangChain 顽强斗争的阶段。在 2024 年，他们终于决定告别 LangChain。

让我们看看他们经历了什么：

「LangChain 曾是最佳选择」

我们在生产中使用 LangChain 超过 12 个月，从 2023 年初开始使用，然后在 2024 年将其移除。

在 2023 年，LangChain 似乎是我们的最佳选择。它拥有一系列令人印象深刻的组件和工具，而且人气飙升。LangChain 承诺「让开发人员一个下午就能从一个想法变成可运行的代码」，但随着我们的需求变得越来越复杂，问题也开始浮出水面。

LangChain 变成了阻力的根源，而不是生产力的根源。

随着 LangChain 的不灵活性开始显现，我们开始深入研究 LangChain 的内部结构，以改进系统的底层行为。但是，由于 LangChain 故意将许多细节做得很抽象，我们无法轻松编写所需的底层代码。

众所周知，人工智能和 LLM 是瞬息万变的领域，每周都会有新的概念和想法出现。而 LangChain 这样围绕多种新兴技术创建的抽象概念，其框架设计很难经得起时间考验。

LangChain 为什么如此抽象

起初，当我们的简单需求与 LangChain 的使用假设相吻合时，LangChain 还能帮上忙。但它的高级抽象很快就让我们的代码变得更加难以理解，维护过程也令人沮丧。当团队用在理解和调试 LangChain 的时间和用在构建功能上的时间一样时，这可不是一个好兆头。

LangChain 的抽象方法所存在的问题，可以通过「将一个英语单词翻译成意大利语」这一微不足道的示例来说明。

下面是一个仅使用 OpenAI 软件包的 Python 示例：

这是一段简单易懂的代码，只包含一个类和一个函数调用。其余部分都是标准的 Python 代码。

将其与 LangChain 的版本进行对比：

代码大致相同，但相似之处仅此而已。

我们现在有三个类和四个函数调用。但令人担忧的是，LangChain 引入了三个新的抽象概念：

• Prompt 模板： 为 LLM 提供 Prompt；

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

• 链： LangChain 的「LCEL 语法」覆盖 Python 的 | 操作符。

LangChain 所做的只是增加了代码的复杂性，却没有带来任何明显的好处。

这种代码对于早期原型来说可能没什么问题。但对于生产使用，每个组件都必须得到合理的理解，这样在实际使用条件下才不至于意外崩溃。你必须遵守给定的数据结构，并围绕这些抽象设计应用程序。

让我们看看 Python 中的另一个抽象比较，这次是从 API 中获取 JSON。

使用内置的 http 包：

使用 requests 包：

高下显而易见。这就是好的抽象的感觉。

当然，这些都是微不足道的例子。但我想说的是，好的抽象可以简化代码，减少理解代码所需的认知负荷。

LangChain 试图通过隐藏细节，用更少的代码完成更多的工作，让你的生活变得更轻松。但是，如果这是以牺牲简单性和灵活性为代价的，那么抽象就失去了价值。

LangChain 还习惯于在其他抽象之上使用抽象，因此你往往不得不从嵌套抽象的角度来思考如何正确使用 API。这不可避免地会导致理解庞大的堆栈跟踪和调试你没有编写的内部框架代码，而不是实现新功能。

LangChain 对开发团队的影响

一般来说，应用程序大量使用 AI Agent 来执行不同类型的任务，如发现测试用例、生成 Playwright 测试和自动修复。

当我们想从单一 Sequential Agent 的架构转向更复杂的架构时，LangChain 成为了限制因素。例如，生成 Sub-Agent 并让它们与原始 Agent 互动。或者多个专业 Agent 相互交互。

在另一个例子中，我们需要根据业务逻辑和 LLM 的输出，动态改变 Agent 可以访问的工具的可用性。但是 LangChain 并没有提供从外部观察 Agent 状态的方法，这导致我们不得不缩小实现范围，以适应 LangChain Agent 的有限功能。

一旦我们删除了它，我们就不再需要将我们的需求转化为适合 LangChain 的解决方案。我们只需编写代码即可。

那么，如果不使用 LangChain，你应该使用什么框架呢？也许你根本不需要框架。

我们真的需要构建人工智能应用程序的框架吗？

LangChain 在早期为我们提供了 LLM 功能，让我们可以专注于构建应用程序。但事后看来，如果没有框架，我们的长期发展会更好。

LangChain 一长串的组件给人的印象是，构建一个由 LLM 驱动的应用程序非常复杂。但大多数应用程序所需的核心组件通常如下：

• 用于 LLM 通信的客户端

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

• 用于 RAG 的向量数据库

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

Agent 领域正在快速发展，带来了令人兴奋的可能性和有趣的用例，但我们建议 —— 在 Agent 的使用模式得到巩固之前，暂时保持简单。人工智能领域的许多开发工作都是由实验和原型设计驱动的。

以上是 Fabian Both 一年多来的切身体会，但 LangChain 并非全然没有可取之处。

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

我真的很喜欢 Langsmith：

• 开箱即用的可视化日志 

• Prompt playground，可以立即从日志中修复 Prompt，并查看它在相同输入下的表现 

• 可直接从日志轻松构建测试数据集，并可选择一键运行 Prompt 中的简单测试集（或在代码中进行端到端测试） 

• 测试分数历史 

• Prompt 版本控制 

而且它对整个链的流式传输提供了很好的支持，手动实现这一点需要一些时间。

何况，只依靠 API 也是不行的，每家大模型厂商的 API 都不同，并不能「无缝切换」。

你怎么看？

^{原文链接：https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents}