LangChain vs LlamaIndex 在 RAG 中怎么选?
LangChain vs LlamaIndex 核心功能与技术定位对比
原题：请列举当前主流的Agent开发框架（如LangChain、LlamaIndex等），并对比说明它们的核心功能、技术定位以及在RAG和Agent系统构建中的典型应用场景。
Agent · 阿里真题
回答与解析
主流Agent框架对比
1. LangChain —— 通用编排框架
核心定位：LLM应用的全流程编排与工具集成
- 核心能力：Chain/Agent抽象、工具调用（Tool Calling）、记忆管理、多模型路由
- 技术特点：LCEL（LangChain Expression Language）支持流式、异步、并行执行
- Agent场景：ReAct、Plan-and-Execute、Self-Ask等推理模式的标准化实现
- RAG角色：提供
RetrievalQA、ConversationalRetrievalChain等高层封装，但检索本身依赖外部
2. LlamaIndex —— 数据检索框架
核心定位：LLM与外部数据的高效连接
- 核心能力：多源数据索引（100+ loaders）、高级检索策略（路由、融合、重排序）、查询引擎
- 技术特点：索引类型丰富（Vector/Tree/Keyword/Composable），支持递归检索、子问题分解
- RAG场景：企业知识库、文档问答的首选，检索精度和效率优化深入
- Agent集成：提供
OpenAIAgent、ReActAgent，但Agent能力相对轻量
3. 其他重要框架
| 框架 | 特色定位 |
|---|---|
| AutoGen | 多Agent对话编排，适合复杂协作场景 |
| CrewAI | 角色扮演型Agent团队，强调任务委托 |
| Semantic Kernel | 微软生态，企业级规划器（Planner） |
| Haystack | 工业级NLP流水线，偏重RAG Pipeline |
典型协作模式
数据层：LlamaIndex（索引+检索）
↓
编排层：LangChain（Agent决策+工具调用）
↓
模型层：OpenAI/Claude/本地模型
场景示例：企业智能客服
- LlamaIndex构建产品手册的向量索引+关键词索引混合检索
- LangChain Agent判断用户意图，决定直接回答/检索知识库/转人工/调用订单API
选型建议
| 场景 | 推荐方案 |
|---|---|
| 纯RAG应用 | LlamaIndex为主 |
| 复杂Agent工作流 | LangChain + AutoGen |
| 已有数据基础设施 | LlamaIndex检索 + 自研Agent |
| 快速原型验证 | LangChain（生态最成熟） |
学习建议
建议从官方文档入手，动手搭建简单项目，理解各框架的模块设计与适用场景，重点掌握LangChain的链式结构与LlamaIndex的数据索引机制。
口语版讲法(约4分钟)
- 一句话定位：面试官问框架对比，本质是问选型能力
- LangChain vs LlamaIndex：一个偏编排，一个偏检索，边界划分
- 真实业务场景：企业智能客服，两者协作的完整链条
- 落地风险：检索质量、模型幻觉、系统复杂度
- 工程师判断收尾：我更倾向以检索为中心，编排轻量化
面试官问Agent框架对比，我觉得本质上不是考你背几个框架名字，而是看你面对真实业务场景时有没有选型能力。说白了，框架只是工具，关键是你知道什么场景该用哪个，以及它们怎么配合。
我先说两个最主流的。LangChain和LlamaIndex，很多人把它们放一起比，但我更倾向于把它们看成上下游关系。LangChain的定位是通用编排框架，它擅长的是把LLM调用、工具调用、记忆管理这些东西串成一条工作流。比如ReAct模式、Plan-and-Execute，LangChain都给你封装好了，你直接用就行。但它的检索能力其实不强，它依赖外部向量库，自己只做高层封装，比如RetrievalQA这些。
LlamaIndex正好反过来，它的核心就是数据检索。它支持100多种数据源加载，索引类型特别丰富，有向量索引、树索引、关键词索引，还能组合索引。它的检索策略也很深，比如Hybrid Search、Rerank、子问题分解这些。所以纯RAG场景，LlamaIndex是首选，检索精度和效率都优化得很到位。但它的Agent能力相对轻量，虽然也有OpenAIAgent，但复杂决策还是得靠LangChain。
那真实业务里怎么用呢？我举个例子，企业智能客服。比如用户问“我买的商品降价了，能退差价吗？”这个场景，你会需要两个能力：一个是检索产品手册里的退换货政策，另一个是调用订单API查用户订单状态。LlamaIndex负责建索引，把产品手册切分成段落，同时用关键词索引和向量索引做混合检索，这样用户说“降价”能匹配到政策，说“退差价”也能匹配。然后LangChain Agent来做决策，它判断用户意图：如果直接能回答，就从LlamaIndex检索结果里取；如果需要查订单，就调订单API；如果问题复杂，再转人工。这样两个框架配合，一个管数据，一个管流程，各司其职。
这里有个坑，就是落地时你得注意前提。LlamaIndex检索质量好不好，取决于你的Chunk策略和Embedding模型。如果文档结构复杂，比如条款里有很多例外情况，简单切分就会漏信息。我一般会用Parent Document的方式，先把大块文档索引起来，检索时先找小片段，再回溯到父文档，这样上下文完整。另外，Hallucination风险也很高，Agent如果调错API或者检索结果不相关，就会乱回答。所以上线前我会做一套回放测试，拿历史对话去测，看召回率和回答准确率，不达标就调参数。
还有一个点值得注意，就是多Agent协作。比如客服场景里，可能需要一个Agent专门处理退款，另一个处理物流查询，它们之间怎么通信、怎么避免冲突，这个LangChain和AutoGen都在做，但还没有特别成熟的方案。我自己试过用LangGraph定义状态机来协调，但复杂度上来了，维护成本也高。
所以总结一下我的选型倾向。如果项目是纯RAG，比如知识库问答，我直接上LlamaIndex，检索做深一点，Agent用简单的ReAct就行。如果要做复杂工作流，比如多步推理、多工具调用，我会用LangChain做编排，但检索层还是会交给LlamaIndex或者自己封一个检索模块。我更倾向把检索和编排解耦，这样出了问题好排查，也方便换组件。最后再补一句，框架变化很快，别死记API，理解它们的设计哲学和适用边界更重要。
关键一句:多Agent协作的通信和冲突问题还没有成熟方案，用LangGraph定义状态机可以协调，但复杂度高。
面试官还可能这样问
- 问法 1 · 场景切入
假设我们要做一个企业智能客服，需要从产品手册里检索信息，还要调用订单API、判断是否转人工。你会怎么选框架？LangChain和LlamaIndex各自负责什么，怎么配合？
- 问法 2 · 层层追问
现在做Agent开发，常用的框架有哪些？……LangChain和LlamaIndex你更倾向哪个？……那如果我要做一个RAG知识库问答，LlamaIndex有什么独到之处？LangChain在Agent场景下又强在哪？
- 问法 3 · 直球架构
直接说一下你熟悉的Agent开发框架，对比LangChain和LlamaIndex的核心定位、功能差异，以及它们在RAG和Agent系统构建中分别适合什么样的场景。