我们为什么不选择使用LangChain？

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

此前我们聊过，LangChain和LangGraph是当下开发者圈子里认可度极高的Agent开发框架，也是复杂AI Agent开发场景下最常用的工具，它给开发者提供了从组件封装到流程编排的完整工具链：

而且随着LangChain 1.x和LangGraph 1.x版本陆续迭代完善，整个生态的分工和工程化落地逻辑也越来越清晰。

我们团队一直做AI 2B业务，落地过不同规模的项目，从Demo到正式交付项目都有接触，但在实际业务中摸爬滚打之后，我反而逐渐放弃了LangChain，转而用更贴合自身业务的原生方式开发。

当然，这并不是说LangChain本身不好，它能成为行业主流，肯定有不可替代的优势。但技术选型从来不是追热点，核心还是要看框架能不能匹配你的项目需求。

框架的价值，最终还是要结合项目规模、业务需求和现有技术栈来判断

今天我就结合自己的实际落地经验，聊聊我们放弃LangChain的具体原因，以及做AI应用开发时，选择框架的一些核心原则：

1. 小型项目/Demo：直接调用大模型原生API开发，灵活没有额外依赖，整体成本更低。

   
   

   
   

2. 中型项目/赶工期项目：可以用LangChain快速搭建项目骨架，但要警惕后续的维护成本。

   
   

   
   

3. 大型/企业级项目：强烈建议自研适配自身业务的框架，更好匹配微服务架构和公司现有基建。

   
   

   
   

核心观点：进入AI编程时代之后，手写“胶水代码”的成本已经极低，自研适配业务的轻量框架门槛也大幅降低了

我们真的需要通用AI开发框架吗

讨论要不要用通用AI框架之前，我们先理清楚，AI框架到底解决什么问题？

AI框架的本质，是给开发者提供一套标准化的开发路径，避免大家重复造轮子，同时提升开发效率，统一团队协作的开发规范。

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

这些功能在不同项目里的实现逻辑高度相似，因此可以把这些通用能力抽离出来做成底层框架，这也是通用框架的核心优势：

1. 提升开发效率：哪怕是不熟悉底层细节的开发者，也能通过少量代码实现复杂功能，避开很多常见的坑。

   
   

   
   

2. 统一开发规范：团队协作的时候，大家遵循同一套开发范式，沟通和代码整合的成本会低很多。

   
   

   
   

3. 生态成熟开箱即用：框架一般都提前集成了主流的工具（比如OpenAI、Pinecone、Chroma），省去了开发者自己对接第三方接口的工作量。

   
   

   
   

但通用框架也存在无法忽视的局限性：

1. 灵活性不足：为了适配五花八门的场景，框架往往会加很多抽象层和依赖，不仅拉高了项目复杂度，还可能带来性能冗余。

   
   

   
   

2. 预设逻辑束缚开发：当业务需要做个性化调整的时候，框架预设的逻辑往往会变成绊脚石，改起来甚至比重写一遍还要麻烦。

   
   

   
   

3. 实际学习成本不低：表面上降低了入门门槛，但想要真的用好、解决实际问题，还是得把框架的运行逻辑摸透，否则很容易变成只会调API，不懂底层原理，出了问题根本不知道该怎么排查。

   
   

   
   

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

但从实际落地经验来看，大部分团队其实都没有维护第三方框架的能力，碰到框架升级或者需要付费模块的时候，会非常吃力，甚至有整个项目推倒重来的风险。

接下来我们就结合不同规模的项目，具体聊聊这个问题：

小项目：原生开发体验更好

如果是做小项目、Demo验证，或者开发内部工具，我一直更推荐用原生开发，不要引入额外的第三方框架。

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

这些功能本身比较单一，边界清晰，不需要复杂的架构设计。这个时候引入LangChain，反而会增加不必要的复杂度，哪怕是用Coze、Dify这类低代码工具都比直接引入框架更合适......

小项目不推荐用通用框架的原因很明确：

1. 需求变动频繁：小项目的需求经常调整，可能过两周就要加会话记忆功能，或者换一家大模型供应商。用框架开发的话，每次改需求都得先想怎么适配框架的规则，原生开发就没有这个束缚，直接改核心逻辑就行。

   
   

   
   

2. 追求轻量高效：小项目要的是能用、好用，不需要追求标准化或者扩展性。

   
   

   
   

3. 方便定制优化：原生开发可以让你完全掌控所有代码，既避免了框架带来的依赖膨胀，又能针对具体场景做优化，比如删掉不必要的中间调用、定制符合自己需求的Prompt模板。

   
   

   
   

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

中型/紧急项目：可以做过渡方案

对于需求明确、有固定上线时间，但团队规模和开发资源有限的中型项目（一般会涉及多轮对话、工具调用、检索等模块），LangChain是一个不错的选择，它可以帮助团队在短时间内搭建出可运行的核心系统，快速完成项目验证。

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

但在项目成功上线、拿到初步验证结果后，如果后续还要持续开发迭代，就需要评估要不要把依赖框架的部分做重构，把业务逻辑和LangChain的通用实现解耦，避免被框架绑定得太深。

具体落地可以参考这几个建议：

1. 按需选用，最小化依赖：不要全盘接入框架，先明确评估需求，只引入你需要的模块。比如可以单独用它的Prompt模板管理和工具调用封装，编排流程或者记忆模块就自己开发，更可控。

   
   

   
   

2. 提前规划替换路径：在做架构设计的时候，就给未来替换LangChain预留好接口。比如用抽象层或者适配器模式封装对LangChain的调用，保证后续可以平滑替换成自研或者其他框架的组件。

   
   

   
   

3. 清晰标注技术债：在项目文档和路线图里明确记录，哪些部分因为用了LangChain做了妥协，并且制定明确的重构优先级和时间表。

   
   

   
   

大项目：有能力的话建议自研

当项目规模比较大，长期维护和迭代的需求明确，或者要作为公司核心基建对外提供服务的时候，放弃LangChain转自研框架几乎是必然的选择。

这个阶段项目的核心诉求已经从“快速开发”转变成了稳定性、可扩展性、可运维性，还要和公司现有技术体系深度集成：

首先，LangChain的设计思路更偏向单体应用，内部模块的耦合度比较高。硬要改造成微服务，改造的工作量非常大，自研框架在这一块就要灵活很多。

其次，我之前在别家公司落地的时候，他们当时用的就是LangChain，但LangChain自带的日志和监控逻辑和公司已有的运维体系不兼容，出了问题排查起来非常麻烦，他们又没办法对框架做深度改造，最后干脆自己自研了一套框架。

最后，LangChain是第三方开源项目，它的发展路线、API变更、对特定模型或者向量库的支持优先级，都不是你的团队能掌控的。

如果框架做了不兼容的重大升级，或者社区生态发生变动，项目就会面临被动升级适配的风险，很可能产生高昂的技术债。

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

现有技术栈的适配问题

这里还有一个比较尴尬的问题，做企业级应用开发的时候，Java依然是主流选择，比如金融、电商、政务这些领域（也有不少团队用PHP、Golang）：

但LangChain的生态核心是Python，硬要在Java技术栈里用LangChain反而会拉高开发成本，我们拿Java举例：

1. 跨语言调用成本高：需要通过RPC或者HTTP接口通信，不仅增加延迟，还可能碰到数据格式不兼容的问题。

   
   

   
   

2. 运维复杂度上升：需要同时维护Python和Java两套运维体系，包括部署、打包、依赖管理都要做两套，工作量翻倍。

   
   

   
   

3. 生态融合困难：没办法深度集成已经成熟的Java中间件（Dubbo、Spring Cloud）和安全监控系统。

   
   

   
   

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

框架更新迭代的问题

AI领域的技术和业务需求迭代速度非常快，而LangChain这类综合性框架，庞大的体量和追求通用性的设计，决定了它的更新速度必然跟不上实际的变化，这就引发了几个关键矛盾：

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

当新的模型能力（比如多模态、长上下文）或者新协议（比如MCP）出现的时候，原生开发可以马上跟进快速试错，但用框架的话只能等官方做适配，在快速变化的市场里很容易陷入被动。

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

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

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

这个过程不仅要求开发者同时理解原生API和框架的封装逻辑，还可能因为框架更新滞后，没办法第一时间用上最新特性。在追求极致性能或者快速跟进前沿能力的场景里，这种成本往往超过了框架带来的收益。

三、拖慢业务迭代速度

创业项目的需求可能在几周内连续变动，当业务逻辑需要突破框架预设的Chain、Agent这些固定范式的时候，往往需要修改框架组件或者自定义组件适配，大部分团队都没有这个能力。

总的来说，框架的价值在于给稳定、通用的需求提效。

但在快速变化、需要深度利用特定技术或者灵活调整业务逻辑的场景里，过度依赖框架就会变成开发负担。

结语

最后说一下现在对框架选择影响最大的因素：AI编程带来的改变。

过去我们依赖LangChain，很大程度上是因为不想重复写那些枯燥的API封装、Prompt拼接、错误处理，还有各类基础能力的封装工作。

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

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

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

自研一个轻量、贴合业务的AI框架，成本已经被AI工具极大降低了。

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

本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。

免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com