当 AI Agent 终于有了自己的文件系统：OpenViking 把上下文当成目录树来浏览

场景开篇

你让一个 Agent 去查项目文档里关于认证的那一段。传统 RAG 的做法是：把所有文档切成块、扔进向量数据库、用 embedding 相似度检索 top-k——返回的五个块里可能三个是无关的，另外两个缺了上下文。

Agent 没法"翻文件夹"，它只能"掷飞镖"。

2026 年 1 月，字节跳动旗下火山引擎开源了 OpenViking——一个把 Agent 上下文组织成虚拟文件系统的数据库。Agent 不再查询黑盒向量库，而是用 ls、tree、find 浏览自己的记忆、资源和技能。半年后，它在 GitHub 拿下三万星，单日增长 803 颗。

核心设计：viking:// 协议

OpenViking 最根本的思路转换是：上下文不是一堆 embedding，是一个文件系统。

viking://
├── resources/          # 项目文档、代码仓库、网页
│   └── my_project/
│       ├── docs/
│       └── src/
├── memories/           # 用户偏好、Agent 经验
│   └── preferences/
│       ├── writing_style
│       └── coding_habits
├── skills/             # 可调用的技能
│   ├── search_code
│   └── analyze_data
└── peers/              # 其他 Agent
    └── web-visitor-alice/

每个记忆、资源、技能都有一个 viking:// URI。Agent 定位上下文的方式从"语义相似度匹配"变成了"目录浏览"——和开发者翻文件夹一模一样。

三层加载：L0 / L1 / L2

这是 OpenViking 省 token 的关键设计。每条内容在写入时就被处理成三个层级：

每个目录也带自己的 L0/L1 层，所以 Agent 可以在"不读任何完整文件"的情况下判断一个目录是否相关：

viking://resources/my_project/
├── .abstract    # L0: ~100 tokens - 快速判断
├── .overview    # L1: ~2k tokens - 结构和要点
└── docs/
    ├── .abstract
    ├── .overview
    └── api/
        ├── auth.md       # L2: 完整内容，按需加载
        └── endpoints.md

类比一下：传统 RAG 是"把每本书全文索引，搜到哪页读哪页"；OpenViking 是"先看书架标签（L0），再翻目录（L1），再读具体章节（L2）"。后者是人类查资料的方式，也是更省算力的方式。

目录递归检索：带着上下文回来

传统向量搜索返回的是孤立的文本块——你知道"认证模块在 line 42"但不知道它属于哪个项目、哪个版本。

OpenViking 的检索分两步：

1. 向量搜索定位最高分目录（不是文件）
2. 从该目录逐层下钻，结果带着完整的目录路径返回

这意味着每次检索结果都自带上下文：你知道这个片段来自 my_project/docs/api/auth.md，而不是一个漂浮的 chunk。

可观测的检索轨迹

每次查询都保留完整的"目录浏览轨迹"。当结果看起来不对时，你可以看到 Agent 是沿着哪条路径走到那个答案的——resources/my_project/.abstract → docs/.abstract → api/.overview → auth.md。

这把 RAG 从"黑盒返回 top-k"变成了"可调试的检索过程"。和传统向量数据库相比，OpenViking 的核心差异不是"检索更准"，而是"检索可解释"。

会话即记忆

会话结束后，OpenViking 异步从对话中提取用户偏好和 Agent 经验，写入长期记忆。下次会话开始时，Agent 不需要重新了解你的编码习惯——它已经在 memories/preferences/coding_habits 里了。

这和 MemTools 的"给 Agent 记忆系统装 USB-C 接口"思路相通：记忆不是附加功能，是 Agent 的第一公民。

为什么重要

OpenViking 的核心洞察是：Agent 需要的不是更大的上下文窗口，而是更好的上下文组织方式。

当前主流的 Agent 记忆方案有三类：

• 暴力塞窗口：把所有历史塞进 prompt，简单但贵
• 向量检索：语义相似度匹配，便宜但丢失结构
• 文件系统：OpenViking 的方案，结构化浏览 + 按需加载

文件系统方案的优势在于它和人类开发者的工作方式同构——我们不会把所有代码文件扔进一个向量库然后搜索，我们会建目录、写 README、按层次组织。OpenViking 让 Agent 也这么做。

数据说话

• GitHub: 30,105 stars（2026-08-19），单日 +803
• 创建时间: 2026-01-05，半年内从 0 到 3 万星
• 背后团队: 火山引擎（字节跳动云基础设施部门）
• 评测: 在 LoCoMo（长对话用户记忆）和 tau2-bench（多轮 Agent 任务）上评测，有公开 benchmark 报告
• 生态: 已有 Red Hat OpenShift AI 集成指南、MarkTechPost 专题报道

一句话总结

OpenViking 把 Agent 的上下文从"向量库里的漂浮 chunk"变成了"可浏览的目录树"——当 Agent 能用 ls 和 find 查资料时，它终于像人类开发者一样工作了。

项目地址: https://github.com/volcengine/OpenViking
官网: https://openviking.ai
文档: https://openviking.ai/docs