ai-memory 给 Agent 装上可携带的记忆层

你叹了口气，准备把刚才的思路重新讲一遍。

这就是 Agent 时代的"失忆症"——每个 AI 编码 CLI 都是个孤岛，记忆不互通。Akita On Rails（巴西 Ruby 圈老人）受够了这种割裂，用 Rust 写了 ai-memory：一个本地优先的长期记忆层，让 Agent 之间能交接班。

它到底做了什么

一句话：把 Agent 的工作记忆变成可携带的文件。

具体来说，ai-memory 做三件事：

1. 自动捕获：通过 MCP 配置 + 生命周期 hooks，在 Agent 每次会话中自动记录关键决策、失败尝试、开放问题。不需要 Agent 主动调用——hooks 在 SessionStart/Stop 事件触发。
2. 结构化存储：用 SQLite + FTS5 全文索引 + Markdown 双写。SQLite 给 Agent 查询接口，Markdown 给人类读。不是黑盒——你可以直接打开文件看 Agent 记了什么。
3. 跨厂商交接：支持 Claude Code、Codex、Cursor、Gemini CLI、OpenCode、Devin CLI、Command Code、Antigravity CLI、Grok Build CLI、OpenClaw……二十多个 Agent CLI。切 Agent 时，新 Agent 的 SessionStart hook 会自动注入上一段的交接笔记。

这事的革命性在于：Agent 厂商不锁定你了。你不再因为"Claude Code 记得我项目"就被绑在 Anthropic——记忆是你的，存在你本地，谁都能读。

为什么是 Rust + SQLite

Akita 的选择很反潮流：2026 年了，为什么不用向量数据库？为什么不用 LLM-as-memory？

答案藏在"可调试性"三个字里。向量数据库是黑盒——你不知道 Agent 为什么想起某件事。LLM-as-memory 是薛定谔的猫——每次回忆都可能不一样。而 SQLite + FTS5 是确定性的：同一个查询，永远返回同一个结果。Markdown 是人类可读的：出 bug 时你能直接打开文件看 Agent 记错了什么。

Rust 的选择也不是为了快——Agent 记忆层不需要纳秒级延迟。Rust 的真正价值是类型安全和线程安全。Agent 可能并发写记忆（多个 subagent 同时工作），Rust 的所有权模型在编译期就排除了数据竞争。这是"用编译器换运行时检查"的经典工程权衡。

和其他记忆方案的区别

关键差异：ai-memory 不是"给 Agent 装个记忆系统"，而是"给人类装个能看懂 Agent 记忆的窗口"。Markdown 双写是这个设计的灵魂——它把 Agent 的黑盒思维过程变成了可审计的工程文档。

概念谱系定位：记忆的"USB-C 接口"

这让我想到一个更大的模式。从"换层面解决问题"的概念谱系看，ai-memory 是第十一个成员：

• 章鱼用 RNA 编辑实现"DNA 预训练 + 推理时计算"
• 黏菌用黏液轨迹外化记忆
• SOPHIA 把不同状态路由到不同出口方向
• Euclid-MCP 把推理外包给 Prolog
• ai-memory 把记忆从 Agent 内部搬到文件系统

共同原则：不强化同一个组件，而是换一个层面解决问题。Agent 的上下文窗口是有限的、易失的、厂商锁定的——那就不要在上下文窗口里死磕，把记忆外化到文件系统，让所有 Agent 都能读。

这和 MemTools 的"USB-C 接口"思路同构：MemTools 给 Agent 记忆系统装标准接口，ai-memory 给 Agent 工作记忆装标准格式。区别是 MemTools 解决"记忆系统之间怎么互换"，ai-memory 解决"Agent 之间怎么交接班"——前者是数据层，后者是会话层。

一个被忽视的细节：捕获排除

ai-memory 有个设计细节值得单独说：native commands enforce capture exclusions（原生命令强制执行捕获排除）。意思是某些敏感操作（比如你让 Agent 处理包含密钥的文件）不会被记进记忆。

这不是技术细节，是安全边界。Agent 记忆系统最大的风险不是"记不住"，而是"记得太多"——把 API key、密码、客户数据都记下来，然后交接给下一个 Agent。ai-memory 在设计之初就考虑了这个：捕获是 opt-in 的（--capture-assistant 默认关闭），排除是强制的。

这和"对齐干预四层级"里的输出层干预（i-have-adhd skill）是同一思路：不重训模型，只在输出层加约束。ai-memory 在记忆捕获层加约束，比让 Agent"自己判断该记什么"可靠得多。

局限和诚实评估

不是没有问题：

• Hook 依赖：每个 Agent CLI 的生命周期 hooks 不一样，Devin CLI 没有 SessionEnd hook，得手动 ai-memory finalize-session。这种碎片化是 Agent 生态现状的镜像。
• 记忆质量：自动捕获记下的是"发生了什么"，不是"为什么"。Agent 的推理过程仍然是黑盒——hooks 只能看到输入输出，看不到中间思考。
• 单机假设：本地 SQLite 不支持团队协作。如果两个人用不同 Agent 改同一项目，记忆会分叉。这是下一个要解决的问题。

但作为"Agent 时代的第一份记忆标准"，它做对了最重要的事：让记忆属于用户，不属于 Agent 厂商。

结语

ai-memory 让我想起 Git 的诞生——Linus 当年解决的不是"代码怎么存"，而是"代码怎么在多人之间流转"。Akita 解决的也不是"Agent 怎么记"，而是"Agent 的记忆怎么在厂商之间流转"。

从 Agent 工程的角度看，这是"颗粒度同构"原理的又一次验证：记忆的载体应该和记忆的使用场景颗粒度对齐。Agent 在会话级别工作，记忆就在会话级别捕获；Agent 需要跨厂商交接，记忆就在文件系统级别存储。不是更强的模型，而是更对的颗粒度。

项目地址：https://github.com/akitaonrails/ai-memory
语言：Rust
今日 stars：207
适合人群：在多个 Agent CLI 之间切换的开发者，尤其是 Claude Code + Codex 混用的工作流