火山引擎开源 OpenViking：3.67 万星的 Agent 上下文数据库，统一记忆、RAG 与 Skills
火山引擎（volcengine）的 OpenViking 今天登上了 GitHub Trending，日增约 200 星，累计 3.67 万星，AGPLv3 协议。仓库地址：https://github.com/volcengine/OpenViking
它不是又一个开源大模型。OpenViking 的定位是 "AI Agent 的上下文数据库"（Context Database）——把当前分散实现的三类长期能力收敛到一个底座：Agent Memory（跨会话记忆）、Knowledge RAG（知识检索）和 Skills（可调用技能），并提供了在线 Demo 与完整文档。
这篇文章拆解它的核心设计：为什么"上下文"值得一个专门的数据库，它用什么数据模型统一三类能力，以及它和现有方案（向量库、记忆层、上下文压缩工具）到底差在哪。
本文 outline
- 问题背景：Agent 的上下文为什么需要"数据库"
- 核心概念：viking:// 文件系统与三类上下文
- 架构拆解：AGFS 存储 + 向量索引 + L0/L1/L2 分层
- 记忆怎么工作：commit 式抽取与自进化
- 检索怎么工作：意图分析 + 目录递归 + 重排
- Skills 与生态集成
- 基准数字：LoCoMo、tau2-bench 提升多少
- 和现有方案怎么选：AGPLv3 与赛道定位
1. 问题背景：Agent 的上下文为什么需要"数据库"
过去两年，Agent 工程的主流形态是无状态对话：每次请求把整段上下文塞给模型，用完即弃。但随着 Agent 从"聊几句"走向"干一整天的活"——跨会话记得用户偏好、跨任务复用经验、查团队知识库、调用各种工具——三个问题浮出水面：
上下文爆炸。长会话越长，重复塞进 Prompt 的 token 越多，成本线性上涨。上一篇文章拆过的 API 缓存能缓解，但治标不治本。
能力碎片化。记忆（Mem0、LangMem）、知识检索（向量库 + RAG）、技能（Skills/MCP）是三个独立生态，各自要一套存储、一套接口、一套运维。Agent 要同时接三套系统，集成成本极高。
检索太"平"。传统 RAG 把文档切成扁平 chunk 做向量相似度，没有层级概念。问"这个项目整体架构是什么"这种全局问题，扁平检索找不到答案——相关片段散落在几十个 chunk 里。
OpenViking 的判断是：这三类长期能力的本质都是"Agent 要长期保存、更新、召回的东西"，既然同源，就该收敛到一个底座。这就是"Context Database"这个名字的含义——像数据库管行数据一样，管 Agent 的上下文。
2. 核心概念：viking:// 文件系统与三类上下文
OpenViking 最特别的设计：把所有上下文放进一个虚拟文件系统，URI 形如 viking://。Agent 对上下文的操作变成了文件操作：ls、tree、read、write、grep、find。
三类长期能力映射为三种上下文类型：
| 类型 | 含义 | 例子 | 生命周期 |
|---|---|---|---|
| Resource | 知识 RAG | 文档、代码仓库、网页、FAQ | 相对静态，用户主动加入 |
| Memory | Agent 记忆 | 用户画像、偏好、实体、事件、助手身份 | 动态，Agent 会话中自动抽取更新 |
| Skill | 可调用技能 | SKILL.md 定义、MCP 工具 | 静态定义 |
文件系统这个隐喻不是装饰，它带来三个实打实的好处：
层级 = 语义。viking://resources/my_project/docs/ 这个路径本身就携带了"哪个项目、什么类型"的语义。目录树天然是知识结构，检索可以沿目录递归，而不是在扁平向量里瞎找。
统一接口。记忆、知识、技能共用一套文件操作 API。Agent 不用区分"我在写记忆还是存文档"——都是在文件系统里 write。
可追踪。一切操作都是文件系统操作，有路径、有历史，检索过程可审计（后面会展开）。
自进化相关的记忆类型值得一提：除了常规的 profile、preferences、entities、events，OpenViking 还有 cases、trajectories、experiences——把历史任务沉淀为案例、轨迹、经验，这就是"Self-evolving"的来源：Agent 用得越久，积累的经验越多，能力越强。
3. 架构拆解：AGFS 存储 + 向量索引 + L0/L1/L2 分层
存储分两层：
- AGFS（内容存储）：POSIX 风格的文件系统，支持
localfs、s3fs、memory三种后端，有多写/复制模式。核心已用 Rust 重写，叫 RAGFS。 - 向量索引：只存 URI、向量、元数据——从不存文件内容。支持
local（内嵌）、http（远程）、volcengine（VikingDB）三种后端，flat_hybrid混合索引（稠密 + 稀疏向量），余弦距离，int8 量化。
最巧妙的是 L0/L1/L2 三级渐进加载：
| 级别 | 内容 | 规模 | 用途 |
|---|---|---|---|
| L0 Abstract | 摘要 | ~100 token / 256 字符 | 向量召回 |
| L1 Overview | 概览 | ~2000 token / 4000 字符 | 重排、导航 |
| L2 Details | 全文 | 完整内容 | 按需读取 |
L0/L1 是目录级 sidecar 文件（.abstract.md、.overview.md），由 LLM 通过 SemanticQueue 异步自底向上生成，最多 10 个并发调用。这意味着检索永远先看摘要、再按需深入，而不是一开始就把全文塞进上下文。这是对"上下文爆炸"的直接回应：你只加载需要的粒度。
4. 记忆怎么工作：commit 式抽取与自进化
OpenViking 的会话生命周期是 Create → Interact → Commit。commit() 做两件事：同步归档旧消息（保留最近 N 轮，更早的进 history/），异步做 LLM 摘要生成和记忆抽取。
记忆抽取流程是它最有"数据库味"的地方：
Messages → LLM 抽取 → 候选记忆 → 向量预过滤找相似记忆
→ LLM 去重决策（skip / create / merge / delete）→ 写入 AGFS → 向量化每次 commit 还会写一份 memory_diff.json 审计日志，记录增/改/删，支持回滚。这不是把对话文本塞进向量库，而是真正的"记忆管理系统"：抽取、去重、合并、删除、审计、回滚，一整套数据管理语义。
对比一下传统做法：Mem0 这类记忆层是"把消息文本向量化存起来，检索时相似召回"。OpenViking 是"每次提交时用 LLM 主动提炼结构化记忆，并做合并去重"。前者是被动的，后者是主动的。
5. 检索怎么工作：意图分析 + 目录递归 + 重排
检索是三段式：
第一段，意图分析。用 LLM 把用户查询拆成 0–5 个"类型化查询"（TypedQuery），每个指定 context_type（memory/resource/skill）和优先级。官方还微调了一个 0.8B 的小模型 guoxuter/ov_intent_analysis_sft（基于 Qwen3.5-0.8B）专门做本地意图规划。
第二段，目录递归检索。这是和扁平 RAG 的核心差异。流程：全局向量搜索 top-k=10 定位起始目录 → 沿目录树递归下降，分数传播（score_propagation_alpha=1.0），3 轮无变化即收敛。目录感知的检索有学术支撑（ICDE 论文，详见参考）。
第三段，重排。用 Volcengine 的 doubao-seed-rerank（或回退到向量分数）。
search() 还支持 mode="context"，直接组装好可注入的上下文块。检索过程本身可追踪——每一步命中了哪个目录、为什么，都有记录。
6. Skills 与生态集成
技能存储为 SKILL.md + YAML frontmatter（name、description、allowed_tools、tags），放在 viking://~/skills/ 或 viking://agent/skills/。亮点是 MCP 工具自动转换：MCP 工具定义里的 inputSchema 字段会被自动检测并转成 skill 格式——MCP 生态直接可用，不用手写。
集成面很广：Claude Code、OpenAI Codex、Cursor、TRAE、OpenClaw、Hermes、OpenCode、LangChain/LangGraph、MCP 客户端，还有一个附带的 VikingBot（Agent 框架）和桌面端应用（macOS/Windows beta）。接口层有 Python SDK、Go SDK、TypeScript SDK、REST API（端口 1933）、CLI（ov 命令）和 WebDAV。
部署方式：pip install openviking + openviking-server init/start，Docker 镜像、Docker Compose、systemd、Kubernetes + Helm 都有。在线 Demo 在 https://openviking.ai/studio 。
7. 基准数字：LoCoMo、tau2-bench 提升多少
README 里的基准数据（用豆包 2.0 Pro 做 VLM、doubao-embedding-vision 做 embedding）：
LoCoMo（跨会话用户记忆），接入 OpenViking 后各 Agent 的记忆准确率大幅提升：
| Agent | 原生 | + OpenViking |
|---|---|---|
| OpenClaw | 24.20% | 82.08% |
| Hermes | 33.38% | 82.86% |
| Claude Code | 57.21% | 80.32% |
同时输入 token 降 34.3–91.0%，查询延迟降 58.45–66.10%。
tau2-bench（多轮任务 Agent），经验记忆让任务成功率提升：
- 零售场景：70.94% → 77.81%（+6.87pp）
- 航空场景：54.38% → 66.25%（+11.87pp）
要说明的是，这些是官方 README 自己报的数字，用的是火山引擎自家的模型栈，第三方复现会打折。但方向是可信的：记忆系统对跨会话 Agent 的提升幅度是数量级的，这正是"上下文数据库"这个赛道存在的理由。
8. 和现有方案怎么选：AGPLv3 与赛道定位
和向量库比（官方 FAQ 表格）：扁平向量存储 vs 层级文件系统；单一向量相似度 vs 意图分析 + 目录递归 + 重排；裸 chunk vs 结构化 L0/L1/L2；无记忆 vs 多类型自动抽取的自迭代记忆；黑盒检索 vs 可追踪检索轨迹；只存文档 vs Resource+Memory+Skill。
和记忆层（Mem0/LangMem）比：那些是"记忆层"，OpenViking 的盘子更大——记忆只是三种上下文之一，还有 RAG 和技能。如果你只需要跨会话记忆，Mem0 更轻；如果你要的是统一底座，OpenViking 的方向更完整。
AGPLv3 的现实考量：服务端代码是 AGPLv3——如果以网络服务方式运行并修改了核心服务端代码，需要向服务的用户开放修改版本。SDK 和 CLI 是 Apache 2.0。对内部自用、不改核心的企业，影响有限；对想基于它做商业 SaaS 闭源产品的团队，需要认真评估。火山引擎同时提供托管 SaaS 和商业版（BYOC/离线部署）。
赛道判断：OpenViking 瞄准的是"Agent 工程从无状态对话走向长周期任务"这个大趋势。当任务跨天、跨会话、需要累积经验时，记忆与知识的存储、更新、召回就成了独立基础设施层——和向量库、上下文压缩工具处在同一赛道，但盘子更大：它想成为 Agent 的"操作系统文件系统"。
对构建多轮、跨天任务型 Agent 的团队，直接研究它的数据模型与检索接口设计，再决定自研还是采用——这个仓库的价值，一部分在于代码，一部分在于它对"Agent 上下文应该怎么组织"这个问题的答案。
参考
- OpenViking GitHub — 3.68 万星，AGPLv3，Python 主语言
- OpenViking 官网与在线 Demo — Studio 在线体验、文档
- VikingMem 论文 — VLDB 2026，stateful LLM 应用的内存基管理
- Directory-Aware Query in Vector Databases — ICDE，目录感知检索（TrieHI）
- VikingRAG 论文 — 结构化文档的 token 高效 RAG
- 前篇：OpenAI 和 Claude 的 API 缓存原理 — 理解长上下文 Agent 的成本问题
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
关注公众号，获取更多 AI 技术干货！
