RAG 框架其实可以混着用：一种常见的生产组合
数据截至 2026-07，价格与限额以各官网为准。
这几个 RAG 框架不是互斥的替代关系，把它们摆成单选题本身就是个假问题。一种在生产里被反复用到的组合是：LlamaIndex 负责 ingestion 与索引，LangChain 负责编排，LangGraph 负责 agent 工作流——各自守住自己最擅长的那一段，而不是逼一个框架把全链路都扛下来。
先承认一个很常见的误解：不少人觉得”混着用”等于技术栈失控，是架构没想清楚才留下的历史包袱。这个担心不是没道理，但它把”混用”和”乱用”混为一谈了。真正会失控的是同一件事被两个框架各做一遍——两套检索逻辑、两套 prompt 拼装、两份配置——那确实是负债。而按职责分段、每段只有一个负责人的组合，跟微服务里按边界拆分是同一个道理，不会因为出现了两个依赖名就自动变成坏架构。
下面按七节展开：这个组合具体长什么样、为什么能成立、怎么按瓶颈决定谁进来、边界怎么划、自托管那一段怎么摆、star 数为什么不能当选型依据，以及混着用要付出什么代价。
一、这个组合具体指什么
拆开看是三段分工：
- LlamaIndex 做 ingestion 与索引：把散落的私有内容——文档、数据库导出、内部系统里的记录——读进来、切块、建立索引。这一段的成败决定了后面所有环节的天花板，索引建得糙，再好的编排也捞不回来。
- LangChain 做编排：把模型调用、检索调用、外部工具调用串成一条可控的流程，处理分支、重试、上下文拼装这些”胶水”逻辑。
- LangGraph 做 agent 工作流：当任务不是”检索一次、回答一次”，而是需要多轮判断、条件跳转、循环推进时，由它来承载状态和流转。
这三段的顺序不是随便排的：数据先要变成可检索的形态，才谈得上编排；编排稳定了，才谈得上把它包进一个会自己决定下一步做什么的 agent 里。跳过前两段直接上 agent，通常的结局是 agent 在一堆质量不佳的检索结果里空转。
二、为什么能混：它们的强项不在同一层
这三个名字经常被并列比较，但它们的重心其实错开了。
LangChain 出现最早、生态最大，有 chains、agents，以及对模型、嵌入、向量库的大量集成。它适合通用的端到端 LLM 应用与 agent——要灵活性、要连接器，它给得最多，代价是学习曲线更陡。要接外部工具、要做复杂的 agent 循环、要深度接 LangSmith 做监控，它的位置很难被替掉。
LlamaIndex 是数据优先的，专注于对私有内容做索引与查询，RAG 专用的原语更贴身。相比之下 LangChain 是生态更广但抽象开销更高。数据密集型的 RAG、需要深度 ingestion 连接器、要用上高级索引策略的场景，它更顺手。这两者的分工细节可以参考 LangChain 和 LlamaIndex 的分工：一个广一个深。
RAGFlow 是开源 RAG 引擎，强项在深度文档理解——分块尊重文档结构，内置知识图谱构建与版面感知解析。扫描版 PDF、财报、版式复杂的法律文书这类传统文本解析器搞不定的语料，它是常见的入手点，另外还配了低代码界面来搭 RAG 工作流。
一个是编排层的通用底座，一个是数据层的专用工具，一个是把难啃语料变成可用文本的引擎——重心不重叠，这才是能拼在一起的前提。如果三者真的功能高度重合，混用才是纯粹的浪费。
三、按瓶颈决定谁进你的组合
组合不是越全越好，进来一个就多一份维护成本。判断标准只有一个：你现在卡在哪。这里有四种典型情况：
- 瓶颈在解析，也就是 PDF 质量差、表格提取乱、扫描件根本读不出文字：从 LlamaIndex（LlamaParse）或 RAGFlow 入手。
- 瓶颈在检索，召回不准、混合检索和重排还没调过：LangChain、Haystack、Cognita 这几个可调的旋钮最多。
- 瓶颈在评估，也就是改了一版说不清到底变好还是变坏：不用换框架，在你已有的栈上加挂 RAGAS。
- 语料本身是有链接的结构化内容，实体之间关系密集：考虑图检索，比如 RAGFlow 的 GraphRAG。
按这个顺序去看，很多团队会发现自己其实只需要两段，第三段是想象出来的需求。更完整的判断路径见 RAG 框架怎么选？按瓶颈选，别按 star 数选。
四、边界怎么划才不会退化成乱用
混着用真正的技术活在于划边界。几条可操作的做法：
用产物做接口，而不是用对象做接口。 ingestion 那一段的输出应该是”落在向量库里的向量与元数据”，而不是某个框架里的内存对象。索引写进独立的向量库之后，编排层只跟向量库说话，不去 import 索引框架的类。这样任何一段被换掉，另一段都不用跟着改。
检索逻辑只允许有一个实现。 这是最容易破防的地方——LangChain 有自己的 retriever 封装，LlamaIndex 也有，图省事的写法是两边各写一点，结果线上排查时没人说得清某次回答的上下文到底是谁捞的。定一个负责人，另一边只调接口。
配置集中一处。 嵌入模型、切块大小、top-k、重排开关这些参数，散在两个框架的初始化代码里，改一次要找两处。抽到一个配置文件里，两边都从那里读。
先跑通固定流程，再上 agent。 把整条链路当作确定性 pipeline 先跑通、先能评估，之后再把它包进 LangGraph 的工作流里。反过来做，agent 的不确定性会掩盖底层检索的问题，调试成本高得多。相关思路可以看 Agentic RAG 是什么。
五、自托管那一段怎么摆
数据要留在内网，就得挑可自托管的组件，这里各家的形态并不一样。
RAGFlow 走 Docker 部署，提供 slim 与 full 两种镜像，slim 约 2GB、full 约 9GB，区别在于是否内置嵌入模型。选哪个取决于你是打算用自己已有的嵌入服务，还是希望开箱即用。
LangChain 和 LlamaIndex 本质上是库，它们没有”部署”这回事——所谓自托管就是你自己跑 Python 服务，再自己跑一套向量库。这一点在做资源规划时容易被忽略，把它们和 RAGFlow 放在同一张部署清单上比较是不成立的。
向量库这一层常配 Qdrant，它支持过滤、payload 索引与量化，可以作为独立二进制运行，也可以跑 Docker 容器。第三方评测称它在 100 万以上向量规模下可以做到 50ms 以内的检索，这是第三方基准口径而非官方指标，你自己的语料、维度和过滤条件都会改变实际表现，落地前还是要用自己的数据压一遍。向量库的横向比较见 向量数据库怎么选。
如果对搭建速度的诉求高于对内网留存的诉求，用 Dify 这类低代码平台可以省掉不少搭建成本，代价是灵活度和可控性下降。这是一个取舍，不存在普遍正确的答案。RAGFlow 那一段的具体部署可以参考 RAGFlow 文档解析怎么用。
六、star 数别当选型依据
顺带把一个常被拿来当结论的数字说清楚。截至 2026 年 1 月的 GitHub star 排名大致是：LangChain 约 125,000，Dify 约 114,000，RAGFlow 约 70,000，LlamaIndex 约 46,500，Haystack 约 24,000。这五个数字都带着明确的时间点，写进方案时不要当成当前值。
更重要的是，star 数只反映关注度，不反映它跟你的场景合不合。star 数最高的项目未必解得了你手上那批扫描件，star 数相对靠后的项目可能恰好就是你缺的那一块。把它当成”这个项目有人维护、遇到问题能搜到答案”的参考指标是合理的，当成排序依据就跑偏了。
七、混着用的代价，得诚实说
这个组合不是没有成本，下面几点在拍板之前应该先摆到桌面上。
抽象层叠加会带来开销。 有评测指出，LangChain 的 LCEL 语法能做复杂的查询重写，但相比 LlamaIndex 的直接检索会多出约 15-20% 的延迟开销。这是第三方基准口径，不是官方数据，具体表现要看你的链路长度和调用方式。如果你的场景对首字延迟很敏感，这部分开销值不值得，需要自己测过再定。
版本升级的协调成本变成两份。 两个活跃项目各自迭代，接口变动的节奏不同步，升级窗口需要自己盯。缓解办法是把跨框架的交界处收窄到尽量少的几个函数里，这样每次升级只需要验证那几处。
新人上手的门槛更高。 一个人要同时熟悉两套心智模型。写清楚”哪一段归谁”的文档，比多写几行代码更有价值。
并不是所有团队都需要这么拆。 如果你的语料干净、检索需求简单、也没有多轮 agent 的诉求，单框架跑完全链路更省事。这个组合解决的是”某一段明显吃力”的问题，没有那个明显吃力的段落时，拆开只会徒增复杂度。
以上各项目的具体能力、参数和部署方式都在持续变化，落地前请以各项目官方文档的当前版本为准。
小结
RAG 框架不是单选题，LlamaIndex 做 ingestion 与索引、LangChain 做编排、LangGraph 做 agent 工作流，是一种被反复用到的生产组合。能混的前提是它们重心错开：一个偏数据层，一个偏编排层，RAGFlow 则是啃难解析语料的引擎。要不要引入某一段，看你当前卡在解析、检索、评估还是知识关系上，别按 star 数排序。混着用的关键在划边界——用落库产物做接口、检索逻辑只留一个实现、配置集中一处、先跑通确定性流程再上 agent。同时也要认账：抽象叠加有延迟开销，维护成本翻倍，语料干净、需求简单的团队用单框架反而更划算。