LangChain：并非完美的选择

在自然语言处理和人工智能领域，LangChain 曾经被寄予厚望，作为一个开源框架，它旨在支持开发者构建由 LLM 驱动的应用程序。然而，实际使用中却发现，LangChain 并没有想象中那么好用。

LangChain 提供了一系列组件和工具，试图让开发者能够更轻松地构建各种应用。例如，借助 LangChain，开发者可以尝试用 GPT - 4 开发旅行顾问机器人，使其能够链接到各种 API 和外部数据库，并根据用户的偏好和对话历史提供个性化建议。这听起来很不错，但在实际应用中，问题逐渐浮现。

一个使用 LangChain 超过 12 个月的技术团队发现，随着需求变得复杂，LangChain 的不灵活性成为了阻碍。其抽象程度过高，导致在开发初期，简单需求尚能满足，但随着项目推进，代码变得难以理解和维护。团队不得不花费大量时间去理解和调试 LangChain，这几乎占据了与构建功能相当的时间。

以翻译任务为例，使用 OpenAI 的包编写的代码简洁易懂，而使用 LangChain 则需要引入提示模板、输出解析器和链等抽象概念，增加了代码的复杂性，却未带来明显优势。从 API 获取 JSON 的任务中，Python 内置的 http 包和 requests 包的写法都比 LangChain 更为简洁。

此外，LangChain 习惯“嵌套抽象”，这使得学习 API 变得更加复杂，开发人员还需面对大量堆栈跟踪信息和不熟悉的内部框架代码进行调试。当技术团队想要构建更复杂的架构，如实现多个 agent 相互交互时，LangChain 成为了限制因素。而且，LangChain 没有提供从外部观察 agent 状态的方法，导致团队不得不缩小实现范围。

尽管 LangChain 的初衷是好的，希望隐藏细节，让开发人员用更少的代码完成更多功能，但实际效果却不尽如人意。如果代价是失去开发的简洁和灵活，那么这种抽象就失去了意义。

事后，该技术团队反思认为，不使用框架可能是更好的选择。虽然这会增加前期学习和调研的工作量，但能让开发者在即将进入的领域打下更坚实的基础。而且，在很多情况下，使用 LLM 的流程可以通过简洁的代码和较小的外部包集合来实现，不一定需要依赖框架。

当然，我们也不能完全否定 LangChain 的价值，在某些简单场景或早期原型开发中，它可能仍然具有一定的作用。但在面对复杂需求和实际生产环境时，开发者需要谨慎考虑是否选择 LangChain。

总之，LangChain 并不是一个完美的解决方案，开发者在选择时应根据具体需求权衡利弊，寻找最适合自己项目的技术工具。

希望本文能为广大开发者提供一些参考，在技术选型时做出更明智的决策。