字节跳动开源 OpenViking：专为 AI Agent 设计的上下文数据库

# 🚀 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 可以像操作本地文件一样管理上下文： ```python # 浏览目录 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. 可观测与自迭代 **上下文白盒化 + 自动进化** **可观测性：** - 层次化虚拟文件系统结构，一目了然 - 检索过程完整留存（目录浏览、文件定位轨迹） - 可视化检索路径，清晰观测问题根源 **自迭代机制：** ```python # 会话结束时调用 client.session.commit() ``` 系统自动： - 分析任务执行结果与用户反馈 - 更新 `/memory/user`（用户偏好） - 更新 `/memory/agent`（操作技巧、工具使用经验） - 提取长期记忆 **效果：** Agent 在与世界的交互中 **"越用越聪明"** --- ## 🛠️ 快速上手 ### 第一步：安装 ```bash pip install openviking ``` ### 第二步：配置模型服务 支持多种模型服务： - **火山引擎（豆包模型）**：推荐，成本低、性能好 - **OpenAI**：GPT-4V 等 VLM 模型 - **自定义模型**：兼容 OpenAI API 格式 创建配置文件 `ov.conf`： ```json { "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 } } } ``` 设置环境变量： ```bash export OPENVIKING_CONFIG_FILE=ov.conf ``` ### 第三步：运行示例 ```python 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 的上下文存储后端** ```python # 未来可能的集成方式 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 分层思想： ```python # 分层 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、知乎、官网*