OpenViking vs Claude Code 记忆机制深度对比

OpenViking 的核心赌注：把 Agent 的"记忆 + 资源 + 技能"全部塞进一个虚拟文件系统（viking://），按 L0/L1/L2 三层粒度按需加载，Agent 像逛文件夹一样找上下文。

Claude Code 的设计哲学：极简、文件即记忆。CLAUDE.md 一次性注入 + Auto Memory 自动学习，没有数据库、没有向量、没有协议。

本质区别：OpenViking 是给"长期自治 Agent"做的基础设施；Claude Code Memory 是给"开发者一次开发会话"做的状态延续。两者解决的不是同一个问题。

01OpenViking 的三个核心创新

不要被"上下文数据库"这个名字骗了——它跟主流 RAG 在范式上是反着的。

PILLAR 01

文件系统范式

所有上下文用 viking:// URI 表达，目录 = 语义分类，可以用 ls / find / tree 像 Linux 一样探索。彻底告别 RAG 的"黑盒向量空间"。

PILLAR 02

L0/L1/L2 分层

每个节点都有三种粒度：摘要 → 概览 → 全文。Agent 先在 L0 里筛，再在 L1 里规划，只在真正需要时才加载 L2 全文。Token 消耗指数级下降。

PILLAR 03

目录递归检索

检索不是单次向量召回，而是"先定位目录 → 再目录内递归 → 最后 rerank"。结构化路径补偿了向量检索语义漂移的缺陷。

在文件系统里，每个目录都长这样：

顶层目录约定了语义类别：resources/（外部资料）、user/（用户记忆和偏好）、agent/（Agent 自己学到的案例和模式）、session/（当前会话）。这个分类本身就是一种 prior knowledge。

02三层信息模型怎么省 Token

"渐进式加载"这个理念在 RAG 圈不新，但 OpenViking 把它做成了一等公民。

Abstract 摘要

~100 tokens

一句话总结，用于向量检索和快速过滤。相当于一个"信息丰富的文件名"。

Overview 概览

~2,000 tokens

核心内容、结构、使用场景。Agent 做规划决策时通常这一层就够了。相当于 README。

Detail 全文

按需

原始全部数据，只在 Agent 真正要"深读"时才通过 URI 加载。

官方在 LoCoMo10 数据集上的对比（OpenClaw + OpenViking）

任务完成率

35.65% → 52.08% +46%

输入 Token 消耗

24.6M → 4.3M −82%

开启 memory-core 选项

→ 2.1M −91%

⚠️ 这是项目方自己跑的 benchmark，要打折看。但即使打对折，这个 token 削减幅度对长程 Agent 也是质变。

03过人之处与局限性

客观看待，避免一边倒。

✓ 相对主流 RAG/Mem 的优势

可观测：上下文不是黑盒向量，而是可以 tree、cat 查看的文件结构，调试 / 审计成本骤降。
统一抽象：memory、resources、skills 三种东西过去往往散在三个地方，OpenViking 用同一个 URI 协议串起来。
Agent 自迭代：agent/memories/cases/、patterns/ 这种目录让 Agent 记录"自己解决过类似问题的方法"，不只是用户聊天记录。
分层加载 = 真省钱：传统 RAG 不管问的是啥都召回固定大小的 chunks，OpenViking 让 Agent 自己决定加载到哪一层。
多模态原生：通过 VLM 把图像也纳入同一套文件系统，不需要外挂一套图像 RAG。

− 不可忽视的局限

太年轻：v0.2.x，2026 年 1 月才开源。生产案例少，踩坑成本由早期用户买单。
运维不轻：要跑 Embedding 模型（Qwen3-Embedding-0.6B）+ VLM（Qwen3-32B）+ 服务进程，单机部署就要 GPU。比 CLAUDE.md 那种零部署高一个量级。
摘要质量决定一切：L0/L1 是 LLM 生成的——如果摘要写得烂，整套检索都崩。"垃圾摘要 = 垃圾检索"。
生态绑定 ByteDance：默认走火山引擎模型链路，替换其他 embedding/VLM 需要改 ov.conf，有学习成本。
写入开销：每次 ingest 都要切片 → 生成摘要 → 嵌入。短会话场景下这套流水线是过度设计。
已知 bug：截至 4 月，openviking-mcp 桥接器还存在硬编码 Cloudwise 路径、不读 OPENVIKING_API_KEY 等问题（Issue #606）。
三层粒度是人为约定：现实中很多内容并不天然分三层，强行套模板可能让 L1 既不够细又冗余。

04Claude Code 的记忆机制

没有数据库，没有协议，没有向量。三层都是 markdown 文件。

LAYER 1

CLAUDE.md 文件（你写的）

会话启动时整篇直接注入到上下文。多级作用域：企业 → 用户（~/.claude/CLAUDE.md）→ 项目根 → 子目录 → 本地（CLAUDE.local.md，git ignore）。更具体的覆盖更广泛的。支持 @path/to/file 引用，但引用的文件也是启动时加载。

LAYER 2

Auto Memory（Claude 自己写的）

存在 ~/.claude/projects/<project>/memory/，从你的纠正和偏好里自动学习。"以后这个项目都用 bun 不用 npm" 之类的会被它默默记下来。也是 markdown，可以读、编、删。

LAYER 3

Session Memory（当前对话）

200K context window 内的一切：你的 prompt、Claude 回复、工具输出、读过的文件。关闭会话即丢失（除非用 claude -c 续接）。/compact 压缩后，根目录的 CLAUDE.md 会从磁盘重新读回来——这是 Claude Code 特意保留的一条"锚"。

关键限制：CLAUDE.md 超过 200 行会被静默截断，因为每行都吃 context budget。这个硬限制反过来逼着用户把记忆做分层引用（路径作用域规则、嵌套 CLAUDE.md），而不是堆成一个百科全书。

05横向对比一张表

同一个维度看两种思路的差异。

维度	OpenViking	Claude Code Memory
设计目标	长期运行的自主 Agent 基础设施	开发者跨 session 的项目上下文延续
存储范式	虚拟文件系统 + `viking://` 协议 + 数据库后端	真实文件系统 + 纯 markdown
检索方式	向量 + 目录递归 + rerank（结构化）	启动时一次性全量注入，无运行时检索
粒度控制	L0 / L1 / L2 三层按需加载	200 行硬限 + path-scoped rules + 嵌套
自学习	Agent 主动写 `cases/patterns/`	Auto Memory 从用户纠正中学
多模态	VLM 原生集成，图像入 FS	主要文本（图片靠 session 内分析）
部署成本	需 GPU + embedding 模型 + VLM + 服务进程	零部署，就是几个 md 文件
可观测性	极强（`ls/find/tree` 探索）	强（文件直接看），但仅你写的 CLAUDE.md 部分透明
跨会话持久	无限（DB 持久化）	有限（CLAUDE.md + auto memory 文件夹）
适用场景	多 Agent 协作、客服机器人、长任务自主体	编码会话、单人开发流
成熟度	v0.2.x，早期	生产可用，已迭代多版本

⚠️ 顺带一提：OpenViking 官方有一个 Claude Code Memory Plugin——也就是说它定位上不是要替代 CLAUDE.md，而是想成为 Claude Code 背后的"长期记忆层"。两者可以叠加。

⌘ 关于你的多 Agent 平台

从你的项目角度看，OpenViking 值不值得集成？

你之前在评估 OpenClaw 作为 runtime——而 OpenViking 正是 OpenClaw 的"亲儿子"配套记忆层（GitHub README 第一句就是 "designed specifically for AI Agents (such as openclaw)"）。所以你大概率绕不开它，至少要决定用还是替换。

对你"群聊式多 Agent 协作"的场景，OpenViking 的三个特性特别契合：① session/ 目录天然适合表达"群聊的共享上下文"；② agent/memories/ 让每个数字员工有自己的学习沉淀；③ L0/L1/L2 让"任务自选机制"能廉价地扫一遍所有 agent 的能力摘要。

但建议先做的事：拿一个最小 demo 跑通——OpenClaw + OpenViking 默认配置，喂一个跨多日的对话样本，亲眼看一遍它生成的目录结构和摘要质量。如果 L0/L1 摘要看起来"中规中矩但抓不到重点"，那它在你的场景里也会这样——这是 LLM 摘要器的固有上限，不要相信项目方的 benchmark。