ai-memory：跨 20+ 编码智能体共享长期记忆

在 Claude Code 里干到一半的任务，切到 Codex 接着干，不用重新解释一遍架构——这就是 ai-memory 想解决的事。这个 Rust 写的开源项目正在 GitHub Trending 上以每天 500 多星的速度蹿升，目前累计 9.3k 星、656 fork、3500 多次提交。它的一句话定位很清晰：给 AI 编码智能体做长期记忆，并且让这份记忆跨工具、跨项目、跨机器流动。

各家自带记忆，为什么还不够用

README 开篇就承认了一个事实：你的编码智能体大概率已经有记忆功能了——Claude Code 会自己记笔记，Cursor 能记住一些东西，各家平台都在加码。但它们有同样的三个局限：笔记存在一台机器上、属于一个智能体、换工具或交接给同事时就从视野里消失。

ai-memory 的解法是把这些限制逐个拆掉。第一，跨智能体：Claude Code、Codex、Cursor、Gemini CLI、OpenCode、Grok、Devin、Kimi、Kiro 等二十多个 harness 喂同一份记忆，交接是有类型协议的——每个 handoff 有明确的所有者，且只能被认领一次，避免两个智能体同时改一份上下文打架。第二，跨项目：一份描述你工作习惯的个人画像（用什么包管理器、测试怎么组织、架构偏好）会在每个新仓库的会话开始时自动加载，你不用再向每个新智能体自我介绍一遍。第三，跨机器：记忆存在你自己跑的服务器上——同一台笔记本、家里的 homelab 机器、或者任何地方——桌上没干完的活，打开笔记本接着干，开放问题和踩过的坑都还在。

谁最需要这个东西

这个项目的目标用户画像非常具体。第一类是多工具并用的高级开发者：今天 Claude Code 订阅额度用完了换 Codex，或者对同一个任务让两家工具交叉验证——没有共享记忆的话，每次切换都是上下文清零重来。第二类是团队协作场景：老手把任务交接给新人，过去的方案、失败过的路径、还没解决的问题，现在可以随仓库沉淀而不是散落在某个人的聊天记录里。第三类是自建基础设施的团队：记忆放在自己的服务器上，代码上下文不出内网，这对企业环境是硬需求。

图 1

工程细节上也能看出这不是周末玩具：记忆库原生采用 Open Knowledge Format（OKF v0.2）格式打包，检索质量有可复现的公开 benchmark，配套了导入器、外部生命周期中继、团队 wiki 同步和 TypeScript SDK 等周边 crate，3.0 版本连升级回滚文档都写好了。README 还特意注明代码库本身是”与 Claude Code 协作构建”的——用 AI 造 AI 的记忆系统，吃自己的狗粮。

记忆层正在成为智能体栈的新战场

值得注意的背景是，”智能体记忆”正在从个人工具升级成基础设施品类。各家模型厂商把记忆做进产品（越用越懂你），中间件项目做向量检索记忆，而这个项目的差异化在于站到了 harness 之上：不绑定任何一家模型或工具，做那个中立的、你自己控制的记忆层。推测这个定位是它星数暴涨的原因——开发者可以换模型、换编辑器，但不想每次都把项目历史重讲一遍。

当然，把”失败过哪些方案、还有哪些开放问题”这样的高价值上下文集中存在一个服务里，本身也是新的信任负担——这份记忆比代码库更能暴露你的工作方式。好在它是 MIT 协议、自托管架构，数据主权在你手里。当智能体成为开发流程的主角，谁掌握记忆，谁就掌握连续性——这个项目赌的就是这个位置。

核心观点：如果你已经在两个以上编码智能体之间来回切换，ai-memory 值得花半小时试一下自托管版本——记忆迁移的成本只会随时间越来越高，早一天接入，早一天停止向新工具做自我介绍。