这四个项目都做混合检索、知识图谱、多模态摄取与智能体式检索——也就是说，你正准备做的那张功能对照表什么也定不了。真正起决定作用的是两件事。第一，这套框架是跑在你自己的进程里，还是作为一套自带数据库、自带用户体系、自带值班表的第二生产系统抵达。第二，文档解析的边界落在哪里——因为正是它决定了你那条质量最高的路径，是一件你自己托管的 Apache-2.0 产物、一张按页计费的账单，还是一份完全由你自己扛的集成工作。选姿态。能力在一年半以前就趋同了；姿态永远不会。
速览
四个总出现在同一张候选名单上、却并不属于同一类东西的项目。
| 项目 | 许可证 | 形态 | 它实际上是什么 |
|---|---|---|---|
| LlamaIndex | MIT | 库，在你的进程里 | 一个事件驱动的工作流框架，而它的商业重心是文档解析 |
| Haystack | Apache-2.0 | 库，在你的进程里 | 一个"组件加管道"的编排框架，对结构有主张，对厂商没有 |
| RAGFlow | Apache-2.0 | 服务，在你的进程旁边 | 一台围绕自家文档理解模型搭起来的、可部署的 RAG 引擎 |
| R2R | MIT | 服务，在你的进程旁边 | 一套以 REST API 暴露的智能体式检索系统，内建用户、集合与鉴权 |
有一个数字值得提一句然后就放到一边：RAGFlow 的 GitHub 星数在这四个里明显最多，领先于 LlamaIndex，Haystack 第三，R2R 最少。这个排名量的是"有多少人想要一套 docker compose up 起来就能给同事看的 RAG 系统"——那是一个真实且正当的想要，而它对"这四个里哪一个该进一套你要跑三年的服务"什么也说明不了。按星数排出来的候选名单，系统性地偏袒那些带界面的项目。
那道没人写进对照表的分野
LlamaIndex 与 Haystack 是库。你 import 它们、把组件接起来，检索跑在你的进程里——同一次部署、同一份日志、同一条追踪、同一个语言运行时、同一张依赖图。当一次查询返回了错误的段落，调查发生在你本来就开着的那份代码里，而修复随你下一次发布上线。
RAGFlow 与 R2R 是系统。你把它们部署起来——RAGFlow 是一组编排好的容器，Python 服务端加 TypeScript 前端；R2R 可以用 pip install r2r 起一个轻量实例，或者用 Docker Compose 起完整版——然后你的应用通过 HTTP 与它们对话。那道边界后面坐着第二个数据库，装着文档、切片、图谱与对话历史；第二套身份模型，有它自己的用户与集合；而在 RAGFlow 这里，还有一整套非开发者会直接上手使用的 Web 界面。这些都是实打实的能力。它同时也是一套第二生产系统，而你在得到它的功能的同时，也一并接手了它的升级节奏、它的备份方案、它的扩容行为与它的故障面。
这道分野最要紧的是团队不会预先盘算的那两个时刻。第一个是排障：库的失败是一个栈帧，服务的失败是一张针对"内部不是你写的"那个组件的支持工单。第二个是离开。从一个库迁走意味着重写那些接线；从一个服务迁走意味着要从一套按那台服务器自身便利设计的 schema 里，把文档、切片边界、图谱边、集合归属与权限状态统统导出来。上面那张矩阵里"离开的代价"一列量的就是这份不对称，也正是 Haystack 在这一列上得分最低的原因——管道是可序列化的组件图，所以你搭出来的东西在很大程度上是一份你带得走的描述。
这些都不说明"服务形态"是错的答案。如果你真实的需求里包含"一套合规团队不用提 PR 就能维护的知识库界面"，那么 RAGFlow 一个下午给你的东西，一个库一个季度也给不了。错误在于经由一张功能对照表拐到那个答案上去，而不是刻意地选它。
解析的边界落在哪里
在一份真实语料上，最大的那根质量杠杆既不是检索器也不是重排器。而是解析器有没有搞明白：那张合并了单元格的表格里、第三列的那个数字，属于往上数两行的那个行表头。下游的一切——切分、嵌入、重排、生成——都继承了这个判断，而一张被压平成散文的表格，再多的混合检索也救不回来。这四个项目在"谁拥有这一步"上下了三种不同的注。
RAGFlow 把它放进了产物里。DeepDoc 是它自家的一整套视觉文档理解栈——OCR、表格结构识别、版面识别，并可选用视觉模型流水线来处理 PDF 与 DOCX 里的图像——而它就装在那份 Apache-2.0 发行版之中。这是四者中那个不寻常的位置：质量最高的那条路就是自托管的那条，没有按页计的表，也没有任何文档离开你的网络。账单换成基础设施的形式送到，因为跑文档理解模型与跑一个 Python 服务，是两场不同的硬件对话。
LlamaIndex 走了相反的方向，而这个方向在它自己的产品叙事里清清楚楚：开源库是编排层，而商业重心已经挪到了 LlamaParse——一项以智能体式文档处理为卖点的服务。这是一门自洽的生意，也确实是一个很强的解析器。它同时也是一项结构性承诺：你质量最高的那条摄取路径要离开你的网络，并且按页计价——这在成为一场工程对话之前，先是一场采购对话与一场数据驻留对话。如果这两件事在你的组织里任何一件是难的，请在第一周就发现它，而不是在流水线跑通之后。
Haystack 与 R2R 都把解析当成一个槽位。Haystack 对此说得很明白——转换器和别的组件一样，设计上就是可替换的，而框架有意不去捆一个重量级模型——这意味着你可以把它指向明年胜出的那个解析器，也意味着够到质量天花板是你自己的集成项目。R2R 在它的 API 后面捆了一条能用的多模态摄取管道，前期省事，而当它成为吞掉你召回率的那个东西时，也更不容易被看见。
实际的推论：在比较任何别的东西之前，先把你自己的文档过一遍这四条摄取路径。挑二十份你最难啃的 PDF——扫描件、有嵌套表格的、双栏带脚注的——看看出来的是什么。这项对比花一天，而它对这几个项目的区分度，远高于任何查询质量基准，因为它量的是那一步"错了之后下游谁都撤销不了"的步骤。一般性的问题见面向 RAG 的文档解析。
四个项目都说"agentic"，说的是四件事
自 2024 年以来四个项目都加上了智能体的说法，而这个词如今几乎不含信息量。各自实际交付的是：
- LlamaIndex——Workflows。一套事件驱动的步骤组合模型，如今是构建任何非平凡东西的推荐方式，其上搭着 ReAct 与函数调用型智能体，并有一条把工作流当服务跑起来的部署路径。这是四者中最通用的一个：它是一种编写智能体控制流的方式，而检索是你能做的其中一件事。如果你想从一个库里同时拿到检索与编排，这一个是认真的。
- Haystack——把智能体做成管道组件。一个智能体由聊天生成器、工具调用器与工具组装而成，就在与其他一切相同的管道模型里；而 Hayhooks 把管道与智能体部署成 REST 端点——或者部署成 MCP 工具，这才是值得注意的细节：你的检索管道由此可以被一个你在别处搭的智能体调用。Haystack 押的是"管道是原语，智能体是它的一种用法"。
- RAGFlow——一个可视化工作流搭建器。带持久记忆与工具调用的多步智能体，在界面里拼出来；另有一个让智能体自主浏览网页的浏览器组件，以及飞书、Discord、Telegram、Line 等聊天渠道集成。这是给那些不打算用 Python 写控制流的人做的智能体搭建，而它是四者中唯一认真瞄准这批受众的。
- R2R——一个藏在端点后面的研究型智能体。多步检索与综合，以一次 API 调用的形式暴露出来，并支持用户自定义工具以扩展这个智能体够得着的范围。这里智能体是检索服务的一项功能，而不是一套你去编程的框架。
把这份清单读作对"控制流住在哪里"的四种回答。在 LlamaIndex 里它住在你的 Python 里。在 Haystack 里它住在一份管道定义里。在 RAGFlow 里它住在一个 Web 应用中的一张图里。在 R2R 里它住在服务内部。这几种都可能是对的；而它们事后极难对调，因为控制流正是你积累得最多的那部分。
什么时候选哪一个
| 你的处境 | 选 LlamaIndex 或 Haystack，如果…… | 选 RAGFlow，如果…… | 选 R2R，如果…… |
|---|---|---|---|
| 在既有服务内部做检索 | 是——库就是为这个场景存在的 | 你是在加一套系统，不是加一个功能 | 只在你刻意想要那道 API 边界时 |
| 难啃的文档：扫描件、密集表格 | 给解析器留预算，开源或付费 | 默认最强，而且是自托管的 | 捆好的、够用；先测一遍 |
| 非开发者要来维护语料 | 那套界面得你自己造 | 随附一套；这是它最好的论据 | 独立应用，偏开发者形态 |
| 任何东西都不许出网 | Haystack：不捆任何服务依赖 | 是——最好的质量留在本地 | 可以，自托管 |
| 检索之外还要智能体编排 | 显然是 LlamaIndex Workflows | 只在可视化搭建器合你团队的胃口时 | 那个智能体是他们的，不是你的 |
| 你预计两年内要迁移 | Haystack——组件带得走 | 现在就把导出方案定下来，别等以后 | API 面让它变容易；数据不会 |
常见问题
模型都长上下文了，RAG 框架还值得引入吗？
值得，理由与上下文长度无关：检索是你落实权限与出处的方式。长上下文改变的是你能塞进去多少，而不改变"要能证明某个答案出自哪份文档"或"要把租户 A 的文件挡在租户 B 的提示词之外"的需要。见有效上下文与宣称上下文。
我能用服务形态的框架，同时保留自己的编排吗？
能，而且这往往是清醒的折中——调 RAGFlow 或 R2R 做检索，把智能体控制流留在自己的代码里。诚实地承认你这么做是在为它的摄取质量与它的界面，付一套第二系统的运维代价；只要这正是你打算做的那笔交换，它就站得住。
哪一个最快？
这个问题很少能在一次真实的 profile 之后活下来。进程内检索省掉了一跳网络，这在延迟预算很紧时要紧；除此之外，四者的延迟都由嵌入调用、向量库与生成主导，而这三样框架都不替你选。用你自己的语料去量，别信任何人的基准——包括这一页的框架。
MIT 与 Apache-2.0 的许可证差别在这里要紧吗？
对多数采用者来说不要紧——两者都是宽松许可证，也都被常规接受。Apache-2.0 含有明确的专利授予，有些法务团队更偏爱这一点；MIT 没有，而有些法务团队从来没提过一次。关于一个 RAG 项目真正值得问的许可证问题，不是 MIT 还是 Apache，而是究竟哪些能力在开源产物之中——也就是上面那个解析问题。
我该先评估什么？
摄取，在你自己最难啃的那些文档上，先于其他一切。检索质量、重排与提示词设计都还能事后补救；一个悄无声息毁掉了你表格的解析器，定下的是一个下游任何组件都抬不起来的天花板。
延伸阅读
本站：
- 面向 RAG 的文档解析——这整篇对比所转动的那一步。
- 进阶 RAG 架构——这些框架是它的实现。
- 选择向量数据库——压在四者之下的那个决定。
- 评估 RAG——怎样让一次选型试跑真的说明问题。
- 智能体式检索——认真对待之后，这个词到底指什么。