作者 | 王轶群
责编 | 唐小引
出品丨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，自己匹配着需求设计架构，更清晰、灵活、可控。」AGI class.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 应用开发支持，涵盖从开发到部署的各个环节:
LangGraph：专注于 Agentic 应用开发的框架
LangServe：用于构建微服务的框架
LangSmith：全生命周期可观测性平台
【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 一年后才完全脱离框架提供的抽象和工具可以加速开发过程，特别是在复杂项目中。而随着项目复杂度增加，框架提供的工具和抽象可能会变得更有价值开发者 可以根据需求选择性地使用框架的某些组件，而不必完全依赖。」
孙志岗认为： 「在试验新技术、原型验证、快速搭 demo 的场景里，框架是有用的，能节省时间。 在应用了复杂的工作流、多 Agent 产品里，长期来看也需要稳定的框架支撑 。 」
「对于有些场景来说，直接调大模型的API，不管是 OpenAI 的 API，还是本地模型的API，都可以直接解决问题的时候并不需要 LangChain。」黄佳表示。对于是否还需要框架他表示：「尤其是 RAG 这个场景，我认为有框架比较好，但是 LangChain 并不一定是做的最好的框架。」
张海立也表示：「RAG 和 Agent 技术的未来发展很大程度上依赖于核心流程和算法的创新。在这个背景下，LangChain、LlamaIndex 等 AI 应用框架应被视为强大的工具集，而非黑盒解决方案。」他认为，开发者应谨慎使用框架中的封装组件，深入理解这些组件的工作原理，而不是简单地依赖它们。
具体的建议是：
关注底层开发框架：LCEL 和 LangGraph 等相对透明的「底层」开发框架值得开发者重点关注。这些工具提供了构建复杂 LLM 应用所需的灵活性和可控性。
利用开源资源：LangChain 团队基于这些底层能力实现了多种广受认可的 RAG 和 Agent 算法。开发者可以在 LangGraph 官方文档（ https://langchain-ai.github.io/langgraph/ ）中找到这些实现，作为学习和创新的起点。
平衡效率与控制：虽然直接使用 API 可能看似更直接，但框架提供的抽象和工具可以显著提高开发效率,特别是在处理复杂场景时。关键是要在使用框架提供的便利和保持对底层逻辑的控制之间找到平衡。
考虑长期维护：在选择开发方法时，要考虑到长期的可维护性和可扩展性。成熟的框架通常提供了更好的文档、社区支持和长期更新，这在维护大型项目时尤为重要。
虽然说法不一，但在最后大家得出了一个共同的结论：AI 应用框架和直接 API 调用各有其适用场景，选择哪种方式应该基于开发者的项目需求、团队经验和长期维护做考虑。
同样，相应开发者需求的 LangChain 也在做着更多改进。
对于未来趋向，张海立表示，LangChain 的发展轨迹可能会集中在两个方向:
LangChain 将继续深化其生态系统，特别是在支持从原型到生产的无缝过渡方面。其中，作为 LangChain 的核心流程开发框架的LangGraph Cloud 的开发就是这一战略的具体体现。LangGraph 的一个显著优势在于其提供了相对底层的 Agent 流程及算法开发框架。虽然这增加了学习曲线的陡峭度，但也为开发者提供了极大的灵活性和创新空间。
进一步强化其在 AI 应用全生命周期管理方面的能力，包括但不限于改进模型评估方法、优化资源使用效率，以及增强与各种 LLM 和工具的集成能力。
李特丽补充道，LangChain 未来发展还将关注「采用优胜劣汰的生态发展策略,将有价值的工具插件提升至核心模块；积极响应主要大模型厂商的更新；关注解决开发者在实际项用中遇到的问题,如支持多个大模型之间的结果互通」等。
对于 LangChain 等原生 Agent 架构发展趋势，李特丽指出了两点趋势：「各大模型厂商将普遍支持类似GPTs的功能，使用户能通过提示词构建个性化Agent。框架重点将转向解决多Agent间的交互和数据流通问题。」
「现在大模型还处于早期，变数很大，没形成固定的套路。需要一段时间沉淀下最佳实践，框架才有更大发挥空间。只不过，因为大模型抽象层高、API 简单这一特点，我认为大模型开发框架在未来，不大可能像 Vue、React 那样成为标准一样地存在。」孙志岗表示。
工具总有千般利弊，但工具的开发与使用的人才是关键。要理解并充分利用这些工具、改进工具、创造更多工具，而不是受其限制。
参考链接：
https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents
https://news.ycombinator.com/item?id=40739982
https://blog.csdn.net/2301_81940605/article/details/137627288
由 CSDN 和 Boolan 联合主办的「2024 全球软件研发技术大会（SDCon）」将于 7 月 4 - 5 日在北京威斯汀酒店举行。
由世界著名软件架构大师、云原生和微服务领域技术先驱 Chris Richardson 和 MIT 计算机与 AI 实验室(CSAIL)副主任，ACM Fellow Daniel Jackson 领衔，BAT、微软、字节跳动、小米等技术专家将齐聚一堂，共同探讨软件开发的最前沿趋势与技术实践。
大会官网： http://sdcon.com.cn/ （可点击 阅读原文 直达）
