LangChain 怎么选：4 个框架按场景对号入座

云间 技术创作者 2026-11-01 10 阅读

截至 2026-11 抓取，langchain-ai/langchainjs 仓库显示 18.3k star、3.5k fork、8,264 次提交，仓库首页的自我定位已经改成 “The agent engineering platform”，不再是单纯的 “framework”。这正是现在值得重新做一次选型的原因：LangChain 官方自己在 README 里把”更高级的定制或 agent 编排”指向了 LangGraph.js，把”入门”指向了另一个更高层的 agent 包，把”上线”指向了 LangSmith——同一个生态内部已经分出了不同工位。选错的典型症状不是跑不起来，而是三个月后想加一条人工审批分支，才发现自己被抽象层卡住。

下面给一条可执行路径：先跑通最小环境，再按四个具体场景对号入座。

动手前的三件事

  1. Node.js 版本对齐：官方 README 明确列出 LangChain.js 支持 Node.js 20.x、22.x、24.x（ESM 与 CommonJS 均支持）。执行 node -v，输出应落在 20/22/24 三个大版本之一，否则先升级。
  2. 确认包管理器：README 给出的安装方式是 npm、pnpm、yarn 三选一。执行 npm -v（或 pnpm -v / yarn -v），确认命令可用即可，三者装出来的包结构一致。
  3. 准备一个模型提供商的 API key：LangChain 只是中间层，真正发起请求的是模型集成。密钥的具体环境变量名取决于你选哪家模型商，请以该集成商的官方文档为准，不要照抄别人博客里的变量名。

第 1 步：先装最小可运行的一层

不要一上来就装全家桶。官方 README 的快速安装给出的就是单一包：

# 三选一
npm install -S langchain
pnpm install langchain
yarn add langchain

装完立刻确认落地位置和版本号：

node -e "console.log(require('langchain/package.json').version)"
ls node_modules/@langchain

第二条命令值得单独跑一次：LangChain 的模型、嵌入、向量库等集成大多以 @langchain/xxx 形式作为独立包存在。你需要知道哪些能力是主包自带的、哪些要另装，否则后面遇到 “Cannot find module ‘@langchain/openai'” 这类报错时，根本分不清是版本问题还是压根没装这个包。

如果项目是 ESM（import 语法），在 package.json 里确认字段：

{
  "type": "module"
}

第 2 步：认准 4 个名字和它们的分工

本文只对比 4 个框架，多一个都不算。

LangChain（JS / Python）：通用 LLM 应用框架，官方定义是”把可互操作的组件和第三方集成串起来”的框架，抽象层从高层 chain 到底层组件都有，覆盖 agents、models、embeddings、vector stores 等标准接口。

LangGraph：官方 README 称之为 “lower-level agent orchestration framework”，即低层 agent 编排框架，提供可定制的架构、长期记忆和 human-in-the-loop（人在回路）工作流。仓库 README 点名 LinkedIn、Uber、Klarna、GitLab 在生产中使用它。

LlamaIndex：社区二手资料里被一致归为”专注 RAG 的数据感知型框架”，优势在文档摄取与检索链路的开箱即用。腾讯云社区那篇框架选型长文（个人作者经验，非官方结论）把它列为”RAG 天花板”，并提到 130+ 数据连接器。

CrewAI：同样出自社区二手资料，定位是多 Agent 协作框架——定义角色、拆任务、分派给不同 Agent，配置相对简单但集成面比 LangChain 窄。

另需说明：LangChain 官方 README 目前还提到面向新手的更高层 agent 包（带规划、子 Agent、文件系统能力）、Deep Agents，以及托管平台 LangSmith。这几个属于 LangChain 生态内的配套设施，不计入上面 4 个的对比。

第 3 步：按场景对号入座

你的场景 选它 依据 代价
一天内要 demo，需要接多家模型和向量库 LangChain 官方 README：标准接口覆盖 agents、models、embeddings、vector stores，支持模型互换 抽象层多，深定制时容易”抽象泄漏”（社区经验）
生产 Agent 要状态持久化、人工审批、可控步骤 LangGraph 官方定位为低层编排框架，含长期记忆与 human-in-the-loop 学习成本明显高于 LangChain，官方把它定位为”advanced customization”
核心任务是让 LLM 吃透私有文档 LlamaIndex 社区资料一致强调其 RAG 专精与数据连接器数量 生态外的第三方集成少于 LangChain
多角色协作的内容生产/研究流水线 CrewAI 社区资料：角色定义清晰、任务自动拆解分派 集成数量少，小团队更合适

这张表的价值在于反着读：如果你正在做的事同时命中”要 demo”和”要人工审批”，那正确动作不是二选一，而是先用 LangChain 把集成层接好、跑通，再把编排迁到 LangGraph——社区那篇踩坑记录就是这么描述从 LangChain 切到 LangGraph 的体感变化的。

第 4 步：3 种方式确认装对了

  1. 版本可读：node -e "console.log(require('langchain/package.json').version)" 能打印出一个版本号，说明包确实被解析到。
  2. 导入成功：在脚本里 import { ChatOpenAI } from '@langchain/openai'（或你所用模型商的对应包），Node 能启动且不抛 module not found，说明依赖图完整。
  3. 调用成功：发起一次最小对话，标准输出里出现模型返回文本。若这一步报错，问题通常不在 LangChain，而在 API key、网络或模型名——先排查这三样，再怀疑框架。

常见卡点与对应解法

“Cannot find module ‘@langchain/openai'”：不是安装失败，是漏装集成包。执行 npm install -S @langchain/openai（换成你实际用的模型商包），再重跑第 4 步的第 2 条。

Node 版本不在 20/22/24：官方 README 只列了这三条线。执行 node -v 看到 18 或 25 时，升级 Node，而不是升级 LangChain 去赌兼容性。

ESM 项目报 “Cannot use import statement outside a module”：这是 Node 的模块配置问题，不是 LangChain 的问题。在 package.json 加 "type": "module"，或把文件后缀改成 .mjs。

跑得通但看不懂内部发生了什么：官方仓库为此单独指向 LangSmith（构建、测试、监控 LLM 应用的统一平台），可以先用免费层跑通一次 trace，看清每次调用经过哪些层，再决定要不要继续加深抽象。社区二手资料里反复出现的痛点是 Chain、Runnable、CallbackHandler 三者关系难梳理——遇到这类困惑，先加 trace 而不是先重构。

改一个自定义工具要继承好几个类：社区作者的结论是”简单场景用 LangChain，复杂定制直接自研，或只取 LangChain 的单个模块”。这是社区经验判断，不是官方建议，但它指向一个合理动作：把该模块单独隔离出来评估，而不是硬套整套框架。

反方：什么时候根本不该用框架

如果你只做一次模型调用或一个简单问答，框架带来的依赖体积、升级成本和抽象层都是净负担。腾讯云社区那篇对比里给出的”自研”路径——直接调模型 API、自己写编排——优点是完全可控、无中间层开销、问题好排查，缺点是要从零实现 prompt、记忆和工具调用。社区资料也提到 LangChain 的版本迭代快、API 变化频繁，升级成本高，这是选型时必须算进去的运营成本。

我的经验判断（非官方结论）：先用裸 API 写通一个最小闭环，再决定要不要引入框架，比反过来省事得多。

参考来源

# AI# 知识

评论区

0 条评论

登录后可评论。

云间 10 阅读