一个记忆插件会分析你的对话，生成1000条孤立片段，塞进向量数据库。你每发一次提示词，它就挂上最相似的5条；如果智能体还是懵的（它确实是懵的），就再手动搜一批。这就是他们口中的"记忆"。
用起来很怪。你想要的是让智能体理解你的项目：某个功能在哪、为什么这么建、你们当初约定了什么、你在意什么。结果你得到的，是每次提示词都注入一次RAG片段的抽奖，指望对的那几条能浮上来。
就算它偶尔奏效，智能体依然不理解你的项目。整个记忆插件生态，都在解一道错题。
因为智能体不需要记忆，它需要文档
市面上每一个记忆插件都是同一套玩法。这就是全部架构。有些工具更花哨：让智能体逐字搜索历史对话记录；或者搞一套多层记忆系统，把短期、长期记忆分门别类；或者加一堆后台守护进程去审查、合并、去重记忆。还有"做梦者"在夜里重写记忆、持续上下文压缩、重排序器等等。
每个插件都在往同一套有缺陷的架构上，叠加新的烧token"功能"。这就是为什么它们没有一个能稳定工作。
这些记忆插件都栽在同一批问题上，而它们试图修复却修不好，是因为它们共享同一个假设：
智能体会忘，这就是问题所在。所以解法是记住。要记得更好，就该抓取更多、索引更好、召回更聪明。
整套论点都围绕"抓取和回忆过去"打转。但没有任何人是用这种方式处理知识的。没人会去重看三年前的团队会议录像，只为了回忆某个功能的约束条件。人们把东西写下来，然后用这些记录。
同理，解法不是给智能体一个搜索工具，让它在上千万token的历史对话里翻找，把发生过的事重新拼成碎片。
解法是基于文档的记忆。
今天，人们用AI以光速产出产品、功能和垃圾，全程不读、也不理解一行代码。在这种节奏下，文档沦为事后补丁再正常不过——而它本该比以往任何时候都重要。
人们早就知道智能体需要上下文。这就是AGENTS.md文件被发明出来的原因：别让智能体两眼一抹黑地跳进代码库。它确实管用。但很多时候，这单个文件就是项目唯一的文档。
一个文件不够。智能体需要的是一整个大脑，一个结构化的工作区，让它能主动记录指令、规格、决策、调研、索引——不用等人开口。
- 记录代码评审流程怎么走的指令
- 记录和用户讨论过什么的规格说明
- 对陌生库或API的可复用调研
工作时，智能体从大脑里读取文件，拿到相关且完整的上下文。工作后，它更新过时的内容，在需要的地方补上新文档——趁完整图景还在上下文里。
这样一来，智能体循环就从"提示→构建→遗忘"，变成"提示→查阅→构建→更新"。记忆从一个硬挂在智能体上的RAG数据库，变成一个你能读、能改、甚至能分享的工作区。
一年多前刚开始用AI编程时，我就意识到了这个问题。我想要一种让智能体跨会话记住工作的方式，于是先建了一个internal/文件夹，让智能体把一切写下来：规格、计划、索引。我要求它每次干活前先读对应文档和索引，干完再更新。
这套简陋的指令慢慢长成一个正式系统，最后变成一个插件——Operator Memory，我在自己所有项目里一直在用。
Operator Memory用上面描述的模式提供基于文档的记忆。它给智能体一个Markdown大脑，用来持久保存重要知识：指令、规格、调研、索引。工作前，智能体总是先查阅大脑里的相关文档；工作后，它更新大脑，回访过时文档，缺文档的地方补上。
没有向量数据库。没有嵌入。没有摘要器、策展器、更新器、做梦者，或任何其他烧token的后台守护进程。没有黑盒召回。
在Operator里，一切都是纯Markdown文档，你能读、能改、能提交、能和团队分享。这套系统我已经用了一年多。想试试的话，它是免费开源的：https://github.com/aerovato/operator-memory
热门跟贴