AI摘要
我把 OpenViking 当前仓库、架构文档、检索机制、Memory、Codex 集成、多租户和部署文档都看了一遍。这个项目值得重点关注。
先给一个定位：
OpenViking 不是传统向量数据库，也不只是 RAG，更不是简单的 Agent Memory。它试图做的是“AI Agent 的 Context Database（上下文数据库）”。
它把 企业知识 Resource、长期记忆 Memory、Agent 技能 Skill 统一放进一个可检索、可浏览、可审计、可持续演化的“虚拟文件系统”里。官方仓库描述就是：Self-evolving Context Database for AI Agents，统一 Agent Memory、Knowledge RAG 和 Skills。 当前仓库约 3.29 万 Star、2512 Fork，2026 年 8 月 24 日仍在高频提交，许可证为 AGPL-3.0。
一、OpenViking 到底解决什么问题？
传统企业 AI 系统一般长这样：
企业 Agent
│
┌───────────┼───────────┐
↓ ↓ ↓
知识库 Agent Memory Skill
│ │ │
pgvector Redis/DB SKILL.md
│
RAG系统结果是：
- 知识是一套系统；
- Memory 是另一套系统；
- Skill 又存在文件系统；
- 会话存在数据库；
- Agent 不知道知识到底在哪里；
- Vector Search 返回一堆 Chunk；
- Debug 很困难；
- 上下文越来越长；
- Token 越来越贵。
OpenViking 想把它变成：
AI Agent
│
↓
OpenViking Context DB
│
viking://
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Resource Memory Skill
│ │ │
企业知识 长期记忆 Agent能力
│ │ │
└───────────────┼───────────────┘
↓
统一检索系统
↓
Agent Context这就是它最大的思想创新。
二、最重要的概念：Context Database
传统 RAG 的思想基本是：
PDF
↓
解析
↓
Chunk
↓
Embedding
↓
Vector DB
↓
TopK
↓
LLMOpenViking 认为这种方式对真正的 Agent 不够。
因为 Agent 需要的不只是 Knowledge。
Agent 实际上需要：
Context
│
├── 我知道什么？
│ └── Resource
│
├── 我记得什么？
│ └── Memory
│
├── 我会做什么？
│ └── Skill
│
├── 我刚才做了什么？
│ └── Session
│
└── 我过去是怎么成功完成任务的？
└── Experience / Trajectory于是 OpenViking 引入：
Context Database
这是理解 OpenViking 的第一关键点。
三、OpenViking 的三种核心上下文
官方把 Context 分成三类：
| Context | 中文理解 | 内容 |
|---|---|---|
| Resource | 外部知识 | 文档、代码、制度、手册 |
| Memory | Agent 记忆 | 用户偏好、事件、经验 |
| Skill | Agent 能力 | SKILL.md、脚本、工具配置 |
这三个概念非常重要。
1. Resource
Resource 基本对应传统 RAG Knowledge。
比如：
公司制度
合同
技术文档
CRM说明书
代码仓库
API文档
产品手册
FAQ例如：
viking://resources/
├── CRM/
├── OA/
├── KDBOSS/
├── contracts/
├── finance/
└── regulations/四、Memory 比传统聊天记忆高级很多
OpenViking 的 Memory 分类已经比较完整。
官方内置包括：
Memory
│
├── profile
├── preferences
├── entities
├── events
├── identity
├── soul
├── cases
├── trajectories
└── experiences这实际上已经开始形成：
Agent Cognitive Memory Model
例如：
Profile
用户是谁
职业
长期背景
项目背景Preferences
用户喜欢怎样回答
代码风格
文档格式
工作习惯Entities
客户A
项目B
系统C
供应商DEvents
项目立项
需求确认
架构变更
重大决策Cases
过去解决过的问题。
Trajectories
完成任务的执行路径。
例如：
需求分析
↓
数据库设计
↓
接口设计
↓
生成代码
↓
测试
↓
修复Experiences
把成功和失败的执行结果进一步提炼为经验。
这个就非常重要了：
Memory 开始从“用户记忆”升级成“Agent 工作经验”。
五、它真正厉害的地方：Memory 会自己演化
传统 Memory 经常是：
聊天记录
↓
Embedding
↓
Vector DBOpenViking 的流程是：
Conversation
↓
Session
↓
commit()
↓
LLM提取候选Memory
↓
Vector预筛
↓
找到相似Memory
↓
LLM判断
┌───┼────┐
↓ ↓ ↓
新增 合并 删除
↓
写入Memory
↓
重新Vectorize官方甚至定义了：
skip
create
merge
delete等决策。
也就是说：
原来：
用户喜欢 PostgreSQL后来：
用户更喜欢 PostgreSQL + PostGIS系统不一定再生成第二条 Memory。
它可以：
旧Memory
+
新信息
↓
Merge
↓
新Memory而且每次 session.commit() 都会生成：
memory_diff.json记录：
新增什么
修改什么
删除什么
为什么跳过因此 Memory 是可审计的。
这一点我认为非常有价值。
六、第二个核心思想：viking:// 虚拟文件系统
OpenViking 没有要求 Agent 面对黑盒 Vector DB。
而是给 Agent 一个类似 Linux 的文件系统：
viking://例如：
viking://
│
├── resources/
│ ├── ERP/
│ ├── CRM/
│ └── contracts/
│
└── user/
└── sam/
├── memories/
├── resources/
├── skills/
├── peers/
└── sessions/Agent 可以：
ls
tree
find
grep
read官方 Service Layer 甚至直接提供：
ls
mkdir
rm
mv
tree
stat
read
abstract
overview
grep
glob
find
search这个设计非常聪明。
因为 LLM 本身就非常理解文件系统。
Codex 更是如此。
所以：
Vector DB 思维
Agent
↓
search("xxx")
↓
TopK chunks变成：
Filesystem 思维
Agent
↓
ls
↓
tree
↓
find
↓
overview
↓
read更加符合 Agent 自主探索 Context 的方式。
七、L0 / L1 / L2：OpenViking 最值得研究的设计之一
OpenViking 没有直接把完整文档扔给 Agent。
它建立三层 Context：
| 层 | 含义 | 默认规模 | 用途 |
|---|---|---|---|
| L0 | Abstract | 256 字符 | 快速判断相关性 |
| L1 | Overview | 4000 字符 | 理解目录内容 |
| L2 | Detail | 原始数据 | 真正使用 |
例如：
viking://resources/KDBOSS/
├── .abstract.md
├── .overview.md
│
├── architecture/
│ ├── .abstract.md
│ ├── .overview.md
│ ├── database.md
│ └── api.md
│
└── billing/
├── .abstract.md
├── .overview.md
├── billing-engine.md
└── invoice.md这里：
L0
可能只有：
KDBOSS 是一套运营商宽带业务运营支撑系统。
只需要几十到几百 Token。
L1
可能是：
KDBOSS
├── 系统架构
├── 客户管理
├── 资源管理
├── 产品管理
├── 计费
├── 结算
└── 财务Agent 看 L1 就知道：
“我要找计费。”
于是继续进入：
billing/L2
才加载：
billing-engine.md完整内容。
于是 Context 加载变成：
L0
↓
相关？
↓ YES
L1
↓
需要深入？
↓ YES
L2而不是：
Top 20 chunks
全部塞进Prompt八、这本质上解决了 Token 浪费问题
传统 RAG：
Query
↓
TopK = 20
↓
20个Chunk
↓
Prompt
↓
30K TokenOpenViking：
Query
↓
L0
↓
找到目录
↓
L1
↓
找到目标
↓
只读取必要L2因此：
Progressive Context Loading
是 OpenViking 很重要的一条技术路线。
官方基准报告称，在其 LoCoMo 测试中，接入 OpenViking 后三个 Agent 的长期记忆准确率达到约 80–83%；官方同时报告输入 Token 降低 34.3%–91.0%。这些数字应理解为官方特定模型、特定 benchmark 下的测试结果，而不是所有场景都能直接复现。
九、它不是简单 Vector Search，而是“目录递归检索”
这是第三个我认为很优秀的设计。
传统向量搜索：
Query
↓
Vector Search
↓
TopK ChunkOpenViking：
Query
↓
Intent Analysis
↓
Global Vector Search
↓
找到相关目录
↓
进入目录
↓
搜索子目录
↓
继续向下
↓
Rerank
↓
找到最终内容官方称：
Hierarchical Retrieval
内部使用优先队列递归搜索目录。
大致：
Query
│
Intent Analyzer
│
Typed Queries
│
↓
Global Vector Search
│
找到相关目录
↓
/CRM
│
┌────────┼────────┐
↓ ↓ ↓
customer billing product
│
↓
billing
│
┌────┴────┐
↓ ↓
invoice payment
│
↓
最终文件这和人查资料的方法非常接近。
十、它还有 Intent Analyzer
复杂任务不是直接拿原问题搜索。
例如用户问：
帮我根据公司的付款制度生成一份付款申请。
OpenViking 可以拆成：
Resource Query
→ 公司付款制度
Memory Query
→ 用户历史付款习惯
Skill Query
→ 创建付款申请也就是：
Query
↓
Intent Analyzer
↓
0~5 TypedQuery
↓
┌────────┬─────────┬────────┐
↓ ↓ ↓
Memory Resource Skillsearch() 会使用 Session 上下文和 LLM 进行 Query Planning；find() 则适合低延迟的简单单查询。
这是典型的：
Agentic Retrieval
而不仅是 Semantic Search。
十一、底层存储设计也很值得研究
OpenViking 使用：
VikingFS
│
┌────────┴────────┐
↓ ↓
AGFS Vector Index
│ │
Content Index非常重要的一点：
Vector DB 不是数据源。
Vector Index 只保存：
URI
Vector
Metadata真正的数据保存在：
AGFS / RAGFS也就是：
Single Source of Truth
↓
AGFSVector DB：
只是 Index我非常认同这个设计。
十二、AGFS / RAGFS 是什么？
官方文档目前说明 AGFS 已经重写为：
Rust 实现的 RAGFS
存储 Backend 支持：
localfs
s3fs
memory因此企业部署可以：
OpenViking
Content
↓
S3 / MinIO / 对象存储
Index
↓
Local Vector
或
VikingDB而且 Vector 层可以独立扩展。
十三、Vector Index 不是单纯 Dense Vector
它的 Context Index 包括：
dense vector
+
sparse vector默认设计文档显示：
IndexType = flat_hybrid
Distance = cosine
Quant = int8Vector Backend 支持：
local
http
Volcengine VikingDB所以从架构概念上看已经接近：
Dense Semantic
+
Sparse Keyword
+
Hierarchy
+
Reranker比单独：
BGE-M3
+
pgvector HNSW高一层。
十四、OpenViking 与 pgvector 的关系
这两个其实不应该直接比较。
pgvector 是：
Vector Storage / Vector Search EngineOpenViking 是：
Context Management Platform更准确地说：
OpenViking
│
├── Context Model
├── Virtual FS
├── Resource
├── Memory
├── Skill
├── Session
├── Retrieval
├── Rerank
├── Parsing
└── Vector Index而：
pgvector只解决其中：
Vector Index这一层。
所以：
OpenViking 更像“RAG + Memory + Skill + ContextFS + Retrieval Engine”的组合体。
十五、文档处理能力也已经比较完整
从当前依赖可以看到：
PDF
DOCX
PPTX
XLS/XLSX
EPUB
HTML/Web
代码仓库并且代码解析引入 Tree-sitter，覆盖：
Python
JavaScript
TypeScript
Java
C++
Rust
Go
C#
PHP
Lua同时包括：
pdfplumber
python-docx
python-pptx
openpyxl
Scrapy
trafilatura
Tree-sitter等。
所以它明显不仅瞄准“文档 RAG”。
也瞄准：
Coding Agent Context。
十六、它已经原生支持 Codex
这一点尤其值得关注。
OpenViking 有专门：
Codex Memory Plugin
其工作机制是：
Codex启动
↓
SessionStart
↓
加载Profile
↓
加载Memory索引
↓
用户输入Prompt
↓
自动Recall OpenViking
↓
相关Memory注入Context
↓
Codex工作
↓
Stop
↓
捕获新对话
↓
PreCompact
↓
Commit Session
↓
提取长期Memory因此可以实现：
Codex 今天做项目
↓
OpenViking 记录
↓
明天重新打开 Codex
↓
Codex 自动知道：
- 项目是什么
- 以前做了什么
- 用户的代码风格
- 架构决策
- 遇到过哪些Bug
- 怎么解决的这已经开始解决 Coding Agent 很核心的问题：
跨 Session Continuity。
十七、还提供 MCP
OpenViking 自带：
/mcp任何 MCP Client 可以连接。
包括官方文档列出的：
Cursor
Trae
Manus
Claude Desktop
ChatGPT
OpenCode
Codex
Claude Code所以：
OpenViking
│
MCP
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Codex Claude Code Cursor
↓ ↓ ↓
Agent Agent Agent多个 Agent 可以共享一个 Context 基础设施。
这个意义非常大。
十八、它正在形成 Agent Context Hub
因此一个企业可以部署：
Enterprise Agent Platform
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Codex Department Agent AI Assistant
│ │ │
└────────────────┼────────────────┘
↓
OpenViking
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Resource Memory Skill
│ │ │
企业知识 企业记忆 Agent技能这里 OpenViking 扮演的其实是：
Enterprise Context Infrastructure
而不是 Knowledge Base。
十九、多租户能力已经有了
企业级应用最关心的问题之一就是权限。
OpenViking 目前建立：
Account
↓
User
↓
Peer三个层级。
其中：
Account
类似：
企业
租户
WorkspaceUser
企业内部用户。
Peer
用户对应的交互对象。
权限角色：
ROOT
ADMIN
USER资源共享关系是：
Account
│
├── Shared Resources
│
├── User A
│ ├── Private Resources
│ ├── Memories
│ ├── Skills
│ └── Sessions
│
└── User B
├── Private Resources
├── Memories
├── Skills
└── Sessions同 Account 可以共享公共 Resource，但是 Memory 默认按用户隔离。
这个设计非常适合企业。
二十、数据加密也已经考虑
OpenViking 已提供静态数据透明加密。
采用三层：
Root Key
↓ HKDF
Account Key / KEK
↓
File Key / DEK
↓
File Content文件内容使用：
AES-256-GCMKey Provider 支持：
Local
HashiCorp Vault
Volcengine KMS因此它并不是完全按照个人开发工具来设计，而明显考虑了：
企业
SaaS
多租户
私有部署
合规环境二十一、部署方式
非常标准。
最简单：
pip install openviking --upgrade
openviking-server init
openviking-server doctor
openviking-server需要：
Python >= 3.10默认：
OpenViking Server
http://localhost:1933Docker：
docker run -d \
--name openviking \
-p 1933:1933 \
-v ~/.openviking:/app/.openviking \
ghcr.io/volcengine/openviking:latest还提供：
Docker Compose
Systemd
Kubernetes
Helm以及：
/health
/ready健康检查。
所以从部署模型看已经比较完整。
二十二、一个企业部署可以设计成这样
我比较推荐：
企业 Agent 平台
│
┌─────────────────┼─────────────────┐
↓ ↓ ↓
Codex 企业Agent 部门Agent
│ │ │
└─────────────────┼─────────────────┘
│
MCP
│
OpenViking API
│
┌─────────────────┼─────────────────┐
│ │ │
↓ ↓ ↓
Resource Memory Skill
│ │ │
└─────────────────┼─────────────────┘
│
VikingFS
│
┌────────────┴────────────┐
↓ ↓
RAGFS Vector Index
│ │
MinIO VikingDB
│ / Local
↓
企业文件如果完全私有化：
LLM
→ Qwen / DeepSeek
Embedding
→ BGE-M3
Reranker
→ BGE-Reranker
Storage
→ MinIO
OpenViking
→ Context Database
Agent
→ Codex / Eino / 自研 Agent这是非常有想象力的一套架构。
二十三、和传统 RAG 做个直接对比
| 能力 | 传统 RAG | OpenViking |
|---|---|---|
| 文档知识 | ✅ | ✅ |
| Chunk | ✅ | ✅/结构化处理 |
| Embedding | ✅ | ✅ |
| Vector Search | ✅ | ✅ |
| Hybrid Search | 部分 | ✅ |
| Rerank | 部分 | ✅ |
| 层级检索 | 较弱 | ✅ |
| 虚拟文件系统 | ❌ | ✅ |
| L0/L1/L2 | ❌ | ✅ |
| Agent Memory | ❌ | ✅ |
| Memory 演化 | ❌ | ✅ |
| Skill 管理 | ❌ | ✅ |
| Session | ❌ | ✅ |
| MCP | 外加 | ✅ |
| Codex | 外加 | ✅ |
| 多租户 | 自建 | ✅ |
| Memory 审计 | ❌ | ✅ |
所以：
如果说传统 RAG 是“给 LLM 装一个知识外挂”，OpenViking 更像“给 Agent 建一个长期上下文文件系统”。
二十四、它与“企业知识库”的关系
我认为这是最重要的认识。
不要把 OpenViking 理解成：
企业知识库 2.0。
更准确的是：
企业知识库
↓
只是 OpenViking Resource 的一部分完整体系：
Enterprise Context
│
├── Knowledge Context
│ ↓
│ Resource
│
├── Historical Context
│ ↓
│ Memory / Events
│
├── Personal Context
│ ↓
│ Profile / Preferences
│
├── Agent Experience
│ ↓
│ Cases / Trajectories / Experiences
│
└── Capability Context
↓
Skills这就比：
向量数据库高了一个架构层次。
二十五、但它现在也有几个明显风险
这一点不能忽视。
① 项目仍然很年轻
仓库创建于：
2026 年 1 月 5 日。
而 pyproject.toml 当前仍明确标记：
Development Status :: 3 - Alpha所以：
架构思想已经很先进，但企业长期稳定性还需要时间验证。
② 迭代速度非常快
这既是优点也是风险。
昨天和今天的：
配置
API
目录结构
插件接口都有可能发生变化。
因此生产项目要：
固定版本
+
充分测试
+
不要直接追 latest③ L0/L1 会增加写入成本
传统 RAG：
Chunk
↓
EmbeddingOpenViking：
Parse
↓
Tree
↓
L1
↓
L0
↓
Parent L1
↓
Parent L0
↓
Embedding因此：
写入明显更重，但读取更智能。
这是一种典型：
Write Heavy
换取
Read Efficient的设计。
官方文档甚至明确记录了父目录 Semantic 刷新仍存在进一步降低 write amplification 的 TODO。
这个细节说明项目仍处于高速工程化阶段。
二十六、AGPL 要特别注意
仓库许可证是：
AGPL-3.0
如果只是：
企业内部使用通常问题相对简单。
但是如果准备：
二次开发
+
SaaS
+
对外提供网络服务就一定要让法务评估 AGPL 的网络交互源码义务。
因此如果要基于它直接做商业 SaaS：
License 是必须先评审的一项，不要等产品做完才处理。
二十七、我对 OpenViking 的评价
如果按几个维度评分：
| 维度 | 评价 |
|---|---|
| 架构思想 | ⭐⭐⭐⭐⭐ |
| Agent 时代方向 | ⭐⭐⭐⭐⭐ |
| Context Engineering | ⭐⭐⭐⭐⭐ |
| Memory | ⭐⭐⭐⭐⭐ |
| RAG | ⭐⭐⭐⭐½ |
| Codex 集成 | ⭐⭐⭐⭐⭐ |
| 企业级设计 | ⭐⭐⭐⭐ |
| 当前成熟度 | ⭐⭐⭐ |
| 二次开发价值 | ⭐⭐⭐⭐⭐ |
综合我会给：
9 / 10
但这个 9 分主要是：
架构方向和战略价值。
如果只按照：
“现在是否应该马上作为企业核心生产基础设施？”
评分，我会给：
7 / 10。
原因就是：
项目年轻
+
Alpha
+
高速变化
+
企业生产案例仍需沉淀二十八、我认为 OpenViking 最有价值的地方
不是某个具体算法。
而是它提出了一个非常正确的抽象：
过去：
Vector Database后来：
Knowledge Base再后来：
RAG Platform现在：
Agent Memory而 OpenViking 往前推了一步：
Context Database
我认为这个方向很可能成为 Agent 时代的重要基础设施层：
Application
│
Agent
│
Agent Runtime
│
Context Database
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Knowledge Memory Skill
│ │ │
└───────────────┼───────────────┘
│
Enterprise Data二十九、尤其值得关注：它和 Codex 的组合
我认为这是 OpenViking 当前最值得实验的一条路线：
Codex
│
Memory Plugin
│
MCP
│
OpenViking
│
┌─────────────┼─────────────┐
↓ ↓ ↓
项目知识 历史记忆 Skills
│ │ │
Source Code Decisions Tools
Documents Experience Workflow这样 Codex 就开始从：
“一次性聪明的 Coding Agent”
升级为：
“了解公司、了解项目、了解历史、了解开发习惯并持续积累经验的工程 Agent”。
OpenViking 的 Codex 插件目前已经支持 SessionStart 自动加载 Profile、每次 Prompt 自动 Recall、Stop 后捕获新 Turn、PreCompact 前 Commit 完整会话，同时通过 MCP 暴露 find / search / read / remember 等能力。
这是我认为它最值得关注的现实用途。
三十、最终一句话理解
如果把：
PostgreSQL
理解为：
企业结构化 Data Database
把：
pgvector / Milvus
理解为：
Vector Database
那么：
OpenViking
可以理解成：
Agent Context Database
它管理的是：
Agent到底应该知道什么
+
记住什么
+
会做什么
+
过去做过什么
+
这一次应该读取多少
+
从哪里读取
+
为什么检索到了这些内容所以我认为，OpenViking 的战略价值明显高于“又一个向量知识库项目”。它代表的是从 RAG → Context Engineering → Context Database 的演进方向。
如果你现在要研究“企业 Agent 的统一上下文底座”，我会把 OpenViking、TencentDB-Agent-Memory、传统 PostgreSQL + pgvector + BGE-M3 放在一起做一次架构级比较；三者其实分别代表了三条不同路线，这个比较会非常有价值。
CONVERSATION
Leave a signal.
还没有评论，留下第一个想法吧。