RAGFlow 1.0 发布，用 Go 重写并加入知识编译能力

过去两年，几乎每家企业都在用 RAG 解决大模型落地的问题。把文档切块，做 Embedding，算相似度，塞进 Prompt。简单、直接、听起来无懈可击。但真正把它搬进生产环境的人都知道：RAG 远不够好。

精确日期查不准，模糊概念搜不到，多文档聚合时检索回来的全是干扰项。于是大家开始加 GraphRAG、加 RAPTOR、加 Contextual Retrieval，架构图越画越复杂，团队越招越多，效果提升却越来越不匹配投入。复杂度上去了，确定性没有上去。

与此同时，另一条路正在被验证：Agent Harness 配上 Grep 这样的简单工具，在很多场景下已经能超越精心调优的 RAG。但这条路也不是终点——数据规模一大，Agent 就开始反复搜索、反复试错，Token 消耗失控，响应时间失控。

几条路都走到了边界。 不是某一家产品做得不够好，而是整个范式需要换一个问法：

检索的核心，到底是“设计一个更强的召回算法”，还是“设计一套能动态编排、持续供给上下文的系统”？

这个问题，过去半年里已经被不同的人、从不同的方向、用不同的方式回答过了。

• Karpathy 提出 LLM Wiki主张知识应该被编译一次、持续更新，而不是每次查询都重新推导一遍。这个想法从个人知识管理溢出到企业 RAG 领域，直接动摇了“每次提问临时拼凑片段”的默认做法。

• PwC 的 “Is Grep All You Need?”给 Agent 同时配备向量搜索和 Grep，结果发现 Grep 常常比语义搜索更准。但论文真正的结论不是“精确匹配就够了”，而是：检索的关键不在工具本身，而在框架——它决定什么能进入上下文，以及 Agent 在利用上下文之前必须做什么。【参考 1】

• 微软的 AgenticRAG把检索拆成 SEARCH、FIND、OPEN 三类工具，消融实验显示最大提升来自“从单次检索转向 Agentic 工具使用”。换句话说，收益来自编排，而不是来自更强的检索器。

• 产业侧的判断更直接VentureBeat 说 “RAG-to-vector database pipeline 已经不够用了，Agentic AI 需要一种不同的方法来整合上下文”；作为向量数据库领域的先驱，Pinecone 在 2026 年发布了专为 Agent 打造的新一代知识引擎 Nexus，其 CEO 在发布时说得更直白：“RAG 是为人类用户打造的，Nexus 是为 Agent 用户打造的——他们的语言不同，期望的响应不同，分配的任务也不同。”

这些声音来自不同公司、不同论文、不同产品，彼此未必引用，却指向同一个判断：

检索的重心，正在从“召回算法”转向“编排框架 + 上下文供给”。Search Harness 负责找到，知识编译负责省着用。

这不是 RAGFlow 一家之言，而是行业正在形成的共识。

RAGFlow 1.0 要做的，不是提出这个判断，而是把它落成可长期运行的产品：用 Go 重写底座，重新设计内部架构，把知识编译与高质量上下文供给，做成任何 Harness 都能调用的基础设施。

今天，RAGFlow 1.0 正式发布。这不是一次普通版本更新，而是 RAGFlow 从端到端 RAG 引擎，正式演进为 Agent Native Database 的起点。

01

全新架构分工：Agent Native Database

从 1.0 开始，RAGFlow 的定位正式升级为 Agent Native Database。

这个定位需要被认真定义，否则它只是一个营销词汇。它不是端到端 RAG 引擎，也不是一个“给模型喂片段”的检索后端。它是Agent Harness 可以直接调用的上下文供给层。

它供给什么？原文片段、编译后的证据单元、导航结构、关系骨架、时间线、Wiki、本体断言、Memory 事实——不论 Harness 需要哪一种，都可以从 RAGFlow 获取。分工可以概括为一句话：Harness 负责编排，RAGFlow 负责供给。

如下图所示：

为什么现在提出这个定位？

因为 Agent 时代的检索不再是“查一次、拿回若干片段、交给模型”的一次函数调用，而是“多轮编排 + 上下文治理”的过程。这个过程需要的不只是更强的召回算法，还需要一个能持续供给高质量上下文、能压缩 Token、能追溯证据、能治理权限与版本的独立层。

供给层必须独立成产品，而不是继续塞在 RAG 引擎或者向量数据库里。

知识编译是这个供给层的核心能力。它把“理解”工作从查询时移到索引时：编译一次、多次受益。

以证据链为例：命中时单个问题可节省 Token 90% 以上，未命中时只损失约 2%；

在复杂多跳 Benchmark 数据集 FRAMES 上，证据链平均 Token 节约在 30–40% 以上。这种“命中收益极高、未命中成本极低”的不对称性，正是供给层值得独立存在的经济学基础——它让 Agent 不必每次从零探索，也不必为探索付出不可控的 Token 成本。

这种不对称还意味着一个很低的盈亏平衡点：只要证据链的命中率超过约 2%，编译成本就能被查询节省覆盖；

而 FRAMES 上的采用免费模型 GLM-4-Flash 编译的结果实测命中率接近 43%【参考 2】。换句话说，知识编译不是“赌命中”，而是一笔在绝大多数语料上都会赚钱的买卖。

除了证据链，知识编译还包括图状关联探索、时间线、LLM Wiki 等形态；本体、Memory 等模板正在路上。证据链导航树、图谱、LLM Wiki、时间线在 1.0 中已经可用。

把这些形态放在一起看，Agent Native Database 的实质就清楚了：它不是又一种数据库，而是上下文供给层。 没有查询语言，也不取代任何存储；

它把原始数据编译成 Agent 可直接查询的上下文工件——带逐字证据的声明、实体关系、时间线、本体标签，类型化、版本化、可治理——再由 Harness 决定某个问题该读什么。编译工件是数据，Harness 决定什么进入窗口，工具是唯一路径。

一个以生产并交付这种上下文为职责、而不是以排序返回分块为职责的系统，就是 Agent Native Database。

RAGFlow 1.0 的分工只有一句话：Harness 负责编排，RAGFlow 负责供给。 供给层独立成产品，Agent 才能专注编排与推理，企业才能把上下文当数据治理，而不是当 Prompt 拼装。

02

架构重构：为“长期运行”而设计

企业级数据治理最怕两件事：一是“有任务、没记录”的悬空状态，二是失败后留下半篇文档、幽灵证据。

RAGFlow 1.0 重新设计 Ingestion Pipeline 与检索侧架构，目标不是增加功能，而是让系统在真实生产负载下稳定、可扩展、可审计，真正接管企业级数据治理流程。

它将 Ingestion Pipeline 重新实现为两级流水线 + 两条编排轴。

两级流水线：

文档级流水线负责单篇文档的解析、切分、编译、向量化、抽取与落盘；数据集级编译负责跨文档归并 Wiki、图谱结构、导航等编译产物。前者处理“一篇文档”，后者处理“一批文档之间的关系”。

两条编排轴：

所有流程——不论是 Ingestion Pipeline 模板还是 Agent 工作流——都由统一的流程定义驱动，编译成 DAG 任务图后执行；任务调度走数据库状态机加消息队列，而不是写死在代码里。

整体 Ingestion 架构如下:

一句话概括设计取舍：流程由配置定义，不由代码写死；失败恢复靠任务重投加结果缓存。

1. 可编排、可容错的增量处理 DAG

从接入到落盘，每个 Ingestion Pipeline 对应的 DAG 的每一层都有明确的失败边界和恢复策略：

• 接入：先记录状态再派发。如果派发失败，记录也会撤回，不会出现“任务已经跑了，但系统里查不到”的情况。
• 投递：如果因为网络原因任务被重发，系统只会延长时间，绝不会把已经解析好的进度清零重来，重跑时只处理发生变化的增量部分。一切以数据库里的状态为准。
• 执行：状态变更绝对安全。程序如果突然崩溃，会被系统捕捉并标记失败，然后把任务退回队列。系统能清晰分辨是“服务器宕机”、“用户取消”、“解析报错”还是“真的做完了”。
• 落盘：分批写入，依靠内容标识进行覆盖而非追加，所以重复处理不会产生多余数据。如果写到一半重试几次还是失败，系统会自动把刚写进去的残缺数据删掉，保证绝对不会搜到“半篇文档”。
• 编译产物：重新解析文档时，旧的知识产物依然可用，不影响业务。只有等新的完全生成好了，才会替换旧的。生成 Wiki 也是一样，先放进暂存区，失败了也不影响原来的知识库。
• 跨文档合并：任务的真实进度以数据库为准，消息队列只负责发通知。合并时只拉取当前批次的增量产物，绝不加载整个知识库。每次处理一个固定的批次，只有这批任务全部成功了才算完成；如果中途失败，任务会留在队列里等下次重试。涉及到覆盖或删除已有数据时，必须先获取数据锁并校验操作权限，防止并发修改导致数据混乱。

明确的设计取舍：流程内部不做断点续跑。恢复靠“任务级重投 + 组件级结果缓存”，让失败只退化为“重跑一次任务的增量成本”，从而避免了复杂的断点续跑机制带来的高昂资源开销与维护负担。

2. 多版本治理

企业场景需要版本治理，RAGFlow 1.0 把它做成了机制，而且分两条线治理：一条管执行编排，一条管知识出处。

Pipeline 版本管“这篇文档按哪张图跑”

每次手动保存生成一个不可变版本；

绑定是文档级的——数据集保存所用版本，上传或新建文档时继承，此后数据集改版不回写已上传文档。所以一个数据集里并存多个版本，是企业场景的常态，不是异常。运行时优先用绑定版本，没有绑定才取最新版本；

绑定失效则任务失败并提示重新选择，而不是悄悄用错版本。运行账本记录“第几次、跑哪个流程”，让每次执行可追溯。

编译版本管“这条知识由哪版模板产生”

模板草稿可改，发布才生效，快照写入后不再更新；退役不删快照，已抽出的断言永远能解释“是哪版模型说的”。产物每行带版本戳，诊断时能直接回答“这条证据是不是旧版本留下的”。

两条线职责清晰：Pipeline 版本让执行可回滚，编译版本让知识可追溯。企业敢灰度、敢回滚、敢审计，才敢把核心数据交给一套系统长期运行。这就是 Agent Native Database 的信任底座。

3. 从解析到落盘的全链路性能优化

高性能不是靠单点调参，而是从入口到落盘的系统性优化。

• 解析更快：DeepDoc 经过彻底重写，全面保留 PDF、Office 兼容性的同时，解析速度相比此前版本有大幅提升，在不涉及 OCR 的纯文本解析场景下，速度更是达到了此前版本的数量级以上。
• 并发分层：为了让海量文档处理得更快，RAGFlow 把并发分成了三个层次：1. 任务级并发：有多少 CPU 核，就同时开多少个任务。系统会自动过滤掉重复提交的同一篇文档，不会白费算力。2. 文档内部并发：在单篇文档内部，模型抽取（如打标、总结）共用一个全局资源池，避免某个超长文档把系统资源占满；而向量化则严格按模型支持的批次大小“攒够一批发一次”，大幅降低网络请求的消耗。3. 数据集级合并：这是最特殊的一层。不同知识库之间的合并可以完全并行，互不干扰；但针对同一个知识库，必须“排队”处理。这看似牺牲了并发速度，但却是必须的——因为如果多个任务同时往同一个库里合并数据，会引发数据覆盖和冲突。

前两层是为了把性能榨干，最后一层是为了保证数据绝对准确。

• 批处理：索引写入分批进行，只在最后一批刷新，把刷新次数从 N 降到 1；合并去重用一次模型往返替代逐对判定；同一相似度命中行的多个候选先分组再合并写入。
• 缓存：分块缓存以“类型 + 模型 + 分块 + 影响结果的配置”为键，记住模型与向量化结果，重跑时同一分块零模型调用；媒体缓存保存图片与视觉解析结果，成功落盘后才清理，失败保留供重试。
• 避免全量扫描：数据集编译只读当前文档产物，再用相似度检索找候选，从不加载整个知识库；Wiki 先算贡献差异，无变化直接短路返回。
• 限流与退避：限流冷却按服务商实例共享，一个工作线程被限流时，同服务商的其他线程一起退避，其他服务商不受影响；退避覆盖约两个半限流窗口并尊重服务端返回的等待时间；超长输入走逐级缩短策略，仍失败则逐条隔离重试，避免一个坏输入拖垮整篇文档。

这套设计的性能上限由“同一知识库串行”和“外部模型配额”两个真实约束决定；框架层的职责是把其余环节全部并行化、批量化、缓存化，并让失败只退化为“重跑一次任务的增量成本”。

4. 从摄入到检索：编译产物落盘之后

文档级流水线里的 Compile 环节，负责把原始文档编译成可检索的知识工件。这个环节有三个工程要求：并发、幂等、可摘除。文档编译是高度并行的任务，1.0 支持并发编译与幂等重建——宁可整体重算，也不留半新半旧的结构。每条编译产物携带血缘，文档被删除时相关贡献被精确摘除，不会在索引里留下幽灵证据。

编译产物落盘之后，检索侧如何消费它？

1.0 的检索侧架构围绕四条设计原则展开。

• 工具层：并行调用、错误变观察、契约稳定：同一轮多个检索动作可以并行执行；工具报错不中断整轮，而是变成模型能读懂的一条结果；工具返回的始终是候选，不是结论。工具契约稳定，意味着上层 Harness 可以替换、可以组合，而不必担心底层行为漂移。
• Harness 层：有状态、可恢复、可归因：会话是一份事件日志，失败的一轮会被回滚，不会把“有调用、没结果”的残骸带到下一轮；跨轮持久化只保留每轮最终答案，不保留取证轨迹，长对话成本不会随轮次线性爆炸；每轮成本按阶段归因——取证、证据直答、汇总各花了多少，回答错了时能分清是“没找到”还是“找到了没用上”。
• 通道隔离：原文与派生内容严格分离：面向模型阅读的正文检索，永远排除编译产物；编译结构只通过编译工具进入上下文。派生知识不冒充原文，原文也不被结构淹没。这是供给层与 Harness 协同的前提，也是企业审计的前提。
• 可审计：每条证据可追溯，每轮成本可归因：每条真正进入模型的证据都有记录：命中了哪些词、是否被截断、原文多大。这不是日志冗余，而是基础设施产品的基本要求——出问题时，要能定位。

这些设计背后是同一个原则：进入上下文的证据，必须是此刻最小的充分集合。 知识编译负责把上下文压缩、结构化、可追溯；Harness 负责判断够不够、发不发、读不读。

具体机制在我们的论文 “Context as Infrastructure: Knowledge Compilation for Retrieval in Agentic Systems with Harnesses”【参考 2】已有展开，本文不再重复。1.0 要回答的是：这些原则如何落成工程保障。

小结：1.0 的稳定性与性能来自架构，不是来自调参

可编排、可容错、可多版本治理、检索侧可消费，这四点共同构成 Agent Native Database 的工程底座。

03

为什么 1.0 要用 Go 重写

架构重构的底座，是另一个更底层的变化：RAGFlow 1.0 完全用 Go 重写了此前的 Python 版本。这里有一个残酷的事实：用 Python 做的 Infra，很难走进生产。

这不是一次“换语言玩性能”的尝试，而是产品定位变化后的必然选择。当 RAGFlow 不再只是一个 RAG 引擎，而是要成为 Agent Harness 长期依赖的上下文供给层，它对底座的要求就变了：要 7×24 运行、要并发编译海量文档、要管理长会话状态、要在故障时保持清晰边界。动态语言在这些场景下的代价，会一笔一笔暴露出来：类型错误在运行时才炸，并发模型受制于解释器与 GIL，长期运行的资源占用和故障隔离几乎无法预测。

Go 带来的不只是快，而是三件事：

• 稳定性： 静态类型与编译期检查，把大量错误拦在构建阶段；明确的错误处理路径，让故障边界清晰可查；单一二进制交付，部署和回滚都可控。

• 并发模型：当检索的发起方从“人类用户的单次查询”转变为“Agent Harness 的多轮高频调用”，RAG 范式升级为 Retrieval Harness，并发请求量呈现数量级以上的爆发式增长。RAGFlow 1.0 在 Go 重写后，检索的并发能力提升了 2 个数量级以上。在 Python 的 GIL 限制下，这是完全无法满足的严苛需求。 知识编译的并发、工具层的并行调用、Harness 的长会话状态管理，在 goroutine 与 channel 下都有统一语义。超时、取消、错误传播，不再依赖第三方库各自为政。
• 长期运行： GC 行为、内存占用、故障隔离，在生产环境里可预测。一个要 7×24 运行的系统，不能把稳定性寄托在“这次应该不会出问题”上。

一句话：PoC 可以 Python，严肃 Infra 不行。 RAGFlow 1.0 选择 Go，是因为它准备长期留在生产环境里。

语言是底座，架构是上层。两者共同构成 Agent Native Database 的工程基础。

04

能力清单与迁移说明

RAGFlow 1.0 已面向开发者开放。以下是这一版中可以直接使用的能力与迁移要点。

• 部署与运行 1.0：1.0 提供 Go 版本的安装与部署方式，支持容器化部署与单机运行；容器镜像尺寸相比之前版本缩小一个数量级，系统启动延迟降低一个数量级，并同时提供 ARM 官方镜像，部署门槛显著降低。
• 知识编译模板体系：1.0 内置树状导航（含证据链节点）、图状探索、时间线、LLM Wiki 等模板，并提供模板配置能力：抽取什么、输出哪些字段、遵循哪些约束、以什么格式呈现，都可以按领域定制，不需要修改引擎代码。企业终于可以把领域知识沉淀成模板，而不是把领域逻辑硬编码进系统。
• Retrieval Harness 体系： 1.0 的 Retrieval Harness 实力如何？在严苛的 FRAMES Benchmark（难度远高于 HotpotQA 等经典多跳数据集，平均每个问题需从 2200 多篇文章中综合 3-4 篇才能得到最终答案）上，仅采用 MiniMax-M3 就达到了 0.91 的准确率。1.0 的 Harness 提供可配置的工具集、步数上限、时间预算、并行策略与证据闸门行为。默认行为面向通用场景；企业可以按语料特点调整工具暴露策略与闸门策略。1.0 同时提供决策模型作为证据闸门的可选项：在没有编译产物时，它可以大大降低 Token 消耗；在有编译产物时，它可以大大加速 Agent 响应速度。换句话说，无论企业是否已经完成知识编译，1.0 都能带来可测量的成本或延迟收益。

• 从 Python 版本迁移： 1.0 的 API 与 Python 版本保持兼容，可从 0.27.x 版本无缝升级，配套的数据模型迁移，在容器启动时自动完成。

05

生态与路线图

RAGFlow 1.0 已开源，编译层、工具层、Harness 持续开放。接下来的路线集中在四个方向：

• 扩展知识编译输入形态： 除了文档，还会覆盖更多企业数据形态——日志、会话、记忆、数据库，让供给层能接入更广泛的知识源。供给层的价值，取决于它能供给多少种上下文；输入形态越丰富，Harness 能调用的知识就越完整。
• 深化与外部 Harness 框架的集成： 提供更稳定的工具接口、更清晰的证据格式、更完整的集成示例，让外部 Harness 可以更低成本地消费 RAGFlow 的供给能力。RAGFlow 不做唯一的 Harness，而是做任何 Harness 都能调用的供给层。
• 推动可复用工程标准： 导航树证据链、本体模板、Memory 模板不应是私有架构，而应成为可复用的工程标准——有明确的格式、血缘规则、审计要求，让不同系统之间可以交换编译产物。这是供给层从“一个产品”走向“一套基础设施”的关键一步。
• 社区模板与领域模板共建： 知识编译的模板体系需要领域知识：法律、医疗、金融、制造，每个领域都有自己的实体类型、关系约束、证据要求。RAGFlow 会持续完善内置模板，也欢迎社区贡献领域模板。

我们邀请开发者参与：试用 1.0、提 issue、贡献模板、参与 benchmark。基础设施产品的成熟，离不开真实场景的反馈。

06

1.0 是一个起点，不是终点

RAG 的十字路口，不是“要不要检索”的十字路口，而是“检索如何被编排、上下文如何被供给”的十字路口。

RAGFlow 1.0 的选择是：用 Go 把 Infra 做稳，用 Agent Native Database 把供给层独立出来。Search Harness 负责找到，知识编译负责省着用。编译一次，多次受益——这是 Agentic 时代上下文基础设施的起点。

1.0 不是终点。它是一次底座重写，一次定位升级，也是一次对“上下文即基础设施”的工程化回答。接下来，RAGFlow 会继续扩展编译形态、深化 Harness 集成、推动工程标准，让这套供给层真正成为 Agent 时代可长期运行的基础设施。

RAG 的时代没有结束，它只是需要一次重写。RAGFlow 1.0，就是这次重写的开始。

欢迎持续关注 RAGFlow 的演进，并前往 GitHub 点亮 Star，与全球开发者一同，见证并参与构建下一代企业 AI 的基础设施。

【参考文献】

1. Is Grep All You Need? How Agent Harnesses Reshape Agentic Search. arXiv:2605.15184
2. Context as Infrastructure: Knowledge Compilation for Retrieval in Agentic Systems with Harnesses. arXiv:2610.41172

文章来自于"InfiniFlow"，作者 "InfiniFlow"。