LangChain

LangChain 是由 LangChain Inc. 开发的开源 Python 和 JavaScript 框架，旨在将大型语言模型与外部数据、工具和执行环境连接起来。自 2022 年发布以来，它已成为开发者构建检索增强生成 (RAG) 系统和自主智能体事实上的起点，累计获得了超过 135,000 颗 GitHub 星标和 279,000 个依赖项目。其核心库采用 MIT 许可证且免费；该公司通过其付费的可观测性和部署平台 LangSmith 实现商业化。

截至 2026 年 4 月，LangChain 以套件形式提供：核心框架负责处理文档加载、链式组合以及跨 50 多家 LLM 提供商的模型 I/O；LangGraph（自 2025 年 10 月起发布 1.0 稳定版）负责处理具有持久化检查点的有状态多步智能体编排；LangSmith 为需要生产级可观测性的团队提供追踪、评估和智能体部署功能。该框架支持通过 Ollama 和 LlamaCPP 运行本地模型，支持 Pinecone 和 Weaviate 进行向量存储，并集成了 FastAPI 用于服务部署。

2026 年 4 月的 LangChain 实际功能

LangChain 的核心工作是抽象：它提供了一个标准接口，使开发者只需极少的代码更改，就能将 OpenAI 替换为 Anthropic 或本地的 Llama 模型。文档加载器可从 100 多种数据源（PDF、Notion、SQL、Web）中提取文本。嵌入和向量存储连接器将这些文本输入到检索管道中。链（Chains）使用 LangChain Expression Language (LCEL) 声明式地组合这些步骤。智能体（Agents）则利用 LLM 本身来决定调用哪些工具以及调用的顺序。

2025 年 10 月 22 日，LangChain 1.0 和 LangGraph 1.0 的双重发布是该框架最重要的里程碑。这两个包都承诺在 2.0 版本之前不会引入破坏性变更，直接解决了在 v0.0.x 到 v0.3 时代导致开发者流失的抱怨。LangGraph 1.0 增加了持久化状态（智能体工作流在服务器重启后自动存活）、通过一等 API 实现的“人在回路”（human-in-the-loop）暂停/恢复功能，以及对 token、工具调用和状态转换的完整流式传输支持。随后的 LangChain 1.1 更新添加了具有可配置指数退避的模型重试中间件。最新的稳定版本是 langchain-core 1.3.2（2026 年 4 月 24 日）。

LangChain Inc. 还于 2026 年 3 月 15 日推出了 "Deep Agents"，这是一种用于多智能体协调的更高级别抽象，在发布后的最初五个小时内就积累了 9,900 颗 GitHub 星标。这究竟标志着真正的强劲势头，还是框架臃肿的重演，在开发者社区中仍是一个激烈争论的话题。

LangChain 与 LlamaIndex 及 OpenAI Agents SDK 的定位对比

当开发者离开或绕过 LangChain 时，最常选择的两个替代方案是 LlamaIndex 和 OpenAI Agents SDK。它们在机制上的差异至关重要。

LangChain vs LlamaIndex： LlamaIndex 是“检索优先”的。它的查询引擎是主要的工作单元，内置了分层分块、自动合并检索、子问题分解和重排等原语。由于检索默认设置经过了精心调优，建立生产级质量的 RAG 管道所需的自定义代码更少。LangChain 则是“编排优先”：为了达到同等的检索质量，你需要构建一个带有工具调用的 LangGraph 智能体，这需要编写更多代码，但它能处理多步推理、API 调用和工具组合，而这些是仅靠 LlamaIndex 无法实现的。基准测试的性能数据显示，在类似的检索任务中，LlamaIndex 的延迟约为 6ms，每次查询消耗 1,600 个 token；而 LangChain 的延迟约为 10ms，消耗 2,400 个 token。许多生产团队会同时使用两者：LlamaIndex 作为检索层，LangGraph 作为其上的编排层。

LangChain vs OpenAI Agents SDK： OpenAI Agents SDK 崇尚极简抽象。它只有一个 Agent 类。你只需定义一个 Python 函数，将其装饰为工具，然后传递给智能体即可。没有 Tool 包装器对象，没有链配置，也没有检索管道设置。追踪功能已内置于 OpenAI 平台中。代价是模型锁定：该 SDK 仅在 OpenAI 模型上运行。LangChain 支持 50 多家提供商，可运行本地模型，并为团队提供了一条摆脱 OpenAI 供应商依赖的途径。对于致力于 OpenAI 生态系统的团队来说，该 SDK 的交付速度更快。而对于需要提供商可移植性、多模型路由或物理隔离部署的团队，LangChain 则是更务实的选择。

框架的真实使用体验

客观地说，2026 年 LangChain 的日常使用体验比两年前要好，但那些影响其声誉的批评声音并未完全消失。

"一旦你需要做一些稍微有创意的事情，你就必须穿过 5 层抽象，仅仅为了改变一个微小的细节。" - sc077y, Hacker News, 2024 年 6 月

这条来自广为流传的 Hacker News 帖子 "Why we no longer use LangChain" (id=40739982) 的抱怨，至今仍引起共鸣。1.0 版本解决了 API 稳定性问题，但并没有扁平化抽象栈。Clara Chong 在记录其团队 2025 年 12 月向 LangChain 1.0 的生产升级时发现，新的中间件系统为较简单的工作流引入了“明显的延迟”，因为内置中间件（ToDoList、Filesystem、Summarization）无法选择性地禁用。该框架的优势同时也是它的负担：每一个集成点都是一个潜在的调试面。

"LangChain 除了做演示之外根本没法用。感觉即使是正常的日志记录也超出了它的能力范围。" - tkellogg, Hacker News, 2024 年 6 月

调试是开发者最常提到的具体故障模式。当智能体循环失败时，调用栈会穿过 LangChain 的内部结构，然后才显示实际的模型调用。如果没有 LangSmith 追踪，要找到发送给模型的确切提示词、检索到了哪个数据块，以及哪个工具调用产生了错误输出，都需要手动埋点。Hamel Husain 在 2024 年 2 月的文章 "Fuck You, Show Me The Prompt" (hamel.dev) 中记录了在 LangChain 生成的提示词中发现拼写错误（"Let'w"）的经历，除非你明确检查请求负载，否则这些错误是不可见的。LangSmith 解决了这个问题，但它是一款付费产品。

2026 年 3 月，Reddit 上一篇题为 "LangChain feels like it's drifting toward LangSmith" 的帖子，暴露了经验丰富的 ML 工程师们更深层的结构性担忧：LangChain 的更新日志越来越倾向于添加追踪钩子，而不是框架功能，并且现在的文档默认技术栈中包含了 LangSmith。LangChain Inc. 首席执行官 Harrison Chase 在 2024 年 6 月的同一篇 HN 帖子中承认了早期的抽象问题，他说“LangChain 的初始版本非常高层，绝对是过度抽象了”。1.0 版本反映了路线的修正。至于这种修正是否足够彻底，在 2026 年 4 月仍然是一个悬而未决的问题。

“先原型后重写”的模式已经非常普遍，成为了一种已知的工作流：开发者使用 LangChain 在几天（而不是几周）内验证一个想法，一旦理解了行为逻辑，就会逐步用直接的 API 调用替换 LangChain 组件。LangChain 被用作脚手架，而不是永久的基础设施。

LangChain 适合哪些人

LangChain 最适合三种特定场景。第一种是多提供商环境，团队为不同的任务运行不同的模型，或者需要规避单一 LLM 供应商的风险。将 OpenAI 替换为 Anthropic 只需要更改模型类，几乎不需要其他修改。第二种是有状态的智能体工作流：如果你的智能体需要在执行中途暂停以进行人工审批、在服务器重启后恢复，或者在持续多天的后台任务中保持状态，LangGraph 的检查点基础设施开箱即用地提供了这些功能。如果直接基于 API 从头构建同等行为，需要数周的工程工作。第三种是快速的企业级 RAG 原型设计：预构建的文档加载器、向量存储连接器和检索链模板确实能加速第一个可用版本的诞生。

已经将 LangSmith 作为可观测性标准的团队，可以从这种紧密集成中获得额外价值。LangSmith 的追踪、评估数据集和标注队列形成了一个反馈循环，这是通用监控工具难以复制的。

LangChain 不适合做什么

当用例很简单，或者团队希望最小化框架接触面时，请跳过 LangChain。没有检索、没有工具使用、没有多步逻辑的单步 LLM 调用无法从 LangChain 中获益；直接的 API 调用编写更快、更容易测试，且没有开销。对于纯粹的文档检索应用，如果主要问题是搜索质量而不是编排，那么 LlamaIndex 的检索优先架构和更低的延迟特性会更合理。对于完全致力于 OpenAI 模型、希望快速交付而不想阅读框架文档的团队来说，OpenAI Agents SDK 是更快的途径。

LangChain 不是无代码或低代码工具。它没有 GUI，没有拖拽式工作流构建器（Flowise 是社区构建的替代方案，它将 LangChain 封装在可视化界面中）。非技术用户需要其他产品。即使在 1.0 版本稳定之后，Python/TypeScript 经验有限的团队仍会在抽象层上遇到困难。对于无法接受任何延迟开销的团队（分秒必争的实时应用），考虑到在类似的检索查询中大约有 4ms 的开销，在决定采用之前，应该将 LangChain 与直接 API 调用进行基准测试对比。

经过三年快速、有时甚至混乱的迭代，LangChain 1.0 的发布标志着其真正的成熟。稳定性保证改变了生产环境采用的考量。但是，开发者社区关于这种抽象是否物有所值的争论仍未解决，而向 LangSmith 依赖的倾斜也是一种值得关注的真实商业模式张力。