这是 OpenViking 系列的第 3 篇。前两篇我们分别讲了“为什么 Agent 需要上下文数据库”，以及“如何跑起第一个最小 Demo”。这一篇开始进入 OpenViking 最核心的设计之一：为什么它要把 Agent 上下文组织成viking://文件系统，而不是只做一个普通向量库？这件事看起来只是换了一种地址格式，但背后其实是 OpenViking 和传统 RAG 系统的一个重要分界点。这篇解决什么问题如果你做过知识库问答，可能很熟悉这套流程：把文档切块。把每个块向量化。用户提问时做相似度搜索。把召回片段塞进 prompt。这个流程对“问答”很有效，但对 Agent 来说还不够。Agent 不只是回答一句话。它会读文档、查代码、调用工具、记录记忆、复用技能，还可能在一个长任务里反复回到同一批上下文。这时，如果所有内容都只是向量库里的碎片，Agent 会遇到几个问题：它知道某段文字相关，但不知道它在项目里的位置。它找到一个片段，但不知道同目录下还有哪些文件。它想复用某条记忆，却缺少稳定路径。它想调试一次错误召回，却看不到检索路径。它想把资源、记忆、技能统一管理，却发现它们分散在不同系统里。OpenViking