OpenViking 深度研究：字节跳动给 AI Agent 造了一个"大脑文件系统"

> GitHub: https://github.com/volcengine/OpenViking

> 文档: https://volcengine-openviking.mintlify.app/

> OpenClaw 集成: https://volcengine-openviking.mintlify.app/integrations/openclaw

> 公司: volcengine（火山引擎 / 字节跳动）

> 研究时间: 2026-03-20

🎯 一句话版本

OpenViking 是字节跳动开源的 AI Agent 上下文数据库，把 Agent 的记忆、资源、技能统一成一个虚拟文件系统来管理。 类似于给 Agent 装了一个带目录结构的大脑，而不是一堆散乱的文本碎片。直接提供 OpenClaw 插件，任务完成率比原生记忆提升 49%，token 消耗降低 83%。

🧠 核心理念：文件系统 > 向量碎片

传统 RAG 的问题：把所有内容切成碎片丢进向量库，检索时全靠相似度匹配，没有全局视角。

OpenViking 的做法：用 viking:// 协议建立虚拟文件系统。

viking://
├── resources/        # 外部资源（文档、代码仓库等）
│   └── OpenViking/
│       ├── docs/
│       └── README.md
├── user/             # 用户记忆（偏好、习惯）
└── agent/            # Agent 记忆（工具使用经验、执行技巧）

Agent 可以像操作文件一样操作上下文：

ov ls viking://resources/
ov tree viking://resources/volcengine -L 2
ov find "what is openviking"
ov grep "openviking" --uri viking://resources/volcengine/OpenViking/docs/zh

📐 三层上下文加载（L0/L1/L2）

这是最聪明的设计：

Agent 先读 L0 定位方向，需要时升级到 L1 了解概况，只有真正需要细节时才加载 L2。按需加载，不浪费 token。

这和我们当前 OpenClaw 的做法形成对比：MEMORY.md 每次都全量注入 prompt，越来越大越来越贵。OpenViking 的分层方案是更优雅的解决方式。

🔍 目录递归检索

不是取代向量检索，而是给向量检索加上结构：

1. 向量检索 → 定位最相关的目录（不是文件碎片）

2. 进入该目录 → 二次检索

3. 如果有子目录 → 递归深入

好处：检索结果保留了全局上下文结构。你不只知道"这段话和 query 相似"，还知道"这段话属于哪个项目的哪个文档的哪个章节"。

可视化检索轨迹：可以看到检索路径，调试为什么 Agent 拿到了错误的上下文。这对 debug RAG 非常实用——大部分 Agent 失败不是模型不行，是上下文给错了。

📊 OpenClaw 评测结果

在 LoCoMo10 长程对话数据集上（1,540 个案例）：

关键数字：

• 任务完成率 +49%（35.65% → 52.08%）
• Token 消耗 -83%（24.6M → 4.3M）
• 比 LanceDB 方案：完成率高 17%，token 少 91%

⚠️ 注意：这是项目方自己的评测，不是独立第三方验证。但数据一致性好，可信度尚可。

🔌 OpenClaw 集成方式

已有现成插件，一键安装：

curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/examples/openclaw-memory-plugin/install.sh | bash

两种模式：

• Local：插件自动启动 OpenViking 服务
• Remote：连接已有的 OpenViking 服务器

需要配置 VLM + Embedding 模型。支持：

• 火山引擎（豆包模型）
• OpenAI
• LiteLLM（Claude、DeepSeek、Gemini、Ollama 等）

🏗️ 技术栈

• Python：核心逻辑、API 服务
• Go：AGFS 组件（Agent 文件系统）
• Rust：CLI 工具 (ov_cli)
• C++：核心扩展（向量计算等）
• 服务端口：1933

四种语言的混合项目，说明团队有能力也有工程资源。

💡 与我们的关联

1. 直接可用 ⭐⭐⭐

OpenViking 已经有 OpenClaw 插件，我们可以直接试用。最低配置：

• 我们的 VPS 跑 OpenViking 服务
• 用 LiteLLM 接 Claude/OpenRouter 做 VLM
• 用 Jina 或 OpenAI 做 Embedding

2. 解决我们的 MEMORY.md 瓶颈

当前 MEMORY.md 的问题：

• 越写越大，token 越来越贵
• 全量注入，没有分层
• 检索靠文本匹配，没有结构

OpenViking 的 L0/L1/L2 分层 + 目录递归检索正好解决这些问题。

3. 和之前调研的项目对比

4. 字节跳动出品的信号

volcengine 是字节跳动的云服务品牌。这不是个人项目——背后有企业级的工程团队和资源。默认推荐豆包模型（doubao），但也支持第三方，不锁死生态。

5. 建议路线

短期（1-2 周）：

• 在 VPS 上试装 OpenViking + OpenClaw 插件
• 用现有对话数据测试记忆检索效果

中期（1-2 月）：

• 如果效果好，迁移 MEMORY.md 内容到 OpenViking
• 深度研究的 raw 数据也可以作为 resource 导入

长期：

• OpenViking 作为全局上下文基础设施
• 多 Agent 共享上下文（researcher、codex 等）

❓ FAQ

为什么需要 VLM？

OpenViking 用 VLM 做两件事：

1. 语义处理：把导入的资源（文档、代码、网页）自动生成 L0 摘要和 L1 概览。不是简单截断——需要"理解"内容才能提炼一句话摘要，所以需要大语言模型。

2. 多模态理解：支持图片类资源。add-resource 导入的如果包含图片（架构图、截图等），VLM 可以"看"图并生成文字描述纳入检索索引。

实际上 VLM 主要当 LLM 用（生成摘要/概览），"V" 是加分项。纯文本资源用普通 LLM（Claude、DeepSeek）通过 LiteLLM 接入完全可以。

成本：每个资源导入时处理一次（生成 L0/L1），之后检索不再调 VLM。一次性成本，不是持续消耗。

为什么能省 83% 的 token？

核心原因是 L0/L1/L2 分层加载，只给 Agent 看它需要的那一层。

举个具体例子，假设 Agent 要回答"Jay 喜欢什么球队"：

OpenClaw 原生做法：把整个 MEMORY.md（700 行）全塞进 prompt → 24.6M tokens

OpenViking 做法：

1. 检索 L0（一句话索引）→ 命中 user/preferences/.abstract："用户体育偏好"

2. 加载 L1 概览 → "阿森纳球迷，关注英超"

3. 已经够用，不加载 L2 全文

三步总共几百 token，而不是把所有记忆都塞进去。

省 token 的三个层次：

而 LanceDB 方案反而 token 更多（51.6M），因为向量检索是平坦的——检索到的碎片缺乏结构，Agent 需要更多上下文来理解碎片之间的关系。

⚠️ 注意事项

1. 依赖重：Python 3.10+ / Go 1.22+ / C++ / Rust，四种语言都要

2. 版本早期：0.1.x，API 可能变

3. 评测是自家做的：没有独立验证

4. 默认推豆包：虽然支持第三方，但最佳体验可能绑火山引擎

5. VLM 消耗：每次语义处理都要调 VLM，成本需评估

📊 评分

报告由深度研究助手自动生成 | 2026-03-20

来源: https://github.com/volcengine/OpenViking