为什么我们不用LangChain？

事件概述

核心观点

小项目：原生开发更直接

• 需求多变，框架适配成本高于直接修改核心逻辑。
• 功能单一、边界清晰，无需引入框架的抽象层和依赖膨胀。
• 可完全掌控代码，针对具体场景优化 Prompt 模板等关键组件，避免不必要的中间调用。

中型项目：LangChain 作为过渡方案

• 利用其 Prompt 管理、工具调用等组件快速搭建可运行系统，缩短验证周期。
• 需提前规划解耦：通过抽象层或适配器模式封装框架调用，为未来替换预留接口。
• 明确记录技术债，制定重构优先级和时间表，避免后期被框架深度绑定。

大型项目：自研框架的必要性

• LangChain 单体设计难以适应微服务架构，自研框架可深度集成企业现有日志、监控、部署等运维体系。
• 第三方框架的升级路线、API 变更不受团队控制，存在被动适配风险，自研可确保绝对可控。
• 当公司技术栈以 Java、Golang 等为主时，强行接入 Python 生态会带来跨语言调用延迟和运维负担，选择 Java 生态工具或自研更合理。

框架更新的滞后矛盾

• 新模型能力（如多模态、长上下文）或协议（如 MCP）出现时，框架适配慢于原生 API，使团队在竞争中处于被动。
• 通用抽象无法发挥模型特有能力，为利用独有功能往往需要操作底层客户端，反而增加了同时理解框架封装与原生 API 的成本。
• 业务快速迭代时，框架预设的 Chain、Agent 范式可能成为束缚，多数团队又缺乏改造框架组件的能力。

AI 编程降低自研门槛

借助 AI 编程工具，可几分钟内生成标准化的 LLM 调用接口、重试机制等胶水代码，自研轻量框架的成本被极大摊薄。开发者可将精力从学习庞大框架转向构建完全受控、仅包含必要功能的自研方案，在灵活性与效率之间取得新平衡。

值得关注

文章强调，在 AI 辅助开发的时代，对第三方综合性框架的依赖不再是必然选择。项目应当根据实际规模、技术栈和长期演进需求，判断是否以及如何使用框架，避免为短期效率牺牲长期可控性。