LangChain 和 LlamaIndex 的分工：一个广一个深
数据截至 2026-07，价格与限额以各官网为准。
这两个项目经常被摆在一起做二选一，但它们其实不在同一层：LangChain 的重心是编排——把模型、工具、外部系统串成一条可控的流程；LlamaIndex 的重心是数据——把你的私有内容变成能被高质量检索的索引。真正决定选谁的，不是哪个名气大，而是你当前卡在哪一步。
一个很常见的误解是：既然两个都能做 RAG，那挑一个学透就行，另一个是重复造轮子。这个判断在小 demo 阶段确实看不出问题——两边都能在几十行代码内把”读文档、切块、embedding、检索、丢给模型”跑通。但项目一旦走到真实语料上，差别就出来了：文档解析得一塌糊涂的时候，编排层再优雅也救不回来；反过来，检索质量已经够用、卡在多轮工具调用和状态管理上的时候，再换一套索引原语也没用。下面按几个具体问题拆开讲。
一、先说定位：一个偏广，一个偏深
**LangChain 出现最早，生态也最大。**它提供 chains 和 agents 这两类抽象，外加对模型、嵌入、向量库的大量集成。如果你的应用要连一堆外部系统、要跑复杂的 agent 循环、要接自家的监控体系（比如 LangSmith 这类配套工具），LangChain 提供的连接器和灵活度是它最大的价值。代价也很直接：抽象层数多，学习曲线更陡，第一次读它的文档很容易被一堆概念名词绕住。
**LlamaIndex 是数据优先的思路。**它把重心放在”对私有内容做索引与查询”这件事上，RAG 相关的原语更贴身——ingestion 连接器、各种索引策略、查询引擎，都是围绕检索质量设计的。同样一个”把 500 份 PDF 变成能问答的知识库”的需求，用 LlamaIndex 写通常更短、更贴合，因为它本来就是为这个场景准备的。
用一句粗糙但好记的话概括：**LangChain 的生态更广，抽象开销也更高；LlamaIndex 的覆盖面更窄，但在 RAG 这条线上更顺手。**广和深各有代价，不存在谁碾压谁。
如果你对 RAG 本身还不太熟，建议先看 RAG 是什么？一文讲清给大模型外挂知识库的原理 打个底，再回头看这篇的选型讨论会更有感觉。
二、star 数该怎么看，不该怎么看
选型时几乎所有人都会瞄一眼 GitHub star，这没错，但要知道它衡量的是什么。
截至 2026 年 1 月的 GitHub star 排名大致是：LangChain 约 125,000，Dify 约 114,000，RAGFlow 约 70,000，LlamaIndex 约 46,500，Haystack 约 24,000。这组数字来自第三方对比资料的统计，具体到你看这篇文章的时刻，实际数值肯定已经变了，以各项目官方仓库当前显示为准。
更重要的是：**star 数只反映关注度，不代表适用性。**它受项目出道早晚、社区运营、话题热度影响很大。LangChain 领先一大截，很大程度上是因为它出现得最早、覆盖场景最宽，接触过 LLM 应用的人几乎都点过它的仓库；这跟”它更适合你的 PDF 知识库”是两码事。反过来说，Haystack 数字最低也不意味着它不成熟——它在检索侧的可调参数其实相当丰富。
把 star 当”这个项目有人维护、遇到问题能搜到答案”的粗略信号是合理的；把它当选型依据就跑偏了。
三、那 15-20% 的延迟差，到底意味着什么
有评测指出：**LangChain 的 LCEL 语法能做复杂的查询重写，但相比 LlamaIndex 的直接检索，会多出约 15-20% 的延迟开销。**这是第三方基准的口径，不是官方公布的性能指标，测试语料、向量库配置、模型选择都会影响结果，别把它当成一个固定常数。
但这个数字背后的机制值得理解：多出来的开销不是白花的，它换来的是查询重写、多路检索、条件分支这类能力。如果你的场景确实需要这些能力，那这部分开销是有对价的；如果你的检索链路就是”一次向量查询 + 一次生成”，那走一遍更厚的抽象层就纯属浪费。
落到实际决策上，可以这么判断：
- 面向用户的实时问答，首字延迟很敏感，检索逻辑又不复杂——直接检索的路线更划算。
- 后台批处理、内部工具、允许几秒响应的场景——多这一点开销基本无感，能力更重要。
- 无法判断的时候，别照搬别人的基准数字，用你自己的语料跑一遍两条路线，测出来的才作数。
四、按瓶颈选，而不是按名气选
这是我认为最实用的一条选型方法：**先定位你当前的瓶颈在哪一步，再选工具。**常见的有四种情况：
- 瓶颈在解析——PDF 排版乱、表格提取不出来、扫描件根本没有文本层。这种情况从 LlamaIndex（LlamaParse）或 RAGFlow 入手更对症，因为问题出在把文件变成结构化文本这一步，跟编排层无关。
- 瓶颈在检索——文本已经能干净地拿出来，但召回的片段总是不相关，需要调嵌入模型、上混合检索、加重排。这一层 LangChain、Haystack、Cognita 提供的可调旋钮最多。
- 瓶颈在评估——你已经改了很多轮，但说不清到底有没有变好。这时候不用换框架，在现有框架上加挂 RAGAS 这类评估工具即可。
- 语料本身是有链接的结构化内容——比如实体之间存在明确关系的资料库，这类场景可以考虑图检索的路线（RAGFlow 提供的 GraphRAG 属于这一类）。
上面数下来正好四种。注意第 3 条：评估工具是叠加上去的，不构成”换框架”的理由，很多人在这一步做了不必要的重构。
五、它们不是互斥的：一种常见的生产组合
前面反复说”选谁”，其实真实的生产系统里，一个相当常见的做法是同时用：
LlamaIndex 做 ingestion 与索引，LangChain 做编排，LangGraph 做 agent 工作流。
这个组合之所以成立，恰恰是因为两者定位不重叠——数据进来这一段用擅长数据的，流程串起来这一段用擅长编排的。真正需要注意的是接口边界要划清楚：让索引层只负责”给我最相关的 N 段文本”，编排层不去关心这些文本是怎么切出来的。边界一模糊，两套抽象混在一起，调试成本会陡增。
如果你的方向偏 agent 而不是纯检索，可以参考 主流 AI Agent 框架对比：LangGraph/LlamaIndex/Coze，那篇讲的是编排侧的选择；如果你想让检索本身变成一个可以自我决策的循环，Agentic RAG 那篇更贴近。
六、自托管：库和引擎不是一回事
这里有个容易混淆的点。LangChain 和 LlamaIndex 本质上是库，所谓”自托管”就是你自己跑 Python 服务、自己起向量库、自己管进程和依赖，它们不提供开箱即用的服务端形态。
RAGFlow 则是一个开源 RAG 引擎，走 Docker 部署，提供 slim（2GB）和 full（9GB）两种镜像，区别在于是否内置嵌入模型。它强在深度文档理解——分块会尊重文档结构，还带版面感知解析和知识图谱构建，另外配了低代码界面来搭 RAG 工作流。扫描版 PDF、财报、版式复杂的法律文书这类传统文本解析器搞不定的语料，是它的主场。
向量库这一侧，常配的一个选择是 Qdrant，支持过滤、payload 索引与量化；第三方资料称它在 100 万以上向量的规模下可以做到 50 毫秒以内的检索，这同样是第三方口径而非官方承诺，实际取决于硬件、索引参数和查询复杂度。Qdrant 既可以作为独立二进制运行，也可以跑在 Docker 容器里。向量库怎么挑，可以看 向量数据库怎么选？Qdrant/Milvus/Supabase 对比。
一个简单的判断原则：**数据必须留在内网，就选可自托管的路线，接受自己承担运维成本；想快速验证业务假设、不想在搭建上耗时间，用 Dify 这类低代码平台起步更省事。**这两条路都合理，取决于你现在最缺的是控制力还是速度。
七、诚实说说局限
有几件事值得提前想清楚：
- **这篇的对比结论来自公开的第三方资料，不是我逐项跑基准测出来的。**延迟开销、检索耗时这类数字都带口径限定，落到你的语料上大概率不一样，请以自测为准，各项目的能力边界以官方文档当前版本为准。
- **框架选型的影响，通常小于数据质量的影响。**同一份烂 PDF，换哪个框架都难有好结果。真要提升效果，把解析和分块做扎实的收益，往往比换框架大得多。
- **抽象层是会变的。**这几个项目迭代都很快，API 在版本之间发生调整并不罕见。如果你要做长期维护的系统，建议在自己的代码和框架之间留一层薄封装，别让业务逻辑直接散落在框架的具体 API 上。
- **没有一个框架能替你做架构决策。**切多大的块、用什么嵌入模型、要不要重排、召回多少条，这些参数才是决定效果的地方，任何框架都只是把这些选项暴露给你而已。
想看企业侧从零搭一套的完整流程，可以参考 企业 AI 知识库怎么搭。
小结
LangChain 和 LlamaIndex 的关系是”广”和”深”，不是”新”和”旧”，别当成互相替代的两个选项。star 数只说明关注度，截至 2026 年 1 月 LangChain 领先较多，但那反映的是出道早和覆盖宽，跟你的场景是否合适无关。第三方评测提到 LCEL 会带来约 15-20% 的额外延迟，这部分开销换来的是查询重写等能力，需不需要要看你的链路复杂度。最实用的做法是按瓶颈选：解析卡壳看 LlamaParse 或 RAGFlow，检索卡壳看 LangChain、Haystack、Cognita，说不清好坏就先加评估工具。最后记住它们可以叠加使用——索引归索引，编排归编排，边界划清楚比纠结选谁更有价值。