有多少人在用RAG系统的思路，做Agent的知识管理系统？
起手就是文档切分、向量化，然后接下来存向量库，最后检索召回，得到最相关的topK片段给到大模型。然后立刻发现，agent场景中，相似度高，并不一定等于正确。一旦出现跨页面答案，或者几个chunk拼合一起，才能组成正确答案的情况，传统RAG流程，就会力不从心。原因很简单，RAG的这套逻辑是做简单、被动查询用的，不是给Agent用的。Agent获取信息，需要像人看书一样，先读目录看整体结构，再点开具体章节文件读，找不到再精准搜、语义搜，这才是最自然的探索逻辑。怎么怎么让agent掌握这种层层递进的知识获取结构呢？针对这一背景，我们尝试在向量数据库之上，搭建一层更贴合 Agent 的知识交互层，将其设计为类似文件系统的使用形态，这就是 VKFS。
以下为VKFS建设思路。01
RAG系统在agent知识管理中，为什么跑不通
RAG的核心是向量数据库，它已经很好地解决了存储和召回，这一点没有问题。但在agent场景中，只依赖向量数据库提供的topK内容，会让检索到的信息没有全局观（完整目录阅读）、上下文缺失等问题。第一种思路，把向量库接口直接丢给Agent，让它学collection、topK、filter、metadata、返回结构这些非常专业的工程概念，这个思路的问题是消耗上下文又容易出错。第二种思路是把检索逻辑依旧固化在系统侧，Agent只当搬运工。这种方式在路径固定、问题明确的时候很好用，但一旦需要 Agent 自己决定什么时候查、查哪里、怎么缩小范围，就会显得不够灵活。第三种思路就是搞个大一统的search入口。这样结构简单了，但是也会把浏览、读取、精准定位全揉在一起，不符合 Agent 的实际使用方式。02
VKFS 是什么？
简单来说，VKFS 是面向 Agent 的知识操作层：底层接的是向量数据库，上层用文件系统的逻辑包装，让Agent用ls、cat、grep、search这些直觉化命令，就能操作知识。agent会在看目录之后，再找文件，再读内容，再做精确或语义搜索。其中，ls、find看目录（内存PathTree实现零延迟，不用频繁调接口），cat把向量库里的零散chunk拼成完整文件，grep做精准关键词过滤（先靠向量库粗筛，再内存正则细筛，不浪费资源），search做语义探索。整个过程中，Agent不需要理解任何向量库逻辑，凭文件操作直觉就能搞定全链路知识访问。在 VKFS 里，知识访问会被整理成这样一组命令：vkfs ls /docsvkfs cat /docs/readme.mdvkfs grep "authentication" /docsvkfs search "deployment guide" /docs --top-k 5
03
VKFS 是如何做agent场景适配的？
VKFS 用一个 PathTree 保存虚拟文件树，把知识组织成一个可导航的命名空间。PathTree 作为一条特殊记录（id = "__path_tree__"）存储在向量数据库的 Collection 中，启动时一次加载到内存。之后 ls、find、stat 这类操作完全不产生网络请求，全部走内存，延迟为零。文件在 ingest 时会被切成 chunk，写入向量数据库，便于后续检索。Markdown 文件按段落边界切分，其他文本按行边界切分，最大分块 2000 字符，分块 ID 由 SHA-256(文件路径:序号) 确定性生成。但在上层，它仍然尽量保持文件级别的语义：可以 cat 读完整内容，也可以围绕路径和文件继续做搜索。这样做不是为了把文件切碎，而是想同时保住两件事：检索粒度，以及文件本身的可读性。vkfs cat /docs/agent-memory.mdvkfs stat /docs/agent-memory.md
前者偏向读具体内容，后者偏向看文件信息。对 Agent 来说，这种区分比直接操作一组检索参数更自然。真实知识访问里，既有语义相关的问题，也有精确定位的问题。有时候要找的是相关内容，有时候要找的是明确出现过的关键字、配置项、接口名。VKFS 里同时保留了 grep 和 search，不是为了把命令做多，而是想让不同类型的问题，都能有更合适的入口。vkfs grep "milvus" /docsvkfs search "how to deploy milvus" /docs --top-k 3
grep 的实现分两阶段：先从向量数据库取出 top-50 候选分块（利用标量过滤能力），再在内存中用正则表达式逐行过滤。Agent 可以用正则做精确匹配，而不需要把所有数据拉到本地。另外，在设计 VKFS 的时候，我们有意地把两层能力做成了可插拔。一层是向量数据库可插拔。VKFS 上层的知识操作方式尽量保持一致，但底层可以接不同的 vector store。目前已经支持Milvus/Zilliz（REST API v2 + gRPC 双模式适配）和SQLite（纯 Go 实现，零依赖，用于本地开发）。这样做不只是为了兼容不同环境，更是为了把"知识操作层"和"具体存储实现"分开。另一层是向量模型可插拔。不同团队在 embedding 模型上的选择会受到成本、语言、效果和部署方式的影响。目前支持 OpenAI、Cohere、SiliconFlow（BAAI/bge-m3）、Ollama（本地模型）。把这层抽出来以后，这个尝试才更像一个接口层，而不是一次性的绑定实现。所以从设计上说，VKFS 不只是想把知识访问换一种交互方式，也想把底层依赖和上层语义尽量拆开。04
为什么构建在 Milvus 之上？
向量数据库的价值，从来不只是把 embedding 存起来。更重要的是，它为上层系统提供了一个可靠的数据底座。VKFS 之所以会落在 Milvus 之上，不是因为它要绕开向量数据库，而是因为它一开始就把向量数据库当成底座。具体来说，VKFS 在一个 Milvus Collection 中同时使用了多种能力：- JSON 文档存储：PathTree 作为一条完整 JSON 记录存入 Collection，启动时一次
GetPathTree 加载，后续浏览操作零网络开销 - 标量过滤：
page_slug like "/docs%" 实现路径前缀过滤，doc_type == "chunk" 区分记录类型，让cat 和grep 能精确命中目标分块 - 向量相似度搜索：
search 命令背后是标准的 L2 距离检索，支持 topK + filter 组合
Milvus 解决的是向量存储、相似度检索、规模和性能；VKFS 试着补的，是 Agent 如何更顺手地去使用这层能力小结
过去，我们讨论知识库，更多是在讨论如何把文档变成向量。但当知识真正交给 Agent 使用时，问题会往前走一步：除了能不能做相似检索，我们还得思考，它能不能给出正确答案。VKFS 当然还只是一个很早期的尝试，远不是一个完善系统。但它至少让我们看见了一种可能性。
粤ICP备14082021号
免费POC，
零成本试错
