🚀 OpenViking —— 字节跳动开源的 AI Agent 上下文数据库
> "Memory, Resource, Skill. Everything is a File." > > 记忆、资源、技能,皆为文件。
---
📋 项目概述
OpenViking 是由字节跳动火山引擎 Viking 团队于 2026 年 1 月开源的专为 AI Agent 设计的上下文数据库。
| 属性 | 信息 |
|---|---|
| GitHub | https://github.com/volcengine/OpenViking |
| 官网 | https://openviking.ai |
| 开发团队 | 字节跳动火山引擎 Viking 团队 |
| 开源时间 | 2026 年 1 月 |
| 核心定位 | AI Agent 上下文数据库(Context Database) |
团队背景
Viking 团队在字节跳动内部有着丰富的上下文工程实践经验:
- 2019 年:VikingDB 向量数据库支撑字节内部全业务
- 2023 年:VikingDB 在火山引擎公有云售卖
- 2024 年:推出 VikingDB、Viking 知识库、Viking 记忆库产品矩阵
- 2025 年:打造 AI 搜索、vaka 知识助手等上层应用
- 2025 年 10 月:开源 MineContext(主动式 AI 应用探索)
- 2026 年 1 月:开源 OpenViking(AI Agent 上下文数据库)
🎯 核心解决的问题
OpenViking 针对当前 AI Agent 开发中普遍遇到的上下文管理痛点:
1. 上下文无序且割裂
- 记忆散落在代码中
- 资源存储在向量库
- 技能分散在各个角落
- 关联和维护成本极高
2. 长程任务需要更多上下文
- Agent 从单轮对话转向长周期任务
- 涉及多工具、多 Agent 复杂协同
- 简单截断会带来不可逆的信息损失
- 模型成本高昂
3. 朴素 RAG 检索效果局限
- 数据切片是平铺式存储,缺乏全局视野
- 面对海量、多模态数据力不从心
- 过于关注语义相关性
- 在开放式场景中表现不佳
4. 上下文缺乏观测和调试
- 隐式检索链路如同黑箱
- 出错时难以归因和调试
- 改进门槛高
5. 记忆成为核心资产
- 沉淀的记忆是 Agent 的核心资产
- 需要在使用初期就建设
- 形成使用时间越长,体验越好的复利效果
💡 核心理念:文件系统范式
OpenViking 摒弃了传统 RAG 的碎片化向量存储模式,创新性地采用 "文件系统范式":
> "We are swimming in a sea of information, and we need to learn to navigate." > > — Norbert Wiener(诺伯特·维纳)
统一抽象
所有上下文(记忆、资源、技能)都映射到 viking:// 协议下的虚拟目录:
viking://
├── /memory # 用户记忆 + Agent 经验
│ ├── /user # 用户偏好、历史交互
│ └── /agent # Agent 自我进化积累的经验
│
├── /resources # 文档、图片、视频等资源
│ ├── /documents
│ ├── /images
│ └── /videos
│
└── /skills # 技能定义和能力模块
├── /code_review
├── /refactoring
└── /debugging
文件操作接口
Agent 可以像操作本地文件一样管理上下文:
# 浏览目录
client.ls("viking://resources/documents")
# 查找文件
client.glob(pattern="**/*.md", uri="viking://resources")
# 读取内容
client.read("viking://resources/documents/guide.md")
# 语义搜索
client.find("what is openviking", target_uri="viking://resources")
这种范式赋予了 Agent 前所未有的上下文操控能力,让上下文管理从模糊的语义匹配演变为直观、可追溯的"文件操作"。
---
🔑 四大核心特性
1. 文件系统管理范式
解决碎片化问题
- 所有上下文统一组织于虚拟文件系统
- 每个条目拥有唯一 URI(如
viking://memory/user/preferences) - 支持
list、find、read等标准指令 - 精确、确定性地定位、浏览和操作信息
2. 分层上下文按需加载 (L0/L1/L2)
降低 Token 消耗,避免信息过载
OpenViking 在上下文写入时自动处理为三个层级:
| 层级 | 名称 | 内容 | 用途 | Token 消耗 |
|---|---|---|---|---|
| L0 | 摘要 (Abstract) | 一句话概括 | 快速判断相关性 | 极低 |
| L1 | 概述 (Overview) | 核心信息 + 使用场景 | 规划阶段决策 | 中等 |
| L2 | 详情 (Detail) | 完整原始数据 | 必要时深入读取 | 按需 |
- 无需一次性塞入海量上下文
- 避免超出模型窗口
- 减少噪声干扰
- 大幅节省 Token 成本
3. 目录递归检索
提升检索效果
融合多种检索方式的创新策略:
1. 意图分析 → 生成多个检索条件
│
▼
2. 向量检索 → 定位高分目录
│
▼
3. 二次检索 → 在目录内精细搜索
│
▼
4. 逐层递归 → 若存在子目录,重复步骤 3
│
▼
5. 返回结果 → 最相关上下文
特点:
- "先锁定高分目录、再精细探索内容"
- 理解信息所在的完整语境
- 提升检索的全局性与准确性
4. 可观测与自迭代
上下文白盒化 + 自动进化
可观测性:
- 层次化虚拟文件系统结构,一目了然
- 检索过程完整留存(目录浏览、文件定位轨迹)
- 可视化检索路径,清晰观测问题根源
# 会话结束时调用
client.session.commit()
系统自动:
- 分析任务执行结果与用户反馈
- 更新
/memory/user(用户偏好) - 更新
/memory/agent(操作技巧、工具使用经验) - 提取长期记忆
---
🛠️ 快速上手
第一步:安装
pip install openviking
第二步:配置模型服务
支持多种模型服务:
- 火山引擎(豆包模型):推荐,成本低、性能好
- OpenAI:GPT-4V 等 VLM 模型
- 自定义模型:兼容 OpenAI API 格式
ov.conf:
{
"vlm": {
"api_key": "<your-api-key>",
"model": "doubao-seed-1-8-251228",
"api_base": "https://ark.cn-beijing.volces.com/api/v3",
"backend": "volcengine"
},
"embedding": {
"dense": {
"backend": "volcengine",
"api_key": "<your-api-key>",
"model": "doubao-embedding-vision-250615",
"api_base": "https://ark.cn-beijing.volces.com/api/v3",
"dimension": 1024
}
}
}
设置环境变量:
export OPENVIKING_CONFIG_FILE=ov.conf
第三步:运行示例
import openviking as ov
# 初始化客户端
client = ov.SyncOpenViking(path="./data")
client.initialize()
# 添加资源(支持 URL、文件、目录)
result = client.add_resource(
path="https://raw.githubusercontent.com/volcengine/OpenViking/main/README.md"
)
root_uri = result['root_uri']
# 探索资源树结构
ls_result = client.ls(root_uri)
print(f"目录结构:\n{ls_result}\n")
# 查找 Markdown 文件
glob_result = client.glob(pattern="**/*.md", uri=root_uri)
if glob_result['matches']:
content = client.read(glob_result['matches'][0])
print(f"内容预览: {content[:200]}...\n")
# 等待语义处理完成
print("等待语义处理...")
client.wait_processed()
# 获取分层信息
abstract = client.abstract(root_uri) # L0 摘要
overview = client.overview(root_uri) # L1 概述
print(f"摘要:\n{abstract}\n\n概述:\n{overview}\n")
# 语义搜索
results = client.find("what is openviking", target_uri=root_uri)
print("搜索结果:")
for r in results.resources:
print(f" {r.uri} (score: {r.score:.4f})")
# 提交会话,触发记忆自迭代
client.session.commit()
# 关闭客户端
client.close()
---
🔗 与 Kimi Code CLI 的潜在关联
在研究 Kimi Code CLI 的过程中,发现两者有许多有趣的对应关系:
| OpenViking | Kimi Code CLI | 关联性 |
|---|---|---|
| 文件系统范式 | AGENTS.md、Skill 目录结构 | 都认识到文件系统是组织上下文的优雅方式 |
| 分层加载 (L0/L1/L2) | SimpleCompaction 机制 | 都试图解决长上下文问题,OpenViking 更系统化 |
| 目录递归检索 | Grep + Glob 工具 | Kimi 需要显式调用工具,OpenViking 内置递归检索 |
/memory 目录 | Session 持久化 + Context | 都关注记忆的长期存储 |
| 自迭代 | D-Mail 时间旅行 | 都实现了 Agent 的自我进化机制 |
/skills 目录 | Skill 系统 | 都用文件/目录组织技能 |
潜在结合点
1. OpenViking 作为 Kimi Code CLI 的上下文存储后端
# 未来可能的集成方式
from kimi_cli.context import OpenVikingContext
context = OpenVikingContext(
viking_uri="viking://sessions/my-project",
enable_layered_loading=True # 启用 L0/L1/L2
)
2. 将 Kimi 的 Agent Spec 映射到 OpenViking 的 /skills
viking://
└── /skills
├── /kimi-cli
│ ├── /default
│ ├── /code-reviewer
│ └── /data-analyst
└── /user-custom
└── /my-special-agent
3. 用 OpenViking 的分层检索优化 Kimi 的 Context Compaction
当前 Kimi 的 SimpleCompaction 保留最近 2 条消息,可能不是最优策略。可以借鉴 OpenViking 的 L0/L1/L2 分层思想:
# 分层 Compaction 策略
class LayeredCompaction:
def compact(self, messages):
# L0: 任务状态摘要
# L1: 关键决策和错误
# L2: 完整代码(按需加载)
pass
---
📚 相关资源
- GitHub: https://github.com/volcengine/OpenViking
- 官网: https://openviking.ai
- 知乎介绍: https://zhuanlan.zhihu.com/p/2000634266720161814
- 社区: 飞书群(GitHub 页面扫码加入)
💬 总结
OpenViking 代表了 AI Agent 上下文管理的一个重要方向:
> 从碎片化的向量存储,走向结构化的文件系统范式。
它的核心理念 —— "Everything is a File" —— 与 Unix 哲学一脉相承,为 Agent 上下文管理提供了一个极简而强大的抽象。
对于 Kimi Code CLI 用户来说,OpenViking 提供了一个潜在的更强大的上下文存储和检索后端,值得关注和探索。
---
*文章整理时间:2026-02-23* *资料来源:GitHub、知乎、官网*