LangChain 教程：对比 LlamaIndex，选对 RAG 与智能体框架

LangChain 教程：如何在 LlamaIndex 和 LangChain 之间选型？

以文档为核心的应用，优先选 LlamaIndex；需要跨工具协调任务的智能体，优先选 LangChain。 两者都能实现检索增强生成，即 RAG：先检索相关来源材料，再让模型据此回答。

如果你是创业者，准备基于产品手册搭建客服助手，LlamaIndex 更适合作为起点。它围绕文档、索引和查询引擎建立抽象，让代码直接体现从数据接入到生成答案的完整路径。如果眼前要解决的是漏检段落、文档结构，或哪些依据会进入模型，就从这里开始。

如果你是开发者，要做的助手需要阅读政策、核对订单，并在退款前请求审批，LangChain 更适合作为起点。它当前的智能体 API 以工具和模型循环为核心，由 LangGraph 提供底层执行框架。如果接下来要处理的是状态、审批，或下一步执行什么动作，就从这里开始。

如果现有应用已经满足检索和工作流需求，继续用就好。换个框架并不能修复解析错误的表格，也不能让不安全的支付操作变得安全。先明确具体出了什么问题，再补上解决它所需的组件。

本文从文档处理、智能体执行控制、集成边界和持续成本几个维度进行判断。结论基于文档分析，并非实测的速度或准确率排名。

来源：LlamaIndex 文档、LangChain 文档、LlamaIndex 包与 LangChain 包，以及各厂商的 LlamaParse 定价与 LangSmith 定价。表中付费托管服务承担的任务不同，不能视为可直接替换的同类订阅。

LlamaIndex 和 LangChain 如今各自解决什么问题？

LlamaIndex 不只是索引，LangChain 也不只是链式调用的集合。 两者当前的文档都将智能体纳入各自生态。关键区别在于：面对你的任务，谁能提供更合适的起步结构。

LlamaIndex：数据流水线与文档智能体

LlamaIndex 是面向自有数据智能体的开源框架，组件覆盖文档加载、可检索表示的构建、依据检索和答案生成。它的 Workflows 还支持包含分支、重试和人工审核的事件驱动流程。官方框架概览明确介绍了这些超出索引的能力。

对合同助手而言，最有用的处理单元往往是文档段落：它来自哪里、属于哪个版本，以及所在章节是否会影响其含义。LlamaIndex 的 Node 将源内容片段、元数据和关联关系放在一起，方便管理这些依据；查询引擎再将检索与答案生成衔接起来。具体可参考 VectorStoreIndex 指南。

它的局限在于输入材料的质量。如果加载器把表格压平成文本，价格就可能与对应的列标题脱节；给这段文本建立索引，只会把错误一并保存下来。LlamaIndex 官方文档也区分了适合干净文本的内置读取器，以及处理复杂文档的商业服务 LlamaParse。可以因为数据抽象而选择框架，但解析能力需要单独评估。

维护情况也值得纳入判断：官方当前的包说明表示，主要重心已经转向 LlamaParse 及相关文档工具，框架仍作为开放工具包提供。如果打算长期依赖它，应先检查所需集成组件的维护情况。

LangChain：以 LangGraph 为底层的智能体框架

LangChain 是开源框架。其当前的 create_agent API 提供可配置的智能体运行结构，将模型完成任务所需的工具、指令和执行逻辑组织起来。中间件则用于定制这一循环前后的行为。官方概览说明，这些智能体以 LangGraph 为底层。

对于订单客服智能体，检索可能只是众多工具之一。应用还可能查询物流状态、准备退款方案。如果产品的核心就是这些工具之间的协作，LangChain 是自然的起点。

它的局限在于，智能体抽象无法替你决定必须遵守的业务规则。哪些用户可以退款、需要什么审批、怎样避免重复执行导致重复退款，仍需由你定义。框架提供执行机制，应用负责业务规则。

LangChain 和 LangGraph 该怎么选？

如果任务适合让模型自行选择工具，可以使用 LangChain 的智能体抽象；如果需要更明确地定义工作流状态及其转换，则直接使用 LangGraph。当前 LangChain 智能体本就包含 LangGraph，因此增加记忆或人工审核，并不必然意味着重写。单独的 LangChain 与 LangGraph 对比会进一步讨论这一选择。

Python 版本与许可证

**核实日期为 2026 年 10 月 13 日：**当时已发布的 Python 包分别为 llama-index 0.14.25、llama-index-core 0.14.25、langchain 1.4.5 和 langgraph 1.2.15。这些是各个包在该时间点的版本，并不代表同一生态中的所有集成组件共用一个版本号。

两个框架仓库均采用 MIT 许可证，参见 LlamaIndex 许可证和 LangChain 许可证。托管产品另有商业条款。框架免许可费，并不包含模型推理、托管向量数据库或应用服务器的费用。

用两个框架完成同一个小型 RAG 任务

两个示例都读取本地文本文件，建立内存索引，再利用检索到的材料回答同一个问题。 示例用于展示 API 的使用方式，已对照文档检查；本次比较并未调用付费模型 API 实际运行代码。

创建 data 目录，放入你自己的 UTF-8 编码 .txt 政策文件。设置 OPENAI_API_KEY，再将两个脚本的 RAG_MODEL 都设为账户可用的同一款 OpenAI 聊天模型。两个示例都显式选用 text-embedding-3-small 生成嵌入向量，也就是用于查找相似内容的数值表示。LlamaIndex 入门教程也建议明确指定嵌入模型。

LlamaIndex 示例

安装 llama-index-core、llama-index-readers-file、llama-index-llms-openai 和 llama-index-embeddings-openai。也可以安装包含这些组件的 llama-index 入门套件，具体见安装指南。

import os
from llama_index.core import SimpleDirectoryReader, VectorStoreIndex
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.llms.openai import OpenAI

docs = SimpleDirectoryReader("data", required_exts=[".txt"]).load_data()
embed = OpenAIEmbedding(model="text-embedding-3-small")
index = VectorStoreIndex.from_documents(docs, embed_model=embed)
llm = OpenAI(model=os.environ["RAG_MODEL"])
engine = index.as_query_engine(llm=llm, similarity_top_k=3)
print(engine.query("What is the refund window?"))

这里的 from_documents 负责将文档转换为节点并建立索引，查询引擎则负责检索和综合生成答案。对小型知识助手而言，优势就在于代码能直接表达文档处理任务；需要调整时，也仍然可以访问更底层的组件。

LangChain 示例

安装 langchain-core、langchain-openai 和 langchain-text-splitters。这个固定检索流程使用 LangChain 的组件包，只有加入智能体时，才需要顶层的 langchain 智能体包。相关 API 见 RAG 指南、内存存储参考文档和 OpenAI 集成文档。

import os
from pathlib import Path
from langchain_core.documents import Document
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter
files = Path("data").glob("*.txt")
docs = [Document(page_content=p.read_text(encoding="utf-8"), metadata={"source": str(p)}) for p in files]
chunks = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100).split_documents(docs)
index = InMemoryVectorStore.from_documents(chunks, OpenAIEmbeddings(model="text-embedding-3-small"))
question = "What is the refund window?"
context = "\n\n".join(d.page_content for d in index.similarity_search(question, k=3))
llm = ChatOpenAI(model=os.environ["RAG_MODEL"])
print(llm.invoke(f"Answer only from this context; if absent, say unknown.\n{context}\nQuestion: {question}").content)

这个版本把各个步骤显式展开：加载文本、切分、生成嵌入并存储、检索段落，最后调用聊天模型。当检索只是大型应用中的一个环节时，这些额外的组装代码就有了价值。

检索与智能体控制：各自擅长什么？

文档检索的起步抽象，LlamaIndex 更合适；协调行动的智能体抽象，LangChain 更合适。 这是对工程适配度的判断，并不意味着任何一方无法完成另一方的任务。

文档接入与检索：优先考虑 LlamaIndex

如果大部分改动都发生在原始文档到模型获得依据的这段路径上，可以选 LlamaIndex。它的索引和查询引擎结构让相关工作集中在一起。比如，要跨合同修订文件回答问题的采购助手，首先需要保留来源之间的关系，而不是再加一个工具调用循环。

LangChain 也能搭建同样的检索流程。其 RAG 文档将索引构建与检索、生成分开，上面的代码展示了最直接的做法。如果已经有好用的搜索服务，从 LangChain 调用它，可能比引入另一个框架更省事。

当检索不再是难点时，选择也会改变。如果知识库已经整理好，应用又需要调用多个业务工具，就更值得把精力放在智能体工作流上。

工具调用与工作流控制：优先考虑 LangChain

如果应用需要在查找依据和执行动作之间来回切换，可以选 LangChain：先读取政策、查询客户记录、补问缺失信息，再准备待审批的操作。它可配置的智能体循环与 LangGraph 底层结构很适合这种流程。

LlamaIndex 同样支持智能体。官方智能体指南介绍了工具调用智能体，入门教程也将检索封装为可调用的工具。一个需要搜索、计算并返回答案的文档助手，完全可以只用 LlamaIndex。

如果现有工作流已经以文档为中心构建在 LlamaIndex 上，没有必要仅仅因为产品开始被称为“智能体”就迁移。只有新增的工作流控制需求足以支持更换执行层时，才值得迁移。

LlamaIndex 和 LangGraph 有什么区别？

LlamaIndex 与 LangGraph 往往处于不同层。LlamaIndex 可以准备和检索依据；LangGraph 可以控制有状态工作流在拿到依据后如何继续。LlamaIndex 自身的 Workflows 也是执行层的一种选择，因此组合使用属于架构决策，并不是为了补齐缺失功能。

判断标准是职责归属：文档检索应由一个组件负责，应用执行状态也应有明确的负责组件。如果两边都独立决定重试和对话状态，重复执行的问题就更难排查。

检索质量怎么评估？先看失败原因，再看框架品牌

功能清单无法证明任何框架的准确率更高。使用同一批来源材料和问题，先检查是否检索到了正确依据，再评价答案的文字表现。

以政策助手为例，测试问题应涵盖普通退款问题、只有修订文件才能回答的问题、材料中没有答案的问题，以及涉及用户无权访问文档的问题。回答流畅远远不够，还要检查来源版本、权限边界，以及答案是否有依据支撑。

先从固定检索流程开始。只有在再次收集依据能够修复失败答案的地方，才加入自适应搜索。Agentic RAG 解析介绍了这种额外决策循环在什么情况下值得投入。

哪些免费，哪些需要付费？

框架本身免费；托管文档处理、可观测性和部署服务需要另行购买。 下列价格已于 2026 年 10 月 13 日对照厂商当时的美国定价页面核实。

LlamaCloud 与 LlamaParse

LlamaParse 是 LlamaIndex 目前在公开定价页上使用的托管文档平台名称，通过 LlamaCloud 控制台访问，涵盖解析、提取和索引构建。它是与开源框架并行的商业服务；导入 llama_index 并不需要订阅它。

公开套餐包括：Free 为 $0/月，含 10,000 积分；Starter 为 $50/月，含 40,000 积分；Pro 为 $500/月，含 400,000 积分。Enterprise 采用定制报价。标准用量费率为每 1,000 积分 $1.25。

解析一个 PDF 页面消耗多少积分，取决于解析档位：Fast 消耗 1 积分，Cost-effective 为 3，Agentic 为 10，Agentic Plus 为 45。下图按这些公开费率，计算同一批页面所消耗积分的对应价值。计算未纳入赠送额度、订阅最低费用和附加项目，因此不代表月度账单。

Fast 输出的是保留空间布局的文本，而非 Markdown，只有这种输出适合你的数据接入流程时才应选它。积分充足也不等于没有套餐限制：Free 和 Starter 允许 5 个并发解析任务，Pro 则为 20 个。升级应出于容量或功能需求；积分包变大，不代表每个积分会自动变便宜。来源：用量定价和套餐对比。

LangSmith

LangSmith 是 LangChain 生态中的商业可观测性、评估与部署平台。它也能追踪使用 LlamaIndex 等其他框架构建的应用，因此是否使用 LangSmith，可以独立于框架选型决定。官方对这种跨框架支持有专门说明。

LangSmith 定价列出的 Developer 套餐为 $0/月，含一个席位及 5,000 条基础追踪记录；Plus 为每席位每月 $39，共含 10,000 条基础追踪记录。额外用量另行计费，Enterprise 采用定制报价。

一条追踪记录对应一次应用执行，其中可以包含多次模型调用和工具事件。它既不等于一个 token，也不等于某个检索段落。Plus 包含一个小型无服务器部署，但额外的部署用量仍需单独预留预算；厂商建议面向客户的智能体使用专用部署。

同样的月度用量，两种框架各花多少钱？

如果服务种类和用量完全相同，换框架并不能节省订阅费。 下面设定一个范围明确的月度场景，应用和索引另行托管：

• 三名开发者需要 LangSmith Plus 席位。
• 应用产生 20,000 条基础追踪记录。
• 使用 LlamaParse 的 Agentic 档位解析 1,000 个新增 PDF 页面。
• 两种实现使用相同的聊天模型、嵌入模型和 token 用量。
• 该场景不使用托管 Index、保留文件存储，或其他消耗积分的文档操作。

解析共消耗 1,000 × 10 = 10,000 积分。如果 Free 套餐的月度额度尚未用于其他用途，正好可以覆盖。实际支出为 $0，尽管消耗积分按公开费率计算的价值为 $12.50。这两个数字含义不同：在 Free 套餐内，消耗了有标价的积分，并不意味着产生了账单。计算依据：LlamaParse 套餐和用量费率。

当前 LangSmith 价格计算器显示，每条额外追踪记录消耗 0.005 LSU，每 LSU 为 $1。三个席位的费用为 3 × $39 = $117。超出共享额度的追踪费用为 (20,000 − 10,000) × $0.005 = $50。所选服务的费用小计为：使用 LlamaIndex 时 $167/月，使用 LangChain 时同样是 $167/月。

这笔小计不包含模型推理、嵌入和自有托管费用。应用总预算还需要把这些支出加上。比较时采用相同的模型工作负载，才能保持这部分输入一致；如果某个框架导致额外检索或模型调用，工作负载就变了，需要另行测量。

这里不存在由框架本身决定的费用交叉点：两个框架的许可费始终为零，也都能使用同一组付费服务。把 $50 的文档处理服务和 $39 的可观测性服务直接比较，实际上是在比较不同任务。真正要决定的是应用需要什么服务，以及会消耗多少用量。

计费差异：检索查询与聊天轮次不是一回事

LlamaParse 的托管 Index v2 对每次检索查询收取 1 积分，对每轮聊天收取 100 积分，另加相关解析和存储费用。按标准费率计算，在扣除套餐额度之前，1,000 次操作对应的积分价值分别为：检索 $1.25，或托管聊天 $125。它们是不同操作，并不是同一个答案的两种报价。来源：Index 定价。

组合技术栈时，这个区别很重要。如果外层智能体已经负责生成最终答案，就需要明确它的检索工具应该返回依据，还是返回另一个服务综合生成的答案。这会同时影响接口和计费方式。本地调用 query_engine.query() 不会自动产生托管 Index 的聊天轮次费用；只有请求实际经过该托管服务，才涉及相应计费。

什么时候适合组合使用 LlamaIndex 和 LangChain？

当文档检索和行动编排各自都很复杂时，可以同时使用两者。 比如，一个既要理解政策修订、又要协调审批流程的客服智能体，就适合考虑这种组合。面对整理好的文本做简单问答，通常不需要。

让 LlamaIndex 负责文档接入与检索，对外提供职责明确的函数或服务，返回相关段落、来源标识和元数据。LangChain 智能体将该函数作为工具调用，底层仍由 LangGraph 执行。厂商的框架组合使用指南介绍了这种分工。

以客服场景为例，检索端应返回政策段落、文档 ID 和修订元数据。智能体再将这些内容与订单记录对照，提出待执行的操作。来源引用应一直保留到最终回复中，让应用能够核查答案的依据。

避免无意中把已经综合生成的答案，再套进另一个答案生成循环。查询引擎返回字符串虽然方便，却也可能让外层智能体看不到底层段落。如果需要核查来源，应优先返回包含明确依据的检索结果。只有在有意划分了这样的任务边界时，才使用已经生成的子答案。

两个框架带来的额外成本主要是维护：两套集成接口、更多依赖更新，以及一个需要增加监测的组件边界。只有能够明确说清各自职责，而不是笼统地说两者都“负责智能体”，这样的组合才站得住脚。

迁移框架时，哪些能保留，哪些容易出问题？

迁移成本主要在数据约定和工作流状态，而不是替换导入语句。 无论是从 LlamaIndex 迁往 LangChain，还是用 LlamaIndex 替换 LangChain 的检索组件，都应先梳理现有应用对外提供的接口约定。

保留原始来源文档和可导出的元数据，包括文档 ID、访问权限标签、来源修订信息及引用关系。这些是应用资产；框架专用的文档和节点对象，只是围绕这些资产建立的适配层。

只要嵌入模型、向量维度、存储文本和数据库模式仍然兼容，现有嵌入向量就可能继续使用。不要默认新适配器能原样读取所有字段。如果改变了分块边界或嵌入模型，就应安排重建受影响的索引，并重新评估检索结果。LlamaIndex 的向量存储指南区分了默认内存存储与持久化集成。

工作流中的对话状态、待审批事项和未完成操作，应作为独立的迁移工作处理。不要仅仅为了重建状态而重放历史工具调用：即使对话看起来正常，重复执行外部动作仍可能造成实际后果。切换流量前，先定义旧会话如何结束、新会话如何开始。

不要仅仅为了贴上智能体标签，就迁移一个运行稳定的 LlamaIndex 文档智能体；也不要因为另一个示例代码更短，就替换好用的 LangChain 检索流程。当现有抽象持续让某项具体需求更难表达或维护时，才值得更换。

常见问题

下一步先做什么？

从原型必须解决的具体问题出发。如果难点是找到正确的来源段落，就先用 LlamaIndex 搭建小型检索流程。如果难点是协调工具和经过审批的操作，就从 LangChain 开始，并定义哪些状态必须在步骤之间保留。第一个可用版本的范围应足够小，让你能够逐一检查检索来源和拟执行的操作。

选择框架前，可用 AI 业务工作流审查清单明确任务、所需依据以及哪些操作需要审批。