Harness 已经很准了，为什么还需要一个 Agent Native Database - 任九赛前分析

RAG 正面临关键转折点 

检索增强生成（RAG）在过去两年间几乎成为大语言模型在企业知识场景落地的“标准配置”。它通过结合外部知识库的检索与生成模型，显著增强了生成内容的时效性和准确性，并大幅降低了幻觉率。这一逻辑听起来完美无缺：模型遇到不懂的内容就即时查询，查询后再给出回应。

然而，现实远比逻辑要复杂得多。

当大量企业真正将 RAG 部署到生产环境后，一个令人沮丧的共识逐渐浮现：RAG 表现不错，但还远未达到理想状态。 基础 RAG——那种“将文档切割成块、进行向量化处理、然后计算相似度”的标准流程——在实际场景中频繁出错。分块策略如何确定？选用哪个 Embedding 模型？相似度阈值设定为多少？每个环节都需要大量参数调整，即使调整完毕也无法保证检索质量。检索到的文本块与答案不相关，干扰项混入上下文后反而扰乱了 LLM 的推理过程。

因此，高级 RAG 应运而生，例如 RAGFlow 的 DeepDoc 解析 PDF、各类高级 Chunker、Hybrid Search、GraphRAG 的知识图谱增强、RAPTOR 的递归摘要树、Contextual Retrieval 的上下文感知分块……技术栈变得越来越复杂，架构图也越来越美观，但效果的提升并未与复杂度的增加相匹配。复杂度无法换来效果。

到了 2026 年，两个关键事件将这场讨论推向了新的高度。

第一个事件：Andrej Karpathy 提出了“LLM Wiki”概念。他主张将原始笔记视为源材料，利用 LLM 将其编译成一份持续更新、带有明确引用、可逐字阅读的 Wiki——不是每次提问时临时拼凑几个相似片段，而是“知识被编译一次，然后保持更新，而不是在每个查询上重新推导”。这个想法迅速从个人知识管理领域扩展到企业 RAG 领域，引发了对传统 RAG 范式的普遍质疑。

第二个事件：PwC US 的研究报告以颇具挑衅性的标题发问——“Is Grep All You Need?” 研究人员为 Agent 同时配备了向量搜索和 Grep，结果发现 Grep（精确字符串匹配）常常比语义搜索提供更高的准确率。进一步的对比实验表明，仅使用字符串匹配实现的 Agentic RAG，其质量已经与 LLM-Compiled Wiki 非常接近。

这两个事件共同指向一个结论：传统 RAG 的“查询→匹配→排序”范式正在被颠覆。检索的核心正在从“设计一个更强的召回算法”，转向“设计一套能在多工具之间动态编排的决策框架”。搜索不再是引擎，而是 Harness（驾驭框架）。

但 Harness + Grep 虽然构成了一个极强的 Baseline，却并非终点。当数据规模扩大时，完全依赖 Harness 的迭代探索和 Grep 的精确匹配，会导致 Agent 需要反复搜索才能找到答案区域——Token 消耗高、响应速度慢，且每一次新的上下文窗口都要重新经历一遍探索过程。

这正是知识编译的入场时机。本文的核心主张是：Search Harness 是 Agentic Search 的引擎；知识编译是它的上下文供给层。 知识编译不是要取代 Search/Grep，而是为 Harness 提供更丰富、更压缩、更可追溯的知识工件，让 Agent 以更少的迭代次数、更低的 Token 消耗精准定位答案。

RAG 面临的四重困境 

要理解知识编译的价值，首先得看清 RAG 今天面临的真实困境。这些困境不是某个产品的缺陷，而是整个范式层面的结构性问题。

困境一：基础 RAG——“检索不准确”是必然结果 

基础 RAG 的本质是“查询→嵌入→相似度排序”这一单一通路。面对原始文档，相似度几乎是唯一的入口。但问题是：相似不等于相关，相关不等于正确。

一个精确的日期查询（比如“2025 年 Q3 的营收是多少？”），用向量搜索只会引入大量语义相近但毫不相关的噪音。一个模糊的概念性问题（比如“什么是微服务架构的核心思想？”），用 Grep 根本找不到相关段落——因为没有人会在文档里写下那句与你查询一模一样的句子。有时答案不在某一个文档块里，而是需要先定位一批候选文档，再逐个深入精读。

单一通路无法覆盖多样化的查询类型。这是基础 RAG 的结构性缺陷，不是靠调参能解决的。

困境二：高级 RAG——“复杂度换不来效果” 

高级 RAG 试图通过引入更复杂的架构来解决上述问题。GraphRAG 用知识图谱增强检索，RAPTOR 用递归摘要树组织文档，Contextual Retrieval 用上下文感知的分块策略……每一个方案都有自己的论文、自己的 Benchmark、自己的拥趸。

但问题在于：这些方案的部署和维护成本急剧上升，效果提升却远未达到预期。 GraphRAG 将碎片化的图状结构作为检索的主来源，在消耗了大量 Token 之后，并未带来检索效果上的根本提升——仅在部分多跳问答场景下有所改善。更糟糕的是，这些复杂方案往往让系统变得难以解释、难以调试、难以维护。

一个需要专家才能调优的 RAG 系统，在真实的企业生产环境中是站不住脚的。

困境三：Agent Harness + Grep 的挑战 

PwC 的研究发现，当 Agent 同时配备向量搜索和 Grep 时，Grep 常常比语义搜索提供更高的准确率。这一发现迅速在行业内被简化为一个颇具挑衅性的结论：“Grep 取代 RAG”。

但与 Vector RAG 的对比实验表明，单纯依靠 Grep 并不能在所有场景下都优于 RAG。更准确的结论应该是：一个设计良好的 Agent Harness，即使只配备 Grep 这类简单工具，也能在很多场景下达到接近甚至超越复杂 RAG 的效果。 这恰恰对“RAG 必须依赖复杂检索架构”这一假设构成了根本性挑战。

不过，Harness + Grep 虽然构成了一个极强的 Baseline，却并非终点。 当数据规模扩大时，完全依靠 Harness 的迭代探索和 Grep 的精确匹配，会导致 Agent 需要反复搜索才能找到答案区域——迭代次数线性增长，Token 消耗指数上升。这正是知识编译需要补位的地方。

困境四：RAG 的“冷启动”问题——最深层的问题 

这是最深层的问题，也是 Karpathy 的“LLM Wiki”概念精准击中的痛点。

传统 RAG 的工作方式是每次查询从零开始。用户提出问题，系统向量化问题，在向量库中检索相似文档块，将检索结果拼入 Prompt，LLM 生成答案——然后一切归零。下一次查询，同样的流程再来一遍。没有积累，没有状态，没有一个可以持续演进的认知基座。

每一次查询都是一次“冷启动”。每一次，系统都要重新“理解”知识库里有什么、文档之间是什么关系、哪些来源是权威的。同样的任务对着同样的数据跑两遍，Agent 可能返回不同的答案，而且没有任何记录说明两次结果的差异来自哪里。

Pinecone 的估算指出，Agent 有 85% 的计算精力消耗在了“重新发现”的循环上，而非真正的任务完成。这不是 RAG 的 bug，这是 RAG 的范式缺陷。知识编译正是对这一缺陷的系统性回应：将部分“理解”工作从查询时移到索引时，让 Search Harness 不必每次从零开始。

Grep 的崛起与 Harness 的边界 

第二章我们看到了 RAG 的四重困境，其中第三重尤为值得深思：一个简单的 Grep 工具，在 Agent 的编排下，竟然能达到接近甚至超越复杂 RAG 的效果。这一发现颠覆了行业对“检索必须依赖语义理解”的固有认知，但也引出了新的问题——Harness + Grep 的边界在哪里？本章将深入剖析 Grep 为何有效、Harness 扮演了什么角色、以及这套组合的局限性如何把我们引向知识编译。

3.1 Grep 为什么能打败 RAG？ 

“Is Grep All You Need?”这个问题的答案，远比表面看起来复杂。

PwC 的研究人员为 Agent 同时配备了向量搜索和 Grep，结果发现 Grep 常常比语义搜索提供更高的准确率。这一发现很容易被简化为“精确匹配就够了”——但真正的洞见在于论文最后的结论：检索并非简单地把知识返回给 Agent，重要的是框架——它决定了什么可以填充到上下文，以及在利用上下文之前 Agent 必须执行哪些操作。

换句话说，让 Grep 变得强大的不是工具本身，而是 Agent 如何编排它。

这使我们不得不区分两类根本不同的问题：

• 语义发现问题：答案隐藏在概念层面，需要理解语义才能找到

• 证据定位问题：答案存在于字面证据——名称、日期、文件路径、函数名、错误字符串

对于 Coding Agent 而言，大量工作恰恰属于证据定位：查找符号、追踪调用链、检查差异、阅读失败的测试用例、定位确切代码行。在这种情况下，一个精确字符串匹配工具远比语义搜索直接有效。

值得注意的是，Agent 使用 Grep 的方式与人类完全不同。OpenAI 对 GPT-5 在 BrowseComp-Plus 数据集上的搜索行为分析显示：98% 的会话中使用引号搜索（远高于人类用户），且查询长度中位数超过人类 99th 百分位。AI 在使用精确匹配时比人类更“精确”、更“结构化”——它能一次性构造出人类不太可能输入的、带多个约束的复杂查询。Grep 本身没有变，但它的用户从人类变成了 Agent，使用方式发生了质变。

3.2 Harness + Grep 的局限：探索代价与 Token 成本 

但 Harness + Grep 虽然构成了一个极强的 Baseline，却并非终点。 原因在于：

当数据规模扩大时，完全依靠 Harness 的迭代探索和 Grep 的精确匹配，会大大增加 Harness 重复迭代探索的代价。Agent 需要反复 Grep 才能找到答案区域，导致两个严重后果：

1. 慢：每一次 Grep 都是一次 IO 操作，迭代次数线性增长导致响应时间急剧上升

2. Token 消耗高：每一次迭代都将搜索结果载入上下文，多轮迭代的 Token 累积是巨大的

面对每一个新的上下文窗口，以 Harness 为中心的 Agentic 检索都会浪费调用次数，一遍又一遍地重新学习什么是有效的搜索策略。这既昂贵又缓慢。

因此，一个自然的问题浮现出来：如何在保留 Harness 编排能力的同时，缩短它的探索路径？

3.3 更丰富的工具体系：微软 AgenticRAG 的启示 

微软在企业级 AgenticRAG（又称 Agentic Harness for Retrieval）中的设计给出了一个清晰的方向：为 Harness 配备更丰富的工具，而非仅仅依赖 Grep。

其核心架构是为企业内部数据搜索配备一个轻量级 Agent，通过迭代式搜索显著超越单次检索的结果。该架构每次迭代主要依赖三类工具：

SEARCH 负责召回，FIND 和 OPEN 负责精读——这套工具组合将搜索行为提升为 Agent 可编排的原子操作。

微软报告其在 BRIGHT、WixQA、FinanceBench 上均取得显著提升，消融研究表明最大提升来自“从单次检索转向 Agentic 工具使用”。这印证了一个判断：Harness 不应只有 Grep 一把锤子。 SEARCH（广域召回）、FIND（精确定位）、OPEN（深度阅读）三种工具的分工，让 Agent 可以在不同层次上操作——先用 SEARCH 缩小范围，再用 FIND 精准定位，最后用 OPEN 获取完整上下文。

而进一步的研究表明，BM25 + Grep 的组合就可以让 Harness 表现更好——BM25 在单次检索中表现较弱，但在 Agent Loop 内部却强得多。这意味着我们不需要复杂的 Embedding 模型和向量数据库，仅靠词汇层面的检索工具组合，就能为 Harness 提供足够强的检索能力。

3.4 检索即 Harness：从工具到编排框架 

基于以上分析，我们可以得出一个核心结论：Retrieval 本身就是一个 Harness 问题。

它不仅仅是“给 Agent 提供什么工具”，而是包含以下设计维度：

• 查询如何被鼓励或约束
• 结果应当如何被呈现
• 搜索返回结果是否包含足够的上下文
• 模型是否可以发出后续搜索
• Agent 何时决定它有足够的信息来回答
• Harness 如何在不同工具之间做路由和编排

换句话说，搜索不再是引擎，而是一套编排框架。 一个设计良好的 Retrieval Harness，即使只配备 BM25 和 Grep 这样的“简单”工具，也能通过迭代式编排，在大量场景下达到接近甚至超越复杂 RAG 的效果。

但如前所述，我们不能止步于此。当数据规模进一步扩大时，即使是最优的 Harness 编排，也会面临迭代次数和 Token 消耗的挑战。这就引出了下一章的主题：如何通过知识编译层，为 Harness 提供更“高质量”的工具——让每一次工具调用都能覆盖更高质量的上下文，从而减少迭代次数、降低 Token 消耗。

知识编译：为 Harness 提供“高密度上下文” 

第三章我们论述了 Retrieval Harness 的价值与局限：它通过编排让简单工具（BM25、Grep）发挥出惊人的效果，但在大规模数据下仍然面临探索成本过高的问题。

知识编译从另一个角度给出了答案：把知识编译的工作从查询时移到索引时。

“不是每次提问时临时拼凑几个相似片段，而是知识被编译一次，然后保持更新，而不是在每个查询上重新推导。”

这个想法迅速从个人知识管理溢出到企业 RAG 领域。向量数据库领域的先驱 Pinecone 在 2026 年发布的 Nexus 知识引擎中，引入了 Context Compiler 的概念——通过内置的 Skills（文档处理、实体抽取、文本分块等基础“函数”）自动完成知识编译操作，将用户数据加工成结构化的 Artifacts。与传统 RAG 直接对原始文档建索引不同，这里的检索对象不再是未经处理的文本碎片，而是经过预编译、富含语义和实体关系的知识工件集合。

Pinecone 的内部基准测试显示，一个原本消耗 280 万 Token 的金融分析任务，在 Nexus 上仅用了 4000 个 Token 就完成了——降幅高达 98%。虽然这一数据尚未在客户生产环境中得到广泛验证，但它指出的方向是明确的：知识编译带来的 Token 效率提升是数量级的。

在 RAGFlow 的架构中，我们对“知识编译”的定义超越了 LLM Wiki 的单一模式。知识编译包含一系列对数据——特别是大规模数据——的语义增强操作。当前实现中，知识编译的落地形态包括树状导航结构（含证据链叶节点）、图状关联探索结构、时间线追踪结构，以及本体模板。证据链不是独立的一层，而是挂在树状导航叶节点上的压缩单元；本体也不是独立引擎，而是作为知识编译的模板存在。

4.1 树状导航结构：章节树与证据链叶节点 

为海量文档生成合适的层级标题，通过标题决定分块粒度，从而为海量数据的导航需求提供定位服务。典型场景包括：

• 单文档长文本：书籍、教材、产品手册、法律条文
• 多文档聚合：FAQ 库、政策文件集、分类文档库

树状结构让 Agent 可以像文件管理器一样“逐层展开”——从根目录到章节到小节再到具体段落——直到定位到答案所在的叶子节点。这种导航方式在用户意图不明确时尤为有效。

但在工程实践中我们也发现了一个重要事实：并非把文档组织成树状结构，就可以给 Agentic Search 带来显著收益。这跟行业很多其他类似开源项目实践得到的结论——例如仅依据文档的章节目录结构、或者通过层次化聚类形成的语义结构提供导航，就可以带来更好效果——截然相反。这些传统树状结构在设计良好的 Agent Harness 中，不仅没有带来增益，反而是负资产：Agent 仍然主要依赖 Search 和 Grep，真正让树状导航产生价值的是证据链叶节点。

当前 RAGFlow 的实现正是如此：证据链挂在树状导航的叶节点上。从原文中抽取 Claim 和 Evidence，形成