面经策

LlamaIndex 如何与 LangChain 结合？ ​

  • 标签：大模型、AI、Agent、LangChain、LlamaIndex

🏛 业务架构师 ​

LlamaIndex 与 LangChain 结合是取长补短的典型架构：LlamaIndex 做数据层，LangChain 做编排层。

  • 数据侧：用 LlamaIndex 的数据连接器（Confluence、Notion、数据库、PDF）和索引抽象（向量索引、树索引、知识图谱索引）构建检索服务，它在"文档解析→切分→索引→检索"这条链路上的成熟度高于 LangChain 同类组件。
  • 编排侧：LangChain 的 Agent、Memory、工具调用、LCEL 流水线负责对话管理和任务编排，把 LlamaIndex 的检索引擎封装成一个 Retriever/Tool 挂进 LangChain 体系。

业务视角：这种组合的适用场景是"知识密集型应用"——企业知识库、研报分析、技术文档助手，数据源杂、检索逻辑重，LlamaIndex 省数据接入的工作量；而对话产品化、多工具协作交给 LangChain。

但我也要给个清醒判断：2026 年两者的能力边界在互相渗透（LangChain 检索在补强，LlamaIndex 也在做 Agent），同时引入两个框架意味着双份学习成本和依赖风险。我的建议：先按主场景选主框架——知识检索为主选 LlamaIndex，流程编排为主选 LangChain——只在主框架明显短板处引入另一个，并在集成层做薄封装，保持未来可替换。

🏗 系统架构师 ​

LlamaIndex 和 LangChain 不是竞争关系，而是"数据框架"和"编排框架"的分工，结合方式是各取所长：

  • LlamaIndex 的强项：数据接入（100+ 种文档格式/数据源 connector）、索引结构（向量索引、树索引、知识图谱索引）、高级检索器（句子窗口、auto-merging、递归检索）——它把 RAG 的"数据→索引→检索"这一段做到了最深；
  • LangChain 的强项：链路编排、Agent、工具生态、记忆管理——把"检索之后怎么用"做得最全。

结合的三种典型姿势：

  • LlamaIndex 的 Retriever/QueryEngine 包装成 LangChain 的 Tool，挂进 Agent——Agent 决定何时查知识库，LlamaIndex 决定怎么查得准；
  • LangChain 做应用骨架（对话、路由、工具编排），LlamaIndex 只负责文档索引层，通过 download_loader/RetrieverAdapter 互通；
  • 共享同一个向量库，两边各自读写。

架构师判断：2026 年两者功能重叠越来越多（LangChain 也有完整 RAG，LlamaIndex 也有 Agent），我选型看团队主场景——重文档问答/知识密集型选 LlamaIndex 为主，重多工具 Agent/复杂编排选 LangChain+LangGraph 为主，混用时接口边界要清晰，避免两套抽象都渗透到业务代码。

💻 全栈开发专家 ​

两者结合的标准姿势是：LlamaIndex 当数据/检索层，LangChain(LangGraph) 当编排/Agent 层。LlamaIndex 的索引、Query Engine、Text2SQL 这些能力都可以直接包成 LangChain 的 Retriever 或 Tool。

两种典型组合：

python
# 组合1：LlamaIndex 查询引擎作为 LangChain Tool
from llama_index.core import VectorStoreIndex
query_engine = VectorStoreIndex.from_documents(docs).as_query_engine()
tool = QueryEngineTool.from_query_engine(query_engine,
        metadata=ToolMetadata(name="kb_search", description="检索内部知识库"))

agent = create_agent(llm, tools=[tool])   # LangChain 负责 Agent 循环
python
# 组合2：LlamaIndex Retriever 直接进 LCEL 管道
retriever = index.as_retriever(similarity_top_k=5)
chain = ({"context": retriever | format} | prompt | llm | parser)

什么时候这么干：数据源异构（PDF+数据库+API）且需要 LlamaIndex 的 connector/Index 抽象，同时业务侧已有 LangChain 的 Agent 编排和 LangSmith 观测——各取所长。我的实际感受：纯 RAG 项目 LlamaIndex 一把梭更顺；多工具 Agent 主导的应用 LangGraph 就够，LlamaIndex 只在数据管道复杂时才值得引入，别为了组合而组合。