出品丨AI 科技大本营（ID：rgznai100）
受益于工具而又受限于工具的例子很多，这次我们的主角是大模型应用开发的主流框架——LangChain。
最近一篇《为什么我们不再使用 LangChain 来构建我们的 AI Agents 》的博文，引起了开发者的广泛讨论。
该博文的作者 Fabian Both 是 AI 测试工具 Octomind 的深度学习工程师。Octomind 团队会使用具有多个 LLM 的 AI Agent 来自动创建和修复 Playwright 中的端到端测试。其团队丰富的实践经验和作者的亲身经历，让文章更具说服力。
诸多限制下，弃用 LangChain 海阔天空
一句话总结：受益于 LangChain 也受限于 LangChain，建议大家也不要用了！
Fabian 在文章中阐释了当抽象弊大于利时，在生产中使用 LangChain 的经验教训以及应该采取的措施。
他讲述了团队在生产中使用 LangChain 超过 12 个月，从 2023 年初开始，并于 2024 年将其移除的故事。
LangChain 在2023年是其团队的最佳选择，但随着项目要求变得越来越复杂，问题开始浮出水面，这“使 LangChain 成为摩擦源，而不是生产力。”
他举了将英语翻译成意大利语的例子，相比之下仅使用 OpenAI 包的 Python 示例比与 LangChain 的版本相比要简单得多。
使用 OpenAI 包的 Python 示例
使用 LangChain 的示例
LangChain 引入了三个新的抽象：
1、提示模板：为 LLM 提供提示
2、输出解析器：处理 LLM 的输出
3、Chains：LangChain 的“LCEL 语法”覆盖了 Python 的 `|` 运算符
由此可见，LangChain 徒增了代码的复杂性，而未带来任何明显的好处。
另一个例子是从 API 中获取 JSON：
使用内置的 http 包代码示例
使用请求包示例
后者的优势显而易见。作者表示：“但我的观点是，好的抽象可以简化你的代码，并减少理解代码所需的认知负担。”
“当我们想要从具有单个顺序代理的架构转变为更复杂的架构时，LangChain 是限制因素。
例如，生成子代理并让它们与原始代理交互。
或者多个专业代理相互交互。
”
Fabian 还在举出了另一个开发场景受限例子：“我们需要根据业务逻辑和 LLM 的输出动态更改代理可以访问的工具的可用性。但 LangChain 不提供从外部观察代理状态的方法，这导致我们缩小了实施范围以适应 LangChain 代理可用的有限功能。”
这一切的解决方法，就是放弃 LangChain：“一旦我们删除了它，我们就不再需要将我们的需求转化为适合 LangChain 的解决方案。我们只需编写代码即可。”
网友表示：臣附议！
一石激起千层浪，不少网友表示对该博文的内容很有共鸣。
有网友表示，自己在开发一个 RAG agent 因不用 LangChain 而遭受同事的质疑，终于有大佬站在自己这边：
“我在过去三个半月的实习时间里建立了一个RAG代理。公司里的每个人都问我为什么不用llangchain或者LlamaIndex，就像我是个疯子一样。在我的公司里，每个做RAG的人都用的是 LangChain ，有一个甚至进了Prod。
我一直告诉他们，如果你有一个标准的用例，它会工作得很好，但如果你需要一些原创的东西，你必须经历5层抽象，只是为了改变一个微小的细节。此外，你不会真正理解流程中的每一步，所以如果出现任何问题或者你需要改进流程，你将从头开始。这（篇博文）真的让我信心大增。”
“群体思维在程序员中非常普遍，尤其是当他们不知道自己在说什么的时候。这表明你不需要很多经验就能看出皇帝没有穿衣服，但你确实需要注意。”网友评论道。
有网友与该博文的作者有着相似经历：
“LangChain 刚问世时，我也有过类似的经历。我花了很多时间尝试使用它——包括做出一些贡献来添加我需要的功能——但最终放弃了它。这让我头疼。
大多数LLM应用程序只需要字符串处理、API调用、循环，如果你正在做RAG，可能还需要一个矢量DB。你不需要几个抽象层和一大堆依赖关系来管理基本的字符串插值、HTTP请求和for/while循环，尤其是在Python中。
在提示方面，除了一些很容易实现的基本技巧（如CoT、情境学习等)，提示是一种逐例迭代的方法，有效地使用提示主要依赖于理解这些模型是如何工作的，而不是模仿其他人正在使用的提示。LLM 应用程序在概念上并不是难以实现的应用程序，但它们很挑剔，很难控制，像 LangChain 这样的东西只会阻碍我。”
“也符合我的经验。大约一年前，我尝试过 LangChain 来开发一款应用，并且有一个相当标准的用例，但即使稍微偏离轨道，我也必须挖掘抽象层，而使用原始的 openai lib 会容易得多。因此，如果您的用例是在您的应用中提供许多不同的 LLM 提供程序，那么它可能会有所帮助，但如果您知道您不会很快更换 LLM 提供程序，那么最好不要使用这样的框架。”HN用户siva也如此表示。
认识到 LangChain 的不足，网友们构建了其他工具：
还有网友表示：“我没有使用过LangChain，但我感觉它真正帮助人们的是流处理和异步控制流。虽然有一些库可以使它变得更容易，但我认为在Python中正确地做这些事情就像在当前的潮流中游泳，因为它的历史主要是同步的、单线程的运行时。”
不用 LangChain 的情况下，该网友用 Go 语言构建了一个基于代理的 AI 编码工具。他表示，自己对这个选择非常满意。“虽然 LLM 相关的库和框架生态系统并不完善，但 Go 的并发原语让我可以轻松实现任何我需要的东西，而且我永远不必担心漏洞百出或难以理解的抽象。”
有网友还是赞同 LangChain 做出的贡献，并表示还有多重工具供选择：
“尽管人们不同意他们的一些设计选择，但我仍然钦佩 LangChain 团队的努力。OpenAI API 和其他 API 还很原始，开发人员很难抵制在其基础上构建抽象的诱惑。
在这次对话中，有些人将 Langchain 等库与 ORM 进行比较，但我认为也许更好的比较对象是 Web 框架。例如，Web/HTML/JSON 也“只是文本”，但你可能不想每次启动新项目时都重新发明一堆字符串和标头解析库。从 JS 生态系统来看，我想很多人都会喜欢像 Express 这样的轻量级库，它可以处理无聊的部分但不会妨碍工作。”
“现在用大模型解决的业务问题，多数都是小问题，几条 prompt、几轮对话的事儿。基于原生 API，自己匹配着需求设计架构，更清晰、灵活、可控。”AGIClass.ai & ChatALL.ai 创始人孙志岗表示，目前Agent开发的主要工作量在拆业务、整理数据、调 prompt 上，这些框架都帮不上什么忙（有些框架内置的 prompt 还可能帮倒忙）。“当开始搞复杂的工作流，多 Agent 协作，对框架的要求就上来了，LangChain 们的价值就大一些了。”
争议之下，依然是主流框架
不可否认的是，LangChain 一直以来在开发者中的口碑和影响力依旧。
在帮助开发者构建LLM应用的框架中，LangChain是最早且星标数最多的项目之一，在开源 LLM 开发框架领域占据领先地位。
LangChain的 GitHub 仓库星标数量显著 —— Python 版本87.9k
，JavaScript 版本11.7k
。
相比之下，同类项目如 AutoGen 目前有27.7k
颗星，LlamaIndex 有33k颗星。
GitHub 星数
在 LangChain 中一共有六大核心组件，分别是模型的输入输出 (Model I/O)、数据连接 (Data Connection)、内存记忆（Memory）、链（Chains）、代理（Agent）、回调（Callbacks）。LangChain 能解决大模型的两个痛点，包括模型接口复杂、输入长度受限于模块设计。
此外，LangChain 生态系统还包括多个相关开源项目。LangChain 为开发者提供了全面的 LLM 应用开发支持，涵盖从开发到部署的各个环节:
《LangChain入门指南》一书的作者李特丽总结道，LangChain 作为常用的大模型应用开发框架，LangChain 具有以下优势：
1. 强大的提示词工程构建功能
2. 实用的输出解析器
3. 丰富的RAG(检索增强生成)数据增强工具
同时，李特丽也指出了 LangChain 的一些缺陷：
1. 过度抽象:某些接口的抽象程度过高,新手可能难以理解源码,导致了对"源码解读"的需求。
2. 学习曲线陡峭:复杂的嵌套结构可能让初学者感到困惑。
3. 性能开销:在Agent场景下,使用LangChain可能会引入不必要的性能开销，Agent调用LLM API的次数很多。
4. 很多提示词工程，没有对中文支持。
“LangChain 封装了比如说React这些框架，也是让初学者能够迅速的就开发出来一个还能够做DEMO的agent，但不是说真正能够用在生产的这个级别。”新加坡科研局资深研究员、《GPT图解 大模型是怎样构建的》作者黄佳表示，“但是现在又真正有多少的agent就能够投入到生产中呢？其实也不多。”
同时，争议带来了热度上涨。谷歌搜索趋势显示，近期 LangChain的全球热度是远超其他框架，且在不断攀升。
LangChain 中文网创始人康轶文表示：“一边使用一边吐槽，这也许是产品发展的最佳土壤。”
在这些正或负向的反馈下，LangChain 正在不断迭代更新：3到6月一次大更新，每天都在做小更新。
康轶文表示：“ LangChain 本来就是为了方便普通程序员转向LLM应用开发的一个框架，本身会隐藏一些代码到背后让前端代码显得简单，但是在某些深层需求时，就变得很麻烦和难维护。”
“像许多高度集成的框架一样，LangChain 也面临一些挑战。最显著的是其“黑盒”特性 —— 某些内部工作机制对开发者来说可能不够透明。为了应对这一问题，LangChain 从 0.1 版本开始大力推广 LangChain Expression Language (LCEL) 语法。LCEL 旨在使 LLM 逻辑流程更直接、更清晰，增强了框架的可理解性和可控性。”
驭势科技云平台研发总监
张海立表示。
对此，官方已经意识到这一点了，并在0.1版本和0.2版本上都做了很大的改进。“LangChain 拿了融资以后我们看到他在积极的改进这些，我们已经看到的他的正在转变，从单纯的开发到整体的运维，这种进步也是业界领先的。”他表示。
孙志岗就是其贡献者之一。“记得我给 LangChain JS 贡献代码的时候，有个统计 token 数的 bug 解决不了，问 reviewer 建议，他直接说这个不重要，然后就把我的代码 merge 了。某种程度来说，业内最新的技术、方法论，LangChain 都会第一时间融入进来。所以看看 LangChain 的 release notes 和博客，能学到不少东西。比如 Rerank 我就是从 LangChain 学到的。然后，对感兴趣的可以马上在 LangChain 里用一下，找找体感，做个 demo，速度很快。”
李特丽也表示：“LangChain 0.2版本的更新降低了模块间的耦合度，使得开发者能更方便地使用其封装好的工具函数。值得一提的是，吴恩达团队的多个项目都使用了LangChain的模块，如最近开源的翻译Agent项目就使用了LangChain的文本分割模块。”
还需要使用 Langchain 一类的框架吗？专家：看需求和段位！
在博文的结尾，作者提出了一个更深层的提问：“我们真的需要一个用于构建 AI 应用程序的框架吗？”
对此他表示：“LangChain 早期通过提供 LLM 功能帮助了我们，让我们可以专注于构建应用程序。但事后看来，长期来看，如果没有框架，我们的处境会更好。”
他建议道：“如果你在没有框架的情况下开始你的人工智能开发之旅，那么你需要花更长的时间来整合你自己的工具箱，并且需要更多的前期学习和研究。但这是值得的，也是对你和你的应用程序未来的一项值得的投资，因为你正在学习你将要操作的领域的基础知识。”
对此，专家们表达了在不同立场和需求下的观点。
“Langchain定义的一套开发概念，某些程度会和有经验的开发者产生冲突，让这部分人觉得不顺手。”康轶文表示，网站社群里也有用户从早期使用、到现在不用并开始转为自己的框架，“LLM开发是一定会用到框架的，这个是确定的，但框架长什么样子顺不顺手每个人的要求标准都不一样。”
“顶级大厨可以用一把菜刀做所有的事，他会觉得没必要这么多辅助工具。而刚入门的厨师会需要买各种刀具来提升效率和水平。”康轶文比喻道。
李特丽表示：
-
对于经验丰富的开发者，在简单场景下,直接使用LLM API和向量数据库可能更加高效和灵活。
-
对于新手开发者来说，AI应用框架如 LangChain 可以降低学习门槛，提供最佳实践和解决方案框架能帮助新手处理接口错误、延迟和重试等复杂问题使用框架可以让新手更快地理解LLM应用开发的整体架构和关键概念。
这样的区分并非绝对，李特丽还解释了框架工具提供的长期价值和灵活性：“即使经验丰富的开发者也可能从使用框架中获益，如文章作者在使用 LangChain 一年后才完全脱离框架提供的抽象和工具可以加速开发过程，特别是在复杂项目中。而随着项目复杂度增加，框架提供的工具和抽象可能会变得更有价值开发者
