本文来自微信公众号： 叶小钗 ，作者：叶小钗
前面我们说过LangChain和LangGraph应该是开发者最推崇的Agent框架，也是在复杂场景下，最常见的AI Agent开发框架，他为开发者提供了从组件封装到流程编排的工具链：
并且随着LangChain 1.x与LangGraph 1.x的逐步完善，整个体系的生态分工与工程化实践也变得更清晰。
我们因为做AI 2B的业务，实际会做不同类型的项目，包括Demo、项目，但真正在业务中实践后，我逐渐放弃了LangChain框架，转向更贴近业务本身的开发方式。
当然，这并不是说LangChain不好，它能成为行业主流，肯定有其不可替代的价值。但技术选型从来不是追热点，关键要看是否真的适合你的项目。
框架的意义，最终还是要落到项目规模、业务需求和技术栈的匹配度上
今天，我就结合自己的实际经验，聊聊选择不用LangChain的几点理由，以及在做AI应用开发时，框架取舍的一些基本原则：
小项目/Demo：直接用原生API开发，灵活且无依赖,成本低。
中型/赶工期：可用LangChain快速搭骨架，但需警惕后期维护成本。
大型/企业级：强烈建议自研框架，以适配微服务架构和现有基建。
核心观点：AI编程时代，手写“胶水代码”成本极低，自研门槛已大幅下降
unsetunset我们需要AI开发框架吗unsetunset
在讨论需不需要AI框架之前，我们先看看什么是AI框架？
AI框架的本质，其实是给开发者提供一条标准化的路径，解决那些重复造轮子的问题，提升开发效率和团队协作的一致性。
开发AI应用时，有很多工作是通用的：比如LLM的调用封装、Prompt的管理、向量数据库的连接、各种工具链的接入（搜索、计算、数据库操作），还有对话历史的维护等等。
这些功能，在不同的项目中都有相似的实现方式，那么这些功能就能抽取出来成为底层框架。这也是框架的核心优势：
提效：哪怕是不太熟悉底层细节的开发者，也能通过少量代码实现复杂功能，避开一些常见的坑。
标准化：团队协作时，大家遵循同一套开发范式，沟通和整合的成本会低很多。
生态成熟：框架通常会集成好主流的工具（比如OpenAI、Pinecone、Chroma），省去了自己对接第三方接口的麻烦。
只不过，也是有一些局限性的：
灵活性差：为了适配各种场景，框架往往会加入不少抽象层和依赖，这不仅增加了项目的复杂度，还可能带来性能上的冗余。
预设束缚：当业务需要个性化调整时，框架预设的逻辑常常会变成束缚，改起来甚至比重写还麻烦。
学习成本：表面上降低了入门门槛，但真想用好、解决问题，还是得理解它的运行机制，否则很容易变成只会调用API，底层原理不清楚，出了问题也不知道怎么处理。
所以，用不用框架，本质上是在开发效率和灵活可控之间找平衡。而找到这个平衡点的关键，就是看清楚你的项目规模和需求特点。
只不过就实践来说：多数团队是没有框架的维护能力的，这会导致升级或者碰到付费模块，会很吃力，甚至有推倒重来的风险。
接下来是不同项目类型的实际情况：
unsetunset小项目：原生开发更香unsetunset
如果是小项目、Demo验证，或者是内部工具开发，我一直都倾向于用原生开发，不引入框架。
这类场景的核心目标是快速验证想法或跑通业务流程，比如做个简单的对话机器人、PDF问答工具，或者文案生成助手。
这些功能本身比较单一，边界清晰，用不上复杂的架构设计。这时候引入LangChain，反而会增加不必要的复杂度，甚至Coze、Dify都是不错的选择......
小项目不推荐使用框架的原因也出来了：
需求多变：小项目的需求常常会变，可能过两周就要加个会话记忆，或者换一个模型供应商。用框架开发的话，每次改动都得先考虑怎么适配框架的设定；原生开发就没有这个束缚，直接改核心逻辑就行。
追求轻量：小项目要的是能用、好用，而不是标准化或扩展性。
定制体验：原生开发让你完全掌控代码，既避免了框架带来的依赖膨胀，又能针对具体场景做优化，比如省掉不必要的中间调用、定制自己的Prompt模板。
总而言之，对于需要快速试错、频繁调整的小场景，原生开发其实是更务实的选择。
unsetunset中型/紧急项目：过渡方案unsetunset
对于功能明确、有固定上线时间，但团队规模与开发资源有限的中型项目（常涉及多轮对话、工具调用、检索等模块），LangChain是一个不错的选择，他可以帮助团队在短时间内搭建出可运行的核心系统，快速验证项目。
LangChain提供了一个开箱即用的组件库，让团队能将精力集中在业务逻辑和差异化功能上，而不是重复实现基础功能。这会缩短通用模块的开发周期。
只不过项目成功上线、获得初步验证后，后续如果还需要持续开发和迭代，就需要评估是否需要对框架依赖部分进行重构，将业务逻辑与LangChain的通用实现解耦，以避免被框架绑定太深。
具体实施的建议如下：
按需选用，最小化依赖：避免全盘采用。明确评估需求，仅引入必要的模块。例如，可以单独使用其Prompt模板管理和工具调用封装，而自定义更可控的编排流程或记忆模块。
提前规划路径：在架构设计之初，就为未来替换LangChain预留接口。例如，通过抽象层或适配器模式来封装对LangChain的调用，确保未来能平滑地替换为自研或其他框架的组件。
清晰界定技术债：在项目文档和路线图中明确记录：哪些部分因使用LangChain而存在妥协，并制定具体的重构优先级和时间表。
unsetunset大项目：有实力就自研unsetunset
当项目规模较大、维护和迭代预期都很多的时候，或者要作为公司核心基建对外提供能力时，放弃LangChain、转向自研框架几乎是必然的选择。
这时项目的核心诉求已经从“快速开发”转向了稳定性、可扩展性、可运维性，以及与公司现有技术体系的深度集成：
首先，LangChain的设计更偏向单体应用，内部模块耦合度较高。硬要拆成微服务，改造工作量很大；自研框架这里会灵活不少。
其次，我在之前一个公司落地的时候，他们就是使用LangChain，但是LangChain内置的日志和监控逻辑和公司已有的运维体系不兼容，出了问题排查起来很麻烦。他们又有点无力对框架进行改造，后面索性就自己自研了一套。
最后，LangChain作为第三方开源项目，其发展路线图、API变更、对特定模型或向量数据库的支持优先级，都不由您的团队掌控。
当框架进行不兼容的重大升级，或社区生态发生变化时，项目将面临被动升级和适配的风险，可能产生高昂的技术债。
说白了，大型项目追求的就是一个可控性嘛......
unsetunset技术栈的适配度unsetunset
这里还有个比较尴尬的问题，在企业级应用开发中，Java仍然是主流选择，比如金融、电商、政务等领域（PHP、Golang都有人用）：
而LangChain的代码生态是Python，如果非要去用可能会提高成本，这里以Java为例：
跨语言调用成本高：需要通过RPC或HTTP接口通信，增加延迟，且面临数据格式不兼容风险。
运维复杂度上升：得维护Python和Java两套运维体系（部署、打包、依赖管理）。
生态融合困难：难以深度集成成熟的Java中间件（Dubbo,Spring Cloud）和安全监控系统。
所以，如果公司技术栈是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辅助，快速构建一个完全受控、逻辑清晰且仅包含必要功能的最小化框架。