0.22 亮点介绍

构建一个 RAGFlow 数据集涉及三个主要步骤：文件上传、解析和分块。0.21.0 版本通过引入“摄入管道”（Ingestion pipeline）使解析和分块阶段变得更加灵活。

这次发布的 0.22.0 版本重点关注数据上传步骤，旨在帮助开发者更快地构建数据集。

我们还增加了以下关键改进

• “摄入管道”中的解析器（Parser）组件现在提供了更多模型选择，以实现更好的文件解析效果。
• 我们优化了智能体（Agent）的 检索（Retrieval） 和 等待响应（Await response） 组件。
• 全新的管理员界面（Admin UI）为您提供更清晰、更便捷的系统管理方式。

支持丰富的外部数据源

新增的“数据源”模块允许您将外部数据连接到数据集中。现在，您可以将来自不同位置的文件直接同步到 RAGFlow 中。

在您的个人中心使用“数据源”菜单，可以添加和设置 Confluence、AWS S3、Google Drive、Discord 和 Notion 等数据源。这让您能在一个地方管理所有数据，并实现自动同步。

示例：S3 配置

1. 请确保您的 AWS 账户中有一个 S3 存储桶。

2. 将您的 S3 详细信息添加到 S3 数据源表单中。

3. 添加后，点击设置图标查看数据源详情。

4. 如果您将“刷新频率（Refresh Freq）”设置为“1”，系统将每分钟检查一次新文件。
5. RAGFlow 会监控您指定的 S3 存储桶（例如 ragflow-bucket）。如果发现新文件，它会立即开始同步。
6. 同步完成后，系统会等待一分钟再进行下一次检查。您随时可以使用“暂停”按钮来开启或关闭此自动刷新功能。

将数据源关联至数据集

1. 创建一个新数据集（例如，TEST_S3）。
2. 点击 Configuration 并滚动到页面底部。
3. 点击 Link Data Source 并选择您想要的数据源（例如 S3）。

成功链接后，您将看到三个图标

• 重建（Rebuild）： 点击此按钮将删除数据集中的所有文件和日志，并重新导入所有内容。
• 设置（Settings）： 在这里查看同步日志。
• 取消链接（Unlink）： 这会断开数据源的连接。它会保留数据集中已有的所有文件，但停止新的同步。

日志中的状态消息

• 已计划（Scheduled）： 任务已进入队列，等待下一次检查文件。
• 运行中（Running）： 系统正在移动文件。
• 成功（Success）： 已完成新文件的检查。
• 失败（Failed）： 上传失败。请查看错误消息以获取详细信息。
• 取消（Cancel）： 您已暂停传输。

您可以将多个数据源链接到一个数据集中，一个数据源也可以为多个数据集提供数据。

增强型解析器

MinerU

RAGFlow 现在支持 MinerU 2.6.3 作为解析 PDF 的另一个选项。它支持多种后端，如 pipeline、vlm-transformers、vlm-vlm-engine 和 http-client。

原理很简单：RAGFlow 请求 MinerU 解析文件，读取结果，然后将它们添加到您的数据集中。

关键环境变量

启动

• 如果您使用 vlm-http-client 后端，请通过 MINERU_SERVER_URL 设置服务器地址。
• 要连接到远程的 MinerU 解析器，请使用 MINERU_APISERVER 提供其地址。

如何启动

1. 从源码启动： 单独安装 MinerU（其依赖项可能与 RAGFlow 的冲突）。然后设置环境变量并启动 RAGFlow 服务器。
2. 使用 Docker： 在 docker/.env 文件中设置 USE_MINERU=true 并重启您的容器。

Docling

RAGFlow 还支持 Docling 作为另一个 PDF 解析器。它的工作方式与 MinerU 相同。

Docling 会在文档中查找文本、公式、表格和图像。然后 RAGFlow 会使用 Docling 的发现。

Docling 的功能

1. 提取文本（段落、标题、列表）。
2. 提取数学公式。
3. 识别表格和图像（并保存它们）。
4. 标记所有内容的位置。

启动： 在 docker/.env 文件中设置 USE_DOCLING=true 并重启您的容器。

Agent 优化

检索现已支持元数据

您现在可以向数据集中的文件添加标签（元数据）。在检索过程中，智能体可以利用这些标签来筛选结果，从而只查看特定文件，而不是整个知识库。

示例： 假设有一个充满 AI 论文的数据集。其中一些是关于 AI 智能体的，另一些是关于 AI 评估的。如果您想要一个只回答评估问题的问答助手，可以为相关的论文添加一个标签，如 "Topic": "Evaluation"。当智能体检索信息时，它将筛选出带有该标签的文件。

以前，这只能在聊天应用中实现。现在，智能体的“检索”组件也可以做到这一点。

更出色的 Agent 协作能力

您现在可以在 等待响应（Await Response） 组件的消息中使用上游智能体的输出。

旧方式： “等待响应”组件中的消息总是静态文本。

新方式： 您可以插入工作流中较早步骤的动态内容，比如来自规划智能体的计划。

这对于“深度研究”智能体或任何需要人工在继续之前检查工作的场景都非常有用。它也是未来“摄入管道”改进的关键部分。

您可以在智能体模板库中找到这个用例，作为一个即用型模板。

管理后台 UI

该版本增加了一个全新的 管理员界面（Admin UI），这是一个为系统管理员设计的可视化仪表盘。

它将您过去需要通过命令完成的任务整合到一个简单的界面中，使管理变得更加容易。

即时查看系统状态

服务状态（Service Status） 仪表盘显示所有核心服务的健康状况。它列出了服务的名称、类型、主机、端口和状态。如果出现问题（例如 Elasticsearch 超时），您可以快速找到问题所在，并复制地址进行测试，而无需登录到不同的服务器。

该界面还显示服务详情。您可以看到详细的日志和连接信息（如数据库密码），而无需接触服务器命令行。这使得解决问题更快，并保持系统更透明、更安全。

轻松管理用户

用户管理（User Management） 部分允许您创建、启用、禁用、重置密码和删除用户。您可以按电子邮件或昵称快速查找用户，并查看他们拥有的数据集和智能体。

结语

RAGFlow 0.21.0 为您提供了强大的数据“摄入管道”。现在，RAGFlow 0.22.0 连接到您数据所在的所有地方。它们共同帮助您打破“数据孤岛”，将所有内容汇集一处，为您的 LLM 提供动力。

我们还改进了智能体与人的协作方式。现在您可以介入智能体的工作流程并指导它，以团队合作的方式获得比完全自动化更准确、更好的结果。

我们将继续添加更多的数据源、更好的解析器和更智能的管道，使 RAGFlow 成为您 LLM 应用的最佳数据基础。

GitHub: https://github.com/infiniflow/ragflow

参考

1. https://ragflow.com.cn/docs/faq#how-to-use-mineru-to-parse-pdf-documents

GitHub 2025年度Octoverse报告的发布，对开源生态系统而言是一个关键时刻，对于像RAGFlow这样的项目也是如此。今年，RAGFlow已成为贡献者增长最快的开源项目之一。凭借其在贡献者参与度上高达2596%的同比增长，RAGFlow不仅仅是获得了关注，更是在定义下一波由AI驱动的开发浪潮。

检索增强生成（RAG）在生产环境中的崛起

正如Octoverse报告所强调的，人工智能已不再是实验性的，而是基础性的。GitHub上现在有超过430万个与AI相关的代码仓库，并且有超过110万个公共仓库导入了LLM SDK，同比增长了178%。在这样的背景下，RAGFlow的迅速普及标志着一个明显的转变：开发者正在从原型验证阶段转向生产级的AI工作流。

RAGFlow——一个内置Agent功能的端到端检索增强生成引擎，完美地满足了这一需求。它使开发者能够构建可扩展、具备上下文感知能力的AI应用程序，这些应用既强大又实用。正如报告所指出的，“AI基础设施正成为吸引开源贡献的主要磁石”，而RAGFlow正好处在AI基础设施与实际可用性的交汇点上。

为什么 RAGFlow 在 AI 时代引发共鸣

Octoverse报告中强调的几个趋势与RAGFlow的设计和使命紧密相连

• 从Notebook到生产环境：报告指出，项目正从Jupyter Notebooks（同比增长75%）转向Python代码库，这表明AI项目正在走向成熟。RAGFlow通过提供一个结构化、可复现的框架来支持这一转变，用于在生产环境中部署RAG系统。
• Agent工作流正成为主流：随着GitHub Copilot编程Agent的推出和AI辅助开发的兴起，开发者越来越依赖能够自动化复杂任务的工具。RAGFlow内置的Agent功能允许团队自动化检索、推理和响应生成——这些都是现代AI应用的关键组成部分。
• 安全性和可扩展性是首要考虑：报告还强调了“失效的访问控制”漏洞同比增长了172%，凸显了设计安全的AI系统的必要性。RAGFlow专注于企业级部署，帮助团队直面这些挑战。

一个处于活跃开发中的项目

RAGFlow的演进反映了一段深思熟虑的历程——从解决基础的RAG挑战，到塑造下一代企业AI基础设施。

该项目最初通过集成技术创新，系统性地解决了核心RAG的局限性，从而崭露头角。凭借深度文档理解（用于解析复杂格式）、融合多种搜索策略的混合检索，以及内置的GraphRAG和RAPTOR等先进工具，RAGFlow将自己打造为一个端到端的解决方案，极大地提升了检索准确性和推理性能。

现在，基于这一坚实的技术基础，RAGFlow正朝着一个更大胆的愿景迈进：成为企业级Agent的卓越上下文引擎。从一个专业的RAG引擎演变为一个统一、有弹性的上下文层，RAGFlow正将自己定位为企业中大语言模型（LLM）的必要数据基础——使任何类型的Agent都能访问丰富、精确且安全的上下文，确保在所有任务中可靠且有效地运行。

RAGFlow 是一款开源的检索增强生成（RAG）引擎，旨在构建生产级 AI 应用。欲了解更多信息或参与贡献，请访问 RAGFlow GitHub 仓库。

本文灵感源自 GitHub Octoverse 2025 报告 的洞察。特别鸣谢 GitHub 团队，为全球各地的开源建设者发声。

自开源以来，RAGFlow 一直持续受到社区的广泛关注。其核心模块 DeepDoc 利用内置的文档解析模型，为多种业务场景提供了智能化的文档分片能力，确保 RAGFlow 在检索和生成阶段都能提供准确、高质量的回答。目前，RAGFlow 预集成了十余种文档分片模板，覆盖了各类业务场景和文件类型。

然而，随着 RAGFlow 在生产环境中的应用日益广泛，原有的十余种固定分片方式已难以满足所遇到的复杂多样的数据源、文档结构和文件类型。具体挑战包括：

• 需要根据特定业务场景，灵活配置不同的解析和分片策略，以适应多变的文档结构和内容逻辑。
• 文档解析和录入不仅涉及将非结构化数据分割成文本块，还包含一系列关键的预处理步骤，以弥合RAG检索过程中的“语义鸿沟”。这通常需要利用模型为原始内容丰富语义信息，如摘要、关键词和层次结构。
• 除了本地上传的文件，大量的数据、文件和知识源于各种渠道，包括云盘和在线服务。
• 随着多模态视觉语言模型（VLM）的成熟，涌现出像 MinerU 和 Docling 这样在解析复杂布局、表格和图文混排文档方面表现出色的模型。这些模型在不同应用场景中展现出独特的优势。

为应对这些挑战，RAGFlow 0.21.0 推出了开创性的 Ingestion Pipeline。该流水线重构了非结构化数据的清洗流程，允许用户根据特定业务需求构建定制化的数据处理流水线，并实现对异构文档的精准解析。

Ingestion Pipeline 本质上是一个为非结构化数据量身定制的可视化 ETL 流程。它基于 Agent 构建，将一个典型的 RAG 数据录入工作流——通常包含文档解析、文本分块、向量化和索引构建等关键阶段——重构为三个不同的阶段：Parser、Transformer 和 Indexer。这些阶段分别对应文档解析、数据转换和索引构建。

• 文档解析（Document Parsing）：作为数据清洗的关键步骤，该模块集成了多种解析模型，DeepDoc 是其中的代表。它将原始的非结构化数据转换为半结构化内容，为后续处理奠定基础。
• 数据转换（Data Transformation）：目前提供两类核心算子，包括 Chunker 和 Transformer。该阶段旨在将清洗后的数据进一步处理成适合各种索引访问方式的格式，从而确保高质量的召回性能。
• 索引构建（Index Construction）：负责最终的数据写入。RAGFlow 内在采用多路召回架构以保证检索效果。因此，Indexer 集成了多种索引方法，允许用户灵活配置。

下面，我们将通过一个具体示例来演示 Ingestion Pipeline 的构建和使用。

首先，在“Agent”页面点击“创建Agent”。您可以选择“从空白创建”来从头构建一个 Ingestion Pipeline。

或者，您也可以选择“从模板创建”，利用预配置的 Ingestion Pipeline 模板。

接下来，我们将开始编排流水线所需的各种算子。从零开始创建时，初始画布上仅显示 Begin 和 Parser 算子。随后，您可以从现有算子的右侧拖拽并连接具有不同功能的其他算子。

首先，需要配置 Parser 算子。

解析器 (Parser)

Parser 算子负责读取和解析文档：识别其布局、提取其结构和文本信息，并最终获得结构化的文档数据。

这是一种“高保真、结构化”的提取策略。Parser 能够智能地适应并保留不同文件的原始特征，无论是 Word 文档的层级大纲、电子表格的行列布局，还是扫描版 PDF 的复杂版式。它不仅提取正文，还完整保留标题、表格、页眉和页脚等辅助信息，并将它们转化为适当的数据形式，具体内容将在下文详述。这种结构化的区分至关重要，为后续的精细化处理提供了必要的基础。

目前，Parser 算子支持 8 大类共 23 种文件类型的输入，总结如下：

使用时，只需在 Parser 节点内点击“添加 Parser”并选择所需的文件类别（如 PDF、Image 或 PPT）。当 Ingestion Pipeline 运行时，Parser 节点会自动识别输入文件，并将其路由到相应的解析器进行解析。

在此，我们对几种常见文件类别的解析器作进一步说明：

• 对于 PDF 文件，RAGFlow 提供了多种解析模型选项，统一输出为 JSON 格式：

  1. 默认 DeepDoc：这是 RAGFlow 的内置文档理解模型，能够识别布局、分栏和表格。它适用于处理扫描文档或格式复杂的文档。
  2. MinerU：目前业界优秀的文档解析模型之一。除了解析复杂的文档内容和布局外，MinerU 还为数学公式等复杂文件元素提供了出色的解析能力。
  3. Naive：一种不使用任何模型的纯文本提取方法。它适用于没有复杂结构或非文本元素的文档。

• 对于 Image 文件，系统将默认调用 OCR 从图像中提取文本。此外，用户还可以配置支持视觉识别的 VLM（视觉语言模型）来处理它们。
• 对于 Audio 文件，需要配置一个支持语音转文本的模型。Parser 将从音频中提取文本内容。用户可以在首页的“模型提供商”页面配置支持此类解析的模型提供商的 API 密钥。之后，他们可以返回 Parser 节点并在下拉菜单中选择它。这种“先配置后选择”的逻辑也适用于 PDF、Image 和 Video 文件。
• 对于 Video 文件，需要配置一个支持多模态识别的大模型。Parser 将调用此模型对视频进行全面分析，并以文本格式输出结果。
• 在解析 Email 文件时，RAGFlow 提供了字段选项，允许用户仅选择所需字段，如“主题”和“正文”。Parser 将精确提取这些字段的文本内容。

• Spreadsheet 解析器会以 HTML 格式输出文件，完整保留其行列结构，确保表格数据在转换后依然清晰可读。
• Word 和 PPT 类型的文件将被解析并输出为 JSON 格式。对于 Word 文件，文档的原始层级结构，如标题、段落、列表、页眉和页脚，都将被保留。对于 PPT 文件，内容将逐页提取，区分每张幻灯片的标题、正文和备注。
• Text & Markup 类别会自动剥离 HTML 和 MD（Markdown）等文件的格式标签，只输出最纯净的文本内容。

分块器 (Chunker)

Chunker 节点负责将上游节点输出的文档分割成 Chunk 片段。Chunk 是 RAG 技术引入的一个概念，代表召回的单元。用户可以根据需要选择是否添加 Chunker 节点，但通常建议使用它，主要有两个原因：

1. 如果将整个文档作为召回单元，最终生成阶段传递给大模型的数据可能会超出上下文窗口限制。
2. 在典型的 RAG 系统中，向量搜索是一种重要的召回方法。然而，向量本身存在语义表示不准确的问题。例如，用户可以选择将单个句子转换为向量，或将整个文档转换为向量。前者丢失了全局语义信息，而后者丢失了局部信息。因此，选择一个合适的片段长度，使其在用单个向量表示时能达到较好的平衡，是一种必要的技术手段。

在实际工程系统中，Chunk 的切分结果往往显著影响 RAG 的召回质量。如果包含答案的内容被分割到不同的 Chunk 中，而检索阶段无法保证所有这些 Chunk 都被召回，就可能导致答案生成不准确和产生幻觉。因此，Ingestion Pipeline 引入了 Chunker 节点，允许用户更灵活地切分文本。

当前系统内置了两种切分方法：基于文本 token 和标题的切分。

按 token 切分是最常见的方法。用户可以自定义每个片段的大小，默认设置为 512 个 token，这是一个为检索效果和模型兼容性优化的平衡值。在设置片段大小时，必须考虑权衡：如果片段 token 数仍然过大，超出模型限制的部分仍会被丢弃；如果设置得太小，可能会导致原文中连贯的语义被过度分割，破坏上下文并影响检索效果。

为了解决这个问题，Chunker 算子提供了片段重叠功能，它允许前一个片段的末尾部分被复制为下一个片段的开头，从而增强语义连续性。用户可以增加“重叠百分比”来提高片段之间的关联性。

此外，用户可以通过定义“分隔符”来进一步优化切分规则。系统默认使用 \n（换行符）作为分隔符，这意味着切分器将优先尝试沿着自然段落进行分割，而不是在句子中间突然截断，如下图所示。

如果文档本身具有清晰的章节结构，按 token 切分文本可能不是最佳选择。在这种情况下，可以选择 Chunker 中的 Title 选项，根据文档的标题进行切分。这种方法主要适用于具有技术手册、学术论文和法律条款等布局的文档。我们可以在 Title 节点中为不同级别的标题自定义表达式。例如，一级标题（H1）的表达式可以设置为 ^#[^#]，二级标题（H2）的表达式可以设置为 ^##[^#]。基于这些表达式，系统将严格按照预定义的章节结构对文档进行切分，确保每个片段都代表一个结构完整的“章节”或“小节”。用户还可以在配置中自由添加或减少标题级别，以匹配文档的实际结构，如下图所示。

注意：在当前的 RAGFlow v0.21 版本中，如果同时配置了 Chunker 的 Token 和 Title 选项，请确保 Title 节点连接在 Token 节点之后。否则，如果 Title 节点直接连接到 Parser 节点，对于 Email、Image、Spreadsheet 和 Text&Markup 类型的文件可能会出现格式错误。这些限制将在后续版本中进行优化。

转换器 (Transformer)

Transformer 算子负责转换文本内容。仅仅解决文本解析和切分的准确性并不能保证最终的检索准确率。这是因为用户的查询与包含答案的文档之间总是存在所谓的“语义鸿沟”。通过使用 Transformer 算子，用户可以利用大模型从输入文档内容中提取信息，从而弥合“语义鸿沟”。

当前的 Transformer 算子支持摘要生成、关键词生成、问题生成和元数据生成等功能。用户可以选择将该算子加入其流水线，以这些内容补充原始数据，从而提升最终的检索准确率。与其他涉及大模型的场景类似，Transformer 节点也为大模型提供了三种模式：即兴（Improvise）、精确（Precise）和平衡（Balance）。

• 即兴模式（Improvise）鼓励模型展现更大的创造力和联想思维，非常适合生成多样化的问题。
• 精确模式（Precise）严格约束模型，确保其输出高度忠实于原文，适合生成摘要或提取关键词。
• 平衡模式（Balance）在两者之间取得平衡，适用于大多数场景。

用户可以选择这三种风格之一，或者通过自行调整 Temperature 和 Top P 等参数来实现更精细的控制。

Transformer 节点可以生成四种类型的内容：摘要（Summary）、关键词（Keywords）、问题（Questions）和元数据（Metadata）。RAGFlow 还将每种内容的提示词（prompt）公开，这意味着用户可以通过修改系统提示词来丰富和个性化文本处理。

如果需要实现多种功能，例如同时总结内容和提取关键词，用户需要为每个功能配置一个独立的 Transformer 节点，并在流水线中将它们串联起来。换句话说，一个 Transformer 节点可以紧接在 Parser 之后，处理整个文档（例如，生成全文摘要），也可以连接在 Chunker 之后，处理每个文本片段（例如，为每个 Chunk 生成问题）。此外，一个 Transformer 节点可以连接在另一个 Transformer 节点之后，以级联方式执行复杂的内容提取和生成。

请注意：Transformer 节点不会自动从其前置节点获取内容。它实际处理的信息来源完全取决于用户提示词（User prompt）中引用的变量。在用户提示词中，必须通过输入 / 符号来手动选择和引用上游节点输出的变量。

例如，在一个 Parser - Chunker - Transformer 的流水线中，尽管 Transformer 在视觉上连接在 Chunker 之后，但如果用户提示词中引用的变量是来自 Parser 节点的输出，那么 Transformer 实际上将处理整个原始文档，而不是 Chunker 生成的块。

同样，当用户选择串联多个 Transformer 节点时（例如，第一个生成摘要，第二个生成关键词），如果第二个 Transformer 引用了第一个 Transformer 生成的摘要变量，它将处理这个摘要作为“新的原文”进行进一步处理，而不是处理更上游 Chunker 的文本块。

索引器 (Indexer)

前面的 Parser、Chunker 和 Transformer 节点处理了数据流入、切分和优化。然而，流水线中最终的执行单元是 Indexer 节点，它负责将处理后的数据写入检索引擎（RAGFlow 目前支持 Infinity、Elasticsearch 和 OpenSearch）。

检索引擎的核心能力是为数据建立各种类型的索引，从而提供搜索能力，包括向量索引、全文索引以及未来的张量索引能力等。换句话说，它是 RAG 这个术语中“检索”（Retrieval）的最终体现。

由于不同类型索引的能力各不相同，Indexer 同时提供了创建不同索引的选项。具体来说，Indexer 节点内的“搜索方法”（Search method）选项决定了用户数据如何被“找到”。

全文（Full-text）指的是传统的“关键词搜索”，这是精确召回的必要选项，例如搜索特定的产品编号、人名或代码。而嵌入（Embedding）则代表了现代由人工智能驱动的“语义搜索”。用户可以用自然语言提问，系统可以“理解”问题的含义并检索内容上最相关的文档块。同时启用两者进行混合搜索是 RAGFlow 的默认选项。有效的多渠道召回可以平衡精确度和语义，最大限度地发现答案所在的文本片段。

注意：在 Indexer 节点内无需选择特定的嵌入模型，因为它会自动调用创建知识库时设置的嵌入模型。此外，RAGFlow 中的聊天（Chat）、搜索（Search）和 Agent 功能支持跨知识库检索，这意味着一个问题可以同时在多个知识库中进行搜索。但是，要启用此功能，必须满足一个先决条件：所有同时选择的知识库必须使用相同的嵌入模型。这是因为不同的嵌入模型会将相同的文本转换为完全不同且不兼容的向量，从而无法进行跨库检索。

此外，通过“文件名嵌入权重”（Filename embedding weight）和“字段”（Field）选项可以实现更精细的检索设置。文件名嵌入权重是一个微调滑块，允许用户将文档的“文件名”视为语义信息的一部分，并为其分配特定权重。

而“字段”选项则决定了要索引的具体内容和检索策略。目前提供了三种不同的策略选项：

• 处理后的文本（Processed Text）：这是默认选项，也是最直观的。它意味着 Indexer 将对来自前置节点的处理后的文本块进行索引。
• 问题（Questions）：如果在 Indexer 之前使用了 Transformer 节点来生成“每个文本块可以回答的潜在问题”，那么这些问题可以在这里被索引。在许多场景中，匹配“用户问题”与“预生成的问题”比匹配“问题”与“答案”（即原文）产生的相似度要高得多，从而有效提高检索准确率。
• 增强上下文（Augmented Context）：这涉及使用摘要（Summaries）代替原文进行检索。它适用于需要快速进行广泛主题匹配而不想被原文细节干扰的场景。

将 Ingestion Pipeline 关联到知识库

构建好 Ingestion Pipeline 后，下一步是将其与相应的知识库关联起来。在创建知识库的页面，找到并点击“Ingestion pipeline”选项卡下的“选择流水线”选项。随后，从下拉菜单中选择已创建的 Pipeline 以建立关联。一旦设置，此 Pipeline 将成为该知识库的默认文件解析流程。

对于一个已经创建的知识库，用户可以随时进入其“Ingestion pipeline”模块，重新调整和选择关联的解析流程。

如果用户希望为单个文件调整 Ingestion pipeline，也可以通过点击“解析位置”来进行调整。

最后，在弹出的窗口中进行调整并保存更新。

日志 (Logs)

Ingestion Pipeline 的执行可能需要相当长的时间，因此可观测性是不可或缺的能力。为此，RAGFlow 为 Ingestion Pipeline 提供了日志面板，记录了每个文件解析操作的全链路日志。对于通过 Ingestion Pipeline 解析的文件，用户可以深入了解每个处理节点的操作细节。这为后续的问题审计、流程调试和性能洞察提供了全面的数据支持。

下图是一个步骤日志的示例图。

案例参考

创建 Pipeline 时，您可以选择“Chunk Summary”模板作为构建的基础，当然您也可以选择其他模板作为后续构建的起点。

“Chunk Summary”模板的编排设计如下：

接下来，将 Transformer 节点中的大模型切换为您希望使用的模型，并将“结果目标”字段设置为“元数据”。此配置意味着大模型对文本块的处理结果（如摘要）将直接存储在文件的元数据中，为后续的精确检索和过滤提供能力支持。

点击右上角的“运行”并上传文件以测试流水线。

您可以点击“查看结果”来检查测试运行的结果。

总结

以上内容全面介绍了当前 Ingestion Pipeline 的使用方法和核心能力。展望未来，RAGFlow 将在数据导入和解析的清晰度方面持续演进，包括以下具体增强：

1. 扩展数据源支持：除了本地文件上传，我们将逐步集成各种数据源，如 S3、云存储、电子邮件、在线笔记等。通过自动和手动同步机制，我们将实现数据无缝导入知识库，并自动应用 Ingestion Pipeline 完成文档解析。
2. 增强解析能力：我们将在 Parser 算子中集成更多文档解析模型，如 Docling，以覆盖不同垂直领域的解析需求，全面提升文档信息提取的质量和准确性。
3. 开放自定义切片功能：除了内置的 Chunker 类型，我们将逐步开放底层的切片能力，允许用户编写自定义切片逻辑，实现更灵活可控的文本组织。
4. 加强语义增强的扩展性：在现有总结、关键词提取和问题生成能力的基础上，我们将以可编程的方式进一步支持可定制的语义增强策略，为用户提供更多优化检索和排序的技术手段。

通过这些增强，RAGFlow 将不断提升检索准确率，为向大模型提供高质量上下文提供坚实支持。

最后，感谢您的关注与支持。欢迎您在 GitHub 上为 RAGFlow 点亮星星，与我们共同见证大模型技术的持续演进！

GitHub: https://github.com/infiniflow/ragflow

为了满足系统运维监控以及用户账户管理的精细化需求，特别是针对 RAGFlow 用户目前面临的“用户无法自行找回遗失密码”、“账户状态难以有效管控”等实际问题，RAGFlow 正式推出了一款专业的后端管理命令行工具。

该工具基于清晰的客户端-服务器架构，通过采用功能分离的设计理念，构建了一个高效、可靠的系统管理通道，使管理员能够在底层实现系统恢复和权限控制。

具体的架构设计如下图所示

通过此工具，RAGFlow 用户可以一站式地了解 RAGFlow Server 以及 MySQL、Elasticsearch、Redis、MinIO 和 Infinity 等组件的运行状态。它还支持全面的用户生命周期管理，包括账户创建、状态控制、密码重置和数据清理。

启动服务

如果您通过 Docker 部署 RAGFlow，请修改 docker/docker_compose.yml 文件，在服务启动命令中添加参数。

command:
  - --enable-adminserver

如果您从源代码部署 RAGFlow，可以直接执行以下命令来启动管理服务器

python3 admin/server/admin_server.py

服务器启动后，默认监听 9381 端口，等待客户端连接。如果您需要使用其他端口，请修改 docker/.env 文件中的 ADMIN_SVR_HTTP_PORT 配置项。

安装客户端并连接至管理服务

建议使用 pip 安装指定版本的客户端

pip install ragflow-cli==0.21.0

0.21.0 版本是当前的最新版本。请确保 ragflow-cli 的版本与 RAGFlow 服务器的版本相匹配，以避免兼容性问题。

ragflow-cli -h 127.0.0.1 -p 9381

这里，-h 指定服务器IP，-p 指定服务器端口。如果服务器部署在不同的地址或端口，请相应地调整参数。

首次登录时，输入默认的管理员密码 admin。成功登录后，建议及时在命令行工具中更改默认密码以增强安全性。

命令使用指南

通过客户端输入以下命令，您可以方便地管理用户并监控服务的运行状态。

交互功能说明

• 支持使用方向键移动光标和查看历史命令。
• 按 Ctrl+C 可以随时终止当前的交互。
• 如果您需要复制内容，请避免使用 Ctrl+C 以防意外中断进程。

命令格式规范

• 所有命令不区分大小写，且必须以分号 ; 结尾。
• 用户名和密码等文本参数需要用单引号 ' 或双引号 " 括起来。
• 密码中禁止使用 \、' 和 " 等特殊字符。

服务管理命令

LIST SERVICES;

• 列出 RAGFlow 后端服务及所有关联中间件的运行状态。

使用示例

admin> list services;
Listing all services
+-------------------------------------------------------------------------------------------+-----------+----+---------------+-------+----------------+---------+
| extra                                                                                     | host      | id | name          | port  | service_type   | status  |
+-------------------------------------------------------------------------------------------+-----------+----+---------------+-------+----------------+---------+
| {}                                                                                        | 0.0.0.0   | 0  | ragflow_0     | 9380  | ragflow_server | Timeout |
| {'meta_type': 'mysql', 'password': 'infini_rag_flow', 'username': 'root'}                 | localhost | 1  | mysql         | 5455  | meta_data      | Alive   |
| {'password': 'infini_rag_flow', 'store_type': 'minio', 'user': 'rag_flow'}                | localhost | 2  | minio         | 9000  | file_store     | Alive   |
| {'password': 'infini_rag_flow', 'retrieval_type': 'elasticsearch', 'username': 'elastic'} | localhost | 3  | elasticsearch | 1200  | retrieval      | Alive   |
| {'db_name': 'default_db', 'retrieval_type': 'infinity'}                                   | localhost | 4  | infinity      | 23817 | retrieval      | Timeout |
| {'database': 1, 'mq_type': 'redis', 'password': 'infini_rag_flow'}                        | localhost | 5  | redis         | 6379  | message_queue  | Alive   |
+-------------------------------------------------------------------------------------------+-----------+----+---------------+-------+----------------+---------+

列出 RAGFlow 后端服务及所有关联中间件的运行状态。

SHOW SERVICE <id>;

• 查询指定服务的详细运行状态。
• <id>: 执行命令 LIST SERVICES; 后显示结果中的服务标识符 ID。

使用示例

1. 查询 RAGFlow 后端服务

admin> show service 0;
Showing service: 0
Service ragflow_0 is alive. Detail:
Confirm elapsed: 4.1 ms.

响应表明 RAGFlow 后端服务在线，响应时间为 4.1 毫秒。

2. 查询 MySQL 服务

admin> show service 1;
Showing service: 1
Service mysql is alive. Detail:
+---------+----------+------------------+------+------------------+------------------------+-------+-----------------+
| command | db       | host             | id   | info             | state                  | time  | user            |
+---------+----------+------------------+------+------------------+------------------------+-------+-----------------+
| Daemon  | None     | localhost        | 5    | None             | Waiting on empty queue | 86356 | event_scheduler |
| Sleep   | rag_flow | 172.18.0.6:56788 | 8790 | None             |                        | 2     | root            |
| Sleep   | rag_flow | 172.18.0.6:53482 | 8791 | None             |                        | 73    | root            |
| Query   | rag_flow | 172.18.0.6:56794 | 8795 | SHOW PROCESSLIST | init                   | 0     | root            |
+---------+----------+------------------+------+------------------+------------------------+-------+-----------------+

响应表明 MySQL 服务在线，当前的连接和执行状态如上表所示。

3. 查询 MinIO 服务

admin> show service 2;
Showing service: 2
Service minio is alive. Detail:
Confirm elapsed: 2.3 ms.

响应表明 MinIO 服务在线，响应时间为 2.3 毫秒。

4. 查询 Elasticsearch 服务

admin> show service 3;
Showing service: 3
Service elasticsearch is alive. Detail:
+----------------+------+--------------+---------+----------------+--------------+---------------+--------------+------------------------------+----------------------------+-----------------+-------+---------------+---------+-------------+---------------------+--------+------------+--------------------+
| cluster_name   | docs | docs_deleted | indices | indices_shards | jvm_heap_max | jvm_heap_used | jvm_versions | mappings_deduplicated_fields | mappings_deduplicated_size | mappings_fields | nodes | nodes_version | os_mem  | os_mem_used | os_mem_used_percent | status | store_size | total_dataset_size |
+----------------+------+--------------+---------+----------------+--------------+---------------+--------------+------------------------------+----------------------------+-----------------+-------+---------------+---------+-------------+---------------------+--------+------------+--------------------+
| docker-cluster | 8    | 0            | 1       | 2              | 3.76 GB      | 2.15 GB       | 21.0.1+12-29 | 17                           | 757 B                      | 17              | 1     | ['8.11.3']    | 7.52 GB | 2.30 GB     | 31                  | green  | 226 KB     | 226 KB             |
+----------------+------+--------------+---------+----------------+--------------+---------------+--------------+------------------------------+----------------------------+-----------------+-------+---------------+---------+-------------+---------------------+--------+------------+--------------------+

响应表明 Elasticsearch 集群运行正常，具体指标包括文档数、索引状态、内存使用情况等。

5. 查询 Infinity 服务

admin> show service 4;
Showing service: 4
Fail to show service, code: 500, message: Infinity is not in use.

响应表明 Infinity 当前未被 RAGFlow 系统使用。

admin> show service 4;
Showing service: 4
Service infinity is alive. Detail:
+-------+--------+----------+
| error | status | type     |
+-------+--------+----------+
|       | green  | infinity |
+-------+--------+----------+

启用 Infinity 并再次查询后，响应表明 Infinity 服务在线且状态良好。

6. 查询 Redis 服务

admin> show service 5;
Showing service: 5
Service redis is alive. Detail:
+-----------------+-------------------+---------------------------+-------------------------+---------------+-------------+--------------------------+---------------------+-------------+
| blocked_clients | connected_clients | instantaneous_ops_per_sec | mem_fragmentation_ratio | redis_version | server_mode | total_commands_processed | total_system_memory | used_memory |
+-----------------+-------------------+---------------------------+-------------------------+---------------+-------------+--------------------------+---------------------+-------------+
| 0               | 3                 | 10                        | 3.03                    | 7.2.4         | standalone  | 404098                   | 30.84G              | 1.29M       |
+-----------------+-------------------+---------------------------+-------------------------+---------------+-------------+--------------------------+---------------------+-------------+

响应表明 Redis 服务在线，版本号、部署模式和资源使用情况如上表所示。

用户管理命令

LIST USERS;

• 列出 RAGFlow 系统中的所有用户。

使用示例

admin> list users;
Listing all users
+-------------------------------+----------------------+-----------+----------+
| create_date                   | email                | is_active | nickname |
+-------------------------------+----------------------+-----------+----------+
| Mon, 13 Oct 2025 15:58:42 GMT | admin@ragflow.io     | 1         | admin    |
| Mon, 13 Oct 2025 15:54:34 GMT | lynn_inf@hotmail.com | 1         | Lynn     |
+-------------------------------+----------------------+-----------+----------+

响应表明系统中当前有两名用户，状态均为启用。

其中，admin@ragflow.io 是管理员账号，在系统初始启动时自动创建。

SHOW USER <username>;

• 通过邮箱查询用户详细信息。
• <username>: 用户的邮箱地址，必须用单引号 ' 或双引号 " 括起来。

使用示例

1. 查询管理员用户

admin> show user "admin@ragflow.io";
Showing user: admin@ragflow.io
+-------------------------------+------------------+-----------+--------------+------------------+--------------+----------+-----------------+---------------+--------+-------------------------------+
| create_date                   | email            | is_active | is_anonymous | is_authenticated | is_superuser | language | last_login_time | login_channel | status | update_date                   |
+-------------------------------+------------------+-----------+--------------+------------------+--------------+----------+-----------------+---------------+--------+-------------------------------+
| Mon, 13 Oct 2025 15:58:42 GMT | admin@ragflow.io | 1         | 0            | 1                | True         | English  | None            | None          | 1      | Mon, 13 Oct 2025 15:58:42 GMT |
+-------------------------------+------------------+-----------+--------------+------------------+--------------+----------+-----------------+---------------+--------+-------------------------------+

响应结果显示 admin@ragflow.io 是超级管理员，且当前状态为已启用 (enabled)。

2. 查询普通用户

admin> show user "lynn_inf@hotmail.com";
Showing user: lynn_inf@hotmail.com
+-------------------------------+----------------------+-----------+--------------+------------------+--------------+----------+-------------------------------+---------------+--------+-------------------------------+
| create_date                   | email                | is_active | is_anonymous | is_authenticated | is_superuser | language | last_login_time               | login_channel | status | update_date                   |
+-------------------------------+----------------------+-----------+--------------+------------------+--------------+----------+-------------------------------+---------------+--------+-------------------------------+
| Mon, 13 Oct 2025 15:54:34 GMT | lynn_inf@hotmail.com | 1         | 0            | 1                | False        | English  | Mon, 13 Oct 2025 15:54:33 GMT | password      | 1      | Mon, 13 Oct 2025 17:24:09 GMT |
+-------------------------------+----------------------+-----------+--------------+------------------+--------------+----------+-------------------------------+---------------+--------+-------------------------------+

响应结果显示 lynn_inf@hotmail.com 是一个通过密码登录的普通用户，最后登录时间显示为提供的时间戳。

CREATE USER <username> <password>;

• 创建一个新用户。
• <username>: 用户的邮箱地址，必须符合标准的邮箱格式规范。
• <password>: 用户的密码，不得包含 \、' 或 " 等特殊字符。

使用示例

admin> create user "example@ragflow.io" "psw";
Create user: example@ragflow.io, password: psw, role: user
+----------------------------------+--------------------+----------------------------------+--------------+---------------+----------+
| access_token                     | email              | id                               | is_superuser | login_channel | nickname |
+----------------------------------+--------------------+----------------------------------+--------------+---------------+----------+
| be74d786a9b911f0a726d68c95a0776b | example@ragflow.io | be74d6b4a9b911f0a726d68c95a0776b | False        | password      |          |
+----------------------------------+--------------------+----------------------------------+--------------+---------------+----------+

已成功创建一个普通用户。昵称和头像等个人信息可由用户在登录后访问个人资料页面自行设置。

ALTER USER PASSWORD <username> <new_password>;

• 更改用户密码。
• <username>: 用户邮箱地址
• <password>: 新密码（不得与旧密码相同，且不得包含特殊字符）

使用示例

admin> alter user password "example@ragflow.io" "psw";
Alter user: example@ragflow.io, password: psw
Same password, no need to update!

当新密码与旧密码相同时，系统提示无需更改。

admin> alter user password "example@ragflow.io" "new psw";
Alter user: example@ragflow.io, password: new psw
Password updated successfully!

密码已成功更新。此后用户可以使用新密码登录。

ALTER USER ACTIVE <username> <on/off>;

• 启用或禁用用户。
• <username>: 用户邮箱地址
• <on/off>: 启用或禁用状态

使用示例

admin> alter user active "example@ragflow.io" off;
Alter user example@ragflow.io activate status, turn off.
Turn off user activate status successfully!

用户已成功禁用。只有处于禁用状态的用户才能被删除。

DROP USER <username>;

• 删除用户及其所有关联数据
• <username>: 用户邮箱地址

重要提示

• 只有已禁用的用户才能被删除。
• 在继续操作之前，请确保所有需要保留的必要数据（如知识库和文件）已转移给其他用户。
• 此操作将永久删除以下用户数据

用户创建的所有知识库、上传的文件、配置的智能体，以及用户在他人知识库中上传的文件都将被永久删除。此操作不可逆，请极其谨慎操作。

• 删除命令具有幂等性。如果在删除过程中系统发生故障或操作中断，可以在排除故障后重新执行该命令以继续删除剩余数据。

使用示例

1. 用户成功删除

admin> drop user "example@ragflow.io";
Drop user: example@ragflow.io
Successfully deleted user. Details:
Start to delete owned tenant.
- Deleted 2 tenant-LLM records.
- Deleted 0 langfuse records.
- Deleted 1 tenant.
- Deleted 1 user-tenant records.
- Deleted 1 user.
Delete done!

响应表明用户已成功删除，并列出了数据清理的详细步骤。

2. 删除超级管理员（禁止操作）

admin> drop user "admin@ragflow.io";
Drop user: admin@ragflow.io
Fail to drop user, code: -1, message: Can't delete the super user.

响应表明删除失败。超级管理员账户受到保护，即使处于禁用状态也无法删除。

数据与 Agent 管理命令

LIST DATASETS OF <username>;

• 列出指定用户的所有知识库
• <username>: 用户邮箱地址

使用示例

admin> list datasets of "lynn_inf@hotmail.com";
Listing all datasets of user: lynn_inf@hotmail.com
+-----------+-------------------------------+---------+----------+-----------------+------------+--------+-----------+-------------------------------+
| chunk_num | create_date                   | doc_num | language | name            | permission | status | token_num | update_date                   |
+-----------+-------------------------------+---------+----------+-----------------+------------+--------+-----------+-------------------------------+
| 8         | Mon, 13 Oct 2025 15:56:43 GMT | 1       | English  | primary_dataset | me         | 1      | 3296      | Mon, 13 Oct 2025 15:57:54 GMT |
+-----------+-------------------------------+---------+----------+-----------------+------------+--------+-----------+-------------------------------+

响应显示该用户有一个私有知识库，文档和分段数量等详细信息如上表所示。

LIST AGENTS OF <username>;

• 列出指定用户的所有智能体
• <username>: 用户邮箱地址

使用示例

admin> list agents of "lynn_inf@hotmail.com";
Listing all agents of user: lynn_inf@hotmail.com
+-----------------+-------------+------------+----------------+
| canvas_category | canvas_type | permission | title          |
+-----------------+-------------+------------+----------------+
| agent_canvas    | None        | me         | finance_helper |
+-----------------+-------------+------------+----------------+

响应表明该用户有一个私有智能体，详细信息如上表所示。

其他命令

• ? 或 \help

显示帮助信息。

• \q 或 \quit

后续计划

我们始终致力于提升系统管理体验和整体安全性。在现有强大功能的基础上，RAGFlow 后端管理工具将持续演进。除了当前高效灵活的命令行界面外，我们即将推出专业的系统管理 UI，使管理员能够在一个更安全、更直观的图形化环境中执行所有运维任务。

为了加强权限控制，当前在普通用户界面中可见的系统状态信息将被撤销。未来专业的管理 UI 上线后，系统核心运行状态的访问权限将仅限于管理员。这将有效解决当前权限暴露过多的问题，进一步加固系统的安全边界。

此外，我们还将陆续推出更多精细化的管理功能，包括

• 对数据集和智能体的精细化控制
• 用户团队协作管理机制
• 增强的系统监控和审计能力

这些改进将建立一个更全面的企业级管理生态系统，为管理员提供更全方位、更便捷的系统控制体验。

RAGFlow 0.21.0 正式发布

此版本将重心从增强在线 Agent 能力转向夯实数据基础，从根本上优先提升易用性和对话质量。0.21.0 版本直接解决了 RAG 的常见痛点——从数据准备到长文档理解，带来了关键升级：一个灵活、可编排的注入管道（Ingestion Pipeline）、用于弥合复杂文件中语义鸿沟的长文本 RAG，以及一个用于简化运维的新版管理后台命令行工具。总而言之，这些元素构成了 RAGFlow 全新的数据管道核心，为构建稳健高效的 RAG 应用提供了更坚实的基础。

可编排的解析流水线

如果说早期的 Agent 主要解决在线数据的编排问题——正如我们在 Workflow 和 Agentic Workflow 中所见——那么注入管道则通过将相同的技术架构应用于编排离线数据注入，体现了这一能力。它的引入使用户能够在一个统一的框架内构建高度定制化的 RAG 数据管道。这不仅简化了定制开发，也更充分地体现了 RAGFlow 中的“Flow”。

一个典型的 RAG 注入过程涉及文档解析、文本分块、向量化和索引构建等关键阶段。当 RAGFlow 于 2024 年 4 月首次发布时，它已经集成了一套先进的工具链，包括基于 DeepDoc 的解析引擎和模板化的分块机制。这些顶尖的解决方案是其早期被广泛采用的基础。

然而，随着行业的快速发展和实践应用的深入，我们观察到了新的趋势和需求：

• 视觉语言模型（VLM）的崛起：日益成熟的 VLM 推动了一波微调文档解析模型的发展。这些模型为具有复杂布局或图文混排的非结构化文档提供了显著提高的准确性。
• 对灵活分块的需求：用户现在寻求更定制化的分块策略。面对多样化的知识库场景，RAGFlow 原有的内置分块模板已证明不足以覆盖所有特定情况，这可能会影响最终问答结果的准确性。

为此，RAGFlow 0.21.0 正式引入了注入管道，其核心能力包括：

• 可编排的数据注入：基于底层的 Agent 框架，用户可以创建多样化的数据注入管道。每个管道可以应用不同的策略来连接数据源与最终的索引，将先前内置的数据写入过程转变为用户可定制的工作流。这提供了更灵活、更符合特定业务逻辑的注入方式。
• 上传与清洗解耦：该架构将数据上传与清洗分离，为未来的批量数据源建立了标准接口，并为扩展数据预处理工作流奠定了坚实的基础。
• 重构的解析器：解析器（Parser）组件经过重新设计，以实现可扩展性，为集成 DeepDoc 之外的先进文档解析模型奠定了基础。
• 可定制的分块接口：通过解耦分块步骤，用户可以接入自定义的分块器，以更好地适应不同知识结构的切分需求。
• 优化复杂 RAG 的效率：对 IO/计算密集型任务（如 GraphRAG 和 RAPTOR）的执行进行了彻底改革。在管道化之前的架构中，处理每个新文档都会触发一个完整的计算周期，导致性能缓慢。新的管道支持批量执行，显著提高了数据吞吐量和整体效率。

如果说 ETL/ELT 代表了现代数据栈中处理结构化数据的标准管道——dbt 和 Fivetran 等工具为数据仓库和数据湖提供了统一灵活的数据集成解决方案——那么 RAGFlow 的注入管道则定位为非结构化数据的等效基础设施。下图展示了这一架构类比：

具体来说，ETL/ELT 中的提取（Extract）阶段负责从各种来源拉取数据，而 RAGFlow 注入管道则通过一个专门的解析（Parsing）阶段来增强这一过程，以从非结构化数据中提取信息。该阶段集成了多种解析模型，以 DeepDoc 为首，将多模态文档（例如，文本和图像）转换为适合处理的单模态表示。

在转换（Transform）阶段，传统的 ETL/ELT 侧重于数据清洗和业务逻辑，而 RAGFlow 则构建了一系列以 LLM 为中心的 Agent 组件。这些组件经过优化，以解决检索中的语义鸿沟，其核心使命可以概括为：提升召回率和排序准确性。

在数据加载（Load）方面，ETL/ELT 将结果写入数据仓库或数据湖，而 RAGFlow 使用索引器（Indexer）组件将处理过的内容构建成一种为检索优化的索引格式。这反映了 RAG 引擎的混合检索架构，该架构必须支持全文、向量以及未来的张量检索，以确保最佳的召回率。

因此，现代数据栈服务于结构化数据的商业分析，而带有注入管道的 RAG 引擎则专注于非结构化数据的智能检索——为 LLM 提供高质量的上下文。两者在各自的领域中占据着等效的生态位。

关于处理结构化数据，这并非 RAG 引擎的核心职责。它由构建在引擎之上的上下文层（Context Layer）处理。该层利用 MCP（模型上下文协议）——被称为“AI 时代的 TCP/IP”——以及配套的上下文工程（Context Engineering）来自动填充所有类型的上下文。这是 RAGFlow 下一开发阶段的重点关注领域。

以下是 v0.21.0 中注入管道的初步展示；更详细的指南将随后发布。我们将用于解析、分块和其他非结构化数据处理任务的组件引入了 Agent 画布，使用户能够自由地编排其解析工作流。

编排一个注入管道可以自动化解析文件并按长度分块的过程。然后，它利用大语言模型生成摘要、关键词、问题甚至元数据。以前，这些元数据必须手动输入。现在，一次配置即可大幅减少维护开销。

此外，管道过程是完全可观测的，会记录并显示每个文件的完整处理日志。

0.21.0 版本中注入管道的实现是基础性的一步。在下一个版本中，我们计划通过以下方式显著增强它：

• 增加对更多数据源的支持。
• 提供更广泛的解析器选择。
• 引入更灵活的转换器（Transformer）组件，以促进编排更丰富的语义增强模板。

长文本 RAG

进入 2025 年，检索增强生成（RAG）面临着由两个主要因素驱动的显著挑战。

传统 RAG 的根本局限性

传统的 RAG 架构通常无法保证强大的对话性能，因为它们依赖于以文本块为主要单位的检索机制。这使得它们对分块质量高度敏感，并且可能因上下文不足而导致结果质量下降。例如：

• 如果一个连贯的语义单元被分割到不同的块中，检索可能会不完整。
• 如果一个块缺乏全局上下文，呈现给 LLM 的信息就会被削弱。

虽然自动检测章节标题并将其附加到块中等策略有助于提供全局语义，但它们受到标题识别准确性和标题自身完整性的限制。

先进预处理技术的成本效益问题

现代预处理方法——GraphRAG、RAPTOR 和上下文检索——旨在向原始数据中注入额外的语义信息，以提高复杂查询的搜索命中率和准确性。然而，它们都存在成本高和效果不可预测的问题。

• GraphRAG：这种方法消耗的 token 数量通常是原始文本的数倍，并且自动生成的知识图谱常常不尽人意。其在复杂多跳推理中的有效性受到不可控推理路径的限制。作为原始块之外的补充检索，知识图谱也丢失了源文件中的一些细粒度上下文。
• RAPTOR：该技术产生的聚类摘要作为独立的块被召回，但自然缺乏源文本的细节，重新引入了上下文不足的问题。

上下文检索：此方法通过关键词或潜在问题等额外语义来丰富原始块。它存在一个明确的权衡：

• 更有效的选项是每个块多次查询 LLM，同时使用全文和当前块作为上下文，这能提升性能，但会将 token 成本推高至原始文本的数倍。
• 更便宜的选项仅基于当前块生成语义信息，节省了成本，但提供的全局上下文有限，性能提升也有限。过去几年，出现了新的 RAG 方案。
• 完全放弃检索：一些方法让 LLM 直接读取文档，根据上下文窗口将其分割成块，并执行多阶段搜索。首先，LLM 决定哪个全局文档是相关的，然后是哪些块，最后加载这些块来回答问题。虽然这避免了召回不准确的问题，但它损害了响应延迟、并发性和大规模数据处理能力，使得实际部署变得困难。
• 放弃嵌入或索引，转而使用 grep 等工具：这将 RAG 演变为 Agentic RAG。随着应用程序变得越来越复杂，用户查询也日益多样化，将 RAG 与 Agent 结合变得越来越不可避免，因为只有 LLM 才能将原始查询转换为结构化的检索命令。在 RAGFlow 中，这一能力早已实现。放弃索引而使用 grep 是在个人或小规模场景下为了简化 Agent 开发而做出的妥协；在企业环境中，一个强大的检索引擎仍然至关重要。
• 长文本 RAG：作为 0.21.0 版本引入的功能，与 GraphRAG、RAPTOR 和上下文检索同属一类，该方法使用 LLM 来丰富原始文本的语义以提高召回率，同时保留索引和搜索。检索仍然是核心。长文本 RAG 模仿了人们查阅信息的方式：通过目录确定相关章节，然后找到确切的页面获取详细信息。在索引期间，LLM 提取章节信息并将其附加到每个块中，以提供全局上下文；在检索期间，它找到匹配的块，并利用目录结构来填补因分块造成的语义碎片化带来的空白。
• 当前体验与未来方向：用户可以通过“TOC 提取”（目录）功能尝试长文本 RAG，尽管它目前处于测试阶段。下一个版本将添加一个注入管道。改进 RAG 的一个关键路径是在不完全摒弃检索的情况下，使用 LLM 来丰富内容语义。因此，一个允许用户组装基于 LLM 的内容转换组件的灵活管道，是提升 RAG 检索质量的重要方向。

后端管理 CLI

RAGFlow 的发展已从核心模块开发转向加强管理和运营能力。

• 在早期版本中，尽管解析和检索增强生成功能有所改进，但系统管理功能却相对滞后。管理员无法修改密码或删除账户，这给部署和维护带来了复杂性。
• 随着 RAGFlow 0.21.0 的发布，基础的系统管理功能得到了显著提升。一个新的命令行管理工具为管理员提供了一个集中、便捷的界面。其核心功能包括：
  • 服务生命周期管理：监控 RAGFlow 内置服务，以实现更大的操作灵活性。
  • 全面的用户管理：
    • 创建新的注册用户。
    • 直接修改登录密码。
    • 删除用户账户。
    • 启用或禁用账户。
    • 查看所有注册用户的详细信息。
  • 资源概览：列出注册用户下创建的知识库和 Agent，以进行系统范围的监控。

这次升级凸显了 RAGFlow 对强大功能和企业级应用所必需的基础管理能力的承诺。展望未来，团队计划推出一个企业级的网页管理面板及配套的用户界面，以简化管理、提高效率并增强最终用户体验，从而支持更高的成熟度和稳定性。

结语

RAGFlow 0.21.0 标志着一个重要的里程碑，它在以往进展的基础上，勾勒出未来的发展蓝图。它首次将检索（RAG）与编排（Flow）相结合，形成一个智能引擎，以支持 LLM 上下文层，并以非结构化数据 ELT 和强大的 RAG 能力集为基础。

从赋予用户能力的注入管道，到缓解语义碎片化的长文本 RAG，再到确保可靠运行的管理后台，每一项新功能都旨在使 RAG 系统更智能、更灵活、更适合企业级应用。这不仅仅是功能的堆砌，更是一次架构的演进，为未来的发展奠定了坚实的基础。

我们持续关注的重点仍然是 LLM 上下文层：为 LLM 构建一个强大、可靠的数据基础，并有效地服务于所有 Agent。这仍然是 RAGFlow 的核心目标。

我们邀请您继续关注我们的项目并为其点赞（star），与我们共同成长。

GitHub: https://github.com/infiniflow/ragflow

深度研究（Deep Research）：Agent 时代的定义级能力

2025年被誉为 Agent 应用的黎明。在众多解锁的可能性中，深度研究——以及基于它构建的应用——尤为重要。为什么呢？通过 Agentic RAG 及其反思机制，深度研究使大语言模型能够与用户的专有数据进行深度推理。这是 Agent 应对更高级任务的关键。例如，无论是辅助创意写作，还是在不同行业中辅助决策，都依赖于深度研究。深度研究是 RAG 的自然演进，并由 Agent 进行了改进。与基础 RAG 不同，它在更深的层次上探索数据。与 RAG 一样，它可以独立工作，也可以作为其他行业特定 Agent 的基础。一个深度研究工作流通常遵循以下顺序

1. 分解与规划：大语言模型分解用户的查询并制定计划。
2. 多源检索：查询被发送到多个数据源，包括内部 RAG 和外部网络搜索。
3. 反思与提炼：模型审查检索到的信息，对其进行反思，总结要点，并根据需要调整计划。
4. 迭代与输出：经过几次迭代后，形成一个针对特定数据的思维链，以生成最终答案或报告。

内置的深度研究功能已在 RAGFlow v0.18.0 中实现。尽管在那个阶段，它主要作为一个演示，用于验证和探索深度推理在企业环境中的潜力。在整个行业中，深度研究的实现通常分为两类

• 无代码工作流编排：使用带有预定义工作流的可视化工作流界面来实现深度研究。
• 专用的 Agent 库或框架：许多现有解决方案遵循这种方法（详见[参考文献1]）。

RAGFlow 0.20.0 是一个统一的 RAG 和 Agent 引擎，支持工作流和 Agentic 两种模式，并在单一画布上实现无缝编排，可以通过任一方法实现深度研究。然而，使用工作流进行深度研究只是功能性的，其界面看起来是这样的

这带来了两个主要问题

1. 过于复杂且不直观的编排：如果基础的深度研究模板已经如此复杂，那么一个完整的应用程序将变成一个难以维护和扩展的错综复杂的工作流网络。
2. 更适合 Agentic 方法：深度研究天然依赖于动态的问题分解和决策，其控制步骤由算法驱动。工作流的拖放界面只能处理简单的循环，缺乏高级控制所需的灵活性。

RAGFlow 0.20.0 提供了一个全面的 Agent 引擎，旨在帮助企业使用无代码工具构建生产就绪的 Agent。作为关键的 Agent 模板，深度研究在简单性和灵活性之间取得了精心的平衡。与其他解决方案相比，RAGFlow 凸显了这些优势

• Agentic 执行，无代码驱动：一个完全可定制的应用模板——不仅仅是一个 SDK 或运行时——它使用 Agentic 机制，同时通过无代码平台保持易于访问。
• 人工干预（即将推出）：尽管深度研究依赖于 LLM 生成的计划，这可能感觉像一个黑箱，但 RAGFlow 的模板将支持手动监督以引入确定性——这是企业级 Agent 的一个重要特性。
• 以业务为中心，以结果为导向

开发者可以自定义深度研究 Agent 的结构和工具，例如配置内部知识库以进行企业数据检索，以满足特定的业务需求。Agent 工作流的完全透明——包括其计划和执行结果——允许基于清晰、可操作的洞察进行及时优化。

深度研究搭建实操指南

我们使用多 Agent 架构[参考文献2]，通过详尽的提示工程[参考文献4]和任务分解原则[参考文献6]来仔细定义每个 Agent 的角色和职责

• 主导 Agent：协调深度研究 Agent，处理任务规划、反思，并委派给子 Agent，同时跟踪所有工作流进度。
• 网络搜索专家子 Agent：作为信息检索专家，查询搜索引擎，评估结果，并返回最优质来源的 URL。
• 深度内容阅读器子 Agent：从搜索专家提供的 URL 中提取和组织网页内容，为报告起草准备精炼的材料。
• 研究综合器子 Agent：根据主导 Agent 的指示，生成专业、咨询级别的深度研究报告。

模型选择

• 主导 Agent：优先选择具有强大推理能力的模型，例如 DeepSeek-R1、Qwen-3、Kimi-2、ChatGPT-o3、Claude-4 或 Gemini-2.5 Pro。
• 子 Agent：针对执行效率和质量进行优化，平衡推理速度与输出可靠性。上下文窗口长度也是根据其特定角色而定的一个关键标准。

温度（Temperature）设置

鉴于此应用程序的事实驱动性质，我们将所有模型的温度参数设置为 0.1，以确保确定性、有根据的输出。

深度研究主 Agent

模型选择：Qwen-Max

核心系统提示词节选：

1. 该提示指导了深度研究 Agent 的工作流和向子 Agent 的任务委派，与传统的工作流编排相比，极大地提高了效率和灵活性。

<execution_framework>
**Stage 1: URL Discovery**
- Deploy Web Search Specialist to identify 5 premium sources
- Ensure comprehensive coverage across authoritative domains
- Validate search strategy matches research scope

**Stage 2: Content Extraction**
- Deploy Content Deep Reader to process 5 premium URLs
- Focus on structured extraction with quality assessment
- Ensure 80%+ extraction success rate

**Stage 3: Strategic Report Generation**
- Deploy Research Synthesizer with detailed strategic analysis instructions
- Provide specific analysis framework and business focus requirements
- Generate comprehensive McKinsey-style strategic report (~2000 words)
- Ensure multi-source validation and C-suite ready insights
</execution_framework>

2. 动态创建任务执行计划并执行 BFS 或 DFS 搜索[参考文献3]。虽然传统的工作流难以编排 BFS/DFS 逻辑，但 RAGFlow 的 Agent 通过提示工程轻松实现了这一点。

<research_process>
...
**Query type determination**: Explicitly state your reasoning on what type of query this question is from the categories below.
...
**Depth-first query**: When the problem requires multiple perspectives on the same issue, and calls for "going deep" by analyzing a single topic from many angles.
...
**Breadth-first query**: When the problem can be broken into distinct, independent sub-questions, and calls for "going wide" by gathering information about each sub-question.
...
**Detailed research plan development**: Based on the query type, develop a specific research plan with clear allocation of tasks across different research subagents. Ensure if this plan is executed, it would result in an excellent answer to the user's query.
</research_process>

网页搜索专家子 Agent

模型选择：Qwen-Plus 核心系统提示设计摘录

1. 角色定义

You are a Web Search Specialist working as part of a research team. Your expertise is in using web search tools and Model Context Protocol (MCP) to discover high-quality sources.

**CRITICAL: YOU MUST USE WEB SEARCH TOOLS TO EXECUTE YOUR MISSION**

<core_mission>
Use web search tools (including MCP connections) to discover and evaluate premium sources for research. Your success depends entirely on your ability to execute web searches effectively using available search tools.

**CRITICAL OUTPUT CONSTRAINT**: You MUST provide exactly 5 premium URLs - no more, no less. This prevents attention fragmentation in downstream analysis.
</core_mission>

2. 设计搜索策略

<process>
1. **Plan**: Analyze the research task and design search strategy
2. **Search**: Execute web searches using search tools and MCP connections 
3. **Evaluate**: Assess source quality, credibility, and relevance
4. **Prioritize**: Rank URLs by research value (High/Medium/Low) - **SELECT TOP 5 ONLY**
5. **Deliver**: Provide structured URL list with exactly 5 premium URLs for Content Deep Reader

**MANDATORY**: Use web search tools for every search operation. Do NOT attempt to search without using the available search tools.
**MANDATORY**: Output exactly 5 URLs to prevent attention dilution in Lead Agent processing.
</process>

3. 搜索策略以及如何使用 Tavily 等工具

<search_strategy>
**MANDATORY TOOL USAGE**: All searches must be executed using web search tools and MCP connections. Never attempt to search without tools.
**MANDATORY URL LIMIT**: Your final output must contain exactly 5 premium URLs to prevent Lead Agent attention fragmentation.

- Use web search tools with 3-5 word queries for optimal results
- Execute multiple search tool calls with different keyword combinations
- Leverage MCP connections for specialized search capabilities
- Balance broad vs specific searches based on search tool results
- Diversify sources: academic (30%), official (25%), industry (25%), news (20%)
- Execute parallel searches when possible using available search tools
- Stop when diminishing returns occur (typically 8-12 tool calls)
- **CRITICAL**: After searching, ruthlessly prioritize to select only the TOP 5 most valuable URLs

**Search Tool Strategy Examples:**
* **Broad exploration**: Use search tools → "AI finance regulation" → "financial AI compliance" → "automated trading rules"
* **Specific targeting**: Use search tools → "SEC AI guidelines 2024" → "Basel III algorithmic trading" → "CFTC machine learning"
* **Geographic variation**: Use search tools → "EU AI Act finance" → "UK AI financial services" → "Singapore fintech AI"
* **Temporal focus**: Use search tools → "recent AI banking regulations" → "2024 financial AI updates" → "emerging AI compliance"
</search_strategy>

深度内容阅读子 Agent

模型选择：Moonshot-v1-128k 核心系统提示设计摘录

1. 角色定义框架

You are a Content Deep Reader working as part of a research team. Your expertise is in using web extracting tools and Model Context Protocol (MCP) to extract structured information from web content.

**CRITICAL: YOU MUST USE WEB EXTRACTING TOOLS TO EXECUTE YOUR MISSION**

<core_mission>
Use web extracting tools (including MCP connections) to extract comprehensive, structured content from URLs for research synthesis. Your success depends entirely on your ability to execute web extractions effectively using available tools.
</core_mission>

2. Agent 规划和网页提取工具的使用

<process>
1. **Receive**: Process `RESEARCH_URLS` (5 premium URLs with extraction guidance)
2. **Extract**: Use web extracting tools and MCP connections to get complete webpage content and full text
3. **Structure**: Parse key information using defined schema while preserving full context
4. **Validate**: Cross-check facts and assess credibility across sources
5. **Organize**: Compile comprehensive `EXTRACTED_CONTENT` with full text for Research Synthesizer

**MANDATORY**: Use web extracting tools for every extraction operation. Do NOT attempt to extract content without using the available extraction tools.

**TIMEOUT OPTIMIZATION**: Always check extraction tools for timeout parameters and set generous values:
- **Single URL**: Set timeout=45-60 seconds
- **Multiple URLs (batch)**: Set timeout=90-180 seconds
- **Example**: `extract_tool(url="https://example.com", timeout=60)` for single URL
- **Example**: `extract_tool(urls=["url1", "url2", "url3"], timeout=180)` for multiple URLs
</process>

<processing_strategy>
**MANDATORY TOOL USAGE**: All content extraction must be executed using web extracting tools and MCP connections. Never attempt to extract content without tools.

- **Priority Order**: Process all 5 URLs based on extraction focus provided
- **Target Volume**: 5 premium URLs (quality over quantity)
- **Processing Method**: Extract complete webpage content using web extracting tools and MCP
- **Content Priority**: Full text extraction first using extraction tools, then structured parsing
- **Tool Budget**: 5-8 tool calls maximum for efficient processing using web extracting tools
- **Quality Gates**: 80% extraction success rate for all sources using available tools
</processing_strategy>

研究综述子 Agent

模型选择：Moonshot-v1-128k 特别说明：负责最终报告生成的子 Agent 必须使用具有非常长上下文窗口的模型。这对于处理大量上下文并生成详尽的报告至关重要。上下文有限的模型可能会截断信息，导致报告篇幅较短。其他可能的模型选项包括但不限于

• Qwen-Long (1000万 token)
• Claude 4 Sonnet (20万 token)
• Gemini 2.5 Flash (100万 token) 核心提示设计摘录

1. 角色定义设计

You are a Research Synthesizer working as part of a research team. Your expertise is in creating McKinsey-style strategic reports based on detailed instructions from the Lead Agent.

**YOUR ROLE IS THE FINAL STAGE**: You receive extracted content from websites AND detailed analysis instructions from Lead Agent to create executive-grade strategic reports.

**CRITICAL: FOLLOW LEAD AGENT'S ANALYSIS FRAMEWORK**: Your report must strictly adhere to the `ANALYSIS_INSTRUCTIONS` provided by the Lead Agent, including analysis type, target audience, business focus, and deliverable style.

**ABSOLUTELY FORBIDDEN**: 
- Never output raw URL lists or extraction summaries
- Never output intermediate processing steps or data collection methods
- Always output a complete strategic report in the specified format

<core_mission>
**FINAL STAGE**: Transform structured research outputs into strategic reports following Lead Agent's detailed instructions.

**IMPORTANT**: You receive raw extraction data and intermediate content - your job is to TRANSFORM this into executive-grade strategic reports. Never output intermediate data formats, processing logs, or raw content summaries in any language.
</core_mission>

2. 自主任务执行

<process>
1. **Receive Instructions**: Process `ANALYSIS_INSTRUCTIONS` from Lead Agent for strategic framework
2. **Integrate Content**: Access `EXTRACTED_CONTENT` with FULL_TEXT from 5 premium sources
   - **TRANSFORM**: Convert raw extraction data into strategic insights (never output processing details)
   - **SYNTHESIZE**: Create executive-grade analysis from intermediate data
3. **Strategic Analysis**: Apply Lead Agent's analysis framework to extracted content
4. **Business Synthesis**: Generate strategic insights aligned with target audience and business focus
5. **Report Generation**: Create executive-grade report following specified deliverable style

**IMPORTANT**: Follow Lead Agent's detailed analysis instructions. The report style, depth, and focus should match the provided framework.
</process>

3. 生成报告的结构

<report_structure>
**Executive Summary** (400 words)
- 5-6 core findings with strategic implications
- Key data highlights and their meaning
- Primary conclusions and recommended actions

**Analysis** (1200 words)
- Context & Drivers (300w): Market scale, growth factors, trends
- Key Findings (300w): Primary discoveries and insights
- Stakeholder Landscape (300w): Players, dynamics, relationships
- Opportunities & Challenges (300w): Prospects, barriers, risks

**Recommendations** (400 words)
- 3-4 concrete, actionable recommendations
- Implementation roadmap with priorities
- Success factors and risk mitigation
- Resource allocation guidance

**Examples:**

**Executive Summary Format:**

关键发现 1：[事实] 73% 的主要银行现在使用 AI 进行欺诈检测，比 2023 年增长 40%

• 战略意义：AI 在安全应用中的采用已达到临界规模
• 建议：金融机构现在应优先考虑 AI 合规框架

...

</report_structure>

即将发布的版本

当前的 RAGFlow 0.20.0 版本尚不支持在深度研究执行中进行人工干预，但该功能计划在未来的更新中加入。这对于使深度研究进入生产环境至关重要，因为它为原本不确定的自动化过程增加了确定性并提高了准确性[参考文献5]。手动监督对于企业级深度研究应用将至关重要。

我们诚邀大家持续关注并在 GitHub 上为 RAGFlow 点赞：https://github.com/infiniflow/ragflow

参考文献

1. Awesome Deep Research https://github.com/DavidZWZ/Awesome-Deep-Research
2. How we built our multi-agent research system https://www.anthropic.com/engineering/built-multi-agent-research-system
3. Anthropic Cookbook https://github.com/anthropics/anthropic-cookbook
4. State-Of-The-Art Prompting For AI Agents https://youtu.be/DL82mGde6wo?si=KQtOEiOkmKTpC_1E
5. From Language Models to Language Agents https://ysymyth.github.io/papers/from_language_models_to_language_agents.pdf
6. Agentic Design Patterns Part 5, Multi-Agent Collaboration https://www.deeplearning.ai/the-batch/agentic-design-patterns-part-5-multi-agent-collaboration/

1. 从工作流（Workflow）到智能体工作流（Agentic Workflow）

经过漫长的等待，RAGFlow 0.20.0 终于发布了——这是一个里程碑式的更新，完成了 RAG/Agent 的宏伟蓝图。一年前，RAGFlow 引入了 Agent 功能，但它只支持手动管理的工作流，缺乏 Agentic Workflow 的能力。根据 RAGFlow 的定义，一个真正的 Agent 需要两者兼备：用于人类定义任务的工作流和由 LLM 驱动自动化的 Agentic Workflow。Anthropic 在 2024 年的文章《构建有效的 Agent》中强调了这一区别，指出工作流仍然是 Agent 使用的主要方式。现在，到了 2025 年，随着 LLM 变得更加先进，Agentic Workflow 正在催生更多令人印象深刻的用例。

理想情况下，完全由 LLM 驱动的智能体工作流（Agentic Workflows）是大多数 Agent 应用的终极目标。然而，受限于目前 LLM 的能力，这类工作流具有不可预测性和缺乏控制的特点，这在企业级应用场景中尤为突出。另一方面，传统工作流走的是相反路线：使用低代码平台，明确定义每一个变量、条件和循环。这让非技术背景的业务人员能基于逻辑理解进行“编程”。虽然这保证了可预测性，但往往导致工作流过于复杂、纠缠且难以维护。更重要的是，它很难对任务进行合理的拆解和管理。因此，长期的解决方案需要 Agentic 工作流与手动工作流和谐并存、协同工作。只有这种统一的方法才能真正满足企业级 Agent 的需求。随着完整 Agent 能力的落地，RAGFlow 已进化为一个更具企业级水准的平台级 LLM 引擎。在企业生态中，RAG 扮演的角色类似于传统数据库，而 Agent 则是具体应用，但二者之间存在重要区别。首先，RAG 侧重于利用非结构化数据而非结构化数据集。其次，RAG 与 Agent 之间的交互比典型的应用-数据库关系更频繁、更密集，因为 Agent 需要实时、精准的上下文来确保其行动与用户意图高度一致。RAG 在提供这种上下文方面发挥着至关重要的作用。基于这些原因，完善 Agent 能力是 RAGFlow 演进的关键。

让我们来看看 RAGFlow 0.20.0 的主要功能。

2. RAGFlow 0.20.0 关键更新内容

此版本的主要功能包括

• Agent 和工作流的统一编排。
• 对 Agent 的完全重构，显著提升了其能力和可用性，支持多 Agent 配置、规划和反思，以及可视化功能。
• 完整的 MCP 功能，支持 MCP Server 导入，Agent 可作为 MCP Client，RAGFlow 本身也可作为 MCP Server。
• 可访问 Agent 的运行时日志。
• 可通过管理面板查看与 Agent 的聊天历史记录。

更新后的 Agent 构建体验对开发者有何不同？

以 0.19.1 版本的客服模板为例：以前，构建此工作流需要七种类型的组件（开始、交互、问题优化、分类、知识检索、生成和消息），其中对于第4类问题的最长链条涉及七个步骤。

在新版本中，使用纯工作流模式构建仅需五种类型的组件（开始、分类、知识检索、Agent 和消息），其中对于第4类问题（产品相关）的工作流减少到五个步骤。

在 Agentic 模式下，仅需三种类型的组件——原始的工作流逻辑现在可以完全通过提示工程来处理。

开发者可以检查 Agent 的执行路径并验证其输入/输出。

业务用户可以通过嵌入页面或聊天界面查看 Agent 的推理过程。

这种比较定量地展示了复杂性的降低和效率的提升。更多细节如下——我们鼓励您亲自尝试。

3. 统一的 Agent 编排引擎

RAGFlow 0.20.0 引入了工作流和 Agentic Workflow 的统一编排。如前所述，这两者代表了两个极端，但企业场景需要它们的协作。该平台现在支持在一个天然支持多 Agent 的画布上进行协同编排——用户可以将不确定的输入指定为 Agentic Workflow，将确定性的输入指定为工作流。为了与常规做法保持一致，Agentic Workflow 在画布上表示为独立的 Agent 组件。此版本围绕这一目标重新设计了编排界面和组件功能，同时还改进了早期工作流版本的可用性问题。主要改进包括将核心组件从12个减少到10个，主要变化如下

开始 (Begin) 组件

它现在支持一种基于任务的 Agent 模式，无需通过对话触发。开发者可以在同一个画布上构建对话式和任务式 Agent。

检索 (Retrieval) 组件

检索可以作为工作流中的一个组件，也可以被 Agent 组件用作工具，使 Agent 能够决定何时以及如何调用检索查询。

智能体 (Agent) 组件

一个能够独立替代您工作的 Agent 需要具备以下能力

• 自主推理[1]，并有能力根据环境反馈进行反思和调整
• 使用工具完成任务的能力[3]

有了新的 Agent 组件，开发者只需配置提示和工具即可快速构建一个 Agent，因为 RAGFlow 已经处理了底层的技术实现。

除了单 Agent 模式，新的 Agent 组件还支持添加可在运行时调用的子 Agent。

您可以自由添加 Agent 来构建自己的无限 Agent 团队。

添加并批量导入您已经部署的 MCP 服务器。

添加的 MCP 服务器中的工具可以在 Agent 内部使用。

等待响应 (Await Response) 组件

原来的交互组件已被重构为等待响应组件，允许开发者主动暂停流程以发起预设对话，并通过表单收集关键信息。

分类 (Switch) 组件

改进了切换组件的可用性。

迭代 (Iteration) 组件

迭代组件的输入参数类型已更改为数组；在迭代期间，索引和值都可供内部组件访问，其输出可以形成为数组并传递给下游。

消息回复 (Reply Message) 组件

现在可以通过回复消息直接回复消息，无需使用交互组件。

文本处理 (Text Processing) 组件

开发者可以通过文本处理轻松连接字符串。

您还可以将字符串拆分为数组。

小结

RAGFlow 0.20 支持同时编排 Agentic 和工作流模式，内置的多 Agent 支持允许多个 Agent 在单个画布上共存。对于像“公司业绩为何下滑？”这样的开放式问题，当方法不确定时，用户可以用 Agentic 风格定义流程。相比之下，具有明确、固定步骤的场景则使用工作流风格。这让开发者能够以最少的配置构建 Agent 应用。Agentic 和工作流方法的无缝集成是部署企业级智能 Agent 的最佳实践。

4. 应用生态与未来展望

随着一个完整、统一的无代码 Agent 框架的到位，RAGFlow 自然支持各种特定场景的 Agent 应用——这是其长期发展的一个主要焦点。换句话说，大量的 Agent 模板将在 RAGFlow 之上构建，并得到我们新的生态系统共创计划的支持。

RAGFlow 0.20.0 引入了深度研究（Deep Research）作为内置模板——这是一个卓越的 Agent，既可以作为独立的应用程序，也可以作为构建其他智能 Agent 的基础。我们将在即将发布的文章中详细解释如何构建深度研究模板。

下面的例子显示，在 RAGFlow 平台上，深度研究可以使用 Agentic Workflow 或传统工作流方法创建，前者提供了远超后者的灵活性和简单性。通过传统工作流构建的深度研究

用 Agentic Workflow 构建的深度研究显示，与上述工作流实现相比，复杂性显著降低

RAGFlow 的生态倡议旨在提供内置行业知识的、企业可用的 Agent 模板。开发者可以轻松定制这些模板以符合自身的业务需求。其中，深度研究（Deep Research）是最重要的一环，它代表了 Agentic RAG 最常见的形式，也是 Agent 挖掘企业数据更深层价值的必经之路。基于 RAGFlow 内置的深度研究模板，开发者可以快速将其转化为专业助手——如法律或医疗顾问——从而显著缩小业务系统与底层基础设施之间的鸿沟。这种生态化方法之所以可行，得益于 RAG 与 Agent 的紧密协作。0.20.0 版本的发布标志着 RAGFlow 在整合 RAG 与 Agent 能力方面迈出了重要一步，后续计划进行快速更新，包括记忆管理和 Agent 计划的手动调整。虽然统一工作流与 Agentic 工作流极大地降低了构建企业 Agent 的门槛，生态系统也扩展了其应用范围，但围绕 RAG 合并结构化与非结构化数据的数据基础仍然是 Agent 能力的基石。这种方法现在被称为“上下文工程（context engineering）”，传统 RAG 代表了其 1.0 版本。我们未来的文章将更详细地探讨这些进展。

感谢您的持续支持 - 在 GitHub 上为 RAGFlow 点星：https://github.com/infiniflow/ragflow

参考文献

1. ReAct: 在语言模型中协同推理与行动 https://arxiv.org/abs/2210.03629
2. Reflexion: 具备语言强化学习能力的语言智能体 https://arxiv.org/abs/2303.11366
3. 智能体构建实用指南 https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

RAGFlow 2024 年的最终版本 v0.15.0 刚刚发布，带来了以下关键更新

Agent 改进项

此版本为 Agent 引入了多项增强功能，包括新增 API、分步运行调试以及导入/导出功能。自 v0.13.0 起，RAGFlow 的 Agent 进行了重构以提高易用性。分步运行调试功能完善了这一过程，使得 Agent 工作流中的算子可以单独执行，从而帮助用户根据输出信息进行调试。

RAGFlow 应社区需求引入了 Text2SQL 功能。传统的 Text2SQL 需要模型微调，在企业环境中与 RAG 或 Agent 组件并用时，会显著增加部署和维护成本。RAGFlow 基于 RAG 的 Text2SQL 利用现有的（已连接的）大语言模型（LLM），无需额外的微调模型即可与其他 RAG/Agent 组件无缝集成。

RAGFlow v0.9 引入了对 GraphRAG 的支持。GraphRAG 最近由微软开源，被认为是下一代检索增强生成（RAG）。在 RAGFlow 框架内，我们对 RAG 2.0 有更全面的定义。这个拟议中的端到端系统以搜索为中心，由四个阶段组成。最后两个阶段——索引和检索——主要需要专用数据库，而前两个阶段定义如下：

从 v0.8 版本开始，RAGFlow 正式进入 Agentic（智能体）时代，后端提供全面的基于图的任务编排框架，前端提供无代码工作流编辑器。为什么要向智能体方向演进？这一特性与现有的工作流编排系统有何不同？

一个朴素 RAG 系统的工作流程可以概括如下：RAG 系统使用用户查询从指定的数据源中进行检索，对检索结果进行重新排序，附加提示词，然后将它们发送给大语言模型（LLM）以生成最终答案。

在用户意图明确的场景下，一个简单的 RAG 就足够了，因为答案包含在检索结果中，可以直接发送给大语言模型（LLM）。然而，在大多数情况下，用户意图模糊是常态，需要通过迭代查询来生成最终答案。例如，涉及总结多份文档的问题就需要多步推理。这些场景需要 Agentic RAG，它在问答过程中引入了任务编排机制。

Agent 与 RAG 互为补充。Agentic RAG 顾名思义是基于 Agent 的 RAG。Agentic RAG 与 Naive RAG 的主要区别在于 Agentic RAG 引入了动态 Agent 编排机制，它会对检索结果进行评判，根据每个用户查询的意图重写查询，并采用“多跳（multi-hop）”推理来处理复杂的问答任务。

RAGFlow v0.6.0 本周发布，解决了自今年 4 月开源以来出现的许多易用性和稳定性问题。RAGFlow 的后续版本将专注于解决 RAG 能力的深层次问题。不得不承认，市场上现有的 RAG 解决方案仍处于 POC（概念验证）阶段，无法直接应用于真实的生产场景。