别再优化 RAG 了，适配 Agent 的 LLM Wiki 知识库理念

前言：Agent 研发必走知识库误区

2026 年再提 RAG 知识库，风向已经变了。用 RAG 搭建 Agent 知识库，开始被很多开发者嫌弃，Agent 工程已经进入上下文精细化管理阶段。

Agent RAG 知识库概念刚兴起时，很多团队和领导很容易沉迷于把公司里又臭又长的祖先文档全部丢进知识库，期待 Agent 通过 RAG 检索使其焕发生机，或者以为将现有内部文档一股脑塞给 RAG，就能迅速理解内部问题，减轻工程师的负担。

传统 RAG 并不适合直接做 Agent 的核心知识外挂。这显而易见。

Agent 即便需要知识库，也是需要一个高度语义化的知识库，而不是像 RAG 这类检索知识库。

Agent 的很多技术适用性仍在探索阶段，当然无法覆盖所有业务场景。但足以给出简单的结论：

1. 无论企业还是个人，文档里真正高价值只占很小一部分。低价值资料不会因为被交给 LLM 就变成高价值。
2. 强大知识库 + 万能 Agent 的组合很诱人，但通过上下文让 LLM 理解新知识非常讲究技巧，RAG 检索相比执行显得过于粗糙。
3. 头部 LLM 对通用知识的理解已经足够广、足够深。如果一个 Agent 产品总是需要“接入新知识”才能成立，说明使用场景和产品边界还没有想清楚。
4. Agent 中大量知识依赖的场景一定是小众需求。
5. 把依赖大量外部知识、优化 RAG 检索作为增强 Agent 能力的方向，在效率、体验和性价比上都非常低，除非强相关场景，一般不建议投入过多资源。

面向 Agent 的知识库技术方案演进

RAG 知识库技术经历了从物理切片、语义切片、网状图谱等演进。在最近 Karpathy 提出的 LLM Wiki，又提供了一条与传统 RAG 不同的路径：让 AI 提前阅读和整理资料，持续维护一个结构化、互相链接的 Markdown 知识库。

本篇主要探讨 Agent 场景下 RAG 知识库的演变，以及当下开始慢慢进入 Agent 工程视野的 LLM Wiki 理念。

大纲

• 传统 RAG：固定切片与一维检索
• 高级语义 RAG：Late Chunking 与父子块解耦
• Graph RAG：图增强的网状知识组织与推理
• 【重点】RAG 的上限：找到材料而非理解知识
• LLM Wiki：从无状态检索到有状态 LLM 连续编译
• Karpathy 的 LLM Wiki 三层设计
• LLM Wiki 搭建个人知识库
• LLM Wiki 搭建企业级 Agent 知识库
• LLM Wiki 适合哪些场景
• LLM Wiki 的局限性
• 面向 Agent 的知识库技术横向对比
• 生产级落地：分层 Hybrid 架构
• 总结思考1，为什么单一的 RAG 不适用于 Agent？
• 总结思考2，如何技术选型？

传统 RAG：固定切片与一维检索

无状态的“粗筛与硬拼接”。系统将长文档机械地按照固定字符或 Token 长度切分为物理块（Chunks），通过 Embedding 模型映射至高维几何空间，再利用向量相似度进行近邻检索。

核心机制

• 滑动窗口（Sliding Window） ：在固定大小切片的基础上，允许相邻文本块之间存在重叠（Overlap，通常为 10%~20%），用以缓解跨边界语义被切断的问题。
• 相似度计算：利用余弦相似度等几何度量，对用户 Query 向量与库中 Chunk 向量进行匹配。

局限性与 Agent 痛点

• 信息断裂与代词指代不明：机械切片极易将完整的因果关系或上下文实体剥离，导致 Agent 召回的内容充斥着“它”“该公司”等缺乏指代主语的噪声。
• 跨文档语义孤立：Embedding 模型在编码时呈“单兵作战”状态。文档 A 与文档 B 之间错综复杂的引用、对比和演进关系，无法在空间几何点中得到表达。
• 机械拼凑引发幻觉：召回阶段仅将 Top-K 个孤立切片通过换行符生硬拼接，破坏了自然语言的逻辑网。Agent 面对相互冲突或具有时序演进的碎片时，极易产生逻辑混乱。

高级语义 RAG：Late Chunking 与父子块解耦

为了在不改变向量检索架构的前提下，尽量保留单篇文档内部的语义完备性，RAG 开始引入前置增强与结构解耦方案。

常见改法主要有几类：

• 父子块（Parent-Child Documents） ：用小 Chunk 做检索，命中后还原更大的父块，避免上下文过碎。
• 语义切片（Semantic Chunking） ：按语义边界切分，而不是固定长度硬切。
• Late Chunking：先让长文档整体编码，再切片，让每个 Chunk 带上更多全局上下文。
• Contextual Retrieval：入库前用轻量 LLM 给 Chunk 补充背景说明，例如所属章节、指代对象和上下文位置。

局限性与 Agent 痛点

这些方案明显改善了单篇文档内部的检索质量，但整体架构仍然围绕 Chunk 展开。它们能够缓解切片造成的语义损失，但没有真正解决跨文档知识关系和长期知识积累的问题。

Graph RAG：图增强的网状知识组织与推理

针对多文档之间交叉知识孤立的物理限制，Graph RAG 将知识组织从无结构文本检索推进到结构化知识推理。

Graph RAG 将知识的组织形式从一维物理点扩展为网状拓扑图。它在入库阶段将大模型能力前置，把整库文档重构为实体（Nodes）与关系（Edges）组成的网状逻辑体。

核心机制

• 实体关系抽取：用 LLM 批量阅读文档，提取实体和关系。
• 社区发现与群组摘要：对图结构做聚类，再为知识社区生成宏观摘要。
• 混合检索：全局问题查社区摘要，局部问题沿实体关系和向量结果扩展上下文。

局限性与 Agent 痛点

• 写放大与高昂建库成本：在入库（Ingestion）阶段，需要调用 LLM 进行大规模的抽取和摘要生成，Token 消耗和写入延迟都很高。
• 错误固化（Error Compounding） ：如果离线抽取阶段 LLM 对关系的理解产生幻觉，错误关系会被固化进图谱，导致后续检索持续受污染。

Graph RAG 擅长表达显式实体关系和跨文档路径，但图谱本身仍然是一次抽取后的中间表示。它可以帮助 Agent 沿关系查找知识，却不会自然地把每次阅读、问答和综合结果持续整理成可直接阅读、修改和审查的知识页面。

【重点】RAG 的上限：找到材料而非理解知识

把前面几种方案放在一起看，会发现一条很清楚的主线：从固定切片，到语义切片、父子块、Late Chunking、Contextual Retrieval，再到 Graph RAG，工程形态越来越复杂，但基本在一个方向优化：

如何从外部知识库中找出可能相关的材料，再塞给 LLM。

它主要解决的是知识选择问题，不是知识形成问题。

在简单事实型问答、长尾资料、低频文档查询里，RAG 仍然很实用。但把它上升成 Agent 的核心知识外挂，就会水土不服：Agent 调知识库时，需要的是一段能直接进入当前任务的语义上下文，而不是几段看起来相似的文本。

Agent 需要的上下文应该像一个懂业务的人临时补充给你的材料：它知道问题背后的场景，知道哪些资料真的相关，也知道哪些旧结论、隐含前提和冲突信息会影响当前判断。普通 RAG 给出的往往不是这种上下文，而是一组被算法挑出来的材料片段。

上下文需要的是高质量、高精度的语义化提示词，而不是一堆浆糊。

前面几类方案的共同问题可以压缩成三层：

• 传统 RAG 把知识库当搜索引擎。它能定位材料，但不会把材料读成知识。
• 语义化 RAG 让召回更聪明，但仍然是在查询时临时找材料。复杂度继续堆在切块、召回、排序、上下文长度和问题改写上。
• Graph RAG 进入了关系层，适合跨文档关系和全局总结，但图结构、向量、元数据和社区摘要，本质上还是在解决“怎么更好地选择材料”。

这就是 RAG 路线的上限：它一直试图用检索算法弥补知识没有被真正理解和组织的问题。 关系图谱再复杂，也不能完整承载语义整合。

Agent 真正需要的是被整理过的知识

Agent 上下文中，有价值的知识，往往来自几篇文档共同指向的结论、会议纪要里的分歧、旧系统文档里的约束、事故记录里的隐性经验，以及这些材料之间的取舍关系。

它需要先被阅读、解释、压缩、关联和修订，然后才适合进入 Agent 的上下文。

多知识源会继续放大这个问题。资料会新增、过期、互相矛盾；旧结论要更新，新资料要合并，冲突要标记，一次问答里总结出的关系也可能值得沉淀。这些已经不是单纯的检索问题，而是知识管理问题。

知识本身需要被提前组织、解释、压缩、关联和持续修订。

这也是为什么我认为 LLM Wiki 值得单独讨论。它把注意力从“如何检索 Chunk”挪开，把知识库基本单位从待召回的碎片，变成可阅读、可链接、可修改、可演化的 Wiki 页面。目前看，这将是 Agent 知识库未来的有效解法。

LLM Wiki：从无状态检索到有状态 LLM 连续编译

LLM Wiki 的核心理念可以概括为：提前编译知识，减少每次提问时临时搜索chunk。

它将多篇原始文档视为“源码（Raw Sources）”，利用 LLM 将资料持续编译为一套高度结构化、互相双向链接（Backlinks）的 Markdown 知识网络。系统由无状态检索转向有状态知识维护，知识库会随着新资料持续演化。

当你新增一篇文章、一本书摘、一份 PDF 或一段会议记录时，LLM 会主动阅读、提取关键概念、创建或更新页面、补充链接、标记冲突，并记录本次改动。

这样，知识库会随着资料增加不断变厚。连接关系和综合工作已经提前完成，之后再提问时，AI 面对的是一个组织过的知识系统，不需要临时拼接原始资料片段。

根本原则只有一个：Agent 需要的是经过理解和整理的知识，这个环节原本以人脑为核心，而不是纯工程技术；如果要自动化，核心只能落到 LLM 上。思考方向应该是如何用 LLM 替代人脑，而不是设计复杂工程技术去替代。

Karpathy 的 LLM Wiki 三层设计

以 Karpathy 提出的 LLM Wiki 设计为例，可以拆成三个简单层次：raw、wiki 和 schema。

1. Raw：原始资料层

这里放 PDF、网页文章、会议记录、文本文件、Markdown 等原始文件。它们是 source of truth，AI 可以读取，但不应该修改。这样可以保证原始材料始终存在，后续如果 Wiki 内容有问题，还能回到原始资料核对。

2. Wiki：AI 生成和维护的知识库

这里是一组 Markdown 文件，包括首页、索引页、概念页、实体页、主题总结页、对比页等。页面之间通过链接连接起来，形成一个人可以理解和修改的知识网络。

3. Schema：知识库规则文件

例如 Claude Code 中的 CLAUDE.md。它告诉 LLM：

• 这个知识库的目的是什么。
• 目录结构是什么。
• 怎样处理新增资料。
• 页面应该怎样格式化。
• 回答问题时应该先看哪里。
• 如何引用来源。
• 遇到不确定信息时如何处理。

这也构成了 LLM Wiki 的核心架构：Sources → Wiki → Schema。新文档输入时，LLM 作为知识记账员（Bookkeeper），通读新资料，并直接重写、合并或修正已有 Wiki 页面。

在检索阶段，系统可以放弃完全依赖几何向量匹配，改用模型自导航检索（Index-Driven Navigation）：先把 Wiki 页面提炼出的轻量级 Index 提供给长上下文 Agent，再由 Agent 通过语言逻辑推理，自主生成导航路径，读取确切的 Wiki 页面或文本块。

LLM Wiki 搭建个人知识库

如果只是个人使用，LLM Wiki 的搭建并不复杂，甚至可以说异常简单。现在比较流行的做法，是用 Obsidian（一个 Markdown 渲染器）管理本地 Markdown 文件，再让 Claude Code、Codex、Cursor 这类本地 Agent 负责读写文件、整理资料、生成 Wiki 页面和维护链接。

一个最小结构通常就够了：

wiki-project/
  raw/       # 原始资料，只读
  wiki/      # AI 整理后的知识页面
  AGENTS.md  # 或 CLAUDE.md，定义整理规则

新增资料时，把原始文档放进 raw，再让 Agent 阅读、归纳、拆分页面、建立链接、更新已有页面。Obsidian 只是浏览和管理层，本质上这仍然是一组 Markdown 文件。

网上教程很多，也可以直接下载 LLM Wiki 的 skill 接管全程，异常简单。

但是除非你是跟大量知识打交道的人，所谓个人知识库对于绝大多数人实际价值不大（也不是完全没价值，起码能得到一张漂亮的知识图，提供情绪价值）。

LLM Wiki 搭建企业级 Agent 知识库

企业级的 Agent 更能撑起 LLM Wiki 实际价值，但如果你想要寻找一些通用框架或最佳实践设计，可能要失望了。LLM Wiki 更像一个设计理念，而不是一个必须引入的标准框架。

到目前为止，它并没有像 GraphRAG 那样形成比较统一的工程实现。原因也很简单：它的核心原理并不复杂，让知识在写入阶段先被读懂、整理和维护，而且具有很强的业务属性。

这反而给 Agent 开发留出了空间。很多 Agent 并不需要一个通用、复杂、抽象程度很高的 LLM Wiki 系统。更实际的做法，是根据当前项目的知识形态，从头设计一个足够小的知识层：

• 如果 Agent 依赖 SOP，就把知识库设计成任务流程、规则边界、异常处理和案例页面。
• 如果 Agent 依赖产品知识，就把知识库设计成产品模块、功能限制、接口约定、用户场景和变更记录。
• 如果 Agent 依赖研究资料，就把知识库设计成主题页、论文页、概念页、证据页和争议页。
• 如果 Agent 依赖项目上下文，就把知识库设计成架构说明、核心决策、目录边界、已知问题和当前状态。

也就是说，不要上来就调研有哪些 LLM Wiki 框架可接入，要先思考：

这个 Agent 到底需要长期记住什么？这些知识应该被组织成什么页面？什么时候更新？由谁校验？

一旦这个问题想清楚，实现可以很轻。完全可以让 Codex Vibe Coding 根据当前项目的真实需求创建目录结构、页面模板、更新规则和检查脚本。比如只保留 sources/、wiki/、index.md、AGENTS.md 四个核心部分，再约定新增资料时如何归档、如何更新页面、如何标注来源、如何处理冲突、如何周期性检查过期内容。

然后再根据实际的 LLM Wiki 结构设计一套检索流程，通常可以设计一个独立检索 Agent，与当前 LLM Wiki 深度绑定，作为子 Agent 在主流程中调用。

不应该一开始就追求“大而全”，是当下 Agent 开发最基本的原则。

LLM Wiki 适合哪些场景

LLM Wiki 不是万能知识库方案，它更适合那些知识价值高、主题长期稳定、需要反复复用、并且会持续修订的场景。

典型场景包括长期研究主题、课程资料、核心 SOP、关键政策、客户访谈、产品决策、项目复盘和专家经验。对于 Agent 来说，LLM Wiki 最适合作为核心知识层，承载任务流程、领域规则、产品边界、关键决策和高价值专家知识。

至于海量低频资料、历史日志、聊天记录和归档文档，仍然更适合交给普通 RAG 或搜索系统兜底，不该全部塞进 LLM Wiki。

LLM Wiki 的局限性

LLM Wiki 仍然有明确的适用边界。

1. 规模墙限制（Scale Wall）

它更适合小规模高价值资料。Karpathy 提到的规模大概是 100 篇文章级别。如果要管理几万页资料，仅靠 Markdown 文件、本地文件夹和长上下文 Agent 是不够的，需要更复杂的基础设施。

如果出现海量文档还需要接入 LLM Wiki 的场景，我觉得你的产品设计一定有问题

2. 编译吞吐量低

每增加一个数据源，都可能触发复杂的 LLM 链式重写，存在明显的写放大，不适合高频实时写入。核心知识更像定时集中整理，一次花费大量 Token，换取 Agent 检索精度。如果需要高频写入，肯定不是这个场景。

3. 输入质量决定输出质量

如果输入资料本身低质量、过时或混乱，Wiki 也会受到影响。小规模高价值知识，一定是面向 Agent 整理过的，而不是原始的人类文档。其实也很简单，因为量级不高，直接让 Codex 先筛选整理一下。

4. AI 会出错

AI 可能错误分类、错误连接概念，或者遗漏重要信息，所以仍然需要人工检查，尤其是在知识库建立早期。Lint Wiki、一致性校验、引用检查和原始资料只读机制，都是为了降低这类问题。

因为编译后的 Wiki 仍然是人类可读的，人类可以适当参与，简单纠正。

面向 Agent 的知识库技术横向对比

特性维度	传统 Vector RAG	高级语义 RAG（Late/Parent-Child）	Graph RAG 流派	编译型 LLM Wiki
底层数学或逻辑依托	高维向量空间几何距离	深度 Attention 融合与结构解耦	图拓扑网络与社区聚类算法	语言逻辑导航与结构化 Markdown
跨文档交叉语义支持	极差，文档相互孤立	较差，依然受限在单篇物理边界内	极强，显式逻辑连线构建知识网	极强，LLM 离线去重、合并与双向链接
消除代词与边界噪声	弱，极易语义断裂	强，通过上下文注入与父块还原	中，依赖三元组提取精度	极强，在编译阶段由 LLM 消除和重写
建库计算开销（写）	极低，仅需 Embedding 编码	较低，轻量 LLM 辅助打标或长文本编码	极高，需要大量 LLM Token 离线提炼	高，增量写入时存在显著写放大
检索确定性（读）	弱，依赖 Top-K 匹配质量	中，细节召回率明显提升	强，可以沿因果链路追踪	强，基于索引和页面结构进行逻辑路由
最适配的 Agent 场景	简单 QA 问答、长尾不活跃数据	结构独立、规则明确的技术或法律手册	关系审计、多主体对比与复杂推理	核心 SOP 固化、高价值领域专家知识库

生产级落地：分层 Hybrid 架构

分层 Hybrid 架构的意思是，按数据价值、规模和查询方式拆层，而不是指望单一流派同时兼顾海量规模、写入效率、细节召回和跨文档关系。

1. 核心骨干层：采用 LLM Wiki

   将数量可控、价值较高的核心业务 SOP、关键政策、公司全局实体定义和专家知识，交由 LLM 编译为有状态 Wiki，作为 Agent 决策的核心记忆层。

2. 关系图谱层：采用 Graph RAG

   将多项目、多财报以及存在强因果关联的文档组织成知识图谱，承载复杂的网状跨文档推理任务。

3. 海量存储层：采用高级 Vector RAG

   使用 Late Chunking、父子块和 Contextual Retrieval 等技术，承载数以亿计的长尾历史日志、历史谈话记录和低频资料。需要细节时，再由 Agent 发起向量检索。

这几种技术解决的是不同层级的问题：Vector RAG 负责低频资料召回，Graph RAG 负责关系路径，LLM Wiki 负责高价值知识的持续编译和复用。

总结思考1，为什么单一的 RAG 不适用于 Agent？

单一 RAG 不适合做 Agent 的核心知识库，是因为它和 Agent 对知识的要求天然错位。

LLM 本身已经有足够广和深的通用知识。Agent 真正需要外挂知识库，通常只有两类情况：领域深度知识，或者模型训练中不存在的内部知识。这两类基本都要求知识足够精准。

这就形成了矛盾：RAG 擅长在海量知识做向量召回，但 Agent 真正需要的是高精度、可执行的语义上下文。 对于 Agent 来说知识真正有价值，往往就应该小而精；如果量特别大，通常意味着里面混入了大量低价值的内容，或者是一个独特的小场景

所以 RAG 的上限很明显：它能找到可能相关的材料，但很难保证材料足够完整、准确、无冲突，并且符合当前任务边界。相似度召回不是理解。更合理的分工是：RAG 做长尾兜底，LLM Wiki 或显式上下文管理承载核心知识。

总结思考2，如何技术选型？

听起来 Hybrid 架构不就是知识库的终极方案吗？什么都有，什么都兼顾。

混合架构听起来很美好，理论很全面，但作为业务负责人或者技术负责人，我仍然认为这种方案多数场景同样不适用，或者说过于复杂和冗余了，所有技术全都兼顾，其实基本就等于你对你 Agent 的设计和开发是没有方向的。

我前面提到，Agent 中要依赖大量知识一定是小众场景。同时需要三种技术做混合架构，一定是更加小众的场景。多数 Agent 架构中，知识库本身就不应该占太大比重，一定要从简开始。

所以我认为通常设计一个简单的 LLM Wiki 就够了，或者直接接入一个 RAG 检索，聊胜于无。

原创声明

原创文章，转载请注明作者和文章原链接，插图来源 AI 生成，关注公众号看更多文章哦！

内容创作 AI 自律声明