夜雨聆风经常跨设备开发的小伙伴们应该都有过类似的体验，不同设备之间会话内容没办法互通，公司电脑分析完，个人电脑打开一点记录也没有，或者在Cluade里分析半天，Codex里面是找不到的。
火山引擎开源的 OpenViking（Apache-2.0 协议，官方定位「上下文数据库」）解决的就是这个问题：记忆存储在服务端，跨会话、跨设备、跨客户端，Claude Code 和 Codex 共用同一份。
一、OpenViking 是什么
OpenViking 把 Agent 需要的上下文统一当作文件管理，挂载在 viking:// 这个虚拟文件系统之下。资源（文档、代码）、记忆（用户偏好、经验）、技能（工具、MCP）各有独立目录，Agent 检索上下文不是从向量库里搜出一堆碎片，而是像浏览目录一样逐层定位。官方提供的 API 也确实叫 find、ls、read。
内容写入时自动分为三层：L0 摘要（256 字符）、L1 概览（4000 字符）、L2 全文。检索时先用摘要粗筛、概览精排，确有需要再读取全文。设计目的很直接：避免上下文窗口被无差别填充。
如果只关心编码工具，这些架构细节了解大概即可，重点在下面。
二、在 Claude Code 和 Codex 中的工作方式
OpenViking 以插件形式接入，安装之后承担两项工作。
第一项，无感读写。它注册了一组 hooks，跟随会话生命周期运行：
• SessionStart：会话启动，注入用户画像、记忆索引、上次会话的工作摘要 • UserPromptSubmit：用户每发送一条消息，先做语义检索，把相关记忆注入上下文 • Stop / SessionEnd：一轮对话结束、会话退出，归档对话记录 • PreCompact：上下文压缩之前强制存档，防止细节在截断中丢失
写入路径是异步的，hook 立即返回，实际写入交给后台 worker 处理。使用上几乎没有存在感，正常启动 claude 或 codex，它会在该出现的时候出现。
第二项，主动管理。它同时注册了一组 MCP 工具：search 做语义搜索，remember 让模型主动记一条，forget 清理过时记忆，add_resource 把文件或 URL 导入为知识库，并支持自动刷新。平时靠 hooks 被动注入，模型需要时也可以主动查询、主动记录。
由于记忆存储在服务端，Claude Code 和 Codex 使用的是同一份。官方博客给了一个例子：用桌面版 Claude Chat 连接 OpenViking，从终端活动自动生成周报，再把报告存回去作为记忆。跨客户端共享是真实可用的能力。
三、记忆的生成：蒸馏与衰减
这是整个项目最有意思的部分。
会话结束，或者上下文累积到阈值（默认 8000 token），原始对话会被交给一个异步 LLM 任务做「蒸馏」，产出两份东西。
一份是 Working Memory，固定七段结构：标题、当前状态、目标、关键决策、相关文件、修复过的错误、未决问题。下次会话启动时注入的就是它，相当于上次工作的交接文档。
另一份是结构化记忆，共八类。用户侧四类：画像、偏好、实体、事件；Agent 侧四类：案例、模式、工具、技能。新记忆写入时不是简单覆盖旧记忆，而是先与已有记忆融合，重复的合并，冲突的更新。
蒸馏之前还有一道防线：剥离 标签内的内容。否则「基于记忆生成的回答」会被当作新知识再次存储，记忆会逐渐失真。这个细节考虑得相当周全。
记忆带温度衰减，公式大意是热度等于访问次数乘以时间衰减，默认半衰期 7 天。一个月未访问的记忆近乎失效，高频访问的记忆则持续保持活跃。这一设计相当务实：没有衰减机制，记忆库迟早被无效信息填满。
官方博客列举了几个实际效果：会话启动自动注入画像和上次的未决 issue；发送提交信息时，毫秒级召回几周前讨论过的相关决策，并附带置信度评分；作者还在一次无关的架构评审中，见到它自动召回了数周前三种设计模式的对比。实际效果有待自行验证，但方向是明确的：记忆的价值在召回，不在存储。
四、安装与配置
一条命令，Claude Code 和 Codex 同时适配，安装器会询问要配置哪个：
bash <(curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/examples/memory-plugin-shared/install.sh)访问 GitHub 困难的地区可以使用火山 TOS 镜像：
bash <(curl -fsSL https://ovrelease.tos-cn-beijing.volces.com/memory-plugin-shared/install.sh)安装是幂等的，重复执行也是安全的。装完重启终端，正常启动 claude 或 codex 即可。部署方式有两种：本地部署，或使用火山引擎云端。
配置文件在 ~/.openviking/ovcli.conf，几个值得了解的参数：
OPENVIKING_RECALL_LIMIT=6 # 每次最多注入 6 条记忆
OPENVIKING_SCORE_THRESHOLD=0.35 # 相关性低于 35% 的结果不注入
OPENVIKING_RECALL_TOKEN_BUDGET=2000 # 注入内容的 token 上限
OPENVIKING_BYPASS_SESSION=true # 敏感会话关闭 hooks注入同时受条数、相关性分数和 token 预算约束，可以看出设计者对上下文污染问题有过切身考量。
安全方面再补充两点。API key 在运行时从配置和环境变量读取，不写入 .mcp.json，不会随仓库泄漏；子代理拥有独立命名空间，会话 ID 形如 cc-xxx__agent-xxx，各自的记忆相互隔离。
五、与 CLAUDE.md 的关系
两者并不冲突，官方博客自己也给出了同样的建议：
我的建议是：静态的规矩（代码风格、提交规范、项目背景）继续写在 AGENTS.md 里，人工维护的内容最可靠；动态积累的经验（调试结论、架构决策、踩坑记录）交给 OpenViking。两者恰好互补。
六、几点不足
Codex 侧的支持尚不完整。终端 Ctrl+C 无法触发干净的退出回调，OpenViking 只能依靠下次启动检查加 30 分钟空闲兜底来归档会话，子代理隔离也暂不支持。Claude Code 侧的 hook 是完整的 7 个，Codex 只有 4 个。
衰减是把双刃剑。半衰期 7 天，意味着低频使用的知识会逐渐淡出。确实需要长期记住的内容，要么让模型 remember，要么写入 AGENTS.md。
隐私问题需要自行评估。对话会被蒸馏成记忆存储到服务端，公司代码是否允许经过它，先确认合规要求。敏感会话可以用 BYPASS_SESSION 关闭 hooks，或者选择本地部署。
结语
OpenViking 解决的是 AI 编码工具最古老的问题：每次都从零开始。它把记忆从静态文件升级为自动沉淀、自动衰减、跨客户端共享的系统，完成度在同类方案中相当突出。
支持的客户端也不止这两个，文档里 Cursor、TRAE、OpenCode、DeepSeek Harness、LangChain 都在名单上。经常切换会话、切换设备、切换工具的开发者，值得一试。