LangChain曾是AI Agent开发的首选框架，但随着项目实践深入，我们发现其通用性设计在特定场景下反而成为负担。本文基于真实项目经验，从项目规模、技术栈适配、框架更新滞后等维度，深入剖析为何在AI编程时代，自研轻量级框架往往比依赖第三方更高效可控。

书接上文：为什么复杂AI项目要用LangChain？

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

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

我们因为做AI 2B的业务，实际会做不同类型的项目，包括Demo、项目，但真正在业务中实践后，我逐渐放弃了LangChain框架，转向更贴近业务本身的开发方式。

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

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

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

• 小项目/Demo：直接用原生 API 开发，灵活且无依赖,成本低。
• 中型/赶工期：可用 LangChain 快速搭骨架，但需警惕后期维护成本。
• 大型/企业级：强烈建议自研框架，以适配微服务架构和现有基建。

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

一、我们需要AI开发框架吗？

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

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

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

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

• 提效：哪怕是不太熟悉底层细节的开发者，也能通过少量代码实现复杂功能，避开一些常见的坑。
• 标准化：团队协作时，大家遵循同一套开发范式，沟通和整合的成本会低很多。
• 生态成熟：框架通常会集成好主流的工具（比如 OpenAI、Pinecone、Chroma），省去了自己对接第三方接口的麻烦。

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

• 灵活性差：为了适配各种场景，框架往往会加入不少抽象层和依赖，这不仅增加了项目的复杂度，还可能带来性能上的冗余。
• 预设束缚：当业务需要个性化调整时，框架预设的逻辑常常会变成束缚，改起来甚至比重写还麻烦。
• 学习成本：表面上降低了入门门槛，但真想用好、解决问题，还是得理解它的运行机制，否则很容易变成 只会调用API，底层原理不清楚，出了问题也不知道怎么处理。

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

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

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

1. 小项目：原生开发更香

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

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

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

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

• 需求多变：小项目的需求常常会变，可能过两周就要加个会话记忆，或者换一个模型供应商。用框架开发的话，每次改动都得先考虑怎么适配框架的设定；原生开发就没有这个束缚，直接改核心逻辑就行。
• 追求轻量：小项目要的是能用、好用，而不是标准化或扩展性。
• 定制体验：原生开发让你完全掌控代码，既避免了框架带来的依赖膨胀，又能针对具体场景做优化，比如省掉不必要的中间调用、定制自己的 Prompt 模板。

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

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

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

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

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

具体实施的建议如下：

• 按需选用，最小化依赖：避免全盘采用。明确评估需求，仅引入必要的模块。例如，可以单独使用其 Prompt 模板管理和工具调用封装，而自定义更可控的编排流程或记忆模块。
• 提前规划路径：在架构设计之初，就为未来替换 LangChain 预留接口。例如，通过抽象层或适配器模式来封装对 LangChain 的调用，确保未来能平滑地替换为自研或其他框架的组件。
• 清晰界定技术债：在项目文档和路线图中明确记录：哪些部分因使用 LangChain 而存在妥协，并制定具体的重构优先级和时间表。

3. 大项目：有实力就自研

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

这时项目的核心诉求已经从“快速开发”转向了稳定性、可扩展性、可运维性，以及与公司现有技术体系的深度集成：

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

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

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

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

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

二、技术栈的适配度

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

而LangChain的代码生态是Python，如果非要去用可能会提高成本，这里以Java为例：跨语言调用成本高：需要通过 RPC 或 HTTP 接口通信，增加延迟，且面临数据格式不兼容风险。运维复杂度上升：得维护 Python 和 Java 两套运维体系（部署、打包、依赖管理）。生态融合困难：难以深度集成成熟的 Java 中间件（Dubbo, Spring Cloud）和安全监控系统。

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

三、框架更新问题

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

1. 新能力接入滞后，无法及时使用

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

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

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

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

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

3. 业务迭代速度

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

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

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

四、结语

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

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

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

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

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

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

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