原贴链接

2025年Langchain仍然像是一个谜团，Langgraph框架也是如此。不知道是只有我这么想还是其他人也这么觉得呢？我发现与其花数小时在这些框架里摸索，一种丑陋的硬编码方式反而实现起来更快。我知道硬编码的东西难以维护，但考虑到Langchain在0.1、0.2、0.3版本中的重大变更，不管怎样都难以维护。

编辑： 抱歉我发帖时语言可能不太友好，因为那天我过得很糟糕。事情是这样的：我试图构建一个自动工作流来做一些事。就像大家说的，代理与大型语言模型（LLM）结合是未来之类的……不管怎样，我开始寻找一个工作流框架。有Dify、Langflow、Flowise、Pyspur、Laminar、Comfyui_LLM_party……但我选择了Langgraph，因为它们或多或少基于代码，不需要为一个简单演示设置像Clickhouse这样的东西，而且我可以编写自定义节点。

于是我一头扎了进去。就像r/LocalLLaMA中的每个人一样，我不喜欢OpenAI或其他大型语言模型（LLM）提供商，我想自己托管实例并确保我的数据属于我自己。所以我选择了llama.cpp（我已经玩了一段时间了）。然后我的糟糕日子就来了：

llama.cpp：与OpenAI兼容的API在工具调用方面表现不佳，参考https://github.com/ggml-org/llama.cpp/issues/11988和https://github.com/ggml-org/llama.cpp/issues/11847；llama.cpp：Jinja模板仍然有漏洞，参考https://github.com/ggml-org/llama.cpp/issues/11938；llama.cpp：工具调用不返回工具调用ID，参考https://github.com/ggml-org/llama.cpp/issues/11992。

我只是想构建一个带有工具调用的自定义工作流，使用我的llama.cpp，有能与我当前项目集成的自定义节点/函数，为什么就这么难……

讨论总结

原帖作者认为langchain在2025年仍然是个“兔子洞”，在其中探索很困难且耗费时间，还讲述了自己构建自动工作流时遇到的各种问题。评论者们大多对langchain持负面态度，认为它存在文档更新不及时、过度设计、集成困难、概念过载等诸多问题，在很多项目中过于复杂而缺乏实用性，是过去的遗留产物，不建议使用。也有部分评论者分享了自己开发框架的经验或者推荐了其他替代方案。

主要观点

  1. 👍 langchain在多数项目中过于复杂而缺乏实用性
    • 支持理由：很多人持有LangChain不太有用的观点，如在构建简单的RAG聊天机器人之类的东西时是过度设计，框架在多数情况下是大材小用。
    • 反对声音：无
  2. 🔥 langchain存在文档更新不及时的问题
    • 正方观点：有评论者指出在阅读一个句子这么短的时间内就发生了类被弃用而文档不更新的情况，可能会给使用者带来不便。
    • 反方观点：无
  3. 💡 硬编码方式比花时间研究langchain框架实现功能更快
    • 解释：很多评论者提到，虽然硬编码难以维护，但考虑到langchain版本更迭带来的不兼容性，硬编码在某些情况下实现功能更快。
  4. 🤔 langchain是过度框架化的开发方法
    • 解释：部分评论者认为LangChain这种开发方式过度框架化，自己不喜欢这种方式，并且在使用过程中遇到诸多问题。
  5. 😒 langchain集成困难且过于臃肿、过度抽象化
    • 解释：有评论者直接表达了对Langchain在集成方面的负面看法，认为它过于臃肿且过度抽象化。

金句与有趣评论

  1. “😂 In the time it took to read this sentence langchain deprecated 4 classes without updating documentation.”
    • 亮点：用夸张的手法强调了langchain文档更新不及时的问题。
  2. “🤔 Langchain, ugh. Don’t even bother with that one.”
    • 亮点：简洁地表达了对langchain的否定态度。
  3. “👀 2000% yes. Do not stare into the abyss that is langchain, else you become the abyss.”
    • 亮点：强烈赞同原帖观点，并用形象的比喻形容深入langchain是一种危险（浪费时间）的行为。
  4. “😎 Instead of spending hours going through the rabbit holes in these frameworks, I found out an ugly hard coded way is faster to implement.”
    • 亮点：提出了硬编码这种不同于使用框架的实现方式，且表明其在速度上可能更有优势。
  5. “💡 Lang chain was ahead of it’s time and tried to be everything to everyone.”
    • 亮点：从独特的角度分析了langchain试图满足所有人需求这种做法的不合理性。

情感分析

总体情感倾向为负面。主要分歧点较少，大多数评论者都对langchain持批评态度，认为它存在各种问题，如复杂难用、文档差、过度设计等。可能的原因是很多人在使用langchain的过程中确实遇到了诸如技术问题、维护困难等诸多不便，导致对其评价较低。

趋势与预测

  • 新兴话题：一些新的框架（如Langroid等）可能会引发后续讨论，以及人们对如何构建适合自己需求的框架会有更多探讨。
  • 潜在影响：如果更多人认识到langchain存在的问题，可能会导致其在相关领域的使用率下降，而促使开发者们寻找或开发更实用、高效的替代方案，对整个LLM开发和应用的框架选择产生影响。

详细内容：

标题：《Langchain 与相关框架在 2025 年引发的热议》

在 Reddit 上，一则题为“langchain is still a rabbit hole in 2025”的帖子引发了广泛关注，获得了众多点赞和大量评论。帖子作者表示，langchain 及其相关的 langgraph 框架宛如“兔子洞”，让人深陷其中。作者本想构建一个带有工具调用的自定义工作流，却遭遇了一系列难题，如 llama.cpp 的兼容性问题等，不禁感叹实现起来为何如此艰难。

讨论的焦点主要集中在对 langchain 及相关框架的看法上。有人认为，langchain 的文档混乱，类的更新过快且未及时更新文档。有用户分享自己在面试中因使用已过时的 langchain 方法而失败的经历。还有人指出，langchain 就像一个华而不实的礼盒，外表诱人，实则内部糟糕，是对时间的极大浪费。

例如，有用户说：“在读完这句话的时间里，langchain 就废弃了 4 个类，却没有更新文档。”还有用户表示：“我曾经因为不小心使用了过时的 langchain 方法，导致面试失败。代码在面试官的机器上无法运行，当我说‘哦，这很奇怪，它在我的机器上运行’时，他说我在撒谎。”

也有不同的声音，有人觉得对于某些特定的工作流构建，langchain 可能是最佳选择。但总体而言，更多的人认为直接调用 OpenAI 兼容的 API 或者自己编写代码更为有效。

那么，在众多观点和经历中，我们应该如何看待这些框架？是继续探索其可能的优势，还是果断抛弃选择更直接的方式？这值得我们进一步思考。