为什么都放弃了 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 SDK 的 Python 示例：
# 原生 Python 实现
response = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "Translate 'Hello' to Italian"}]
)
这是一段简单易懂的代码，只包含一个类和一个函数调用。其余部分都是标准的 Python 代码。
将其与 LangChain 的版本进行对比：
![图片：Python 原生翻译示例 vs LangChain 实现对比]
代码大致相同，但相似之处仅此而已。
我们现在有三个类和四个函数调用。但令人担忧的是，LangChain 引入了三个新的抽象概念：
- Prompt 模板：为 LLM 提供 Prompt；
- 输出解析器：处理来自 LLM 的输出；
- 链（Chain）：LangChain 的「LCEL 语法」覆盖 Python 的
|操作符。
LangChain 所做的只是增加了代码的复杂性，却没有带来任何明显的好处。
这种代码对于早期原型来说可能没什么问题。但对于生产使用，每个组件都必须得到合理的理解，这样在实际使用条件下才不至于意外崩溃。你必须遵守给定的数据结构，并围绕这些抽象设计应用程序。
让我们看看 Python 中的另一个抽象比较，这次是从 API 中获取 JSON。
使用内置的 http 包：
import http.client
conn = http.client.HTTPSConnection()
conn.request(, )
res = conn.getresponse()
data = res.read()
