LangChain 替代方案：选项对比

我们的立场：我们是 Geonode，销售代理，与 LLM 框架毫无关系。无论你选哪个，我们都没有任何收益，因此这是一篇没有利益关系的人写的对比——在这个类别里并不常见，因为大多数对比都来自其中一家厂商。以下所有版本、许可证和仓库活跃度均于 2026 年 9 月核对。

人们为何寻找替代方案

值得把真正的抱怨说清楚，因为它们决定哪种替代方案有用。

抽象深度。 调试一条 chain 经常意味着去读框架源码，才能弄清实际发出去的 prompt 是什么。让演示变短的间接层，会让生产事故变长。

API 动荡。 框架在生命周期里变动很大，教程很快过时。针对某个主版本写的代码需要回头改。

依赖重量。 大表面积带来大依赖树，这在受限部署和安全审查里很重要。

做得太多。 Chains、agents、memory、retrieval、tooling、evaluation。大多数项目只需要其中两项，却继承了全部。

注意，这些抱怨都不是针对想法本身。LangChain 的抽象是对问题空间的合理描述，这也正是它们被复制的原因。抱怨的是：为了用其中一部分，却要采纳整个框架的成本。

也值得说明项目并没有停步：langchain 为 1.3.18，langchain-core 为 1.6.1，均于 2026 年 8 月底发布，MIT 许可，仓库活跃度在该类别中名列前茅。许多批评描述的是更早的版本。

格局概览

所有数字来自 PyPI 和各项目自己的仓库，于 2026 年 9 月核对。

全部在积极开发——每一个都在核对前几天内有过推送。全部是宽松许可。差异在范围和理念，而不在是否可行。

LlamaIndex：检索优先

最接近的通用替代方案，而且来自另一个方向。

LangChain 从组合 LLM 调用起步，LlamaIndex 从把 LLM 接到你的数据起步——它自己的概括是 "interface between LLMs and your data"。这个起源体现在它擅长的地方：从极广来源加载文档、分块策略、索引构建，以及超越简单 top-k 相似度的检索模式。

适合选择的时机 是检索质量才是问题的难点。它的索引抽象和 query engines 比通用框架里的对等物更精细，loader 生态也足够广，接入一个少见的数据源通常只要一行。

保留意见 和 LangChain 同形：它已经长成通用框架，为检索而采用它，也会带上你可能并不想要的 agents、工作流和 tooling。

Haystack：生产级流水线

Deepset 的框架，也是这组里最明确面向生产的——它自称是一个 "to build customizable, production-ready LLM applications" 的框架。

其区分点在于：pipelines 是带有声明式输入输出的显式组件图，可序列化为 YAML。这让实际运行的内容比 method-chaining 更容易检查，也让 pipeline 成为可以版本管理、diff 和评审的对象。

适合选择的时机 是你在构建将被运维、而不是被演示的东西——能看清 pipeline 结构、序列化它、并在评审中推理它，比最短路径做出能跑的原型更重要。

它也是本列表中唯一 Apache-2.0 而非 MIT 的项目，实际差别不大——两者都宽松——但偶尔会在有偏好的法务审查中起作用。

DSPy：真正不同的思路

最有意思的替代方案，也不是其他方案的变体。

DSPy 的前提是：手写 prompt 是错误的抽象。你用输入和输出来声明模块该做什么，框架再针对你定义的指标去优化 prompt——包括 few-shot 示例。

结果是另一种开发循环。你不再手工迭代 prompt 措辞，而是构建评测集、定义指标，让优化器去搜索。这把 prompt engineering 从手艺变成更接近训练流程的东西。

适合选择的时机 是任务有可测质量、有评测集，且量足够让系统优化划得来。分类、抽取和结构化推理都适合。

不要选择的时机 是你无法定义指标，或任务只是一次性的。整套方法建立在能自动给输出打分上，而构建那个评测集才是真正的工作。

以 37,000 stars 和持续开发来看，它早已过了实验阶段——但前期对你的要求比这里任何其他选项都高。

Pydantic AI 与 Instructor：有意为窄

两个故意少解决一些问题的项目。

Instructor 只做一件事：结构化输出。你定义一个 Pydantic 模型，它处理 schema、校验和无效时的重试循环。这就是整个库。

LLM 应用代码里极大一部分是“从模型拿到符合这个形状的合法 JSON”，Instructor 用几行代码、几乎没有框架开销就给出完整答案。如果这就是你的需求，为了得到它去采用通用框架是一笔糟糕的交易。

Pydantic AI 更宽——一个 "the Pydantic way" 的 agent 框架——把类型安全、依赖注入和结构化输出带到 agent 构建里。它比其他项目更年轻、增长很快，尤其吸引已经投入 Pydantic 和类型检查的团队。

适合选择这些的时机 是问题定义清楚，而你更想要库而不是框架。这个区分很重要：库是你调用的东西，框架是调用你的东西，后者难离开得多。

Semantic Kernel：企业与多语言

微软的框架，也是当 Python 不是全部故事时该考虑的那个。

其区分点是对 .NET、Python 和 Java 的一等支持，以及围绕 plugins 和 planners 构建、映射到企业集成模式的架构。

适合选择的时机 是你在 .NET 团队、需要跨多种语言的同一套概念，或组织的平台决策指向这边。这些是真实约束，而且经常比技术优劣更能拍板。

对没有这种约束的纯 Python 项目，Python 原生选项在生态里通常更有动量。

LangGraph：LangChain 内部的替代方案

值得单独拿出来说，因为人们说想要替代方案时，经常真正想要的就是它。

LangGraph——同一团队，MIT 许可，版本 1.2.11——自称用于 "building stateful, multi-actor applications with LLMs"。它是带有显式状态的图执行模型，而不是 chain 抽象。

这个区分很重要，因为对 LangChain 的多数抱怨都关于隐藏的控制流。LangGraph 让控制流成为你写的东西：节点、边、条件转移，以及你定义的状态对象。凌晨三点出问题时，这要好读得多。

适合选择的时机 是应用有真正的状态、分支或循环——会循环的 agent、带审批步骤的工作流，任何“下一步发生什么”取决于“之前发生了什么”的场景。可以不采用其余 LangChain 而单独使用。

不用框架：支持的理由

大多数对比文章省略的选项，也是相当一部分应用的正确答案。

模型提供商 SDK 现在已经很好。直接调用只要几行，而且完全透明：

response = client.messages.create(
    model=MODEL,
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}],
)

你放弃的： 提供商抽象、预构建集成、现成的检索组件，以及 agent loop。

你得到的： 能读懂自己的代码。发出去的 prompt 就是文件里的 prompt。调试是看一条 request 和一条 response，而不是穿过框架层追踪。依赖树是一个 SDK。升级看的是提供商的 release notes，而不是框架的迁移指南。

一个合理的中间立场： 对具体问题用窄库——Instructor 做结构化输出、向量数据库 client 做检索、HTTP client 做 tool calls——编排自己写。编排通常五十行，你写的五十行比你没写的框架更好维护。

框架真正值得其位置的时候： 当你需要很多提供商集成，当你在构建复杂 tool 使用的 agents 并希望循环被处理掉，当团队受益于共享约定，或当原型速度比生产可读性更重要。这些是真实理由，也适用于真实项目。

要避免的失败模式是：为 demo 采用框架，到生产才发现你看不见它在做什么。

从框架中迁出

如果你已经有 LangChain 应用并在考虑搬家，工作比看起来更可预期——而且顺序很重要。

先弄清它实际在发送什么。 改任何东西之前，先捕获真实的 prompts 和参数。大多数框架为此提供 callback 或 debug 开关，打开它会产出整个练习中最有用的工件：用 HTTP requests 而不是 method calls 表达的、应用实际在做什么的记录。一半时候，单凭这一步就会发现框架在做你没打算做的事。

一次只搬一个组件，不要整应用一起搬。 各部分是可分离的。把检索步骤换成直接的向量数据库 client 调用，其余先留着；确认输出质量没变；再搬下一块。一次性重写会把“新代码错了”和“新代码不一样”混在一起，你就分不清是哪一种。

保留输出对比 harness。 用同一批输入跑两套实现，并对结果做 diff。检索和生成足够非确定性，“看起来还行”不是证据；一百对配对输出会暴露抽查看不到的回归。

预料 prompt 模板会是难点。 框架 prompt 模板常常包含你没写、甚至可能没读过的样板——格式说明、output parsers、few-shot scaffolding。复现行为意味着复现这些，所以先捕获实际发出的 prompts。

并且诚实地问值不值得。 一个能跑、只是你觉得有点不透明的应用，并不显然差于一个你懂、但有新 bug 的重写版。当框架在主动让你付出代价——调试时间、升级动荡、依赖冲突——迁移的理由就强；当动机只是审美，理由就弱。凭口味做的重写记录很差。

对大多数团队，现实的中间路径是停止增加新的框架表面积，而不是立刻拆除现有表面积。新组件直接写，旧的先放着，直到本来也要改。

如何选择

一套能解决大多数情况的短流程。

写下你真正需要什么。 结构化输出？检索？带 tools 的多步 agents？切换提供商？大多数项目只需要其中一到两项。为其中一项去采用通用框架，后悔就从这里来。

先不带框架试一次。 花半天直接对着 SDK 写，会告诉你问题真正难的部分是什么，而那个答案通常指向特定库，而不是通用框架。

让工具对准难点。 检索质量指向 LlamaIndex。有评测集、任务质量可测指向 DSPy。结构化抽取指向 Instructor 或 Pydantic AI。有状态的多步工作流指向 LangGraph 或 Haystack。企业多语言指向 Semantic Kernel。

权衡退出成本。 去掉它，你有多少代码要改？你调用的库离开成本低；拥有控制流的框架则不然。这个问题值得在采用前问，而不是之后。

也不要只按流行度选。 这里每个选项都在积极维护、宽松许可。生态规模对找例子有用，但并不等于适合你的问题。

常见问题

最好的 LangChain 替代方案是什么？

取决于你需要哪一部分。检索密集的应用选 LlamaIndex，可检查的生产流水线选 Haystack，有可测质量的任务选 DSPy，结构化输出选 Instructor 或 Pydantic AI，有状态工作流选 LangGraph。对许多应用，直接调用提供商 SDK 才是最佳选项。

LangChain 还在维护吗？

非常在维护。2026 年 8 月底，langchain 为 1.3.18，langchain-core 为 1.6.1，均为 MIT 许可，仓库活跃度在该类别中名列前茅。流传的许多批评描述的是更早版本。

用 LLM 构建一定要框架吗？

不必。提供商 SDK 很直接，直接调用只要几行，对发出去的内容完全透明。框架在大量集成、复杂 agent loops 或团队共享约定时赢得位置——代价是你看不清正在发生什么。

LangChain 还是 LlamaIndex？

如果检索是难点，选 LlamaIndex：它的 document loaders、分块策略和索引抽象更成熟。如果你需要跨许多提供商和 tools 的广泛组合，选 LangChain。两者都已长成通用框架，区别比从前小。

DSPy 是什么，有何不同？

它把 prompts 当作要优化的参数，而不是要写的文本。你声明输入输出、定义指标，框架针对评测集优化 prompts 和 few-shot 示例。它需要评测集，这既是真正成本，也是真正收益。

LangGraph 是 LangChain 的替代方案吗？

来自同一团队，可以独立使用。它用节点、边和状态的显式图替换 chain 抽象，回应了对 LangChain 最常见的抱怨——控制流被隐藏。对有状态或有分支的应用，它经常就是人们真正想要的。

哪个 LLM 框架最适合生产？

Haystack 最明确面向生产，带可序列化、可版本管理和评审的 pipelines。LangGraph 适合有状态工作流。但最生产友好的选择常常是最少框架——凌晨三点能读懂的代码，胜过你必须一层层追踪的抽象。

这些框架免费且开源吗？

全部都是。LangChain、LangGraph、LlamaIndex、DSPy、Semantic Kernel、Pydantic AI 和 Instructor 是 MIT 许可；Haystack 是 Apache-2.0。全部宽松、无 copyleft 限制，截至 2026 年 9 月都在积极开发。

总结

框架问题其实是范围问题。这里每个项目都维护良好、许可宽松，所以决定不在质量——而在你想交出应用控制流的多少。

交出很多，你得到更快做出第一个能跑的版本、你没写的集成，以及你不必去想的 agent loop。交出很少，你得到能读的代码、能审计的依赖树，以及看着一条 request 和一条 response 就能做的调试。

值得养成的习惯是：先花半天不用框架。这会告诉你问题真正难的部分是什么——通常是检索质量、结构化输出合法性，或评测，这些通用框架都不会比聚焦的库解决得更好。

然后针对那个具体问题来选。检索用 LlamaIndex，能衡量质量时用 DSPy，结构化输出用 Instructor 或 Pydantic AI，状态和可检查性重要时用 LangGraph 或 Haystack，平台决策已经定了时用 Semantic Kernel。并把退出成本放在眼前，因为库和框架的差别不在它为你做什么——而在你停止使用时，有多少代码必须改。