LangChain vs LlamaIndex：RAG 框架选型
2026 年的 RAG 与 Agent 应用开发中，LangChain 与 LlamaIndex 仍然是两个绕不开的框架。前者从 Agent 编排起步，定位是大模型应用的胶水层；后者从文档检索起步，定位是数据驱动 LLM 应用的索引专家。两者功能高度重叠又各有偏重，新手常常陷入选择困难。本文从设计哲学、数据摄取、向量集成、Agent 抽象、学习曲线、生态、跨语言支持、生产化考量八个维度做正面对比，并给出何时直接用原生 SDK 反而更明智的判断准则。
设计哲学的差异
LangChain 的设计哲学是组合，提供大量原子化组件（LLM、Prompt、Retriever、Tool、Memory、Output Parser），开发者像搭乐高一样把它们串成 Chain 或 Agent。它的目标是覆盖大模型应用的所有场景，从聊天机器人到代码生成、从工具调用到多 Agent 协同。LlamaIndex 的设计哲学是数据，所有抽象都围绕如何把外部数据高效灌入 LLM 这一目标。它的核心概念是 Document、Node、Index、Query Engine、Agent，所有路径都从数据出发。简单说，如果你的项目本质是把 LLM 当工具使用，LangChain 提供更广的工具箱；如果你的项目本质是让 LLM 理解你的资料，LlamaIndex 提供更深的索引能力。
数据摄取与连接器
LlamaIndex 在数据摄取上有先天优势。LlamaHub 提供 200 多种 Reader 与 Tool，覆盖 PDF、Word、Notion、Slack、Confluence、Google Drive、SQL、MongoDB、Elasticsearch 等几乎所有常见数据源。它的 Node Parser 可以智能保留文档结构（标题、列表、表格），便于后续检索。LangChain 的 Document Loader 数量也不少（150 多种），但很多由社区维护，质量参差。LangChain 的优势是 LangChain Hub 之外还有 LangSmith 数据集管理、LangServe 部署，以及与各大 SaaS 的深度合作。如果你要解析复杂 PDF（含表格、公式、双栏），强烈建议先看 LlamaIndex 的 PDFReader、PyMuPDFReader、LlamaParse 商用服务；其他场景两者差距不大。
向量库与检索能力
两个框架对向量库的支持都极其全面，Pinecone、Weaviate、Milvus、Qdrant、Chroma、PGVector、Redis、Elasticsearch 等主流选项都有官方或社区集成。差别在于检索抽象层。LlamaIndex 内建多种索引结构：VectorStoreIndex、SummaryIndex、TreeIndex、KeywordTableIndex、KnowledgeGraphIndex，可以根据数据特点选择。它还提供 Sub-question Query Engine、Multi-step Query Engine、Auto-merging Retriever 这类高级模式，开箱即用即可获得相当不错的检索质量。LangChain 的 Retriever 抽象更通用，需要自己组合 SelfQueryRetriever、MultiQueryRetriever、ParentDocumentRetriever、ContextualCompressionRetriever。如果你愿意花时间调参，LangChain 的灵活性更高；如果想快速跑出第一版，LlamaIndex 的默认值更友好。
Agent 与工具调用
Agent 是 LangChain 的传统强项。它提供 ReAct、OpenAI Functions、Tool Calling、Plan-and-Execute 等多种 Agent 类型，并通过 LangGraph 提供基于状态机的高级编排，支持循环、条件分支、并发、Human-in-the-loop。LangGraph 已成为复杂 Agent 应用的事实标准，被 Replit、Klarna、Norwegian Cruise 等公司用于生产环境。LlamaIndex 也提供 Agent 能力（OpenAI Agent、ReAct Agent、Multi-Agent Workflow），但抽象层次较低，更聚焦于数据相关的工具（查询引擎、Tool Spec）。如果你做的是面向数据的 Agent（如多文档问答助手），LlamaIndex 足够；如果是通用任务 Agent 或多 Agent 协同，LangChain 加 LangGraph 是更稳的组合。
学习曲线与文档
LangChain 的学习曲线常被吐槽陡峭，主要原因是抽象层多、版本变化快、文档分散。从 0.1 到 0.3 经历了几次大重构，老教程多已过时，初学者容易在 LCEL、Runnable、Chain 三种风格之间困惑。但好消息是 0.3 之后的官方文档已显著改善，提供了完整教程、概念页、API 参考、how-to 指南四个层级。LlamaIndex 的文档结构更清晰，新手指南、用例教程、组件参考分得很开，加上《Building RAG with LlamaIndex》这类官方电子书，三天即可完成从入门到上线一个 demo。如果团队是 LLM 新手，建议从 LlamaIndex 入手；有经验后再扩展到 LangChain 处理 Agent 与多模型路由。
生态、社区与跨语言支持
LangChain 的社区规模更大，GitHub Star 已突破 9 万，第三方插件数量也更多。它有完整的 TypeScript 实现 LangChain.js，并和 Vercel AI SDK、Next.js 生态深度集成，前端到后端的全栈 Node 项目首选 LangChain。LlamaIndex 也有 TypeScript 版本 LlamaIndex.TS，但功能比 Python 版本落后一些，更新慢。Python 端两者社区都活跃。FastAPI 集成方面，LangChain 有 LangServe，LlamaIndex 有 create-llama 脚手架与 LlamaDeploy，都可以快速生成 API。从企业服务看，LangChain 提供 LangSmith（观测、评估、数据集）与 LangGraph Cloud，LlamaIndex 提供 LlamaParse 与 LlamaCloud。两家都在持续投入 PaaS 化。
什么时候直接用原生 SDK
不是所有项目都需要框架。出现以下情况时，建议直接用 OpenAI SDK 或 Anthropic SDK 而不是引入 LangChain 与 LlamaIndex：第一，逻辑非常简单，只有一个 Prompt 加少量工具调用，框架带来的依赖与抽象成本超过收益；第二，性能极致敏感，框架内部的额外封装会增加 50 至 200 毫秒延迟；第三，团队对 AI 框架不熟悉但对原生 HTTP 调用很熟悉，写直接调用反而更可控；第四，项目对依赖体积敏感（如 Cloudflare Workers、Deno Deploy 等边缘环境）。即便不用框架，也建议借鉴它们的抽象思路，自行封装薄薄一层 Prompt Template 与 Tool Adapter，便于后续替换模型。
生产化考量与监控
生产环境的考量远不止开发体验。可观测性方面，LangSmith 是 LangChain 团队的官方方案，可记录每一步调用、token 用量、延迟、错误，并与 OpenTelemetry 兼容。LlamaIndex 集成了 Arize Phoenix、TruLens、Helicone 等多种第三方监控。缓存方面，LangChain 提供 LLM Cache、Embedding Cache 多层抽象；LlamaIndex 默认缓存 Embedding 结果。重试与退避两者都内置。安全方面，要注意 Prompt 注入防御，对用户输入做白名单与转义；输出层面用 Output Parser 加 Schema 校验。最后是版本管理：建议把模型名、Prompt 模板、向量库版本一起做版本化（GitOps 风格），这样回滚问题时定位更快。
选型决策与组合方案
给三类典型团队的选型建议：第一类是个人开发者做副业项目，资源有限想快速上线，优先 LlamaIndex 加 OpenAI SDK，复杂 Agent 部分按需引入 LangChain；第二类是中型创业团队做企业知识库，建议 LlamaIndex 做数据层 + LangChain 做 Agent 层 + LangSmith 做监控，是目前最常见的组合；第三类是大型企业做内部 Copilot，技术栈通常多语言，建议核心服务用 Python LangChain + LangGraph，前端 BFF 用 LangChain.js，文档处理用 LlamaIndex 加 LlamaParse。无论选什么，把抽象层做薄、把模型与向量库做成可替换组件，是最重要的工程纪律。
常见问题
LangChain 和 LlamaIndex 可以混用吗
可以并且很常见。许多团队用 LlamaIndex 处理文档摄取、分块、索引这条数据管线，再把检索结果交给 LangChain 的 Agent 层负责工具调用与多步推理。两者的接口都遵循 LangChain Runnable 与 LlamaIndex Query Engine 标准，互相调用并不困难。需要注意的是，混用会引入两套依赖，CI/CD 与版本升级要更小心。
生产环境到底该不该用这两个框架
看团队规模与场景。若你只是单一调用模型加少量工具，直接用 OpenAI SDK 或 Anthropic SDK 反而更稳，依赖少、性能好。若你的产品涉及多步 Agent、多种数据源、多模型路由，框架可以省下大量胶水代码。生产前请把关键路径写测试、固定版本号，并准备好回退方案。
LangChain 的版本更新太频繁怎么办
LangChain 已稳定到 0.3 系列，并把核心包拆分为 langchain-core、langchain、langchain-community、langchain-openai 等子包，升级冲突明显减少。建议固定子包版本、用 lock 文件、关注官方 changelog 中的 breaking change 标记。需要更高稳定性可考虑 LangGraph 与 LangChain Expression Language，它们的 API 已基本稳定。
LlamaIndex 适合做哪些场景
LlamaIndex 的强项是文档密集型应用：企业知识库问答、长文档摘要、合同与论文分析、跨多文档对比。它内置了 60 多种 Reader、丰富的索引结构以及 Sub-question Engine、Agentic RAG 这类高级模式。如果产品核心价值是文档智能，LlamaIndex 最合适。
中文场景两个框架表现怎么样
两个框架对中文都没有特别优化，但通过更换分词器、Embedding 模型可以适配。建议在 LangChain 中用 RecursiveCharacterTextSplitter 配合中文分隔符，在 LlamaIndex 中替换 SentenceSplitter 为支持中文标点的版本。Embedding 用 BGE 系列或通义 Embedding；如果需要 Re-ranker，bge-reranker-large 是很好的中文选择。