为什么我们不用LangChain？

本文来自微信公众号： 叶小钗 ，作者：叶小钗

前面我们说过LangChain和LangGraph应该是开发者最推崇的Agent框架，也是在复杂场景下，最常见的AI Agent开发框架，他为开发者提供了从组件封装到流程编排的工具链。

并且随着LangChain 1.x与LangGraph 1.x的逐步完善，整个体系的生态分工与工程化实践也变得更清晰。

我们因为做AI 2B的业务，实际会做不同类型的项目，包括Demo、项目，但真正在业务中实践后，

我逐渐放弃了LangChain框架

，转向更贴近业务本身的开发方式。

当然，这并不是说LangChain不好，它能成为行业主流，肯定有其不可替代的价值。但技术选型从来不是追热点，关键要看是否真的适合你的项目。

框架的意义，最终还是要落到项目规模、业务需求和技术栈的匹配度上

今天，我就结合自己的实际经验，聊聊选择不用LangChain的几点理由，以及在做AI应用开发时，框架取舍的一些基本原则：

核心观点：AI编程时代，手写“胶水代码”成本极低，自研门槛已大幅下降

unsetunset我们需要AI开发框架吗unsetunset

在讨论需不需要AI框架之前，我们先看看什么是AI框架？

AI框架的本质，其实是给开发者提供一条标准化的路径，解决那些重复造轮子的问题，提升开发效率和团队协作的一致性。

开发AI应用时，有很多工作是通用的：比如LLM的调用封装、Prompt的管理、向量数据库的连接、各种工具链的接入（搜索、计算、数据库操作），还有对话历史的维护等等。

这些功能，在不同的项目中都有相似的实现方式，那么这些功能就能抽取出来成为底层框架。这也是框架的核心优势：

只不过，也是有一些局限性的：

所以，用不用框架，本质上是在开发效率和灵活可控之间找平衡。而找到这个平衡点的关键，就是看清楚你的项目规模和需求特点。

只不过就实践来说：多数团队是没有框架的维护能力的，这会导致升级或者碰到付费模块，会很吃力，甚至有推倒重来的风险。

接下来是不同项目类型的实际情况：

unsetunset小项目：原生开发更香unsetunset

如果是小项目、Demo验证，或者是内部工具开发，我一直都倾向于用原生开发，不引入框架。

这类场景的核心目标是快速验证想法或跑通业务流程，比如做个简单的对话机器人、PDF问答工具，或者文案生成助手。

这些功能本身比较单一，边界清晰，用不上复杂的架构设计。这时候引入LangChain，反而会增加不必要的复杂度，甚至Coze、Dify都是不错的选择......

小项目不推荐使用框架的原因也出来了：

总而言之，对于需要快速试错、频繁调整的小场景，原生开发其实是更务实的选择。

unsetunset中型/紧急项目：过渡方案unsetunset

对于功能明确、有固定上线时间，但团队规模与开发资源有限的中型项目（常涉及多轮对话、工具调用、检索等模块），LangChain是一个不错的选择，他可以

帮助团队在短时间内搭建出可运行的核心系统，快速验证项目。

LangChain提供了一个开箱即用的组件库，让团队能将精力集中在业务逻辑和差异化功能上，而不是重复实现基础功能。这会缩短通用模块的开发周期。

只不过项目成功上线、获得初步验证后，后续如果还需要持续开发和迭代，就需要评估是否需要对框架依赖部分进行重构，将业务逻辑与LangChain的通用实现解耦，以避免被框架绑定太深。

unsetunset大项目：有实力就自研unsetunset

当项目规模较大、维护和迭代预期都很多的时候，或者要作为公司核心基建对外提供能力时，放弃LangChain、转向自研框架几乎是必然的选择。

这时项目的核心诉求已经从“快速开发”转向了

稳定性、可扩展性、可运维性

，以及与公司现有技术体系的深度集成：

首先，LangChain的设计更偏向单体应用，内部模块耦合度较高。硬要拆成微服务，改造工作量很大；自研框架这里会灵活不少。

其次，我在之前一个公司落地的时候，他们就是使用LangChain，但是LangChain内置的日志和监控逻辑和公司已有的运维体系不兼容，出了问题排查起来很麻烦。他们又有点无力对框架进行改造，后面索性就自己自研了一套。

最后，LangChain作为第三方开源项目，其发展路线图、API变更、对特定模型或向量数据库的支持优先级，都不由您的团队掌控。

当框架进行不兼容的重大升级，或社区生态发生变化时，项目将面临被动升级和适配的风险，可能产生高昂的技术债。

说白了，大型项目追求的就是一个可控性嘛......

unsetunset技术栈的适配度unsetunset

这里还有个比较尴尬的问题，在企业级应用开发中，Java仍然是主流选择，比如金融、电商、政务等领域（PHP、Golang都有人用）：

而LangChain的代码生态是Python，如果非要去用可能会提高成本，这里以Java为例：

所以，如果公司技术栈是Java（PHP、Golang），选择Spring AI这类Java生态工具，或自研Java版AI框架，比强行用LangChain可能成本更低。

unsetunset框架更新问题unsetunset

AI领域的技术和业务需求迭代极快，而LangChain这类综合性框架，其庞大的体量和追求通用性的设计，决定了它的更新速度必然滞后于实际变化。这导致了几个关键矛盾：

一、新能力接入滞后，无法及时使用

当新的模型能力（如多模态、长上下文）或协议（如MCP）出现时，原生开发者可以立即跟进、快速试错。而框架用户只能等待官方适配，在竞争中处于被动。

二、通用抽象带来适配成本，难以发挥极致性能

框架通过统一的接口屏蔽了底层差异，这简化了基础开发，但也带来了新的复杂度。

当需要充分发挥某个模型的独有优势时，开发者往往需要通过model_kwargs或直接操作底层客户端来实现。

这个过程不仅需要同时理解原生API和框架的封装逻辑，还可能因为框架的更新滞后而无法第一时间用上最新特性。在追求极致性能或快速跟进前沿能力时，这种成本可能超过其收益。

创业项目需求可能在几周内连续发生变化。当业务逻辑需要突破框架预设的Chain、Agent等固定范式时，往往需要修改框架组件或自定义组件来适配，而多数团队是没有这个能力的。

框架的价值在于为稳定、通用的需求提效。

但在快速变化、需要深度利用特定技术或灵活调整业务逻辑的场景下，对框架的过度依赖会转化为一种负担。

unsetunset结语unsetunset

最后说下可能未来最重要的影响因子：AI编程带来的影响。

在过去，我们依赖LangChain，很大程度上是因为不想重复编写那些枯燥的API封装、Prompt拼接和错误处理代码、基础能力的封装。

但现在，情况完全不同了。

借助AI编程，我们可以在几分钟内生成一套标准化的LLM调用接口，或者快速实现一个带有重试机制的向量检索模块。

那些曾经需要耗费大量时间编写的“胶水代码”，现在只需要一句话指令就能自动生成。

自研一个轻量级、贴合业务的AI框架，其成本已经被AI工具极大地摊薄了。

当我们不再受限于手动编码的效率瓶颈时，与其花时间去学习和调试一个庞大复杂的第三方框架，不如利用AI辅助，快速构建一个完全受控、逻辑清晰且仅包含必要功能的最小化框架。

责任编辑：

文章来源：http://www.jingmeijuzi.com/2026/0202/2208.shtml