再也不怕换工具失忆了：它给 AI 编程助手装上"长期记忆"

一句话定位：为 AI 编程助手提供跨会话的长期记忆，让你从 Claude 换到 Codex，不用重新解释项目上下文。

你已经花了两个小时跟 Claude Code 聊一个项目，讨论了架构选型、踩了几个坑、决定用 PostgreSQL 而不是 MySQL。然后你的 Claude Code 订阅到期了，或者老板让你换用 Codex，你不得不重新开始------把同样的背景重新说一遍，同样的问题重新解释一遍。

两小时的努力，因为换了个工具，变成了零。

这个问题，听起来有点离谱，但在 AI 编程工具爆炸式增长的今天，它正在变得越来越普遍。

Github:

github.com/akitaonrail...

ai-memory 是什么？

2026 年 5 月，一位名叫 akitaonrails 的开发者发布了一个项目：ai-memory。

它做的事情很简单------给 AI 编程助手装上一个"长期记忆系统"。

这个系统本质上是一个运行在你电脑或服务器上的轻量级服务，监听你所有 AI 编程助手的对话和工具调用，自动把它们整理成结构化的笔记，保存在一个类似维基百科的 Markdown 仓库里。当你下次开启一个新会话，或者换了一个不同的 AI 助手，这个系统会把上一个会话的"进度条"和"决策记录"交给新的助手，让它不用从零开始。

项目的 README 写了一句话，精准地概括了它的核心价值：

"Quit Claude Code mid-task, start OpenAI Codex in the same directory, continue without re-explaining the architecture, the failed approaches, or the open questions."

（在任务中间退出 Claude Code，在同一目录下启动 Codex，无需重新解释架构、失败的尝试和待解决的问题。）

3,309 颗星星和 272 个 fork 证明：很多人需要这个功能。

它解决了什么核心痛点？

痛点一：换了 AI 工具，上下文全丢

这是 ai-memory 设计的核心场景。2026 年，市面上至少有十几个主流 AI 编程助手：Claude Code、OpenAI Codex、Cursor、Command Code、Devin CLI、Gemini CLI......它们各有各的优势，各有自己的定价模型，开发者经常需要"多工具切换"。

但问题是：每个工具的对话上下文都是独立的。你在 Claude Code 里讨论的内容，Codex 完全不知道。

ai-memory 充当了这些工具之间的"翻译官"。它在所有工具之上跑，用统一的协议捕获每个工具的会话，然后把结构化后的笔记提供给下一个工具。

痛点二：会话断了，之前讨论的决策没了

即使不切换工具，同一个 AI 助手的不同会话也是独立的。你今天跟 Claude 讨论了项目方向，明天重启对话，你可能需要花十分钟重新让 Claude "回忆"起昨天的内容。

ai-memory 在会话结束时自动生成一个"交接文档"，包含当前任务的进度、开放的问题、已做出的决策。下次会话开始时，这个文档会自动注入，助手一眼就知道上次做到哪了。

痛点三：重复犯错

开发者最怕的不是从零开始写代码，而是犯同样的错误。你上次在一个模块里踩过某个坑，这次忘了，又绕回去了。

ai-memory 的一个高级功能叫"自动改进"：当它检测到某个错误被反复出现时，会自动生成一份"避坑指南"笔记，写入项目的知识库。下次遇到类似情况，AI 助手会先查一下知识库，然后自动避开已知的雷区。

它的核心设计是什么？

ai-memory 的设计有几个值得称道的地方。

设计一：记忆存在 Git 仓库里

大多数 AI 记忆工具把数据存在数据库里，你用 SQL 查询，或者用 API 调取。ai-memory 做了一个更朴素的选择：把所有的记忆保存为普通的 Markdown 文件，放在你的项目的 Git 仓库里。

这意味着什么？

你可以用 grep 搜索记忆、可以用 git log 查看历史的每一次修改、可以在任何编辑器里直接打开阅读、可以像管理代码一样管理记忆。不需要专门的数据库，不需要额外的管理工具。

这种设计叫做"Karpathy 式 LLM Wiki"------它借鉴了 Andrej Karpathy 提出的一个概念：用维基百科的方式管理 AI 辅助开发中的知识，而不是靠日志堆积。

设计二：分层搜索机制

ai-memory 的记忆检索有四层，像一个精密的搜索引擎：

• 全文搜索（FTS5）：最基础的关键词匹配，快速找到包含某词的笔记
• 实体匹配（Entity Match）：识别笔记中的具体名词，比如"PostgreSQL"、"数据库迁移"，即使用描述不同的词也能找到
• 图谱邻居匹配（Graph Neighbor）：通过笔记之间的链接关系，找到相关的上下文
• 向量相似度（可选）：如果你配置了向量嵌入，还可以做语义级别的搜索

这四层一起工作，返回的结果按相关性排序，然后再由 AI 模型生成最终的摘要。

设计三：一套协议，支持所有主流工具

ai-memory 不是一个单一的工具，而是一个协议层。它定义了与各个 AI 编程助手的通信方式，目前已支持的工具包括：

• Claude Code（官方支持）
• OpenAI Codex（官方支持）
• Cursor
• Command Code
• Devin CLI
• Gemini CLI
• OpenCode
• Kimi Code
• Kiro CLI
• 等等......

每个工具的对接方式不同：有的通过 MCP（模型上下文协议）配置，有的通过生命周期钩子（Lifecycle Hooks），有的两者兼用。但对你来说，只需要安装一次，所有工具的会话都会被统一捕获。

设计四：可选的智能处理

ai-memory 的一个聪明设计是：记忆功能可以不依赖 AI。

如果你不配置任何 LLM 提供商，它仍然可以用全文搜索、实体匹配和图谱导航来管理和检索记忆。只有当你需要自动总结、自动改进、语义搜索这些高级功能时，才需要接入 OpenAI、Anthropic 或其他兼容的服务。

这让它在没有 API Key 的情况下也能基本可用，降低了入门门槛。

它跟竞品有什么区别？

2026 年的 AI 编程助手生态已经非常热闹了，围绕"记忆"这个主题，有很多不同的方案。我们来做一个横向比较。

赛道一：跨工具记忆（ai-memory 所在的赛道）

项目	Stars	核心特点
ai-memory	3,309	Rust 编写，多工具支持最广，Git 仓库式记忆存储，自动改进
ECC	241,259	更全面的"助手增强平台"，不只是记忆，还有技能、安全、研究等功能
holaOS	10,291	"所有 AI 工具的统一工作台"，100+ 集成，自带共享记忆
ruflo	68,405	多代理蜂群编排，强调自主工作流协调
context-mode	20,001	侧重上下文窗口优化，压缩工具输出减少 Token 消耗

这个赛道的核心竞争点是：支持的工具数量、记忆的准确性、跨工具的无缝程度。ai-memory 在这个维度上有一个明显优势：它不绑定任何特定工具，而是作为一个独立的基础设施运行。

赛道二：Obsidian 式本地记忆

项目	Stars	核心特点
obsidian-mind	4,516	基于 Obsidian 的知识库，适合喜欢双链笔记的用户
obsidian-second-brain	4,117	自组织知识系统，45 个命令，可定时维护

这个赛道的特点是：记忆存在你自己的 Obsidian vault 里，跟你的个人知识管理打通。如果你已经是 Obsidian 用户，体验会很自然。但代价是配置复杂，而且与 Obsidian 绑定，脱离了那个环境，记忆就失去了价值。

赛道三：代码库记忆索引

项目	Stars	核心特点
provenant	28	Microsoft Build AI 2026 第一名，本地代码库索引
agent-memory-loom	0	较新项目，基于 Zettelkasten 卡片笔记法

这个赛道的核心是：记忆的是代码库本身的结构和状态，而不是对话内容。对于代码理解型任务很有用，但无法解决"换工具要重新解释"的问题。

总结对比

维度	ai-memory	ECC	holaOS	obsidian-mind	provenant
跨工具支持	12+	多种	内置	部分	N/A
记忆持久化	Git 仓库	混合	统一后台	Obsidian	代码索引
是否需要 LLM	可选	需要	需要	可选	不需要
自动改进	有	有	有	有	无
Docker 部署	支持	有限	支持	不适用	不适用
学习曲线	中等	较高	中等	较高（Obsidian 门槛）	低

ai-memory 的定位很清晰：它不是最全面的平台（ECC 更大），也不是最简单的方案（provenant 更轻），但它是唯一一个专门为"跨工具会话记忆"而设计的独立基础设施。

为什么 ai-memory 值得关注？

理由一：它解决了 AI 编程工具"碎片化"时代的必然问题

2026 年，AI 编程工具的格局远未稳定。今天的主流工具，明天可能就被超越。开发者需要随时切换工具------为了更好的功能、更低的价格、更强的性能。

但切换工具的成本越来越高：上下文丢失、重复解释、记忆断裂。

ai-memory 的存在，就是为了解决这个"碎片化税"。它让你拥有的是你自己的工作记忆，而不是某个工具的对话记录。这个记忆可以带走，可以复用，可以在任何支持它的工具之间流通。

理由二：设计哲学很克制

很多 AI 工具倾向于做"大而全"的平台------既要记忆、又要编排、还要调度。ai-memory 的创始人显然做过权衡：先把一件事做好。

它就是一个记忆系统。不抢工具的本事，不替代你的 IDE，不试图成为你的"AI 操作系统"。它的边界很清晰，这意味着它不会跟你的工具链产生冲突。

理由三：对开源和隐私友好

数据存在你自己的 Git 仓库里，不上传到第三方云服务。你可以随时 git log 检查每一条记忆的修改历史，也可以随时删除任何一条笔记。没有 vendor lock-in，没有黑箱。

理由四：社区增长很快

从 2026 年 5 月发布到现在不到三个月，已经拿到了 3,309 颗星星和 272 个 fork。对于一个专注于单一功能的开源工具来说，这个增长速度相当快。

如何使用？

最简单的方式：Docker 一键部署

docker run -d --name ai-memory \
    --restart unless-stopped \
    -p 127.0.0.1:49374:49374 \
    -v ai-memory-data:/data \
    -e AI_MEMORY_LLM_PROVIDER=anthropic \
    -e ANTHROPIC_API_KEY=sk-ant-... \
    -e AI_MEMORY_EMBEDDING_PROVIDER=openai \
    -e OPENAI_API_KEY=sk-... \
    akitaonrails/ai-memory:latest

部署后，运行两行命令完成安装：

ai-memory install-mcp --client claude-code --apply
ai-memory install-hooks --agent claude-code --apply

之后，每次会话的输入输出都会自动被捕获，并写入本地知识库。

跨工具切换

# 先在 Claude Code 里工作
ai-memory run claude

# 在 Codex 里继续（自动获取上一个会话的交接文档）
ai-memory run codex --yolo

# 不加名字，继续最新的会话
ai-memory run

查询记忆

在对话中直接问 AI 助手：

"我们上次讨论过关于数据库选型的问题吗？"

助手会自动调用 ai-memory 的搜索功能，给你一个基于历史记录的准确回答。

这个项目适合谁？

多工具切换者------如果你经常在 Claude Code、Codex、Cursor 等工具之间切换，ai-memory 是最实用的选择。

团队协作者------ai-memory 支持多用户部署，团队成员的决策和上下文可以跨会话共享。

项目管理导向者------如果你在意"做了什么、为什么这么做、接下来做什么"，ai-memory 的结构化记忆比模糊的对话记录更有价值。

隐私敏感者------所有记忆存在本地 Git 仓库，不用上传到任何云服务。

Github:

github.com/akitaonrail...

总结

ai-memory 解决的是一个看似简单、实则复杂的问题：如何让 AI 编程助手的"记忆"真正属于你，而不是属于某个工具。

在 2026 年这个 AI 编程工具百花齐放、但又各自为政的时代，这种"跨工具的连续性"正在从锦上添花变成刚需。ai-memory 的出现，恰好踩中了这个需求。

3,309 颗星星说明：已经有足够多的开发者感受到了这个痛点。更重要的是，它的设计哲学------克制、开放、本地优先------让这个工具在喧嚣的 AI 工具圈里，显得难得地清醒。

我的理解

看完 ai-memory 的 README，我最欣赏的是它的一句话：

"No vector database to babysit, no write_note ceremony, no manual context-loading."

（不需要你喂养向量数据库，不需要仪式感的写笔记操作，不需要手动加载上下文。）

这句话道出了很多 AI 工具的共同问题：你想用记忆功能，但用起来比不用还累。

ai-memory 的反向思路是：把所有繁琐的工作都藏在后台，你只需要正常用你的 AI 工具，记忆功能自动运行。这才是"无感记忆"的真正含义------不是让用户意识到自己在用记忆系统，而是让记忆系统悄悄在背后工作。

这大概就是好的产品设计该有的样子：你不需要知道它的存在，但它确实在帮你。

关注

如果你觉得这篇文章对你有帮助，欢迎关注我的公众号，获取更多优质开源项目的深度解读。