Agent 的「记忆」通常以两种形态存在：向量库里的切片，或者数据库里的一行行记录。两种都对，但都要求你先接受一个前提——记忆的所有权在系统手里，不在你手里。ReMe 走的是另一条路：把记忆直接写成你电脑上的一堆 Markdown 文件，索引全部可重建，删掉索引不丢内容。
这个项目在 GitHub 上有 3,654 星（本站快照 3,647 星，2026-10-19 数据），Apache-2.0 许可，主体用 Python 写，核心库发布在 PyPI 上。它同时提供了一个 DSH 插件 @agentscope-ai/reme-dsh-plugin（npm 版本 0.1.2），本站的兼容性检查里登记的是「已验证」，并且在 dsh 0.2.1-rc.2 下做过真实安装（L4）。
两种记忆形态的实际差别
向量库的问题是不可读。你问「上次定下的周报时间是几点」，系统能召回到一段切片，但你没法打开那段切片看一眼、改一个字、再放回去。文件形态的记忆没有这个问题：digest/personal/ 下面就是若干 Markdown，带 frontmatter 和 wikilink，你用任何编辑器都能改。
代价也很直接：文件形态要求索引层能容忍外部改动，否则你手改一个文件，索引就永远对不上。ReMe 的解法是把索引整个放进 metadata/，并明确标注这一层可重建——BM25、wikilink 图、可选的向量，全部从源 Markdown 重新生成。
工作区是怎么分层的
默认工作区是当前目录下的 .reme/，也可以用 workspace_dir=... 指到别处。目录不是随便分的，它对应记忆的四个阶段：
<workspace_dir>/
├── metadata/ # 可重建的索引、图、目录与缓存
├── session/ # 对话源记录（auto_memory 保存的 jsonl）
├── resource/ # 外部素材
├── daily/ # 轻度加工：日事实、对话摘要、素材卡片
└── digest/ # 长期记忆：personal / procedure / wikisession/ 到 daily/ 是加工，daily/ 到 digest/ 是沉淀。digest 又分三段：个人事实、过程性经验、知识节点。这个分层的好处是每一层都能单独检查——日卡片写错了，改日卡片；长期记忆错了，改 digest 里那一个节点，不用重建整个库。
五个动作，各管一段
| 动作 | 触发方式 | 产出 |
|---|---|---|
| auto_memory | Agent 钩子或 reme auto_memory | session/dialog/*.jsonl + 当日 daily 卡片 |
| auto_resource | 素材监听或手动 | 带来源的素材卡片 |
| auto_index | 后台 watcher 或 reme reindex | BM25 / 向量 / wikilink 图 |
| auto_dream | 日程或手动 | digest/** 下的长期节点 |
| proactive_read | Agent 决策前调用 | 结构化兴趣主题 |
这里有个容易被忽略的细节：reme reindex 只重建已有切片的索引，不重新摄入文件。它的定位是「索引坏了修索引」，不是「新增文件后补索引」——后者归后台 watcher。把两者混为一谈，就会出现「我明明 reindex 了，新文件还是搜不到」。
auto_dream 也有明确边界：默认只从最近两天变更过的文件里提取，一次最多五个可复用单元，然后去创建、印证、精修或纠正 digest 节点。它不是全量重写，所以你不会某天早上发现整个知识库被模型改了一遍。
检索质量靠什么保证
默认配置下只有 BM25 加 wikilink 邻域，embedding 是关闭的。想要语义检索，得改 reme/config/default.yaml 的两处（打开 components.as_embedding 与 components.embedding_store），再把 file_store.default.embedding_store 从空串改成 default，并另配 embedding 的 Key。向量结果与 BM25 用 RRF（倒数排名融合）合并。
召回返回的不是整篇文档，而是带行号区间的片段加有界的 wikilink 邻居。这个设计对 Agent 更友好：上下文里进的是「第 12–28 行」，不是一整篇三千字的笔记。
仓库公布的评测数据可以直接引用：LongMemEval cleaned-s 的 500 个问题上 89.4%，BEAM 100K 上下文 66.1%、1M 上下文 65.0%，π-Bench 五人格的 PROC 得分 0.580。这些是仓库自己的参考跑分，样本、提示词与判分口径都写在对应文档里，不是第三方复核结果。
DSH 插件做了什么、没做什么
@agentscope-ai/reme-dsh-plugin 只做五件事：
1. 会话开始时注入一段「长期记忆使用指引」；
2. 注册一个只读的 reme_search 工具；
3. 每轮对话结束后，把用户和助手消息批量提交给 auto_memory；
4. 按日程跑 auto_dream；
5. 提供一个 ReMe Status 页，看连通性、队列、整合结果与工作区文件。
它不把历史记忆塞进系统提示词。官方文档写得很清楚：注入的是使用指引，只有当 Agent 判断这次请求依赖历史时，才会去调 reme_search。这么设计是为了避免旧内容被模型当成新指令执行。
同样值得记一笔的是采集侧的排除规则：插件注入的上下文和工具返回结果不会被写回长期记忆。没有这条，模型读到的检索结果会在下一轮被当成「用户说过的话」重新入库，几轮之后记忆库就被自己的输出污染了。
它不适合什么场景
如果你的使用方式是「一天几十个短会话、每次都不想留痕」，这套东西的日常开销（文件增长、整合任务、索引重建）比收益大。如果你需要的是跨团队共享的知识库，ReMe 的定位是 local-first、用户持有文件，共享要靠你自己同步目录。如果你完全不接受「让模型写你的 Markdown」，那它从根上就不合适。
总结
ReMe 的价值不在检索算法，而在所有权：记忆以可读文件存在，索引随时可重建，删掉 metadata/ 不会丢一条事实。想对照其他同类插件的中文清单与安装形态，可以看 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：长期和同一个 Agent 协作、希望记忆可读可改的人；需要把对话沉淀成个人知识库的开发者；已经在用 Markdown 做笔记、想把 Agent 接进现有目录的人；对「记忆写在别人数据库里」有顾虑的人。
不适合：只想要一次问答、不需要跨会话记忆的人；不愿维护本地服务与配置文件的人；需要多人实时共享同一份记忆库的团队。
标签：ReMe、DeepSeek Harness、长期记忆、Markdown、本地优先
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。