智能体的「金鱼记忆」困境
用过 Cursor、Claude Code 或任意一款编码智能体的开发者，大概率撞见过这种情况：聊了半小时，智能体突然忘了你之前说的关键信息，甚至开始编造你从没提过的内容。根子在于，主流做法用 RAG 给智能体补上下文——把文档切碎、扔进向量库、按相似度捞出来。这个方案在简单场景够用，但在智能体场景有三个硬伤：上下文碎片化（记忆在对话里、资源在向量库、技能在代码里，互不相通）、检索太扁平（所有内容拍平成一池碎片，丢了全局语境）、检索是黑盒（出了错不知道从哪查）。字节跳动火山引擎 Viking 团队在 2026 年 1 月开源的 OpenViking，想用文件系统的思路重做这件事。
一切上下文皆文件：viking:// 协议
OpenViking 定位是「为 AI 智能体设计的自进化上下文数据库」（Self-evolving Context Database for AI Agents）。它的核心抽象反直觉但好懂：所有上下文——记忆、资源、技能——都挂在一个虚拟文件系统协议 viking:// 之下。viking://resources/ 放项目文档、代码库、网页；viking://user/ 放用户偏好、习惯、私人项目；viking://agent/ 放智能体自己的任务经验与执行轨迹。Agent 访问上下文不再去「查一个黑盒向量库」，而是像开发者操作文件一样用 ls、find、按路径定位。对模型来说，「用 ls 找上下文」比「盲猜一个 embedding 召回」更可解释、也更可控——这是它和传统向量数据库本质的区别。
三级加载：不是所有上下文都要一次读全
OpenViking 最有意思的设计是 L0/L1/L2 三级上下文加载。每条内容写入时被自动处理成三层：L0 Abstract 约 100 个 token，一句话摘要，用于快速判断相关性；L1 Overview 约 2000 个 token，核心信息与使用场景，用于规划；L2 Details 是完整原始数据，只在任务确实需要时再读取。这很像人去图书馆：先看分类（L0），再读目录与摘要（L1），确认相关才翻开细读（L2）。对上下文窗口有限的智能体，这意味着在极少的 token 下先建全局视图，再按需深入，而不是一上来把所有相关内容塞进提示词。官方称在大多数场景用 L0+L1 即可满足需求，token 消耗可降低 60% 到 80%。
目录递归检索：先定位目录，再精细探索
传统 RAG 靠一次向量相似度匹配，OpenViking 用多层次的目录递归检索：先意图分析，生成若干检索条件；再用全局向量检索快速锁定得分最高的起始目录；然后逐层向下钻取，在目录内做二次精细检索；存在子目录则递归下探；最后汇总最相关上下文返回。因为先锁定目录再探索内容，召回结果带着它的「上下文邻居」一起回来，而不是一堆孤立片段。检索过程还可视化——每次查询保留它浏览目录的轨迹，哪条结果不对，你能直接看到是哪条路径带出来的。对调试 Agent 的记忆，这把「黑盒」变成了「可追踪」。
可视化轨迹与自进化：越用越懂你
会话结束时，OpenViking 会异步分析任务执行结果与用户反馈，自动更新到用户与智能体记忆目录：用户侧记住偏好，下次回应更贴合；智能体侧沉淀操作技巧与工具使用经验，辅助后续决策。这正是「Self-evolving」名字的由来——不是每次从零开始，而是越用越聪明。每条新记忆还会和已有记忆做去重决策：新建、更新、合并或跳过。团队已把这类集成做进 Claude Code、Codex、Cursor、TRAE、OpenClaw、Hermes 等，并通过 MCP 或 Hook 接入，给既有 Agent 一个更好的上下文层，而不替换它们。
数字说话：三个基准上的提升
团队在三个场景做了测评。长对话用户记忆（LoCoMo 基准）：Claude Code 接入 OpenViking 后准确率从约 57% 提升到约 80%，查询时延从约 49 秒降到约 20 秒，输入 token 从约 3.53 亿降到约 1.30 亿（降约 63%）；OpenClaw 从约 24% 跃升到约 82%，时延从约 95 秒降到约 39 秒，token 从约 3.93 亿降到约 3742 万（降约 91%）。Agent 任务经验记忆（tau2-bench）：零售任务准确率从 70.94% 升到 77.81%（+6.87 个百分点），航空任务从 54.38% 升到 66.25%（+11.87 个百分点）。知识库问答（HotpotQA）：OpenViking top-20 准确率 91%，比 LightRAG 的 89% 更高，检索时延 0.23 秒对比 75 秒（快约 326 倍）。这些数字来自项目方给出的基准表，是否能在不同负载下复现仍待社区验证。
冷静看：底层仍是向量检索，价值在上层范式
社区里也有不同声音。有开发者跑通源码后指出，核心链路仍是 parse、chunk、embed、retrieve 的标准 RAG 流程，所谓「记忆衰减机制」在当时还是占位代码；分层摘要（L0/L1/L2）实质是让 LLM 对每层目录写个 summary，工程上并不复杂。这类批评有道理，但说它「换皮 RAG」有失公平：OpenViking 真正的价值不在底层存储引擎，而在上层的组织范式——它用文件系统逻辑在向量检索之上加了一层有意义的结构。对管理大量异构上下文（文档、代码、用户画像、任务记忆）的企业级 Agent 场景，这套统一管理框架有实际优势；个人开发者若只是做简单文档问答，现有方案已够用。它的学术支撑来自 VikingMem 论文（arXiv 2605.29640），已被 VLDB 2026 录用，核心以 AGPLv3 开源（CLI 与示例为 Apache 2.0）。
结语
OpenViking 用文件系统范式重做了智能体的上下文管理：分层加载省 token、目录递归检索补全局视野、可视化轨迹治黑盒、会话自演化让 Agent 越用越懂你。它未必是一步到位的方案，底层仍是向量检索，但「从扁平走向结构化」这个方向值得认真对待。对正在被 Agent 健忘反复折磨、又想要可解释可调试记忆层的团队，OpenViking 至少提出了一个值得一试的答案——把记忆、资源与技能，装进一个能像文件一样被浏览、被推理的数据库。