为什么我没有用 LangChain（以及我为什么一点都不后悔）

LangChain 不是不好，而是它解决的问题，和我正在解决的问题，并不一致。

我在做一个偏底层的 Agent Runtime Server（不是写 Demo 那种），被朋友问了一句：

“你为什么不用 LangChain？不是很方便吗？”

本质上我的选择其实是一种直觉带来的，一个模糊的，不健全的，不可靠的结论，我一时语塞没能回答出来，于是我就认真的想了想，答案其实很明确，只是未经总结，话在嘴边缺说不出来。

1️⃣ 因为我不是在「拼功能」，我是想「掌控系统」

LangChain 很擅长一件事：

把“常见 AI 应用模式”快速拼出来。

RAG、Tool Calling、Agent、Memory、Retriever……
顺着官方示例走，很快就能跑起来一个“能用”的东西。

但问题是：

• 我不是在拼 Demo
• 我是在写一个 长期演进、可观测、可审计、可重放 的系统

而 LangChain 的默认抽象是：

“帮你跑起来”优先于“让你完全掌控”

当你开始关心这些问题时：

• 这一次回复究竟由哪些事件组成？
• SSE 输出的 token 来自哪个阶段？
• Tool 是谁决定调用的？为什么？
• Context 是如何被裁剪、合并、回放的？

你会发现：
我特么已经和框架的“默认设计”干起来了。

2️⃣ 抽象一旦比需求多，就会变成重担！

LangChain 的抽象有一个明显特点：

为“所有人”设计，而不是为“你”设计。

这意味着：

• 对简单场景：它很爽
• 对定制场景：你要不断“绕开它”

典型体验是：

• 想改 Agent Loop？不太弄
• 想插入自己的 Policy / Dispatcher？这源码我能看懂？
• 想控制 Context 的真相源？我得给内部状态模型的肠肠肚肚整个翻出来看一遍

最后会发现一个尴尬的事实：

这写的压根就不是业务代码，而是在“适配 LangChain”。

对我来说，这是一个危险信号。

3️⃣ LangChain 更像 WordPress，而我在写框架

这是我最真实的感受之一，越写越确定。

• WordPress 非常牛逼
• 但你不会用 WordPress 去写所有你手头的网站应用。

LangChain 的定位更像是：

“低成本、快落地 AI 应用的通用平台”（大概是这个意思）

而我现在做的事情是：

• 定义 ChatSession 的生命周期
• 把 ContextStore 作为唯一真相源
• 用 SSE 输出事件流
• 把 Agent / Tool / Policy 都当作可插拔组件

换句话说：

我在做的是“平台内核”，不是“应用模板”。

这两者的需求，天然是冲突的。

4️⃣ 真正让我放弃它的，不是“它不好”，而是“我不需要它”

我并不是讨厌 LangChain，甚至在我初期学习的时候，这东西给了我很大帮助，我从鼠标点点点德国里，就已经理解了很多。

我很清楚它什么时候非常有价值：

• PoC / Demo
• RAG 产品原型
• 小团队快速试错
• 教学 / 研究 / 快速验证想法（真的如果你第一次学着做这些一定要试试看，它很棒）

但对我当前的阶段来说：

• 我需要的是 最小可控系统
• 而不是 最大通用框架

当一个工具：

• 付出的理解成本 > 带来的业务价值
• 调试问题时必须翻框架源码
• 为了“顺着它的意思”而改变系统设计

那它对我来说，就已经不是加速器了，而是实施意义上的摩擦力。

5️⃣ 不用 LangChain ≠ 重造轮子

这是一个常见误解。

不用 LangChain 并不意味着：

• 自己从零实现模型协议
• 自己造 Prompt DSL
• 自己写 Tool Schema 标准

而是：

只拿我需要的“零件”，而不是整台机器。

• 模型 API：直接用官方 SDK
• Tool 调用：用标准 JSON Schema / MCP
• Context 管理：自己定义事件模型
• Agent Loop：自己写、但完全透明

这不是“造轮子”，
这是明确哪些轮子值得自己掌控。

写到这，突然发现，这和我们喜欢微服务和微服务框架的原因是一样的，不是吗？

6️⃣ 一句话总结

LangChain 不是过时了，而是它的“甜蜜区”变得很明确。

• 如果你想 快：它很棒
• 如果你想 可控、可演进、可解释：你可能会像我一样，慢慢离开它

对我来说，
真正的自由，不是功能多，而是我知道系统下一步会怎么走。