OpenViking 解读：火山引擎的 Agent 上下文数据库

Claude Code 自带的记忆机制在 LoCoMo 长对话基准上的准确率是 57.21%，接入 OpenViking 之后达到 80.32%；OpenClaw 的原生记忆只有 24.20%，接入后 82.08%。这组数字来自 OpenViking 官方基准报告，测的是同一件事：当对话历史长到塞不进上下文窗口时，Agent 能否答对那些依赖早期信息的问题。

OpenViking 是火山引擎 2026 年 1 月开源的 Agent 上下文数据库，GitHub 仓库 volcengine/OpenViking，AGPLv3 协议，star 数已接近 3 万，单日新增超过 800，长期占据 AI Agent 基础设施方向的趋势榜。它要解决的问题在 Agent 工程里已经非常具体：记忆、知识库、技能这三类上下文各自存在不同的系统里，检索靠黑盒向量库，Agent 无法解释自己为什么拿到了这些内容，也无法在结果出错时定位问题。

把上下文做成一个文件系统

OpenViking 的核心设计是把所有上下文挂载到一个虚拟文件系统下，协议名为 viking://。记忆（memories）、资源（resources）、技能（skills）各占一个目录分支，每个条目都有自己的 URI。Agent 操作上下文的方式与开发者操作文件一致：ls 列目录、tree 看结构、find 做语义查找、grep 做全文匹配。

README 给出的目录结构示例：

viking://
├── resources/              # 项目文档、代码仓库、网页等资源
│   └── my_project/
│       ├── docs/
│       └── src/
└── user/
    └── {user_id}/
        ├── memories/       # 用户偏好、事件、习惯
        ├── resources/      # 用户私有资源
        ├── skills/         # 技能定义
        └── peers/          # 协作实体

文件系统带来的直接收益是检索可观测。每次查询都会保留完整的目录浏览轨迹：向量检索先定位得分最高的目录，再逐层下钻，结果始终带着来源路径。当一条检索结果看起来不对，可以回放它经过了哪些目录、每一层的得分是多少。这个设计把 RAG 系统里最难调试的一环变成了可以逐步检查的过程。

上图是带来源追踪的检索输出示例，Provenance 部分记录了查询经过的目录、每一步的匹配分数和思维轨迹（thinking_trace）。

L0/L1/L2 三层加载

另一个关键机制是写入时的分层处理。每条内容进入 OpenViking 时会被处理成三层：

• L0（摘要）：一句话概括，约 100 token，用于快速判断相关性；
• L1（概览）：核心信息和使用场景，约 2000 token，用于任务规划；
• L2（详情）：完整原始内容，只在需要时读取。

每个目录自带 .abstract 和 .overview 文件，意味着相关性判断可以先在目录级完成，不必读取任何完整文件。Agent 拿到任务后先扫 L0，锁定目标目录后读 L1，确认后再下钻 L2。这个逐层收窄的过程直接反映在 token 消耗上：官方基准中，接入 OpenViking 后三个 Agent 的输入 token 下降 34.3% 到 91.0%，查询延迟下降 58.45% 到 66.10%。

会话结束后，OpenViking 会异步从会话记录中提取用户偏好和 Agent 经验写入长期记忆，下一次任务可以直接复用。这个机制在 tau2-bench 上有对应数据：同一个 LLM，加上经验记忆后，Retail 场景任务成功率从 70.94% 升到 77.81%，Airline 场景从 54.38% 升到 66.25%。

基准数据逐项看

用户记忆（LoCoMo）。OpenViking 0.3.22 分别接入三个 Agent 框架测试，结果如下：

三个框架接入后全部落在 80% 到 83% 区间。OpenClaw 的 token 总量从 3.93 亿降到 3742 万，降幅 91.0%，是三组中最陡的一档。

经济模拟（ClawWork）。50 个任务后，Agent 净收入从 2,269.77 美元提高到 3,843.74 美元（+69.34%），每小时 token 消耗从 1,030.3K 降到 872.4K（-22.8%）。经验记忆在提升收益的同时降低了单位消耗。

知识库问答（HotpotQA）。这部分数据适合横向对比：

OpenViking top-20 拿到 91.00% 准确率，单题延迟 0.23 秒；LightRAG 准确率 89.00%，延迟 75 秒、token 消耗 28,443。在准确率略高的前提下，延迟和 token 都压了一个数量级以上。

边界在哪里。在 FinanceBench、NaturalQuestions、ClapNQ、Qasper、SyllabusQA 五个数据集的单轮 RAG 平均成绩上，OpenViking 是 66.87%，低于 LightRAG 的 76.00%。它的索引 token 成本是 8,671,538，约为 LightRAG（62,705,469）的 13.8%，检索延迟 0.19 秒。这组数字划出了适用范围：多轮、长程、需要反复在同一个知识空间里收窄范围的 Agent 场景是它的强项；追求单轮检索精度极限的场景，图谱增强方案仍有优势。

部署与集成

安装链路足够短：

pip install openviking --upgrade
openviking-server init      # 交互式向导：配置 provider 和模型
openviking-server doctor    # 校验配置、Python 版本、连通性、磁盘空间
openviking-server           # 启动服务

模型后端支持火山引擎、OpenAI、Codex OAuth、Kimi、GLM 以及本地 Ollama，init 向导可以自动检测硬件并拉取适配的模型。安装包自带 ov 客户端：

ov add-resource https://github.com/volcengine/OpenViking
ov tree viking://resources/volcengine -L 2
ov find "what is openviking"

Agent 集成覆盖了主流编码工具和框架：Claude Code、Codex、Cursor、TRAE、OpenCode、pi、OpenClaw、Hermes、LangChain/LangGraph，以及任意 MCP 客户端。集成的动作是两件事：把 OpenViking 的召回注入 Agent 上下文，以及在会话结束时自动提交记忆。官方还提供一个桌面控制台 OpenViking Helper（macOS/Windows，beta），可以可视化配置本地 Agent 集成、检查会话轨迹、管理本地记忆和技能文件。

OpenViking Studio 在线体验环境，浏览器直接打开，无需安装。左侧是功能导航，中间是 Context tree 目录结构，右侧演示通过终端命令检索用户编码偏好。

不想本地部署的可以直接用托管在火山引擎上的 SaaS 版：个人版 50 个文件以内免费试用，底层用 VikingDB 支撑远超本地硬件的规模；企业版提供多用户上下文管理、团队协作与权限、SLA 支持。开源版本没有功能门控，AGPLv3 完整开放，不需要账号和激活密钥。企业自管版面向自有云账户（支持 BYOC）和完全离线的隔离环境，通过许可证密钥激活，在开源版之上增加分布式部署和官方支持。

研究背景

OpenViking 的核心能力来自 VikingMem 论文（A Memory Base Management System for Stateful LLM-based Applications，arXiv:2605.29640），已被 VLDB 2026 接收。论文作者来自浙江大学等机构。仓库的 benchmark 目录提供了复现脚本，上述数字都可以独立验证。

生态方面，项目已与 deer-flow（字节跳动开源的长程 SuperAgent 框架）、NoKV（AI 原生分布式文件系统）、loopx（轻量循环工程状态内核）、Hermes Agent 达成共建合作。对开发者的实际意义在于：如果你在维护一个长会话产品，或者 Agent 需要跨任务积累经验，OpenViking 提供了一套可以直接 pip install 的上下文层，检索过程全程可查，成本边界有基准数据支撑。

来源：

• volcengine/OpenViking README
• OpenViking Benchmark Update（官方博客）
• VikingMem 论文 arXiv:2605.29640