几乎所有 AI 记忆插件的工作方式都如出一辙：分析对话，生成碎片，塞进向量数据库，每次 prompt 检索 Top 5 注入。更花哨的还会搞长期短期记忆分层、加后台 daemon 去重、加"梦境者"夜里重写记忆、加 reranker。但修来修去还是同一套有缺陷的架构。
仔细想想真正要解决的问题：你希望 Agent 理解你的项目，知道某个功能在哪、为什么这样设计、团队之前达成了什么共识。但结果是一堆 RAG 碎片的抽奖，每次注入 5 条，赌它们正好能浮上来。即使偶尔赌对了，Agent 仍然不理解你的项目。
liao.gg 上的一篇文章对此给出了明确诊断：记忆插件整个生态都在解决错误的问题。
RAG 式记忆的五个硬伤
- 相似性检索只看距离，不看对错。向量检索只关心 embedding 离得近不近，不关心哪条是对的、哪条是新的。
- 碎片脱离上下文。一条 RAG 片段能塞的信息有限，动机、环境、约束、踩过的坑全丢了。
- 过去被当成事实。代码每天都在变，你没法知道哪些碎片还准确。
- Agent 不知道自己不知道什么。就算给它搜索工具，它怎么会知道自己该搜什么？
- 存储不可审计。一万条 embedding 躺在数据库里，哪些是旧的、哪些在带偏判断，你查不出来。
这些问题指向同一个根因：所有记忆插件都默认"Agent 忘了东西，所以得帮它记住更多"。但这不是人类处理知识的方式——没人会去翻三年前的会议录像来确认一个功能的约束条件。大家把事情记下来，然后查记录。
换个思路：文档，不是记忆
代码项目里，人们写 README、写 spec、写决策记录，干活前查阅，干完活更新。Agent 也可以这样。
给 Agent 一个可读可写的 Markdown 工作区，里面有指令、规格、决策、索引、调研笔记。工作循环从 prompt → build → forget 变成 prompt → consult → build → update。
不需要向量库、不需要 embedding、不需要后台进程。每个文档你都能直接看、直接改、直接提交、直接跟团队分享。
这个思路的作者已经用了一年多，还开源了一个插件叫 Operator Memory，支持 Claude Code、Codex、OpenCode 等多个平台。它把知识分三层存放：.operator/ 是私有项目知识，.operator-shared/ 可以跟仓库一起推送，~/.operator/user/ 放个人规则跨项目共用。
也有人不同意
游戏开发者 Mario Zechner（libGDX 作者）说："推荐阅读，但我仍然不同意。对代码来说，记忆和文档都不高效。你的代码库就是全部所需。让它模块化，让模块足够小，最多维护一张小地图指路。"
有人反对："文档和注释过期太快，会严重误导。"
Mario 回复："你要是明确告诉它们怎么做，它们其实可以。"
还有人提出了一个更微妙的角度："大多数知识工作根本没有代码库，痕迹散布在十几个网站里，所以记忆插件才干了仓库该干的活。"
这倒是点出了关键。对纯代码项目，文档精简到一张地图确实够了。但那些没法用代码表达的东西——用户偏好、产品决策、跨系统依赖、调研结论——一个可维护的文档空间比抓取对话历史靠谱得多。
记忆插件本质上是在跟"遗忘"较劲。文档不是。文档是面向未来写的，只记录此刻值得留下的结论。Agent 有了文档，至少你还能审阅它知道什么。那一万条 embedding，你连错在哪都查不出来。
