MemoryCustodian：给编程AI一个仓库原生的持久记忆库

编程AI的"健忘症"该怎么治

如果你长期使用 Claude Code、Codex 或 Gemini 这类编程助手，很可能遇到过一个恼人的问题：AI 记不住项目上下文。上一次你告诉它"这个模块必须用异步实现"、"我们已经拒绝了引入 Redis 的方案"，但换了一个会话，它又开始重复建议那些早已被否决的做法。

这种"健忘症"的根源在于大语言模型本身没有跨会话的持久记忆。每一次对话都是从零开始，除非你把所有背景信息重新塞进 prompt。大语言模型（LLM）的工作机制决定了这一点：每次对话时，模型只能处理一个固定长度的"上下文窗口"（context window）内的信息——目前主流模型的上下文窗口从 128K 到 200K tokens 不等。这个窗口就像模型的"工作记忆"，一旦会话结束，窗口中的所有内容都会被清除。与人类大脑会自动将重要经验编码为长期记忆不同，LLM 每次都必须从头开始理解所有背景。

而把项目历史全部塞进上下文窗口，既昂贵又低效，还会稀释模型对当前任务的注意力。Token 计费意味着更长的 prompt 直接增加 API 成本，而研究也表明，当上下文过长时模型对中间部分信息的关注度会显著下降（即"lost in the middle"现象）。

近期登上 Product Hunt 的开源工具 MemoryCustodian（当日排名 #6，获得 162 票、25 条评论），正是瞄准了这个痛点。它的核心主张只有一句话：给编程智能体一个"仓库原生（repo-native）"的持久记忆。

什么是"仓库原生记忆"：记忆即代码的设计哲学

MemoryCustodian 的设计哲学与市面上多数记忆方案截然不同。当前主流的 AI 记忆解决方案通常依赖向量数据库（如 Pinecone、Weaviate、ChromaDB 等），将文本转换为高维向量 embedding，通过计算向量之间的余弦相似度来实现语义检索。在此基础上的 RAG（Retrieval-Augmented Generation，检索增强生成）架构会将知识库文档切片并向量化存储，当用户提问时，系统检索出语义最相关的片段注入 prompt。这种方案的优势在于自动化程度高、能处理大规模知识库，但缺点是检索结果不透明、可能引入噪声，且通常依赖外部托管服务。

MemoryCustodian 选择了完全不同的路径：它不依赖任何托管服务，也不使用外部向量数据库，而是把 AI 的记忆直接以纯 Markdown 文件的形式存放在你的代码仓库里。

具体来说，那些关键的项目信息——技术决策、约束条件、被否决的方案、以及项目背景——都会被记录成 Markdown 文档，和你的源代码一样存在于 repo 中。这带来了几个直接的好处：

• 可审查：记忆内容以纯文本存在，任何团队成员都能像 review 代码一样审阅 AI 记住了什么；
• 可版本化：记忆随 Git 一起提交，你能追踪它的演变历史，也能回滚错误的记录；
• 可共享：团队成员克隆仓库即可获得同一份项目记忆，无需额外配置；
• 可删除：不再需要的记忆可以像删代码一样直接删掉，透明可控。

这种"记忆即代码"的思路，把 AI 的隐性上下文变成了显性的、可管理的项目资产。相比那些把记忆锁在云端黑盒里的方案，它给了开发者完全的掌控权。

用 manifest 机制精准加载相关记忆

仅仅把记忆存下来还不够。如果每次都把全部记忆塞给模型，又会回到"prompt 膨胀"的老问题。MemoryCustodian 的解法是引入一个 manifest（清单）机制：它只加载与当前任务真正相关的记忆片段，而非一股脑全部注入。

Manifest（清单）机制在软件工程中有悠久的传统。Android 应用的 AndroidManifest.xml 声明了应用需要的权限和组件，npm 的 package.json 列出了项目依赖，Kubernetes 的 YAML 清单描述了要部署的资源。MemoryCustodian 借鉴了同样的思路：通过一个索引文件声明"当前上下文需要加载哪些记忆片段"，实现按需加载而非全量注入。这种显式声明的方式虽然需要一定的手动维护，但换来了完全的可预测性——开发者清楚知道模型将看到哪些信息。

这个设计相当关键。它意味着无论你的项目记忆积累到多大规模，实际进入上下文窗口的内容都保持精简，从而在"记得住"和"不臃肿"之间取得平衡。这也是它区别于简单地维护一个大 README 或 CLAUDE.md 文件的地方。

本地优先与跨智能体：解决隐私和工具锁定问题

MemoryCustodian 的另外两个核心卖点是 local-first（本地优先） 和 cross-agent（跨智能体）。

本地优先（Local-First）是一种由 Ink & Switch 实验室在 2019 年系统阐述的软件设计理念，其核心原则包括：数据主要存储在用户本地设备上，软件离线时仍能正常工作，用户对自己的数据拥有完全所有权。这一理念是对过去十余年"云优先"趋势的反思——当所有数据都存储在云端时，用户实际上失去了对自己数据的控制权，面临服务商倒闭、API 变更、隐私泄露等风险。

在 MemoryCustodian 的语境下，本地优先意味着你的项目决策、架构约束这些敏感信息不会被上传到任何第三方服务器。对于注重数据隐私和合规的企业团队来说，这一点尤为重要——记忆始终留在你自己的仓库里，受你自己的访问控制策略保护。

跨智能体则解决了工具碎片化的问题。2024-2025 年间，编程 AI 助手市场呈现爆发式增长和高度碎片化：Claude Code（Anthropic）以代理式工作流见长，能自主执行多步骤编程任务；Codex CLI（OpenAI）强调本地沙盒执行；Gemini Code Assist（Google）、GitHub Copilot、Cursor、Windsurf 等工具各有侧重。每个工具都发展出自己的记忆/上下文管理方案（如 Claude 的 CLAUDE.md、Cursor 的 .cursorrules），但这些方案互不兼容。

今天你可能用 Claude Code，明天团队里有人偏好 Codex，还有人在试 Gemini。传统方案往往绑定在某个特定工具的记忆体系上，一旦换工具记忆就丢了。而 MemoryCustodian 以标准 Markdown 为载体，理论上任何能读取仓库文件的编程智能体都能复用同一份记忆，避免了厂商锁定。

一个务实的工程化选择

从技术选型上看，MemoryCustodian 并没有追逐时髦的向量检索或复杂的 RAG 架构，而是选择了最朴素、最透明的方案——文本文件加清单索引。这看似"简单"，实则是一种务实的工程判断：对于编程场景下的项目记忆，可读性、可审查性和 Git 兼容性，往往比语义检索的精妙更有实用价值。

这种选择背后有一个重要的工程洞察：编程项目的记忆不同于通用知识库检索。项目技术决策通常数量有限（几十到几百条），结构化程度高，且与特定模块或功能域强关联。在这种规模和特征下，精确的手动索引反而比模糊的语义匹配更可靠——你不希望模型因为向量相似度的微妙差异而加载了错误的决策记录。

开发者能一眼看懂 AI 记了什么，能手动修正，能纳入代码评审流程——这种确定性和可控性，恰恰是黑盒记忆方案所缺失的。

适用场景与局限性分析

这款工具由 Zekun Wang 开发，开源、免费，归类于开发者工具与人工智能领域。它最适合的场景是：

1. 需要长期维护、上下文复杂的中大型项目；
2. 多人协作、希望团队共享同一套 AI 上下文的开发团队；
3. 对数据隐私敏感、不愿把项目信息交给托管服务的用户；
4. 同时使用多种编程 AI、希望记忆能跨工具复用的开发者。

当然，纯文本加手动 manifest 的方案也有其取舍。当记忆条目极多时，如何组织和检索可能需要一定的人工维护成本；相比自动化的语义检索，它对"什么该记、什么该加载"的判断更依赖人的介入。这既是它的透明优势，也可能是它的规模瓶颈——当项目记忆从几十条增长到数百条时，manifest 的维护本身可能成为一项负担，届时可能需要引入分层组织或半自动化的索引生成机制作为补充。

结语

随着编程智能体逐渐成为开发工作流的一部分，"AI 记忆管理"正在从一个附加功能演变为核心基础设施。MemoryCustodian 提供了一个思路清晰、立场鲜明的答案：记忆不该藏在云端黑盒里，而应像代码一样，留在仓库中，被审查、被版本化、被团队共享。

在众多追求复杂架构的记忆方案里，它"记忆即代码"的克制设计反而显得难得。对于每天与编程 AI 打交道、又苦于其"健忘"的开发者而言，这或许值得一试。