开源个专业的一键备份codex、claude code 所有记忆的程序

导读

Agent 的记忆资产越来越成为我们的核心资产，而这些不应该掌握的闭源软件手里。最好的方法应该是我们自己掌控。

为啥叫专业的备份程序 ？ 因为我们不是随随便便备份那么几个文件，而是有设计、放在任何Agent 中都能即开即用的！且无泄漏～

本文详细介绍了codex、claude code 目前记忆系统模块，然后基于此设计一个一款一键备份记忆的程序，介绍了技术选型理由及具体使用方法，以及如何更进一步挖掘资产，全部开源，欢迎试用～

目前最好的AI agent 无异于是claude code 与 codex ，随着我们深入的使用，让Agent 更懂我们，我们一般会开启它们自带的记忆功能，这两个app 里其实有了我们的宝贵信息

这些就是 memory：它记住了你喜欢怎么沟通，某个项目怎么跑测试，哪些仓库以前踩过坑，哪些命令不要再试，写文章时哪些表达你讨厌，研究开源项目时应该先看本地代码。

问题是，Codex 和 Claude Code 都是闭源工具。

我们能看到一部分本地文件，也能看官方文档，但看不到完整的记忆生成、筛选、召回和注入逻辑。工具升级之后，格式可能变；换机器之后，目录可能漏；账号或产品策略变了之后，某些记忆还能不能被用上，也不完全由用户控制。

更主要的如果哪天不幸号没了，那我们这些宝贵数据不能用了，就很可惜！

还有一点就是未来我们agent 肯定不止一两个，如何串联它们，不要每个agent 都要强调下自己的喜好，这个也很关键

于是我打算做一个很东西：把 Codex 和 Claude Code 在本机已经积累的记忆收回来，做成一份本地、可读、可查、可迁移的记忆档案。

程序只读取 Codex 和 Claude Code 的记忆目录，不修改原始文件，这个程序只负责备份、脱敏、归档和编译。

知己知彼，在技术选型前，先看看现状，看看codex、claude code 的记忆长什么样

Codex 记忆长什么样

Codex 的记忆更像一层本地召回缓存，主要给 Codex 自己用。

我这台机器上开了这些配置：

本地目录大概是这样：

几类文件各有分工：

比如 Codex 的某个 skill （这个和我们通用的skill不太一样，是codex自己生成的，有点类似hermes的逻辑） 可能会记住：用户发微信公众号链接时，先调用本地工具转 Markdown；做财经早报时，跑哪个脚本、保存哪些 JSON、怎么校验链接。

这类内容很有用。它本质上是 Codex 给自己写的工作手册。

但它的问题也明显：它主要服务 Codex 自己，外部程序很难把它当成一个稳定的结构化记忆库。

Claude Code 记忆长什么样

Claude Code 的记忆更文件化。

最基础的是 CLAUDE.md。它适合放长期规则、项目命令、代码风格、团队约定。常见位置包括：

另外还有一套自动记忆。它通常长这样：

MEMORY.md 是索引，只放标题和一句说明。真正的内容在 topic file 里。topic 文件通常带 YAML frontmatter，比如 name、description、metadata.type、originSessionId。

这套设计挺适合归档。索引轻，正文可读，来源也比较清楚。

选型

结合前面的现状，以及诉求，我想要的产品要支持如下几个痛点：

• 本地长期保存

• 最好能 Markdown 直接读

• 保留原始来源路径方便溯源

• 有 hash 去重和版本快照

• 区分 user memory 和 agent memory

• 能检索，后面也能接向量和混合检索（除了能存，还能用）

• 不被某一个闭源工具绑死

• 支持数据增量

调研阶段我看了 Mem0、OpenViking、OpenHuman 的记忆模块、MemOS 等方案。

它们各有优势：

比如 Mem0 更偏产品化记忆服务

OpenViking 更像带虚拟文件系统和上下文组织能力的 Agent OS

OpenHuman 的 llm-wiki 思路很适合沉淀结构化知识

MemOS 在记忆对象建模上也更系统。但放到“备份和整理个人 Agent 记忆”这个场景里，整体都偏重了一些。

有的方案默认要跑服务，有的依赖特定数据库或框架，有的更像一套完整 Agent 协议或运行时。我的需求更朴素：先把 Codex 和 Claude Code 这些闭源工具里的记忆资产完整、安全、可读地收回来，形成一个本地长期可维护的记忆仓库。

考虑自己开发也可以，但是会有遗漏，向量数据库怎么选？不同记忆如何组织，如何快速检索，如何扩展都需要考虑到。

最后朋友推荐，我发现了一个最近很火的开源仓库，发现它非常适合做本地记忆存储，就是：EverOS

EverOS 的思路正好贴近我这个需求：

它的目录模型也适合这件事：

我的想法是：users/<user_id> 放长期偏好和工作方式；

agents/codex 放 Codex 的历史任务经验；

agents/claude-code 放 Claude Code 的项目记忆和技能卡。

开发

everos-memory-archive

可以做哪些事情：

导入后的目录是分开的：

我针对cc 与codex 做了区分，也便于恢复和后续整合

sources/ 是脱敏后的原文快照，records/ 是整理后的 Markdown 卡片。*.versions/.md 用来保留不可变版本。unified_index/ 里放统一索引和报告。

compiled/ 是后来补上的编译层。它把归档里的原材料再整理成更好用的 Memory Pack。

怎么用

前面看起来挺复杂，其实用起来很简单，已经帮大家封装好了

一键脚本已经在仓库里：

一句话 skill 模板也在仓库里：

更进一步：Memory Pack

归档层解决的是“收回来、查得到、能追溯”。

但真正要给 Agent 用，我们再整理一层！

我加了一个本地规则编译命令：

它会生成：

这一版不调用 LLM，不请求远程 API。

它只是从 archive records 和 manifest 里按规则整理候选内容。

优点是：快、本地、可复现、不会额外泄露给远程模型。

缺点也有：它不会做真正的语义去重、冲突消解、抽象总结。比如两条记忆表达同一个偏好，它可能都保留；一句话没有命中关键词，也可能漏掉。–如果想要更精准，可以用LLM协助整理

几个文件的用途：

比如新开一个 Agent，会话前先读 bootstrap_context.md，它至少能知道我的基本偏好、常用流程，以及哪些项目有历史背景。

备份过程设计：

这东西有什么用

从此，记忆不再只躺在某个闭源工具自己的目录里。

换机器、换工具、换 Agent 时，也可以把这些记忆带走。

你还能审计它们：工具到底记了什么，哪些记忆来自哪里，什么时候导入，hash 是什么。

更有意思的是后面这层：把记忆变成可复用的工作资产。

比如：

把 project_cases.md 给新 Agent 当项目恢复材料。

把 bootstrap_context.md 放进一个新工具，让它开局就知道我怎么工作。

这才是我觉得最值得挖的地方。

模型会换，IDE 会换，Agent 框架也会换。但长期积累下来的个人上下文、项目经验和工作方式，应该属于用户自己。

这个程序现在做的，就是先把这些东西从工具目录里收回来，变成一份本地、可读、可追溯的记忆资产。

最后，感谢EverOS的开源， 帮助我快速完成本项目！

附：

EverOS的开源 地址： https://github.com/EverMind-AI/EverOS

本项目开源地址： https://github.com/cclank/everos-memory-archive

打磨很久，创作不易，欢迎大家star ～