在 Claude Code 里把重构做到一半，卡在一个还没定下来的问题上，想换 OpenAI Codex 接着写------结果它对整个仓库一无所知，你得把架构、试过的死路、还没决定的问题重新口述一遍。仓库 akitaonrails/ai-memory 就是针对这个场景做的工具。据 README 自述，它的定位是「AI 编码代理的长期记忆层」，目标使用方式是：在 Claude Code 里退出，然后在同一目录启动 Codex 接着干，不用重新解释项目背景。
它试图改变的部分
据 README 自述，它对现有厂商内置记忆的批评是：笔记只存在一台机器上，只属于一个代理，一旦换工具或换队友，这些记忆就不可见。它提出的主张是记忆应当 agent-neutral、与机器无关，并且能被他人继承。README 还把 handoff 定义成「协议」，而不只是「约定」，用了 typed、owned、claimed exactly once 这样的表述；但具体机制在可获取的素材里没有展开。
已知的信息
仓库创建于 2026-05-21，最近一次推送是 2026-10-19；语言构成 100% Rust，rust-toolchain.toml 要求 1.95+；MIT 许可；提供 GitHub Releases 入口，可能同时以发布二进制和源码构建两种方式分发。README 称已接入 20 多个 harness：Claude Code、Codex、Cursor、Gemini CLI、OpenCode、Grok、Devin、Kimi、Kiro 等。仓库没有 Topics，也没有主页。
检索时指标：11008 stars、780 forks、18 个 open issues、152 位贡献者。对一个创建五个月的新仓库来说，issue 数量少得不太寻常。
判断这些数字时要保守一些
可信度只有「单一来源」：实质内容全部来自 README，而摘录在「Why ai-memory」处就截断了。同一批次的独立解析也没有取得内容------DeepWiki 返回 Vercel 安全校验页，CodeWiki 返回 404。因此，架构、记忆单元、检索策略、存储格式、作用域，以及接入方式究竟是 MCP、文件系统还是 hook，还有安装命令和 CLI 子命令，全都没有第二个来源可用，我不补。
也没有下载量、包管理器安装量这类硬指标，无法验证 star 与真实使用之间的比例。「20+ harness」这种广度，通常意味着每个集成的深度有限，实际体验还需要自行验证。
它与哪些方案相对（以下为推断）
三条替代路线：厂商内置记忆（Claude Code 的 CLAUDE.md 和笔记体系、Cursor memories，免费且零配置，是最大对手）；开源记忆服务与协议（mem0、Letta/MemGPT 系、Basic Memory、MCP 记忆服务器）；自建约定（把架构文档放进仓库、AGENTS.md）。ai-memory 的差异不在于算法更强，而在于「跨厂商可携带」------这恰恰是厂商没有动力做的方向，所以它的不可替代性取决于厂商是否跟进。
风险
项目太年轻，存储格式与 API 很可能出现破坏性变更；多个代理写入同一份记忆，存在互相污染的可能；记忆被保存到磁盘后，其隐私、加密与团队权限在可获取的素材里没有说明；152 位贡献者需要区分是核心模块作者还是适配器碎片提交；单点维护的风险尚不明确。
目前公开的界面素材只展示项目入口本身，而不是记忆检索的实际效果；在官方文档补齐之前，它只能说明这个方向确实有人在认真做。
值得关注的几件事
会不会出现一份公开的「代理记忆交换格式」并被第三方实现；主流代理是否官方收录或内置它；发版说明里有没有存储格式迁移的破坏性变更；以及能否拿到下载量这类能戳破 star 泡沫的指标。现阶段它是一个值得关注的方向，而不是一个可以托付项目记忆的依赖。