AI 助手每次开新会话就失忆？48 小时涨到 347★ 的 Go 项目，把记忆直接存进 Git
你同事的 Claude Code 是个失忆患者。上周刚在架构评审里拍板"接口走 PKCE，不用 implicit"，今天它在新会话里又一脸茫然地问你：“这个项目的认证流程怎么定的？“你把决策重讲一遍，它又忘了，下次再问。
这不是个例，是几乎所有 AI 编程助手的通病。上下文窗口一关，关键决策就跟着丢了。 我试过把规范写进 CLAUDE.md，可那个文件越长越没人看，越看越乱；也见过团队上向量数据库，结果换来一个"黑盒记忆”——记忆存了，可你根本不知道它记得对不对、什么时候过期。
直到我在 GitHub 上翻到 okf-agent-memory：一个发布不到 48 小时、冲到 347★ 的纯 Go 项目。它的解法干脆到有点反直觉——把记忆做成仓库里的普通 Markdown 文件，用 Git 本身当记忆的版本库和审计日志。 不搞向量库，不碰黑盒，让记忆像代码一样能被 diff、被 review、被回滚。
先看清楚问题：失忆不是"记不住”，是"记了也白记"
市面上给 agent 记记忆的方案，基本分两类，各有各的死穴。
第一类是 CLAUDE.md、AGENTS.md 这种散装 Markdown。你往里写"记住，认证走 PKCE"，可它没有结构、没有检索，agent 每次要么全量塞进上下文（费 token），要么干脆漏看。写多了就是一本没人读的说明书。
第二类是 Mem0、Letta 这类向量数据库。效果好是好，可它们把记忆变成了黑盒——记忆存在哪、内容准不准、谁改过，全靠一个外部数据库兜着，还每次都调用 embedding API，检索一次要 150ms 到 800ms。对高频工具调用的 agent 来说，这个延迟和成本是实打实的拖累。
这两种方案的共同盲区是：它们都在解决"怎么存"和"怎么查"，却没人真正回答——这条记忆还新鲜吗？ 代码上周改了，你脑子里那条"接口走 PKCE"的旧决策，还算数吗？
这才是 agent 记忆真正的痛点：不是检索慢，是记忆腐烂（memory rot）。决策过期了没人更新，事实错了没人发现，agent 用一条过时的"记忆"反而比没有记忆更危险。
为什么是 Git？记忆的新鲜度，需要审计和回滚
okf-agent-memory 的创始人 Stephan Knauer（GitHub 账号 sknr）在项目里只提交了一次 commit，就甩出了整套 v0.1.0。它跑在 Google 今年 6 月发布的 OKF（Open Knowledge Format）v0.2 规范之上——一个把 agent 知识标准化为"Markdown + YAML frontmatter"的开源格式。
它的核心洞察就一句话：记忆不该住在外部数据库里，该住在你的仓库里。 具体长这样：
- 记忆是一堆带 YAML 头的 Markdown 文件，放在
knowledge/目录，比如knowledge/decisions/auth-flow.md - 每个文件自带生命周期元数据：
verified（人工确认过）还是generated（agent 自己写的），外加一个stale_after字段——这条记忆的保质期到哪天，过期就自动标记为待复核 - 检索用内存里的 BM25，本地词法索引，不调 embedding API。官方基准：概念检索 <300 微秒，全量图谱校验约 4 毫秒，进程冷启动 <4 毫秒，内存占用 <15MB——对比 Mem0/Letta 那套 Python + 向量库动辄 120MB 起步、检索 150ms 起跳，完全是两个量级
- 最关键的一条：记忆本身是纯文本、在 Git 里。谁改了什么、什么时候改的、是不是过期被刷新，
git diff和git log一清二楚。记忆像代码一样被 review、被回滚，而不是被埋进数据库表
这套设计的妙处在哪？它把 agent 记忆从"运行时状态"变成了"项目资产"。你审查一条记忆，跟审查一段代码的 diff 没区别——这就是版本管理的价值。官方说这套渐进式披露（progressive disclosure）机制能把上下文 token 膨胀削掉约 80%：agent 只加载它当下需要的概念，而不是把整本说明书塞进窗口。
绕开向量库，是省成本，还是更聪明的架构选择？
看到"纯 Go、零依赖、BM25 本地检索"这几个标签，你可能觉得作者在炫技。但往深一层想，这个选择背后是一个很现实的经济账，正好接上昨天聊的 Token 成本话题。
向量记忆的方案，检索 1000 次要烧 0.1 到 0.5 美元的 embedding 费用，还附带每次 150ms+ 的网络往返。对 agent 这种高频工具调用循环来说，这是双重的拖累。而 BM25 这种传统词法检索，虽然语义理解上不如向量，但它零成本、亚毫秒、完全本地——对"项目里有哪条决策提到 PKCE"这种精确召回，反而比向量更可靠（向量经常召回语义相近但逻辑错误的内容，这是做 RAG 的人都知道的坑）。
所以这不是"便宜没好货"，而是在精确指令场景，稀疏检索本来就更对路。BM25 和向量不是替代关系，是分工关系——agent 记忆里大量是 API 名、变量名、精确约束，这些恰恰是词法检索的强项。
当然账得算全。纯 Markdown + BM25 的短板也很明显：语义相似召回弱、跨概念联想基本没有、记忆图的"理解"远不如向量方案。它牺牲的是"智能"，换来的是"可控、可审计、零成本"。对一个要跑在生产环境里的 agent 来说，“可控"可能比"智能"更值钱。
这套思路，明天就能抄到你的项目里
别急着给项目上 heavy 的向量记忆，先试试这条轻量路径——它不挑语言、不挑框架，只要你的 agent 读得懂 Markdown。
第一步，把你 CLAUDE.md 里那些"拍板过的事"拆出来，每条写成一张带元数据的记忆卡片：
|
|
第二步，给记忆加上保质期。代码库一周改十次，决策三个月后就过期了——与其让 agent 用一条过时记忆误导你，不如主动标记"这条该复核了”。
第三步，跑一个本地的 BM25 检索工具（okf-agent-memory 自带 CLI 和 MCP server，okf search "auth flow" knowledge 亚毫秒出结果），让 agent 先检索再决策，别把整本说明书塞进上下文。
打开你的 agent 项目，把第一条"架构决策"从 CLAUDE.md 里拆出来，改成带 stale_after 的记忆卡片——这一步不用装任何东西，纯 Markdown 就能开始，但你会立刻感觉到 agent 的上下文清爽了一大截。等它长到几百条，再考虑上 okf-agent-memory 那套 Git 原生的工具链。
记忆的"版本管理"，正在成为 agent 工程的下一个主战场
回头看这个 48 小时冲到 347★ 的项目，它真正的价值不在代码，而在一个判断：记忆层正在从"辅助功能"变成"基础设施"，而基础设施的命门是标准。 Google 的 OKF 想当这个标准——把 agent 知识格式统一成 Markdown + YAML，让不同家的 agent 能读懂同一份记忆。现在冲进来的项目，是在抢这块还没有人站稳的生态位。
对你我这种写 agent、做 AI 后端的程序员来说，这不是一条需要立刻迁移的技术栈，而是一个值得现在就开始押注的方向：未来的 agent 记忆，一定是可审计、有保质期、能像代码一样管理的。谁先把自己的项目记忆管理起来，谁就先一步让 agent 从"每次都失忆的实习生"变成"记得住每一次决策的老员工"。
下次你同事再问"这个认证流程怎么定的"，你可以不用解释了——因为你的 agent，已经替你把答案记在了 Git 里。