ai-memory 把上下文交给下一个 Agent:Markdown Wiki 不是聊天记录仓库退出一个编码智能体,再在同一目录打开另一个,真正昂贵的往往不是启动命令,而是重新解释架构、已验证结论、失败尝试和未决问题。ai-memory 试图解决的正是这段交接。但它的关键选择不是“把所有聊天永久保存”,而是把生命周期事件整理成有边界的观察,在会话结束时生成摘要和下一棒交接。层保存什么主要用途明确边界 生命周期观察裁剪后的提示与工具事件还原工作过程不是完整聊天Markdown Wiki决策、理由、步骤与知识页长期可读、可版本追踪历史内容仍需复核SQLite 索引会话、全文、实体、链接与可选向量快速检索与状态管理不是知识真相源Handoff摘要、未决问题与下一步给下一个会话接棒依赖可靠结束事件真正有价值的长期记忆,不是让模型永远记住每句话,而是让关键决策、失败路径和下一步变成可检查、可回滚的工程资产。完整聊天看似信息最多,却也会把噪声、重复内容、过时结论和敏感片段一起留下。上下文越长,下一次会话越难判断什么真正重要。ai-memory 选择收集生命周期观察。用户提示和压缩后摘要有明确长度上限,通知与工具摘录更短;客户端和服务端都执行清洗。官方明确说明,这些观察不是完整原生聊天记录。当会话真正结束时,系统先生成规则型 sessions 页面,再打开一条交接记录。配置外部模型后,可以把摘要重写为更完整的概念、决策、步骤或踩坑页面;不配置时,基础摘要和检索仍可工作。这里的目标不是复刻每一句话,而是让下一个会话知道:做到了哪里,为什么这样做,哪些路走不通,还有什么没有解决。二、一次交接怎样从事件变成知识数据流从生命周期钩子开始。会话启动、用户提交任务、工具调用、上下文压缩和会话结束等事件,被转换成统一的观察类型。客户端先执行就近的捕获排除策略,被忽略的文件事件不会进入本地队列、网络或存储。服务端再次裁剪和清洗内容,再写入单写者管理的状态层。真正的 SessionEnd 到来后,服务端在同一结束路径里生成会话摘要、标记会话完成,并创建给下一会话使用的交接。交接是一次性的:被符合条件的新会话领取后,旧的自动交接会过期,避免重复注入。Codex 有一个现实边界。官方支持矩阵写明,它没有可靠的自动真实会话结束钩子,因此需要显式执行 finalize-session,才能进入同一套结束、摘要和交接路径。三、为什么 Markdown 是真相源项目把存储拆成两层。第一层是 Git 版本化的 Markdown Wiki,保存概念、决策、步骤、踩坑和会话摘要。它可以直接搜索、用编辑器或 Obsidian 打开,也能查看版本历史和回滚。第二层是 SQLite 派生索引。它保存会话、观察、交接、审计与检索数据。全文搜索、实体匹配、链接邻居和可选向量会共同产生候选,再经过有边界的权重调整。这个关系非常重要:Markdown 是知识真相,SQLite 是为了更快找到它。索引可以重建,决策页面需要人工可读和可审查。外部模型也不是必需项。无模型模式仍提供全文、实体和链接检索以及规则摘要;配置后才增加知识整合、矛盾检查和改进建议。四、历史记忆为什么仍然不可信项目在 README、架构文档和安全策略中反复强调:检索到的页面、交接和摘要是历史证据,不会因为被放进规则目录、被置顶或排名靠前,就自动获得指令权威。原因很直接。页面可能已经过时,也可能包含被代码或外部内容带入的恶意指令。即使内容经过清洗,也无法证明模型一定会忽略所有操纵性文字。所以需要明确分工:历史记忆用来找过去的决策、理由、失败尝试和流程;当前 checkout、构建、测试与实际运行结果才负责回答代码现在是什么。安全模型也有范围。v1 面向单一信任域的工作站或家庭服务器,没有静态加密和用户级私有记忆隔离。需要成员之间互不可见时,应使用独立服务和数据目录,而不是把用户标识当作访问控制。五、它适合什么团队,不适合什么场景它适合经常跨编码智能体和多会话推进同一仓库的团队,尤其是任务持续数天、失败路径很多、决策理由不能只留在聊天窗口里的项目。它也适合希望把记忆留在可读文件中的开发者。Markdown 可审查,Git 可追踪,检索索引可以独立维护;知识不会只困在某个客户端的私有会话里。它不适合被理解成无配置的企业多租户知识库,也不应该直接暴露给不受信任的公网。敏感项目还要主动设置捕获排除、网络认证和独立数据边界。截至 2026 年 8 月 19 日,仓库为 2,845 Stars,最新版本 v1.28.1 在前一天发布。这解释了它为什么进入当日热榜,却不能替代独立部署验证。我的判断是,ai-memory 最有价值的不是“无限记忆”,而是把跨会话交接变成一个可检查的工程对象。记忆可以帮助继续工作,但最终真相仍然要回到代码和证据。来源:ai-memory 官方 README、架构文档、安全策略、v1.28.1 Release 与 GitHub REST 元数据;核验于 2026-08-19,完整口径见 sources.md。