AI-DIVE
登录订阅
深度·Neo·2026.04.19

OpenViking：字节把 AI Agent 的上下文管理做成了文件系统

OpenViking 不是又一个向量库，而是在把 Agent 的记忆、资源和技能统一成可递归、可观察、可分层加载的上下文数据库。

OpenViking：字节把 AI Agent 的上下文管理做成了文件系统

建议摘要：OpenViking 不是又一个向量库，而是在把“Agent 的记忆、资源、技能”统一收进一个可递归、可观察、可分层加载的上下文数据库里。它更像 Agent 时代的上下文操作系统，而不是传统 RAG 工具。

先说结论

如果你只把 OpenViking 看成“开源向量检索项目”，会低估它。

它真正想做的，是把 AI Agent 运行时最麻烦的一层——上下文管理——做成基础设施：

  • 记忆不再散落在 prompt、代码、向量库和临时缓存里
  • 资源不再只是扁平文档，而是可按目录组织、递归检索的上下文树
  • 技能不再只是工具函数，而是可被调用、可被沉淀、可被复用的上下文资产
  • 会话不再只是聊天记录，而是能提炼长期记忆的成长过程

一句话概括：

OpenViking 不是“更好的 RAG”，而是在尝试做 Agent 时代的上下文操作系统。

这个项目到底在解决什么问题

传统 RAG 和普通记忆系统，最常见的问题有几个：

  1. 上下文碎片化

    • 记忆在对话记录里
    • 文档在知识库里
    • 技能在代码里
    • 结果就是：Agent 很难统一理解“我现在到底拥有什么上下文”

  2. 长任务会膨胀

    • Agent 一跑就是几十轮
    • 上下文越来越大
    • 直接截断会丢信息，直接压缩又容易损失关键细节

  3. 检索是黑盒

    • 扁平向量检索能找相似，但很难解释“为什么是这段”
    • 一旦错召回，调试体验很差

  4. 记忆不会自己进化

    • 很多系统只是“存对话”
    • 但真正有价值的是：把对话里的偏好、事件、模式、工具经验提炼出来

OpenViking 的思路，是把这些问题统一收口到一个文件系统范式里解决。

项目概览

  • 仓库：volcengine/OpenViking
  • 维护方：字节跳动 / 火山引擎
  • 许可证：AGPL-3.0
  • 创建时间：2026-01-05
  • 最新 Release：v0.3.9（2026-04-18）
  • Stars：约 22.5k
  • 定位：面向 AI Agents 的 Context Database

它的定位不是“一个工具”，而是“Agent 的上下文底座”。

架构拆解：文件系统 + 分层上下文 + 递归检索

OpenViking 的核心抽象很统一：
它把所有上下文都变成一个 viking:// 风格的虚拟文件系统。

总体架构图

flowchart TB A[Client\nSync / Async / HTTP / CLI] B[Service Layer\nFS / Search / Session / Resource / Relation] C[VikingFS\nviking:// 虚拟文件系统] D[AGFS\n文件存储层] E[queuefs\nSemanticQueue / EmbeddingQueue] F[SemanticProcessor\n生成 L0/L1 + 向量化] G[Vector Index] H[Session System\ncommit / archive / memory extraction] I[Retrieval\nintent analysis + recursive search + rerank] A --> B --> C B --> H C --> D C --> E E --> F F --> G H --> C B --> I I --> C

三种上下文类型

OpenViking 不是只存文档，它把上下文分成三类：

  • Resource：知识和规则，比如文档、FAQ、代码仓库
  • Memory：Agent 的长期记忆，比如用户偏好、事件、模式
  • Skill：可调用能力，比如工具、MCP、工作流

对应路径大致是：

viking://resources/...
viking://user/memories/...
viking://agent/skills/...

这一步很关键。
因为它不是把所有东西都混成“文本块”，而是从一开始就给上下文分了角色。

核心机制 1：L0 / L1 / L2 三层上下文

OpenViking 的另一个核心，是把内容分成三层：

flowchart TB L2[L2 原文 / 原始文件] L1[L1 .overview.md\n导航型摘要] L0[L0 .abstract.md\n极短摘要] V[向量检索] R[Rerank / 路径理解] O[按需读取原文] L2 -->|bottom-up 生成| L1 L2 -->|bottom-up 生成| L0 L0 --> V L1 --> R L2 --> O

这三层分别干什么

  • L0
    • 很短
    • 适合快速过滤和向量召回
  • L1
    • 更完整
    • 适合 rerank 和理解目录结构
  • L2
    • 原始内容
    • 真正需要细节时再加载

这个设计的价值

它解决的是“上下文不能一次性全塞给模型”的问题。
先给一个极短摘要，再给导航摘要，最后才给原文。

这会带来两个好处：

  1. 省 token
  2. 更容易按层级理解内容

对 Agent 来说，这比“把所有资料直接拼 prompt”合理得多。

核心机制 2：递归检索，不是扁平搜索

OpenViking 的检索不是单纯“搜相似文本”，而是：

  1. 先做 intent analysis
  2. 生成 0–5 个 TypedQuery
  3. 在对应根目录做全局搜索
  4. 再在目录树里递归深入
  5. 最后 rerank

检索流程图

flowchart LR Q[用户查询] --> IA[Intent Analysis] IA --> TQ[TypedQuery] TQ --> GS[Global Search] GS --> HQ[Recursive Directory Search] HQ --> RK[Rerank] RK --> R[返回结果]

为什么这比普通 RAG 更适合 Agent

因为 Agent 的真实任务通常不是“找一句话”，而是：

  • 找一个项目的语境
  • 找一个目录下的一组资料
  • 找一个事件背后的长期记忆
  • 找一组能配合执行的技能

也就是说，它要找的不是“片段”，而是上下文子树。

OpenViking 的递归检索，本质上是在模拟人类理解资料的方式：

先看目录，再看摘要，再决定要不要看全文。

核心机制 3：Session commit 会提炼长期记忆

OpenViking 还有一个很重要的点：
它不是只保存会话，而是把会话变成长期资产。

从文档和源码看，session 的生命周期大概是：

  • 创建
  • 交互
  • commit
  • archive
  • 提炼摘要
  • 提取长期记忆

记忆提取的 8 类

  • profile
  • preferences
  • entities
  • events
  • cases
  • patterns
  • tools
  • skills

这意味着：

它不是“保存聊天记录”，而是“把交互蒸馏成可复用上下文”。

这点非常适合长期运行的 Agent。

技术实现上的几个亮点

1) viking:// URI 是统一入口

这个设计很妙。
它把上下文从“零散路径”统一成了一个地址空间。

好处是：

  • 能定位
  • 能递归
  • 能授权
  • 能解释
  • 能可视化

2) SemanticProcessor 自底向上生成摘要

源码里有一个很明确的底层处理器：
它会对目录里的内容做自底向上的语义处理，生成 .abstract.md 和 .overview.md，再送去向量化。

这让“层级上下文”不是概念，而是工程上真的可执行。

3) find() 和 search() 分层

  • find()：轻量语义查询
  • search()：复杂任务检索，会结合 session 语境和意图分析

这说明它没有把所有检索压成一个 API，而是区分了“查资料”和“做任务”。

优势与不足

优势

1. 上下文建模很对路
它把 Resource / Memory / Skill 分开，特别符合 Agent 场景。

2. 文件系统范式很直观
比纯向量库更容易理解、调试和协作。

3. 分层上下文能省成本
L0 / L1 / L2 让检索和加载更像“渐进展开”。

4. 有自迭代能力
session commit 会产生长期记忆，不只是存档。

5. 社区热度高
22.5k stars + 最新 release，说明不是概念稿。

不足

1. 系统偏重
它同时包含：

  • 文件系统
  • 检索
  • 向量索引
  • session
  • queue
  • prompt 模板
  • CLI / server / HTTP

这意味着学习和部署成本不低。

2. 依赖面广
模型、embedding、rerank、存储、CLI、服务端都要配好，排障会比轻量 RAG 更复杂。

3. AGPL 对商业团队有门槛
如果你要闭源商用，这个许可证需要认真评估。

4. 仍处于 Alpha
方向很强，但还不能把它当成“完全成熟的生产标准件”。

适合谁

最适合

  • 做 Agent 平台的人
  • 做上下文管理 / 长任务记忆的人
  • 想要可解释检索的人
  • 想做“Agent OS”或“Context Layer”的团队

不太适合

  • 只想快速搭一个简单 RAG 的团队
  • 不想处理复杂部署和依赖的人
  • 强闭源、对 AGPL 敏感的商业团队

我的判断

如果把 OpenViking 放到整个 Agent 基础设施赛道里看，我会把它归类为：

非常值得关注的“上下文底座”方向项目。

它最有价值的地方，不是“检索更强”，而是它在尝试回答一个更底层的问题：

Agent 的上下文，到底应该怎么组织？

OpenViking 的答案是：

  • 用文件系统组织
  • 用层级摘要压缩
  • 用递归检索理解语境
  • 用 session commit 提炼记忆
  • 用技能和资源统一成可调用上下文

这套思路，比传统扁平向量库更接近 Agent 的真实工作方式。

一句话总结

OpenViking 不是更好的向量库，而是在把 Agent 的上下文管理做成一套可递归、可观察、可成长的操作系统。

结论

OpenViking 最有价值的地方，不是“检索更强”，而是它在尝试回答一个更底层的问题：

Agent 的上下文，到底应该怎么组织？

它给出的答案是：

  • 用文件系统组织
  • 用层级摘要压缩
  • 用递归检索理解语境
  • 用 session commit 提炼记忆
  • 用技能和资源统一成可调用上下文

这套思路，比传统扁平向量库更接近 Agent 的真实工作方式。

一句话总结：OpenViking 不是更好的向量库，而是在把 Agent 的上下文管理做成一套可递归、可观察、可成长的操作系统。