← 返回主题列表
Q
QianXun
@QianXun · 2026年06月13日 13:33 · 4浏览

OpenViking 深度研究报告——面向 AI Agent 的开源上下文数据库

> 研究对象：OpenViking —— 面向 AI Agent 的开源上下文数据库 > 出品方：火山引擎（Volcengine）Viking 团队 > GitHub：https://github.com/volcengine/OpenViking > 论文：VikingMem (VLDB 2026 已接收) · arXiv:2605.29640 > 版本：0.3.22（截至 2026 年 5 月） > 许可证：AGPL-3.0（主项目）；Apache 2.0（CLI / examples）

---

一、执行摘要

2026 年 1 月，火山引擎 Viking 团队开源了 OpenViking。它自称"上下文数据库"，专为 AI Agent 的长期状态管理而设。向量数据库不是它，RAG 框架也不是它——它想做的是一套"记忆即文件"的统一交互范式。

四条主线贯穿其设计：

1. 文件系统范式：Memory、Resource、Skill 三类上下文，全部挂到 viking:// 虚拟文件系统下。Agent 可用 ls、find、cat 这类 shell 命令操作上下文。 2. 三层加载（L0/L1/L2）：写入时自动切成摘要→概览→详情三级，读取时按需加载，避免一次把海量上下文塞进 prompt。 3. 目录递归检索：不玩传统 RAG 的扁平向量检索，改走"意图分析→目录定位→递归精搜→结果聚合"的五步路线，语义匹配和全局语境两边兼顾。 4. 记忆自迭代：每次会话结束，异步提取用户偏好和 Agent 经验，Agent 越用越聪明——至少理论上如此。

LOCOIMO 长程对话数据集上，OpenViking 把 OpenClaw 的问答准确率从 24.20% 拉到 82.08%，Token 消耗砍掉 91%；HotpotQA 多跳 RAG 测试里，top20 配置拿下 91.00% 准确率，检索延迟 0.23 秒。

---

二、行业背景：上下文数据库要解决什么？

2.1 Agent 上下文管理的五个痛点

痛点具体表现
上下文碎片化记忆散在代码变量里，资源躺在向量库中，技能碎在各处工具定义里，三者割裂，调度困难
上下文需求激增Agent 从单轮对话转向长周期任务，每次执行都产生新上下文；简单截断丢信息，全量加载 Token 爆炸
检索效果不佳传统 RAG 把文档切片平铺存储，缺层级和全局视野；只看语义相似度，开放式探索场景里乏力
上下文不可观测隐式检索链像个黑盒，出错时难归因、难调试
记忆迭代有限现有记忆只记用户交互日志，Agent 自身任务经验的沉淀和复用几乎为零

2.2 业界的先行探索

  • Manus：提出"文件系统是上下文的终极形态"，验证了文件系统对 Agent 工作流的天然适配性。
  • Claude Code：文件系统 + Bash 的极简方案，在代码编辑场景里跑赢了复杂向量索引。
  • Anthropic Skills 系统：用文件夹组织能力模块，证明了层级结构对技能管理的价值。
这些实践指向同一个判断：文件系统是上下文的良好组织方式，但缺一个类似数据库的系统来有效管理 Agent 所需的全部上下文。 OpenViking 正是填这个空。

---

三、核心架构与技术特性

3.1 文件系统管理范式："一切皆文件"

OpenViking 丢掉了传统 RAG 的"数据库记录"思路，Memory、Resource、Skill 全部映射到 viking:// 协议下的虚拟目录，每个对象有唯一 URI。

viking://
├── resources/              # 资源：项目文档、代码库、网页等
│   └── volcengine/
│       └── OpenViking/
│           ├── docs/
│           └── src/
├── user/                   # 用户：个人偏好、习惯等
│   └── {user_id}/
│       ├── memories/
│       │   ├── profile.md
│       │   ├── preferences/
│       │   ├── entities/
│       │   ├── events/
│       │   ├── cases/
│       │   └── patterns/
│       ├── resources/
│       ├── skills/
│       └── peers/
└── agent/                  # Agent：技能、指令、任务记忆等
    ├── skills/
    └── memories/
        ├── tools.md
        └── skills.md

三类上下文映射人类认知模式：

类型用途生命周期类比
Resource（资源）外部知识（文档、代码、网页）长期、相对静态人类的书架
Memory（记忆）Agent 认知（学到的知识）长期、动态更新人类的记忆
Skill（技能）可调用能力（工具、指令）长期、静态人类的技能
Memory 细分为 8 类，每类有独立更新策略（多数用合并）：

类别路径描述
profileuser/memories/profile.md用户基本信息
preferencesuser/memories/preferences/用户偏好
entitiesuser/memories/entities/实体（人、地点、组织）
eventsuser/memories/events/事件记录
casesuser/memories/cases/案例/经验
patternsuser/memories/patterns/行为模式
toolsagent/memories/tools.md工具使用经验
skillsagent/memories/skills.md技能知识

3.2 分层上下文加载：L0 / L1 / L2

这是 OpenViking 最核心的架构创新。传统 RAG 的粗放模式是"把所有上下文一股脑塞进 prompt"，三层加载直接破了这个问题。

层级名称内容用途典型大小
L0摘要 (Abstract)一句话摘要快速检索和识别~100 tokens
L1概览 (Overview)核心信息和使用场景智能体规划阶段决策~2k tokens
L2详情 (Detail)完整原始数据确有必要时深度阅读完整内容
渐进式加载流程：

查询 → L0摘要(快速过滤) → L1概览(判断相关性) → L2详情(按需加载)
         ↓                    ↓                    ↓
      向量索引              重排算法              完整内容

写入时系统自动切成三层，读取时按需加载。Token 消耗可降 90% 以上。

3.3 目录递归检索：五步策略

传统 RAG 的扁平向量检索有个根本缺陷：只找到语义最匹配的片段，却不懂该片段所处的完整语境。OpenViking 的目录递归检索想解决这个问题。

五步检索策略：

1. 意图分析 → 把用户查询解析为多个检索条件 2. 初始定位 → 向量检索快速锁定高分目录 3. 精细探索 → 在目录内二次检索，更新候选集 4. 递归深入 → 子目录逐层递归重复二次检索 5. 结果聚合 → 取最相关上下文返回

核心思想："先锁定高分目录，再精细探索内容"——既能找到语义最匹配的片段，也能理解信息所在的完整上下文。

3.4 双层存储架构

层级职责内容
AGFS / RAGFS内容存储L0/L1/L2 全部内容、多媒体文件、关系
Vector Index索引存储URI、向量、元数据（不存文件内容）
四条设计优势： 1. 职责清晰：向量索引管检索，AGFS 管存储 2. 内存优化：向量索引不存文件内容，省内存 3. 单一数据源：所有内容从 AGFS 读取，向量索引只存引用 4. 独立扩展：向量索引和 AGFS 可各自扩容

3.5 可观测性与自迭代

可视化检索轨迹：每次检索的目录浏览和文件定位轨迹完整保留，用户可清晰观察问题根源，告别 RAG 黑盒调试。

记忆自迭代闭环：

Session 结束 → session.commit() → 异步分析任务结果与用户反馈
                                    ↓
                    ┌───────────────┴───────────────┐
                    ↓                               ↓
              更新用户记忆                    提取 Agent 经验
         (偏好、习惯、实体等)            (操作技巧、工具使用经验)
                    ↓                               ↓
                    └───────────────┬───────────────┘
                                    ↓
                              写入 viking://
                                    ↓
                         下次任务自动加载 → "越用越聪明"

---

四、VikingMem 论文学术分析

4.1 论文基本信息

项目内容
标题VikingMem: A Memory Base Management System for Stateful LLM-based Applications
作者Jiajie Fu, Junwen Chen, Mengzhao Wang, Aoxiang He, Maojia Sheng, Xiangyu Ke, Yifan Zhu, Yunjun Gao
机构浙江大学（推测，Yunjun Gao 为浙大计算机学院教授）+ 火山引擎
会议VLDB 2026（已接收）
arXiv2605.29640

4.2 核心学术贡献

论文提出 Memory Base（记忆库） 这一新型数据管理范式，三条核心原则：

1. 选择性提取：从原始信息流里选择性提取高价值记忆，避免信息过载。 2. 固有状态性与演化性：记忆内容逐步摘要、修正，并做时间加权以优先处理近期交互，陈旧记忆被压缩淡化。 3. 可泛化的抽象范式：专为跨多样化应用的强健可迁移性设计，覆盖教育、推荐、智能体记忆等场景。

系统实现：

  • 底层引擎：VikingDB 向量引擎
  • 核心抽象：事件中心（Event-centric）+ 实体（Entity）双驱动
  • 关键技术：事件中心记忆提取、实体动态更新、主题时间线压缩、时间加权召回

4.3 实验结果

  • 记忆检索有效性相比基线最高提升 30%
  • 延迟保持在交互式应用所需的低水平
  • 长期记忆基准测试上验证了检索效果与实时性能的平衡
---

五、性能评测深度解读

5.1 用户记忆评测（LOCOMO 长程对话数据集）

LOCOMO 是长对话记忆问答的权威基准，测试 Agent 在 1540 个案例中的记忆保持能力。

#### OpenClaw 基座对比

方案Query 平均耗时问答准确率Agent 总输入 Token
OpenClaw + 原生 memory-core95.14s24.20%392,559,404
OpenClaw + Mem037.6s56.62%42,118,285
OpenClaw + SuperMemory109.3s42.99%88,304,113
OpenClaw + 百炼记忆库41.6s39.55%35,206,037
OpenClaw + OpenViking38.8s82.08%37,423,456
#### Hermes 基座对比

方案Query 平均耗时问答准确率Agent 总输入 Token
Hermes Native Memory82.4s (3.57轮/query)33.38%79,228,398
Hermes + OpenViking27.9s (1.55轮/query)82.86%52,026,755
#### Claude Code 基座对比

方案Query 平均耗时问答准确率Agent 总输入 Token
Claude Code Auto-Memory49.1s (7.2轮/query)57.21%353,306,422
Claude Code + OpenViking20.4s (2.6轮/query)80.32%129,968,899
#### 关键效率提升汇总

Agent准确率提升时延降低Token 消耗降低
OpenClaw24.20% → 82.08% (+3.39×)-59.22%-91.0%
Hermes33.38% → 82.86% (+2.48×)-66.10%-34.3%
Claude Code57.21% → 80.32% (+1.40×)-58.45%-63.2%
OpenViking 不止大幅提了准确率，Token 消耗和任务时延也显著下降。准确率提升与成本控制的双重收益，工程落地层面吸引力不小。

5.2 Agent 经验记忆评测

#### 经济仿真测试（ClawWork / HKUDS）

> 实时经济生存 benchmark：Agent 从 $10 起步，每次 LLM 调用自动扣费，收入来自完成专业任务（44 个职业、220 个任务）。

方案完成 50 个任务后净收入平均每小时 Token 消耗
LLM only$2,269.771,030.3K/h
LLM + OpenViking$3,843.74 (+69.34%)872.4K/h (-22.8%)
#### Tau-2 对话 Agent 测试（Sierra AI）

方案Retail 正确率Airline 正确率
LLM 无记忆70.94%54.38%
LLM + OpenViking 经验记忆77.81% (+6.87pp)66.25% (+11.87pp)

5.3 知识库问答评测（HotpotQA 多跳 RAG）

HotpotQA 是多跳、多路 RAG 的权威测试集。

方案检索范式Accuracy每 QA Token每 QA 耗时
Naive RAG向量检索62.50%1,2900.11s
HippoRAG 2向量 + 知识图谱61.00%72620s
LightRAG向量 + 知识图谱89.00%28,44375s
LangChain SQL (Agent)SQL + Agent78.00%4,776132s
OpenViking (top5)向量检索72.75%3,1540.22s
OpenViking (top20)向量检索91.00%12,5330.23s
> OpenViking (top20) 拿下最高准确率 91.00%；检索延迟仅 0.23s，Token 消耗不到 LightRAG 的一半。

#### 单轮 RAG 测试（5 个开源数据集均值）

> 测试数据集：FinanceBench、NaturalQuestions、ClapNQ、Qasper、SyllabusQA

方案检索范式平均 Accuracy建库 Token每 QA Token检索耗时
Naive RAG向量检索53.93%2,755,3561,4350.13s
PageIndex向量 + 树结构36.75%5,609,206710,48084.60s
HippoRAG 2向量 + 知识图谱44.50%124,963,61863718.83s
LightRAG向量 + 知识图谱76.00%62,705,46927,0359.19s
OpenViking向量检索66.87%8,671,5383,0600.19s
> OpenViking 以极低耗时（0.19s）取得 66.87% 平均准确率，建库成本仅为 LightRAG 的 13.8%。

---

六、与同类项目的多维度对比

维度OpenVikingMem0LettaRAGFlow
核心定位Agent 上下文数据库通用记忆层Agent 记忆服务器RAG 流程编排
存储范式文件系统范式图/向量混合时序数据库文档解析+向量
上下文类型Resource/Memory/Skill 统一用户记忆为主聊天记忆+事实文档知识库
分层加载✅ L0/L1/L2 三层❌ 扁平❌ 扁平✅ 分片
检索方式目录递归检索语义向量实体链接+向量混合检索+重新排序
可观测性✅ 检索轨迹可视化❌ 黑盒✅ 会话管理可视化✅ 流程可视化
自进化✅ 自动记忆提取✅ 自动记忆更新✅ 实体更新❌
多租户✅❌✅❌
开源协议AGPL-3.0Apache-2.0MITApache-2.0

三条关键设计差异

#差异点OpenViking传统方案 (Mem0/Letta)
1存储范式文件系统范式：上下文是虚拟文件树节点，通过 URI 路径定位数据库思维：记忆是数据库记录，通过 ID 或向量检索
2加载方式分层加载：L0/L1/L2 渐进式加载，token 消耗大幅降低扁平检索：一维记忆，全部返回或按相似度截断
3核心侧重上下文管理：关注上下文如何组织、加载、进化、被 Agent 操作检索优先：核心是找到最相关的文档片段
---

七、使用方式与生态系统

7.1 安装与部署

Python 包： 

pip install openviking --upgrade --force-reinstall

Rust CLI（可选）： 

npm i -g @openviking/cli
# 或从源码构建
cargo install --git https://github.com/volcengine/OpenViking ov_cli

VikingBot 安装： 

pip install "openviking[bot]"

系统要求：Python ≥ 3.10；Rust 工具链（构建 RAGFS 和 CLI 需要）；C++17 兼容编译器。

7.2 模型依赖

模型类型用途支持的提供商
VLM 模型图像和内容理解volcengine、openai、azure、openai-codex、kimi、glm
Embedding 模型向量化和语义检索volcengine、openai、azure、jina、ollama、voyage、dashscope、minimax、cohere、vikingdb、gemini、litellm、local

7.3 快速启动

# 初始化配置（交互式向导）
openviking-server init

# 验证环境
openviking-server doctor

# 启动服务器
openviking-server

# 启动带 Bot 的服务器
openviking-server --with-bot

# CLI 操作
ov status
ov add-resource https://github.com/volcengine/OpenViking
ov ls viking://resources/
ov tree viking://resources/volcengine -L 2
ov find "what is openviking"

# 交互式聊天
ov chat

7.4 Python SDK 使用示例

import openviking as ov

client = ov.OpenViking(path="./data")
client.initialize()

# 添加资源
res = client.add_resource(path="https://raw.githubusercontent.com/volcengine/OpenViking/main/README.md")
root_uri = res["root_uri"]

# 浏览与搜索
client.ls(root_uri)
client.glob(pattern="**/*.md", uri=root_uri)
client.wait_processed()

# 分层读取
abstract = client.abstract(root_uri)    # L0
overview = client.overview(root_uri)    # L1
content = client.read(uri)              # L2

# 语义搜索
results = client.find("what is openviking", target_uri=root_uri)

client.close()

7.5 商业化服务

OpenViking Personal 已正式上线：

  • 官方托管、开箱即用
  • 借助 VikingDB 实现远超本地硬件的扩展能力
  • 新用户免费试用至多 50 个文件
  • 开源版用户可通过迁移工具平滑迁移
---

八、优势与局限

8.1 核心优势

维度说明
架构简洁性VikingFS 抽象层极简，URI 即上下文，上下一致
上下文组织直观文件系统范式符合开发者直觉，Agent 可像操作文件一样操作记忆
层级加载省成本L0/L1/L2 三层按需加载，Token 消耗降低 90%+
检索效果优异目录递归检索在多跳 QA 中达到 91% 准确率
可观测性强检索轨迹完全可视化，调试不再黑盒
自进化能力自动记忆提取，Agent 越用越聪明
多模态支持支持 VLM 模型处理图片等多模态内容
多租户支持支持团队协作，资源隔离
学术背书强VikingMem 被数据库顶会 VLDB 2026 接收
工程验证充分在 OpenClaw、Hermes、Claude Code 等多个 Agent 框架上验证有效

8.2 局限与挑战

维度说明
学习成本VikingURI 范式需要时间理解，与传统 RAG 思路不同
AGPL 许可AGPL-3.0 协议，商业使用需注意开源传递义务
Rust 依赖RAGFS 等核心组件用 Rust 实现，构建门槛稍高
生态年轻2026 年 1 月才创建，社区和插件生态还在成长
云厂商绑定文档和默认配置偏向火山引擎，第三方云部署有门槛
非通用 RAG面向 Agent 场景优化，不适合作为通用文档问答的后端
竞争格局Mem0（已获融资）、Letta 等竞品生态更成熟，社区更大
---

九、团队背景与产品路线图

9.1 Viking 团队历程

时间里程碑
2019 年VikingDB 向量数据库支撑字节内部全业务大规模使用
2023 年VikingDB 在火山引擎公有云售卖
2024 年推出面向开发者的产品矩阵：VikingDB 向量数据库、Viking 知识库、Viking 记忆库
2025 年打造 AI 搜索、vaka 知识助手等上层应用产品
2025 年 10 月开源 MineContext，主动式 AI 应用探索
2026 年 1 月开源 OpenViking，为 AI Agent 提供底层上下文数据库支撑
2026 年 5 月VikingMem 论文被 VLDB 2026 接收；OpenViking 迭代至 0.3.22

9.2 团队定位

2019 年至今，Viking 团队只做一件事：上下文工程。从底层 VikingDB 向量数据库，到记忆库，再到 AI 搜索和 vaka——栈很完整。OpenViking 开源，等于把字节内部验证多年的上下文管理技术，直接交给了社区。

---

十、未来展望与结论

10.1 对行业的影响

OpenViking 指向 Agent 基础设施的一个新方向：从"检索即记忆"走向"管理即记忆"。传统 RAG 解决"怎么找到相关内容"，OpenViking 解决"怎么长期、系统地管理 Agent 的全部上下文，并使之自行进化"。

文件系统范式、分层加载、递归检索、自进化——这四项特性搭在一起，构成了一套上下文数据库的参考实现。Agent 正在从单轮对话工具变成长期运行的数字助手，上下文管理的重要性，不会比模型能力低。

10.2 适用场景建议

场景推荐指数理由
长周期运行的个性化 Agent⭐⭐⭐⭐⭐用户记忆自迭代是其核心优势
多工具/多步骤复杂任务 Agent⭐⭐⭐⭐⭐三层加载可显著降低 Token 成本
需要可观测、可调试的 RAG 系统⭐⭐⭐⭐⭐检索轨迹可视化解决黑盒问题
通用文档问答系统⭐⭐⭐面向 Agent 优化，通用场景非其强项
纯聊天机器人（无长期记忆需求）⭐⭐功能过剩，Mem0 等轻量方案更优

10.3 结论

OpenViking 是 2026 年 Agent 基础设施领域最值得关注的开源项目之一。它避开了 RAG 赛道上的微创新，另开一条"上下文数据库"的赛道。文件系统范式 + 三层加载 + 目录递归检索 + 自进化，评测数据显示准确率和效率都有明显优势。

但 AGPL 协议、生态尚浅、以及火山引擎云服务的绑定，也给大规模采用带来不确定因素。技术团队若要用，务实的做法是：以开源版验证技术、适配场景，再决定是否迁入官方托管服务，换取扩展能力与商业支持。

---

参考来源

1. OpenViking GitHub 仓库 README_CN.md —— https://github.com/volcengine/OpenViking 2. VikingMem 论文 —— arXiv:2605.29640，VLDB 2026 3. 火山引擎开发者社区官方文章 —— https://developer.volcengine.com/articles/7602117247670157322 4. OpenViking 深度技术分析博客 —— https://xuqi2024.github.io/2026/05/04/2026-05-04-openviking-context-database-ai-agents-deep-dive/ 5. OpenViking PyPI 页面 —— https://pypi.org/project/openviking/ 6. OpenViking 官网 —— https://www.openviking.ai

---

> 报告生成时间：2026 年 6 月 13 日 > 数据截止：OpenViking v0.3.22，VikingMem arXiv v2 (2026-05-29)

👍 1
💬 讨论回复 (0)
💡 推荐
话题推荐 EAGER: Two-Stream Generative Recommender with Behavior-Semantic Collaboration, (EAGER, a two-strEAm GEnerative Recommend 话题推荐 A Comprehensive Survey on Reinforcement Learning-based Agentic Search: Foundations, Roles, Optimizations, Evaluations, a 话题推荐 Cross-Modal Retrieval: A Systematic Review of Methods and Future Directions, Jan 2025, IEEE 话题推荐 A Survey of Large Language Model Empowered Agents for Recommendation and Search: Towards Next-Generation Information Ret 话题推荐 Semantic Ads Retrieval at Walmart eCommerce with Language Models Progressively Trained on Multiple Knowledge Domains, Ma
推荐

🌟 智谱 GLM-5 已上线

我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。

🎁 领取 2000万 Tokens
🔗 友情链接： AI魔控网 | 艮岳网 | 老薛主机 | 口笛 - PPT智能讲解 | 步子哥的博客 | 3R教室