新能力亮相，赋予 AI 长期记忆，RAGFlow 0.23.0 正式发布，核心之一在于推出全新的 Memory 模块，它可以使 Agent 不仅能够实时检索与任务最相关的历史经验，更能持续、结构化地积累和优化其知识资产，构建起具备自主进化能力的智能核心。
除此之外，本版本也在多个维度进行了重要增强：
- Agent 能力扩展：重构底层架构，加速 Agent 运行；支持通过 Webhook 触发自动化流程；并开放语音输入与输出接口。
- RAG 能力升级：在文件解析阶段批量生成 Metadata ；提取图片/表格时，可在其所在切片内根据配置附带其上下文文本以增强语义表达；另外，切片策略新增了“父子切片”。
- API 改进：Agent 接口现已返回详细运行日志，便于开发者在前端直观展示其思考与执行过程；Chat API则增强了对Metadata的筛选支持，实现更精准的答案控制。
接下来，我们将逐一介绍这些特性与改进。
Memory 管理与使用
Memory 旨在保存 Agent 运行过程中动态产生的交互日志与派生数据（用户输入、LLM 输出、可能的交互状态、由LLM 生成的摘要或反思等），其目标是维持会话的连续性、实现个性化、以及从历史经验中学习。
该模块不仅能保存原始的交互数据，还能从中提取语义记忆、情景记忆和工作记忆等，将这些数据保存到 Memory 后，用户可以在后续对话中轻松引入这些信息作为上下文的一部分，从而提升对话的连贯性和推理的准确性。
Memory 管理
Memory 模块支持便捷的统一管理。用户可以在创建 Memory 时指定需要提取的记忆类型，并在导航页面 Overview >> Memory 处进行重命名、团队共享等操作。下图为创建 Memory。
进入单个 Memory 页面，可以对保存的记忆条目进行管理，选择在 Agent 调用中启用或禁用，或操作遗忘不再需要的记忆条目。
已操作遗忘的记忆条目将不再出现在 Agent 调用的结果中。在 Memory 存储容量到达上限触发遗忘策略时，已操作遗忘的记忆条目也将被优先清除。
增强 Agent 上下文
在 Agent >> Retrieval 节点和 Agent >> Message 节点下，新增了 Memory 调用功能。用户可以在 Message 节点配置存储到指定 Memory, 在 Retrieval 节点配置查询 Memory。下图展示了一个简单问答机器人 Agent 如何使用 Memory。
在配置 Memory 的 Agent 节点中，需要有配置 Retrieval 节点从 Memory 中召回。
同时把 Message 节点中 Save to memory 选择到相应的 Memory 中。
Agent 需要配置 User prompt 使得 Agent 节点获得 Retrieval 节点中的信息。
Memory如何让Agent越用越懂你
当一个概念在多个领域中同时存在时，Agent 有时会偏离用户的真实意图，给出不符合上下文的回答。
例如用户提问：“什么是 Reflexion？”，Agent 可能默认从认知科学 / 大脑心理学的角度进行解释，而非用户真正关心的 Agent / LLM 推理框架中的 Reflexion 概念。
在这种情况下，用户可以对 Agent 的理解进行澄清与纠正，明确指出这是一个 Agent 领域的术语。该澄清会被记录进 Memory，作为该用户的长期偏好与语义上下文。
此后，当用户再次询问同一概念时，Agent 会基于过往的交互经验，自动对齐用户的领域偏好，直接从 Agent 视角给出 Reflexion 的定义与说明，而无需重复澄清。
通过这个案例可以看到，Memory 让 Agent 不再是一次性应答工具，而是一个能够随着用户的使用不断校准认知、逐步成长的智能助理。
Agent 能力增强
在之前的版本中，社区反馈 RAGFlow 的 Agent 在配置了工具后，处理复杂任务的时有较高的执行准确率以及很强的泛化能力，但在处理一些日常复杂度不高的业务时，Agent 运行速度较慢和 Tokens 消耗大。
这是因为之前的版本中，Agent 的底层已经针对较复杂的任务做了分层设计，引入基于 LLM 的 Plan 和反思。
在 0.23.0 版本，Agent 对于简单任务做了进一步优化，对比最初 0.20.0 刚刚上线的 Agent ，处理这些任务的时间压缩约 50% 。这些优化主要从架构层面着手，改造了 Agent 节点的执行流程以及针对 LLM 的调用链路。
下例是构建了一个搜索学术内容的 Agent。
0.23.0 之前版本概念性的问题 “What is Reflexion in Agent domain?” 耗时 50 秒：
0.23.0 生成类似篇幅的回答耗时答复减少至 27 秒：
开发者还可以根据自己的业务流程自行决定 Agent 的运作流程，例如下图中开发者严格指定了工具调用顺序。
日志中可以看到的确先调用了 ArXiv：
接着再调用了 Tavily Search：
整个 Agent 运行耗时还维持在 30 秒这一时间量级。
通过 Webhook 触发流程
在实际业务场景及开发需求中，普遍存在依赖外部系统通过 HTTP 请求触发操作的情况，典型应用包括用户提交表单、聊天机器人消息推送等。
RAGFlow 的 Agent 在 0.23.0 版本实现了通过 Webhook 来接收外部 HTTP 请求，从而实现自动化触发和启动工作流的能力，提升了系统的灵活性和扩展性。
如下所示，系统会自动为每个工作流生成一个唯一的 Webhook URL，用户只需使用该 URL 即可方便快捷地接入外部系统，实现自动化集成。
用户可在 Webhook 配置页面直接复制生成的 Webhook URL，用于配置第三方系统或接口调用，并选择接收HTTP请求的方式。
Security 配置
Webhook 提供多层次的安全认证和流量控制机制，确保数据传输的安全性和系统的稳定性。
支持包括令牌认证（Token）、基本认证（Basic auth）以及 JWT 认证，三种认证方式以满足不同安全等级的需求；同时支持请求频率限制（Request limit）和最大请求体大小限制（Maximum body size），并提供 IP 白名单（IP whitelist）配置功能，防止恶意访问和流量过载，确保服务稳定可靠。
Schema 配置
Schema 用来指定 Webhook 接收的 HTTP 请求的数据格式，RAGFlow 据此格式来解析请求。Schema 配置包含 HTTP 的内容类型 （Content types）和查询参数，目前支持的内容类型包括如下：
支持从传入请求的查询参数（Query parameters）、请求头参数（Header parameters）以及请求体参数（Request body parameters）中解析和提取所需数据，作为下游任务的输入变量。
Response 配置
提供两种执行模型——Accepted response 和 Final response：
- Accepted response：请求校验通过后立即返回接收成功响应，工作流在后台异步执行。
- Final response：系统在工作流执行完成后返回最终处理结果。
Accepted resopnse 经由 Begin 节点配置：用户可在 200-399 范围内自定义成功响应状态码与响应内容正文。
Final response 配置由 Message 节点承担：用户可在 200-399范围内自定义成功响应状态码。
测试运行和查看日志
测试运行阶段，系统将使用测试专用 URL 进行触发。用户可在 Test run 页面中实时查看整个工作流的运行状态并 Overview 整体输入与输出结果；同时，Logs 模块会详细记录每一个节点的执行过程与日志信息，便于问题排查与调试。
支持全局引用对话变量
在真实的开发场景中，往往存在需要在 Agent 流程中复用中间变量的情况。例如，在对话过程中，判断用户当前的提问是否在上一轮对话中已经出现过。这就要求能够将上一轮的提问结果保存到一个变量中，并在后续流程中进行复用和比对。
在 RAGFlow 中可以通过 Conversation variable 定义一个全局变量，用于定义 Agent 的中间输出，作为可复用的变量。
比如定义名为 his_query 的全局变量接收用户的历史提问。
并通过 Variable assigner 节点为全局变量赋值。
支持 Agent 节点结构化输出
之前版本的 RAGFlow 工作流，节点输出格式是简单的文本或非结构化数据，限制了后续节点对信息的精确解析和利用。
RAGFlow 0.23.0 引入了对节点结构化输出的支持，以标准化、格式化的数据形式（如 JSON 对象）进行传递，作为后续节点可读取和处理的变量。
在 Agent 节点结构化输出配置中添加字段名、类型及描述，系统会自动生成对应的 JSON Schema。例如，添加一个 author 字段，JSON Schema 如上图所示。
运行后，输出结果会遵循该结构化格式，作为变量传递给后续节点，方便准确读取和处理，结果示例如下：
支持语音输入输出
RAGFlow 0.23.0 版本支持端到端的语音输入和输出，基于此特性可以构建语音类 Agent 应用，例如数字人等等。语音输入和输出同时在 Chat 和 Agent 模块支持。
Chat 模块的语音输入输出操作入口：
Agent 模块的语音输入输出操作入口：
RAG 能力增强
自动生成与管理 Metadata
过去 RAGFlow 对于 Metadata 的支持较为薄弱，管理层面只提供了手动编辑单个文件的 Metadata 能力。
通过与社区开发者们的沟通和调研发现大家对 Metadata 的需求比较强烈。
因此 RAGFlow 中引入了 Auto-metadata 功能。对比过往只能手动一个个为文件增加 Metadata，现在可以使用大模型为文件自动提取和生成元数据。
通过利用好 Metadata，它可以在 RAG 流程中承担双重职责：
- 检索时：过滤无关文件，缩小搜索范围以提升召回准确率。
- 生成时：若分块被召回，其关联的元数据将一并传递给 LLM，使其生成回答时具备更多关于该文档的背景信息。
配置 Auto-metadata 生成规则
在知识库 Configuration 页面，需先选择 Indexing model，该模型将用于生成当前知识库的知识图谱、RAPTOR、Auto-metadata、Auto-keyword 以及 Auto-question。
点击 Auto-metadata -> Settings 进入自动生成元数据的规则配置页面。
点击 + 添加新字段，进入该字段的配置页面。
输入字段名称例如 Author，并在 Description 处添加对该字段的描述和示例，以指导大模型更准确地提取该字段下的 Values。若该项留空，大模型将仅根据字段名提取相关的 Values。
若需指定大模型仅在有限范围内生成元数据，如图所示可开启 Restrict to defined values 模式，并手动添加 Values，大模型将仅生成预设范围内的结果。
配置完成后，在 Configuration 页面打开 Auto-metadata 开关，所有新上传的文件在解析时都会应用该规则并自动生成元数据。对于已经解析完成的文件，需通过重新解析触发元数据生成，用户可通过筛选功能查看文件的元数据生成状态。
管理 Metadata
系统支持对整个知识库层面以及单个文件层面的元数据进行管理。
在知识库中点击 Metadata，进入 Manage metadata 页面。
此处可统一管理所有已生成的元数据：支持更改 Values，若将两个值修改为相同名称，则自动合并；支持删除特定值或整个字段，这些操作将影响全部关联的文件。
后续将陆续支持更精细化的管理功能，例如为选中的部分文件设置特定生成规则，或批量为文件手动添加元数据等。
单个文件的管理页面如下图所示，先点击文件的解析方式（如 General），再进入 Set metadata 可查看和编辑该文件的元数据。用户可以为该文件执行新增、删减或编辑元数据字段的操作。在此处进行的编辑会同步在知识库 Metadata 的全局统计中显示。
通过 Metadata 进行筛选
筛选功能分为知识库管理层面的筛选以及检索阶段的筛选。
在知识库中点击筛选按钮，可以查看已有元数据字段下每个值所绑定的文件数，勾选特定值即可展示关联的全部文件。
还可以通过“No metadeta”筛选出还未生成 metadata 的文件，进行批量重解析以触发自动生成。
在检索阶段同样支持通过元数据筛选文件。以 Chat 为例，在配置知识库后可以设置元数据过滤规则：
- Automatic 模式将根据用户的 Query 和知识库现有的元数据，自动过滤
- Semi-automatic 模式先由用户设置字段层面的筛选范围（例如刚才的 Author），再在这个范围内自动过滤
- Manual 模式则完全由用户手动设置精确到 value 的过滤条件，并且支持选择多种过滤操作符如：Equals, Not equals, In, Not in 等。
为图片和表格添加上下文
RAGFlow 基于内部的 DeepDoc，外部的 MinerU、Docling 等文档模型，可以提供文档解析布局。
在之前的版本中，根据文档布局得到的图片和表格会作为一个独立的 Chunk 存在。检索时若没有命中图片和表格本身的内容，则图片和表格不会被召回。在实际的文档中，经常出现图表内容和周边文字混合编排的情况，文字对图表内容进行描述，因此，基于这些上下文来召回图表，也是必备的功能。
为此，RAGFlow 0.23.0 新增了 Image & table context window 功能，这也是借鉴了主打多模态 RAG 的研究性开源项目 RAG-Anything 的主要特点，可以根据用户配置的上下文窗口大小，允许这些文字和图表被共同放置在一个 Chunk 当中，从而可以被共同召回，该特性可以有效提升针对图表召回的准确率。
具体配置如上所示：红框的数值表示：截取图表上方和下方文本的约 N 个 tokens，插入到类型为图片/表格的 Chunk 中作为对图表的上下文补充。截取时会依据标点符号优化边界以保持语义完整，用户可根据需要调整获取的上下文 Tokens 数。
切片增强
在 RAG 的实际应用中，一个长期存在的痛点在于传统的“分块-嵌入-检索”流水线存在结构上的矛盾：单一的文本切片（Chunk）被同时用于承担语义匹配（召回）与上下文理解（利用）两项任务，而这两者本身存在冲突——召回需要粒度小、定位准，而生成答案则需要上下文连贯、信息完整。
为解决这一矛盾，RAGFlow 在过往版本中已推出 TOC（Table of Contents） 目录增强功能：基于大语言模型生成文档目录结构，在检索阶段借助目录自动补全因切片切分而缺失的相关上下文。
在 0.23.0 版本中，该能力已被系统化集成至 Ingestion pipeline。同时，在 0.23.0 版本还推出了父子切片机制，也可用于部分解决这个矛盾： 在这一机制下，文档首先被切分为较大的父切片，每个父切片保持一个相对完整的语义单元，确保逻辑与背景的完整性；之后，每个父切片内部可进一步细分为多个子切片，用于实现精准召回。
检索时，系统会先基于子切片定位到最相关的文本段，同时自动关联并召回其所属的父切片，从而在保持高召回相关性的同时，为生成环节提供充足的语义背景。
例如，在处理一份《合规手册》时，当用户提问“违约责任”相关条款，系统可能精准召回到“违约罚款数额为合同总价的 20%”这一子切片，却因缺失上下文而无法说明该条款适用于“一般违约”还是“严重违约”。
借助父子切片机制，在返回该子切片的同时，也会一并带回包含该条款完整章节的父切片，使大模型能够基于更全面的上下文作出准确判断，避免断章取义。
通过这种“精准定位 + 上下文补充”的双层结构，RAGFlow 在保障检索准确率的同时，显著提升了生成答案的可靠性与完整性。
父子切片使用方式如下，在知识库 Configuration 页面打开 Child chunk are used for retrieval 开关，并设置 Child chunk 的分隔符。
开启子切片后，Recommended chunk size 的逻辑变为父切片的大小，可以适当调高这一配置（如1000-2000 tokens）让大模型回答时获取更多上下文。
Ingestion pipeline 中的配置同理。
需要指出的是，父子切片与 TOC 目录增强分别从规则和模型两个维度，缓解了 RAG 中“召回精度”与“上下文完整”间的结构性矛盾。二者均为阶段性方案，旨在为开发者提供即用的优化手段。RAGFlow 后续版本将持续推进底层能力升级，致力于从架构层面更系统、更彻底地解决这一问题。
API 更新
Agent API 返回 Trace logs
RAGFlow Agent API 支持返回详细的执行跟踪日志，帮助开发者调试和分析 Agent 的执行流程。
支持的接口
- POST /api/v1/agents/{agent_id}/completions
使用注意事项
1. 通过设置 return_trace: true 启用跟踪日志 2. 跟踪日志包含每个组件的执行时间、输入输出和错误信息 3. 在流式响应中，跟踪信息通过 node_finished 事件返回 4. 在非流式响应中，跟踪信息可以在data.data.trace中获取
Curl 示例
Agent 对话（带 Trace Logs）
curl --request POST \
--url http://{address}/api/v1/agents/{agent_id}/completions \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <YOUR_API_KEY>' \
--data '{
"question": "How to install neovim?",
"stream": true,
"session_id": "cb2f385cb86211efa36e0242ac120005",
"return_trace": true
}'事件类型说明
- message: 流式消息内容
- message_end: 消息结束，可能包含引用信息
- node_finished: 组件执行完成，包含跟踪日志
通过分析 trace logs，开发者可以了解 Agent 的执行路径、性能瓶颈和错误原因，从而优化 Agent 配置。
Chat API 层面支持 Metadata 筛选
RAGFlow Chat API 现已支持 metadata 筛选功能，允许在对话时根据文档元数据字段进行精确过滤，控制检索结果范围。
支持的接口
- POST /api/v1/chats/{chat_id}/completions
- POST /api/v1/chats_openai/{chat_id}/chat/completions
使用注意事项
1. metadata 字段必须在文档中存在，否则条件将被忽略 2. 字符串比较区分大小写 3. 支持的逻辑操作符：and、or 4. 支持的比较操作符：is、not is、contains、not contains、start with、end with、empty、not empty、>、<、≥、≤
Curl 示例
与聊天助手对话（带 metadata 筛选）
curl --request POST \
--url http://{address}/api/v1/chats/{chat_id}/completions \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <YOUR_API_KEY>' \
--data '{
"question": "Who are you",
"stream": true,
"session_id":"9fa7691cb85c11ef9c5f0242ac120005",
"metadata_condition": {
"logic": "and",
"conditions": [
{
"name": "author",
"comparison_operator": "is",
"value": "bob"
}
]
}
}'OpenAI 兼容接口（带 metadata 筛选）
curl --request POST \
--url http://{address}/api/v1/chats_openai/{chat_id}/chat/completions \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <YOUR_API_KEY>' \
--data '{
"model": "model",
"messages": [{"role": "user", "content": "Say this is a test!"}],
"stream": true,
"extra_body": {
"reference": true,
"metadata_condition": {
"logic": "and",
"conditions": [
{
"name": "author",
"comparison_operator": "is",
"value": "bob"
}
]
}
}
}'关于上述 API 的详细描述，可以查看 RAGFlow 的 API 参考文档。
写在最后
作为 RAGFlow 在 2025 年的最后一次大版本更新，0.23.0 版本是一个承前启后的重要里程碑。它标志着 RAGFlow 从一个专注于知识库场景的 RAG 引擎，正式向支撑各类 Agent 构建的上下文引擎演进。
本次版本不仅持续增强了 RAG 核心能力，还全新引入了 Memory 模块——用于保存与检索 Agent 对话过程中产生的数据，并自动将其融入上下文之中。这些被 Memory 留存的数据，将帮助对话系统沉淀经验，逐步形成可持续迭代的能力飞轮。
如果说在 Agent 体系中，模型负责推理，RAG 与工具代表行动，那么 Memory 便是承载个性化与历史的灵魂。关于 Memory 的探索才刚刚开始，未来我们将推进更细粒度的记忆区域管理，并围绕工具使用形成有效的 Skills 与 Guideline 机制。
作为服务大语言模型的数据基座，RAGFlow 的初心始终如一：在提供完整无代码 Agent 构建平台的同时，更致力于成为所有采用其他工具开发 Agent 的数据基石。
