或许从诞生那天起，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