知识库建设的目标用户群体有哪些

你的公司一定有过这样的经历：花了不少钱搭建知识库，NAS 网盘、企业云盘、Notion、语雀、Confluence，各种方案都试过。员工上传文档、整理分类、建立标签体系。半年后没人更新了，一年后搜索出来的内容已经过时，两年后它变成了数字坟场。

所有知识库都是这个宿命。

但从2025年开始，随着 Agent 的逐步广泛应用，知识库的使用者正在从人变成 Agent。 知识库的设计逻辑、维护方式、甚至存在的意义，都需要重新思考。

人是最慢的节点

在 Agent 时代，知识库给人"用"这件事本身，就是效率瓶颈。

围绕"人的使用习惯"设计知识库，你得到的是一个需要人来维护、人来检索、人来整理的系统。而人恰好是这个系统里最慢、最贵、最容易厌倦的环节。

整理文档需要人。分类、打标签、写摘要，全是人工。 检索信息需要人。你得知道关键词是什么，你得在搜索结果里一条一条翻。 更新维护需要人。旧文档过时了谁来改？新文档产生了谁来关联？跨文档的矛盾谁来发现？

维护负担的增长速度永远快于价值的增长速度。 每个公司的知识库最终变成数字坟场，维护成本是主因。

换一种思路：如果知识库的主要使用者是 AI Agent，那个 7x24 不休息、不会厌倦、一次能读 15 个文件、永远记得更新交叉引用的"员工"呢？

围绕 Agent 重新设计知识库

围绕 Agent 来设计知识库，逻辑完全不同：

组织方式： 给人用的是文件夹 标签 搜索框，给 Agent 用的是结构化 Markdown 交叉引用 索引。

维护者： 给人用的靠人维护（所以没人维护），给 Agent 用的由 Agent 维护（成本趋近于零）。

检索方式： 给人用的是关键词搜索、人翻结果，给 Agent 用的是索引定位 按需钻取。

更新频率： 给人用的是想起来才更新，给 Agent 用的是每次新资料进来自动更新。

知识形态： 给人用的是原始文档堆在一起，给 Agent 用的是预编译的结构化知识网络。

积累性： 给人用的是文档越来越多但没人整理，给 Agent 用的是每加入一份资料，整个知识库都变强。

你不需要直接操作知识库。你问 Agent 一个问题，它去知识库里查、去综合、去推理，把结论给你。查询、检索、更新、交叉引用，全部在背后完成。

人从繁琐的系统操作中解放出来，去做策展、判断、思考。这些是 Agent 做不了的。

那么，要让 Agent 更懂你、更智能，给它提供什么样的知识库？

知识库的三次进化

知识库技术正在经历第三次范式变迁。

第一代：传统智能知识库（2016-2022）。 以阿里云智能客服为典型代表。知识由人工分类、打标、归档，形成树状或标签体系，检索靠关键词匹配。问题是维护成本极高，灵活性差，一旦产品迭代或业务变更，知识库就迅速过时。而且，"按产品维度分类还是按问题场景分类"这类问题根本没有标准答案——简单的树状结构无法刻画知识间的网状关系。

第二代：RAG（2023-2024）。 大模型兴起后，RAG 成为主流。前置小模型检索 后置大模型生成，解决了海量知识的存储和召回。但小模型语义理解有限，每次交互独立检索不积累，知识无法沉淀。

第三代：Agent 时代（2025-）。 知识被大模型提前编译、结构化、关联好，形成持久可用的知识网络。代表性方案包括 LLM Wiki、GBrain 等。

这次变迁改变的是知识的存在形态：从存原材料，到存编译后的知识。

当前主流方案：RAG

RAG（Retrieval-Augmented Generation，检索增强生成）是目前绝大多数 Agent 系统的知识库方案。RAGFlow、Dify、FastGPT、Coze，几乎所有主流平台都内置了 RAG 知识库模块。

工作方式：

上传文档 → 切片（按段落/字数切成小块）→ 向量化入库用户提问 → 语义检索 关键词检索 → 重排序 → 返回最相关的片段给 Agent

RAG 让 Agent 能够参考外部知识回答问题，简单场景下够用。

但 RAG 有一个根本性的缺陷：它不积累。

你问一个问题，RAG 去检索相关片段，Agent 生成答案。你问一百个问题，每次都是同样的流程，从零开始检索，从零开始拼凑答案。RAG 库里永远是那些原始文档的切片，不会因为你的提问而变得更聪明。

三个结构性问题：

第一，没有交叉引用。 RAG 根据语义相似度去找文本块。文档 A 和文档 B 之间有矛盾吗？概念 X 在三个文档里分别被提到，综合起来意味着什么？这些关系没有被保存，每次查询时 Agent 需要临时发现、临时综合。对于复杂问题，回答质量不稳定。

第二，没有知识编译。 RAG 存储的是原始文档的切片——"原材料"。但人类专家的知识不是原材料的堆砌，而是经过综合、提炼、建立联系的结构化网络。RAG 缺的就是这一步"编译"。

第三，没有自我进化。 你用了一年，RAG 库还是那个样子。新文档加进来了，但旧的矛盾没有解决，过时的内容没有标记，缺失的交叉引用没有补上。知识库不会因为你用得越多就越好用。

RAG 是一个"只读"的知识库，被动等着被检索，从不主动进化。

让 Agent 自己维护知识库

2026 年初，Andrej Karpathy（前 Tesla AI 总监、OpenAI 联合创始人）提出了 LLM Wiki：让 LLM 增量构建和维护一个结构化的 wiki，一组互相链接的 Markdown 文件，位于你和原始资料之间。

原始资料（不可变）↓ Agent 阅读、提取、整合Wiki（结构化知识，持续维护）↓ 指导 Agent 行为Schema（组织约定和工作流定义）

当你加入一份新资料时，RAG 只是把它切片、向量化、丢进数据库。而 LLM Wiki 会：

阅读整份资料，提取关键信息 更新相关的概念页、实体页、摘要页 发现新信息与旧知识的矛盾，标记出来 建立新的交叉引用，强化知识网络 更新索引和日志，让后续检索更精准

一份新资料可能触达 10-15 个 wiki 页面。 整个知识网络被强化了一次。

Agent 需要的知识分两种。经验性知识是编码习惯、命名规范、"先跑通 Demo 再重构"这类隐性策略。事实性知识是概念定义、FAQ、技术文档这类客观信息。RAG 对两者都只能存原始切片，LLM Wiki 会把两者都"编译"：经验性知识被转化为可执行的策略步骤，事实性知识被组织成有交叉引用的结构化网络。

用 Karpathy 的话说：

RAG 是每次查询从零开始推导。LLM Wiki 是编译一次，持续维护，知识随时间复利。

这就像编程中"解释执行"和"编译执行"的区别。RAG 每次都重新"解释"原始文档，LLM Wiki 把知识"编译"成结构化网络，然后在此基础上高效查询。

LLM Wiki 生态的几种工程化方案

Karpathy 的 LLM Wiki 本身只是一个 Markdown 文件，一篇思想实验。社区在此基础上做了多种工程化实现：

1、Obsidian-Wiki 。在 LLM Wiki 的三层架构上增加了几个关键能力：Delta 追踪（用 SHA-256 哈希跟踪哪些资料已处理、哪些有更新，避免重复劳动）、溯源标记（每条知识标注"直接提取"还是"推断所得"，让人和 Agent 都知道信息可信度）、以及跨 Agent 历史摄入，自动从 Claude、Codex、Hermes 等不同 Agent 的会话记录中提取隐性知识，打破 Agent 间的数据孤岛。

2、GBrain 。走的是更"重"的工程化路线。核心创新是混合检索架构：先用向量语义搜索快速筛选相关候选（找得快），再加载完整页面让大模型深度阅读（答得准）。同时引入轻量级知识图谱，通过规则自动抽取实体关系、强制建立反向链接。在 240 页的测试语料上，带图谱的检索准确率从 17.7% 提升到 49.1%。GBrain 还有一个架构哲学：Thin Harness, Fat Skills，把编排层做薄，主要精力放在丰富知识上。以及"潜在空间 vs 确定性"的分工：让 LLM 负责判断和决策（"这条信息属于哪个页面"），让代码负责确定性操作（构建交叉引用、验证格式）。"最差的 Agent 系统总是把错误的工作放在错误的一边"。

这些方案都在实践同一个理念：Skillify，把 Skill 从固定格式的指令集泛化为知识组织形态。知识可以是任何格式的 Markdown、笔记、文档片段，通过元数据定义"在什么场景下调用哪些知识"，实现渐进式披露。Agent 按需查阅，而非一次性加载。

一个具体的例子

用某个正在运行的知识库来说明。

假设维护一个关于"AI Agent 工程化"的个人知识库，里面有上百篇来自不同来源的素材，技术文章、访谈、产品文档、创业方法论。

当加入一篇关于"高德地图 AI 自主增长系统"的技术文章时，Agent 做了什么？

提取核心技术概念（状态机编排、上下文隔离、元评估 Benchmark 等） 为每个新概念创建独立页面 发现这些概念与已有的"Agent Harness 架构"页面高度相关，建立交叉引用 发现高德团队的实战验证了之前从 Multica 访谈中得出的同一个结论，在两个页面间建立关联 更新索引，追加操作日志

一次摄入，更新了 10 个页面。 下次问"有哪些团队验证了 Harness Engineering？"，答案已经在 wiki 里了，交叉引用已经建好了，Agent 不需要临时去原始文章里翻。

编译和检索的区别就在这里。

怎么把 LLM Wiki 接入你的 Agent？

知识库建好了，怎么让你的 Agent 按需调用？

最简单的方式：Skill 封装。 把知识库的操作封装成一组 Skill（技能），Agent 在需要时自动调用。例如，有开发者写了一个 weknora-for-wiki Skill（已开源），接入 WeKnora 知识库平台，支持自然语言查询、文件导入、wiki 页面管理、健康检查等全套操作。装好之后对 Agent 说"帮我查一下知识库里有没有关于 XX 的内容"，它就会自动选择最合适的 Agent 模式（wiki 问答、快速问答、智能推理等）去检索和回答。

这个 Skill 里有一个细节值得注意：File Back 机制。当 Agent 做了一次跨页面的综合分析或对比研究后，它会把有价值的结论写回 wiki，而不是一次性消耗。这就是"知识复利"在工程上的实现。

更灵活的方式：MCP 协议。 通过 MCP（Model Context Protocol）将知识库暴露为 Agent 的原生工具，Agent 可以像调用文件读写一样自然地查询知识库。

最轻量的方式：直接读文件。 对于中小规模的知识库，Agent 直接读索引文件定位相关页面，再读具体页面获取详情。不需要向量数据库，不需要嵌入模型，就是读 Markdown 文件。这在数百页规模下效果出奇地好。

选择哪种方式取决于你的规模和场景。核心原则：让 Agent 自己管理知识库，人不直接操作。

规模天花板和混合架构

LLM Wiki 这类"渐进式披露"方案有一个明显的代价：响应速度比 RAG 慢。Agent 需要多次文件读取和工具调用来逐步加载知识，RAG 是一次性返回所有相关片段。在规模较小时（数百页以内），这个延迟可以接受。一旦知识库膨胀到上千页，纯靠 index.md 文件读取的定位方式就会显著变慢。

另一个限制是弱结构化。LLM Wiki 用 wikilink 做交叉引用，只能表达"页面 A 提到了页面 B"，无法表达"A 投资了 B"或"C 在 D 公司工作"这类语义关系。对于需要多跳推理的复杂场景（比如"找出所有由张三投资且李四任职的公司"），纯 Markdown 链接力不从心。

GBrain 的混合检索解决规模问题，知识图谱解决语义关系问题。企业级生产环境中，混合架构往往是最佳实践：

向量检索 关键词索引做快速初筛，解决"找得快" 渐进式披露 离线迭代做深度阅读和知识编译，解决"答得准"和"记得牢"

兼顾 RAG 的速度和 LLM Wiki 的准确性、知识复利，各取所长。

写到这里，真是忍不住感叹一下，开源社区的发展速度真的是非常非常快，各种方案层出不穷。真是应了那句话，只要你学得慢，你就不用学。

知识库不是目的，知识才是

回到最开始的问题：企业知识库是给谁来用的？

知识库是 Agent 的"领域专长"，让 Agent 更懂你的业务、技术栈、决策历史。最终受益的当然是人。

实现路径变了：

旧路径：人 → 整理文档 → 存入知识库 → 人检索使用新路径：人 → 策展原始资料 → Agent 编译维护知识库 → Agent 按需调用 → 人获取结论

在新的路径里，人只做两件事：策展和判断。哪些资料值得收录？哪些结论是对的？哪些方向值得深挖？

整理、分类、交叉引用、更新、矛盾检测、过时标记，全部交给 Agent。

人不维护知识库，人通过 Agent 获取知识。知识库自己进化。

如果你正在考虑为企业构建 AI Agent 系统，第一个该想清楚的问题是：我的知识库应该为谁设计、由谁维护、如何进化？