字数：约2500字 | 阅读时间：7分钟 “上下文窗口是租来的，记忆得自己盖房。”

一、从一次"失忆"说起

上个月，我在两台机器上让两个AI协作开发同一个项目。A机上的AI刚做完一轮设计评审，结论写进了它的会话记录；B机上的AI第二天接着干活，对这份结论一无所知，按自己"新想"的方案把接口改了。等我发现时，两边的代码已经分叉，返工花了整整一个晚上。

这件事之后我盘了盘自己的AI工作流，发现"失忆"无处不在：

  • 会话内失忆：上下文窗口一满，早期聊定的决策就被挤出去，AI开始"自作主张"；
  • 会话间失忆：新会话从零开始，我要么把背景重新粘一遍，要么接受它带着错误的前提干活；
  • 工具间失忆：A工具记住的东西，B工具看不到。换一个工具，等于换了一个没有经验的实习生；
  • 机器间失忆：我在台式机、笔记本、服务器上各跑着AI助手，它们对同一个项目的认知互不相通。

这些问题的根子不在模型。模型的能力一直在涨，但记忆这件事，从来没有一个正经的架构位置——它被默认塞在上下文窗口里，而上下文窗口本质上是租来的临时工位。

二、结论先行：做一个"外置记忆层"

am（agent memory）想做的事情一句话能讲完：把"记忆"从AI身体里搬出来，做成一个独立于任何AI、任何工具，人和程序都能读写的知识层。

它不是一个聊天记录归档工具，也不是又一个向量数据库。核心形态是四样东西：

  • 一堆纯Markdown文件：每个文件记录关于某个"话题"（Topic）的事实（Fact）和关系（Relation）；
  • 一个Git仓库：每次记忆变更都是一次commit，可diff、可回滚、可审计；
  • 一层自动化维护程序：监听会话、代码提交、文件变更，自动提取新事实、更新旧事实、标记过期；
  • 一套切片查询接口：任何AI进入任务前，报上"我是谁、在哪个项目、哪个分支、什么时间"，就能领到一份恰好够用的上下文包。

三、四条底线

设计阶段最纠结的是取舍。最后沉淀下来四条底线，一条都不能让：

1. 明文Markdown是唯一正本

记忆永远以人能直接读的Markdown存在。embedding、索引、缓存都是派生物——删了随时能重建，永远不作为事实来源。这条底线保证的是：哪天这套系统黄了，我剩下的还是一堆能直接翻的笔记，而不会是一把打不开的锁配一个看不懂的库。

2. 每次变更都是一次Git commit

谁改的、什么时候改的、改了什么——全部留在commit历史里。AI改错了记忆，和改错了代码一样，可以被review、可以revert。这条底线的价值很快就被验证过：项目进行中有一次，一个AI报告"本机仓库曾被外部进程强制重置"，我们就是靠Git的操作日志（reflog）把现场完整恢复的。要是记忆存在某个私有数据库里，那次可能就直接丢了。

3. 工作区隔离

每个项目的记忆是独立的vault（库），物理隔离，一个项目的记忆污染不能蔓延到另一个项目。多个AI对世界有不同"认知"时，靠Git分支来隔离各自的现实。

4. 跨库一等链接

记忆之间用双链语法（类似Obsidian的[[链接]]）连接，跨项目、跨库的引用是一等公民。真实世界的知识本来就不是树状的：一个"传感器"话题，会同时关联"通信协议"、“部署环境”，和"那次印象深刻的踩坑"。

四、一条记忆长什么样

空谈架构容易飘，看个简化示例（省略了部分字段）。一条关于项目的事实，在库里就是一个Markdown小节：

### fact-0217 · 切片查询默认走三级降级
- 关于: [[Tool: 切片查询]]
- 陈述: 检索先走向量近似，超时或预算不足时逐级退回
  token索引、图遍历，保证任何情况下都有返回。
- 版本轴: repo=am-main, branch=main, commit=f40cd48
- 来源: 2026-09-23 基准测试轮 · 置信度: 高
- 状态: 有效

机器读它，人也能读它，Obsidian里点开就能改。查询的时候，AI报上"我在哪个仓库、哪个分支、当前时刻"，系统从记忆图里切出这个"世界"下所有有效的条目，渲染成一份上下文包交出去——过期的事实一条都不会混进来。而这一切的每一次变更，都对应Git历史里一行可以追溯的commit。

五、最容易低估的难点：时间

整个设计里最反直觉、也最值钱的决定，是给每条记忆标注它属于哪个版本的世界。

举个例子。一条记忆写着"配置文件的格式是YAML"。三个月后项目重构，格式改成了JSON。这条记忆过期了吗？

看情况——如果你的服务还跑在旧版本上，它依然有效；如果你在新分支上开发，它已经错了。所以每条事实都必须回答：“我在说哪个仓库、哪个分支、哪个提交时刻的世界？”

我们把版本分成两根轴：

  • 轴A：记忆库自己的版本。Git分支在这里表示"我对世界的另一套认知"；
  • 轴B：被记忆对象（项目代码库）的版本。一条事实挂在"项目X的feature分支"上，说的是那个分支的现实。

任何涉及版本的记忆，必须标清说的是哪根轴。查询的时候同理：先声明"我在哪个记忆现实里、推理哪个对象版本"，系统再给你切出对应的切片。我们管这个叫版本切面查询。

这个设计经受住了后期蓝队攻击式评审的三轮推敲，也是这个项目相对市面上现有方案最大的差异点。

六、为什么不用现成的轮子

立项之前，我让AI做了一轮生态调研，把能找到的十几个"AI记忆"项目翻了个底朝天：学术界的HippoRAG、微软的GraphRAG、创业公司的mem0和Letta，还有几个主打Markdown+本地存储的小项目。

调研结论浓缩成一句话：要么不独立（记忆内嵌在某个Agent框架里，换个框架就被锁死），要么不可审计（数据一进库就变成黑盒向量），要么不懂版本（所有记忆都活在"永恒的现在"）。

下载量最高的mem0每周十几万次安装，但它回答不了"这条事实在哪个代码分支上成立"这种问题。往Markdown+Git这个方向走的同路人也有几个，但"双版本轴+切片查询"这个完整形态，到2026年为止还没有现成实现。

所以决定自己动手。好消息是技术选型非常省心：Markdown、Git、Obsidian双链语法，全是最成熟、最不会消失的东西，真正要写的只是中间那层自动化编排程序。

七、这个栏目接下来写什么

这是「am项目」栏目的第一篇。这个项目由我和几个AI协作开发：一台服务器上的AI做编排，另外几台机器上的AI分头写代码，一块共享任务板协调进度。接下来按三条线展开：

  • 设计线：数据模型怎么建、切片查询怎么做（下一篇）；
  • 工程线：怎么组织几个AI分头开发还不出乱子、检索准确率怎么从44%提到78%；
  • 安全线：给一个"AI记忆系统"做安检是什么体验——供应链、注入、路径穿越，一个都不会少。

后台的自动化流水线已经在跑了：每天晚上有一条巡检任务检查项目进展，有值得写的进展就会更新这个栏目。对一个"记忆系统"来说，用自己的开发过程喂饱自己的记忆，狗粮算是吃得相当彻底了。

下一见。

本文由人机协作完成：AI起草，人类审校拍板。这个栏目的每一篇，本身就是一个AI协作的现场记录。