过去两年，几乎每家企业都在用 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 协同的前提，也是企业审计的前提。
- 可审计：每条证据可追溯，每轮成本可归因：每条真正进入模型的证据都有记录：命中了哪些词、是否被截断、原文多大。这不是日志冗余，而是基础设施产品的基本要求——出问题时，要能定位。
这些设计背后是同一个