企业官网建设流程全解析

LangChain和LlamaIndex这两个名字，最近两年几乎成了大模型应用开发圈绕不开的经典选择题。每次有人问我"到底选哪个"，我一般不会直接给答案，而是先反问一句：你手里要做的，是一个会调用工具的Agent，还是一个要给一堆文档做问答的知识库？这两个框架看起来都在做大模型应用支撑，但核心优势点完全不同。选错方向，写代码的时候可能还没什么感觉，等项目进入维护期，想改架构、调检索、加新工具，才会意识到当初选错了抽象层次。

这篇文章想把LangChain和LlamaIndex各自的优势、适用场景和选型逻辑讲透。内容不吹不黑，都是我实际做项目、帮别人做技术选型时踩过坑之后沉淀下来的判断方法。不管你是刚接触大模型开发的新手，还是已经在生产环境里迭代过几轮的工程师，这里的对比维度多少能给你一点参考。

1. 为什么LangChain与LlamaIndex会变成二选一难题

1.1 表面上都在做同一件事，底层的抽象层次并不一样

先说结论：这两个框架确实有很大功能重叠，都支持文档加载、向量检索、提示词管理、模型调用、Agent，甚至最近都加入了类似工作流的编排能力。但这不等于它们可以互相替代，因为核心抽象完全不同。

LangChain的核心抽象是"流程"。PromptTemplate、Model、OutputParser、Retriever、Tool，全部被包装成一个个可串联的组件。你思考问题的角度是：一次任务要分成几步，每一步由模型做还是由工具做，步骤之间怎么传参，失败怎么重试。一句话概括，LangChain帮你组织"模型和外部世界的交互"。

LlamaIndex的核心抽象是"数据"。Document、Node、Index、QueryEngine。你想的是：我的资料从哪来，PDF怎么解析，长文档怎么切，metadata怎么保留，检索时按向量还是按关键词还是组合，检索结果怎么交给模型组织回答。一句话概括，LlamaIndex帮你组织"外部数据进入模型上下文"的过程。

这个差异不是文档里的一句口号，它会体现在每个核心接口的设计上。比如你用LangChain做一个RAG，文档加载只是众多环节之一，你还要自己纠结retriever怎么接chain；而LlamaIndex里文档到索引本身就是它的主场，数据加载和检索的默认配置都经过专门优化，写起来明显更顺手。

1.2 出身背景已经决定了各自的长处

这两个框架的起点完全不同。LangChain最早就是冲着"把多次模型调用串成链"去的，让模型可以做多步骤推理，后来一步步加入memory、agent、tool、retriever，从聊天应用扩展到复杂任务编排。所以它对模型行为的抽象特别丰富，也很早就形成了"模型为主角、数据是配角"的设计气质。

LlamaIndex的前身GPT Index则是从"给文档做索引"起步的，初衷是解决模型上下文不够用、需要检索外部知识的问题。它的整个演进都围绕一个目标：如何把千奇百怪的资料变成模型可高效查询的内容。后续加入QueryPipeline、Agent、Workflow，出发点还是"更好地完成以检索为基础的问答任务"。

打个不太严谨但很形象的比方：LangChain像剧组里的导演，脑子里全是脚本、分镜、灯光怎么配合，目标是让整场戏按剧本走；LlamaIndex像资料管理员，脑子里全是资料怎么分类、怎么编目、怎么快速调出来，目标是让模型想找什么都能精准拿到。你让导演去整理档案库，或让管理员去导一部戏，不是完全干不了，但就是不得劲。

2. LangChain的核心优势：流程编排和生态纵深

2.1 一套可任意组合的Runnable管道

LangChain最值钱的东西，是它的LCEL（LangChain Expression Language）和RunnableProtocol。在这个设计里，几乎一切对象都实现了一个统一的接口：输入一个值，输出一个值。这让组件之间的组合变得非常优雅，用管道符就能串起一条业务链路。

from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI prompt = ChatPromptTemplate.from_template("用一句话解释：{question}") model = ChatOpenAI(model="gpt-4o-mini") chain = prompt | model | StrOutputParser() result = chain.invoke({"question": "什么是RAG"})

这段代码看着简单，背后是完整的Runnable协议。如果我要加入检索、加入记忆、加入工具调用，也是一样往里接组件就行，模型调用天然支持流式、异步、批次执行。这种管道式写法在Agent场景里特别有价值，因为你可以在不改整体结构的前提下，随时在链路中间插入一个路由判断、一个验证步骤或一个工具节点。模块之间的边界很清楚，出了问题能直接在某个节点上单独测。

2.2 Agent和状态图：处理复杂行为时的心智模型

LangChain另一大优势是Agent生态。这里的Agent不是简单的"让模型决定调用哪个函数"，而是完整的行为编排方案。React风格的工具循环、结构化输出、多Agent协作、基于状态图的控制，都有比较成熟的实现。

我个人的体会是，LangChain的Agent在心智上很契合"让语言模型做动态决策"这类需求。比如一个客服场景，用户问"帮我查一下上个月的订单物流"，模型要先判断这个请求需要调用订单接口还是物流接口，然后再决定调用参数、解析结果、组织回答。这种任务如果用纯代码写if-else，规则会越写越厚；而交给Agent编排后，决策逻辑留在模型提示词里，代码结构反而干净。

LangChain系列配套的调试工具也值得一说。Agent跑起来之后的不确定性很高，同一句话两次可能走不同分支，没有调用链追踪几乎没法排查。官方工具能够看到每一步的输入输出、耗时和token消耗，定位问题效率提升非常明显。

2.3 生态广度是被低估的护城河

LangChain最让人离不开的，其实是生态。从模型厂商到向量库、从文档加载器到第三方API工具，几乎你叫得上名字的都有对应集成。这意味着做技术选型时不用担心"这个功能框架不支持"，更多时候是自己要不要用的问题。

再加上社区教程存量特别大，遇到报错搜一圈基本都有解。对项目周期紧、团队经验不深的场景来说，这个隐性优势比某个先进特性值钱得多。

但代价也要讲清楚。LangChain概念矩阵确实庞杂，早期版本里Chain、Agent、Tool、Memory、Callback等概念交叉很多，新人很容易迷失在"应该用类A还是类B"的选择里。API变动也比较频繁，大版本升级时一堆import路径要改，维护成本要注意。用LangChain前建议锁定版本，对外部依赖做一层封装，避免核心代码被框架演进绑架。

3. LlamaIndex的核心优势：数据接入与检索深度

3.1 文档加载和解析：把杂乱资料变成规范节点

如果说LangChain的长处是把组件串起来，那LlamaIndex的长处是把数据管起来。这个框架对"从原始资料到可查询内容"这一整条链路有完整覆盖，而且每一环都做得比较细。

首先在数据接入上，它自带各种Reader，涵盖PDF、Word、Excel、网页、数据库、API等常见数据源，Hub上还有大量社区贡献的加载器。最关键的是，它提出了明确的Document和Node概念。加载进来的每个文档会被切分成若干Node，每个Node可以挂metadata、保存文档来源、记录前后节点关系。这在后面的检索和引用溯源中极其重要。

我当时帮某开发者调一个企业知识库项目，对方资料里大量是扫描版PDF和带复杂表格的Excel。用通用加载会丢结构，LlamaIndex可以做更细腻的解析配置，控制每个Node存哪些字段、如何保留层级信息。这类需求如果在LangChain里虽然也能做，但很多地方要靠自己写预处理逻辑，相当于把框架省掉的活又捡了回来。

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader documents = SimpleDirectoryReader("data").load_data() index = VectorStoreIndex.from_documents(documents) query_engine = index.as_query_engine() response = query_engine.query("这份文档的核心结论是什么？") print(response)

3.2 索引结构不是只有向量这一条路

很多人一提到检索就默认是向量检索，这个认知放在LlamaIndex里就有点浪费了。它设计了一套多种索引结构，针对不同数据形态和查询习惯给出不同选择，这是我最初看中它的原因。

• VectorStoreIndex：语义相似度检索，适合自然语言问答。
• SummaryIndex：按顺序组织Node，适合对整个语料做汇总提炼。
• TreeIndex：先把数据分层摘要再检索，适合超长文档。
• KeywordTableIndex：按关键词匹配，适合术语密集、对精确性要求高的查询。
• KnowledgeGraphIndex：提取实体关系，适合知识图谱类问答。

举个例子，某研究类问答项目里，文档充斥着专业缩写和术语。纯向量检索容易把查询向量带到语义相近的段落，关键词索引反而能直接命中精确表达。更好的做法是向量和关键词双路召回，合并排序后再交给模型。这种多索引组合在LlamaIndex的体系里几乎是一等公民，你可以用QueryPipeline把多个retriever串起来，写起来很自然。而LangChain虽然也有对应的组合检索器，但整体设计重心并不在这里。

3.3 查询管线：每一步都看得见、可替换

LlamaIndex对开发者的另一个好处是"不黑盒"。从加载、切分、向量化、检索到最终合成的每个环节，都可以显式指定。觉得检索结果不准，可以单独换retriever、改top-k、调相似度阈值；觉得生成答案太啰嗦，可以单独换合成模式。整个RAG链路的性能瓶颈能快速定位。

它后期加入的QueryPipeline和Workflow，让用户可以把多个步骤命名后显式串联，比如"关键词召回 + 向量召回 -> 合并去重 -> 排序 -> 合成"。这种精细控制对生产环境的RAG效果调优非常有帮助，因为你不需要为了一个小改动把整个链路推翻重写。

换个角度看，LlamaIndex不够擅长的是通用行为编排。它的Agent抽象虽然也在演进中不断增强，但对复杂工具链的编排、多Agent协作这类需求，设计重心终究不在那里。强行也能做，但就是会有点拧巴。

4. 一张决策表：什么样的项目该选谁

4.1 以行为编排为核心的项目：LangChain更顺手

判断标准很简单：核心难点是不是"让模型根据情况做多种决策、调用多种外部能力"。如果答案是肯定的，LangChain合适。典型场景包括智能客服、代码助手、多工具工作流、多Agent协作。这些项目的复杂性不在数据，而在任务流程和分支决策上，LangChain的Agent、状态图、管道抽象正好切中要害。

举个例子，某电商客服Agent需要根据用户问题判断走退换货流程、物流查询流程还是商品推荐流程，每个流程还要调用不同的内部API。这个项目的核心是流程逻辑、动态决策和工具调用，LangChain的编排模型就特别自然。你可以把整个客服会话看成一个状态机，模型在每一步决定下一跳点，工具调用则作为节点插入。

4.2 以数据检索为核心的项目：LlamaIndex更直接

反过来，如果核心难点是"文档量大、格式杂、检索要求细致"，LlamaIndex更省心。典型场景是企业内部知识库、合规文档问答、研究资料分析、合同审查辅助。这些项目的复杂性在数据侧，语义检索必须结合关键词、全文、来源、权限过滤来综合做，这正是LlamaIndex的主场。

某开发者的企业制度问答系统，把几千份制度文件按部门、制度类型、生效年份分别做好metadata，然后按用户问题做向量加关键词双路召回，再按权限过滤候选节点后交给模型回答。整个过程用LlamaIndex实现时，每一步都有对应抽象，调试起来很顺。同样功能用LangChain也能做，但会比LlamaIndex多写不少胶水代码。

4.3 两者的适应范围对照表

如果项目两边都占，我的建议是不要硬选一个，而是拆分职责：用LlamaIndex做数据接入和检索层，用LangChain做Agent和行为编排层，通过retriever接口对接。我实际参与过这类组合方案，效果比单押一边要好。

5. 我判断选型的三个抓手

5.1 先判断复杂度落在数据轴还是行为轴

很多人选型时喜欢数功能：A支持这个，B不支持那个，那我选A。这是一种危险的习惯。功能列表是最容易变化的东西，协议类的支持也很快会趋同，不应该成为决定性因素。

我一般会把需求拆成两个轴：数据复杂度和行为复杂度。数据复杂度指的是资料来源多不多、格式乱不乱、检索要求细不细，比如上百种模板文件、需要权限过滤、需要指定来源引用。行为复杂度指的是模型要不要做多步决策、要串多少外部工具、分支逻辑深不深，比如客服流程、报告生成流水线。

数据轴长，优先LlamaIndex；行为轴长，优先LangChain；两轴都中等，按团队熟悉度选。这个判断方法比翻功能对比表可靠得多。

5.2 维护成本和版本风险要提前算

框架的API稳定性是生产选型里容易被忽略的一点。LangChain大版本升级时常见import路径大规模调整，依赖版本变化也牵一发动全身。LlamaIndex核心概念相对集中一些，但同样在快速演进。所以不管选谁，都建议在项目代码和框架之间加一层自己的封装接口，把"和框架耦合的部分"收敛到几个文件里。这样框架怎么变，你只需要改这一层，业务代码不用动。

另外还有一个很多人踩过的坑，叫"抽象泄漏"。框架给的默认配置不见得适合你的数据。chunk size默认值是通用经验值，放到专业文档上未必好用；embedding模型不同，检索效果差距巨大。这些都不是框架问题，而是配置问题。别一上来就把框架当黑盒，要愿意去读它的默认值是什么、每个参数控制什么。

5.3 用最小Demo跑出手感再决定

技术选型这件事，看文档十遍不如动手跑一遍。我的做法是准备两个最小实验：一个是文档问答Demo，给定十几份格式混杂的资料，实现加载、建索引、查询、答案带上来源引用；另一个是工具调用Demo，让模型根据用户请求选择并调用工具，然后把结果组织成回答。

用两个框架各写一遍，整个过程会告诉你很多东西。写RAG时哪个更顺、调检索时哪个可选项多、写Agent时哪个心智负担小、报错时哪个社区解答更全，很快就有体感。做完这两个Demo，你会发现上面那些对比维度都变成了切身感受，而不是纸面结论。

6. 实测下来的一点体会

6.1 知识库和Agent项目的"组合打法"

我自己看过、也参与过不少项目，一个观察是：纯知识库项目用LlamaIndex，纯Agent项目用LangChain，最后效果都还不错。真正复杂的是那种又想问答、又想做智能体交互的系统。

有一类项目是这样拆的：LlamaIndex负责接收企业资料、做解析和索引、向外提供retriever接口和query engine；LangChain负责对话流程、意图判断、工具调度，需要查资料时把问题交给LlamaIndex这边的检索服务，拿回上下文再继续往下走。两边各用自己的强项，接口通过自定义的方式对接，整体运行起来非常稳。

6.2 新手入门尽量先手写再上框架

如果是从零开始学，我强烈建议先用基础库手写一遍RAG：读文档、切分、调embedding接口、存向量、查相似、拼prompt给模型。这个过程可能两三天就搞定，但你会把每一个环节的细节看明白。再看框架时，你会清楚它替你做的是哪部分工作、哪些配置可以在哪里覆盖，而不是对着抽象接口猜来猜去。

顺便说一句，现在很多教程上来就教框架，反而把最基本的原理跳过去了。遇到框架报错、效果不好时，能救你的往往不是框架知识，而是你对手写RAG每一步的理解。

6.3 框架不是信仰，选型是约束条件的最优解

最后说点实在话。LangChain和LlamaIndex都在不断向对方擅长的地方延伸，也许再过一段时间，两者的边界会更模糊。到那时候决定选型的可能就不是技术特性，而是生态习惯、团队熟悉度、社区活跃度这些"软因素"。

我的态度是：不把任何框架当成信仰。做数据重的项目，我会觉得LlamaIndex在专属跑道上跑得舒服；做行为重的项目，我会觉得LangChain的编排思维更放松。先判断约束，再谈偏好，选型这件事就没那么难了。