LlamaIndex vs LangChain：搭 RAG 到底选哪个

先给结论，省得你往下翻：纯做检索问答、数据接入复杂，选 LlamaIndex；要串多步骤、多工具、Agent 流程，选 LangChain。 两个能混用，而且实战里经常混用。

下面说为什么。

一句话定位

LlamaIndex：从一开始就是冲着「把你的数据喂给 LLM」去的。索引、分块、检索这套，它做得最顺手。

LangChain：更像一个「胶水层」，把模型、工具、记忆、Agent 全都能串起来。RAG 只是它能做的一小块。

所以问题不是「谁更强」，是「你的活儿偏哪头」。

直接上对比表

维度LlamaIndexLangChain

核心强项数据索引与检索流程编排 / Agent 上手难度检索场景更低概念多，学习曲线陡 数据连接器极丰富（LlamaHub 几百个）有，但没那么全 检索策略内置多，开箱即用要自己拼 Agent 能力有，但不是主场主场，生态最大 文档质量检索部分清晰庞杂，版本变动快

什么时候选 LlamaIndex

如果你的需求是这种：「我有一堆 PDF / Notion / 数据库，想让用户用自然语言问，答案要准、要带出处」——闭眼选 LlamaIndex。

它的 VectorStoreIndex 几行就能跑起来：

python
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
docs = SimpleDirectoryReader("./data").load_data()
index = VectorStoreIndex.from_documents(docs)
qe = index.as_query_engine(similarity_top_k=5)
print(qe.query("我们的退款政策是怎么规定的？"))

更关键的是检索策略。像句子窗口检索、自动合并检索这些进阶玩法，LlamaIndex 是内置的，换个 retriever 类就行。同样的东西在 LangChain 里你得自己搭。如果你做的是企业知识库、客服问答这类，省下来的时间很可观。

向量库这块我一般配 pgvector 或 Qdrant，具体可以看 pgvector 向量搜索实战。

什么时候选 LangChain

只要你的流程超出「检索→回答」，开始有分支、有工具调用、有多轮决策，LangChain 的价值就出来了。

举个真实场景：一个 Agent 要先判断用户问的是「订单问题」还是「产品咨询」，订单问题去查数据库，产品咨询走 RAG，查不到再转人工。这种带状态、带分支的流程，用 LangChain（更准确说是 LangGraph）画状态图，比硬写 if-else 清爽太多。这部分可以参考 LangGraph 有状态 Agent 指南。

python
from langchain.agents import create_react_agent, AgentExecutor
把检索、查库、转人工都包成 tool，交给 Agent 自己决定调哪个
agent = create_react_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools)

别忽略的坑

LangChain 的版本问题：它迭代太快，去年的教程今年可能 import 路径就变了。生产项目一定要锁版本，别用 latest。这是我们踩过最疼的坑——一次小版本升级，链路直接断。

LlamaIndex 的 Agent 不要硬上：它也有 Agent 模块，但生态和稳定性跟 LangChain 没法比。需要复杂 Agent 别勉强用 LlamaIndex 凑。

性能上两者差距不大：真正的瓶颈在向量检索和 LLM 调用，框架本身的开销可以忽略。别在这上面纠结。

那能不能一起用？

能，而且推荐。常见组合是：LlamaIndex 负责数据索引和检索，把它包成一个 LangChain 的 tool，再交给 LangChain 的 Agent 编排。 各用各的长处，这是目前比较成熟的生产架构。

选型速查

只做文档问答、知识库 → LlamaIndex

要 Agent、多工具、复杂流程 → LangChain

既要好检索又要复杂编排 → 两个一起用，LlamaIndex 做检索层

团队是新手、想快出 demo → 看哪个场景更贴，别两个都学

选框架这事，别被「哪个更火」带跑。先看你这个项目三个月后会长成什么样，再决定。