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 的四重困境，其中第三重尤为值得深思：一个简单的 Gre