分层记忆 Kagurazaka135/dsh-memory

dsh-memory

给 DeepSeek Harness（dsh）加一层跨会话的长期记忆。

dsh 的会话是孤立的：新开一场，之前的项目约定、你的偏好、上周定下的方案都不在里面。
这个插件把该长期保留的东西抽出来存成明文文件，下次会话开始时递回给模型。

不依赖数据库、不调外部服务、不需要 API key。记忆就是你磁盘上的几个 Markdown 和 YAML。

状态

| 环境 | 状态 |
| dsh 0.2.x（PC） | 已实测，功能完整 |
| dsh 安卓版（App 内插件） | 已实测，功能完整 |
| dsh 0.1.x | 工具可用；无 schedule 服务时不会自动定时整理 |

验证覆盖：工具注册、写读落盘、版本链、分片、检索、简报注入、跨进程/重启持久、真实环境零污染。

它做什么

存事实，不存聊天记录。 「发布分支叫 stable」「周报周五下午发」这类长期有效的信息写成一条条事实。
值变了就追加新版本，旧版本留在 history 里 —— 所以能回答"这个什么时候改的、改成什么了"。

新会话开始时把简报交给模型。 一段固定的能力说明常驻系统提示（字节稳定，不破坏 prefix 缓存），当前简报和记忆目录走动态快照，内容变了才更新。

按需整理。 手动调 memory_organize，或在 profile 有 schedule 服务时到点自动跑：扫最近几场会话，把反复出现、值得长期保留的内容提炼进事实和简报。只增不删。

事实多了按主题拆文件。 默认超过 80 条开始分片，配一份索引；检索先按索引挑文件，判不准就全读 —— 宁可慢，不会漏。
只在首次分片时询问模型分组方案，之后新事实走纯代码增量归属，布局稳定。

记忆会过期

存下来的是写入那一刻的断言，不是现值。文件改了、配置换了，记忆不会自动跟着变。

所以插件在三个地方提醒模型：

- 系统提示里常驻一条规则：涉及文件名、路径、配置值时，行动前先核验当前状态
- memory_recall 命中内容含具体路径/配置时，结果末尾附提醒
- 查不到时不给空列表，而是给出下一步：换更少更独特的词 → 按标签查 → 看简报

0 命中不等于从未记录。 换个措辞就是另一条命中。

数据长什么样

全部在 $DSH_HOME/memory/（默认 ~/.dsh/memory/，可用 memory_dir 改）：

memory/
brief.md 当前摘要（Markdown，可直接读改） facts.yaml 事实（分片之前在这里） candidates.yaml 待确认的线索 facts/ 分片之后的事实（超过阈值才出现） _index.yaml 分片索引（缓存，可删，不影响任何事实） <topic>.yaml 按主题拆出来的分片 unsorted.yaml 归不进去的兜底 .archive/ 旧的 facts.yaml 归档（移动过来，不删） log/YYYY-MM-DD.json 整理日志（追加式） .sessions.json 已处理会话台账

一条事实：

- id: "mem-1792927799706-001"
fact: "发布分支" since: "2026-03-02" history: # 版本链，最后一条 = 当前值
- date: "2026-03-02"
value: "release"
- date: "2026-04-18"
value: "stable"
note: "用户要求改名"

安装

dsh plugin --profile <你的profile> add <包路径 / 包名>

装上后六个工具立即可用。夜间自动整理需要 profile 里存在 schedule 服务（如 dsh-experimental-schedule-bundle）；没有的话手动整理一样能用。

不需要配 API key 或代理。 整理走宿主自己的模型服务（ctx.llm），你在 dsh 里配的模型就是它用的模型。默认跟随宿主默认模型，想指定就在配置里写 organizer_provider + organizer_model。

配置

在 profile 的 cordis.patch.yml 里覆盖：

| 配置项 | 默认 | 说明 |
| memory_dir | $DSH_HOME/memory | 记忆存放目录 |
| organizer_provider | 跟随宿主 | 整理用的 provider |
| organizer_model | 跟随宿主 | 整理用的模型名 |
| daily_time | 04:00:00 | 夜间整理时间（本地时区） |
| time_zone | 宿主时区 | IANA 时区名 |
| scan_sessions | 12 | 每次整理最多扫多少场会话（上限 40） |
| shard_threshold | 80 | 事实超过多少条开始分片；设 0 关闭 |
| enable_shard | true | 完全关闭分片 |
| enable_schedule | true | 关掉自动注册夜间任务 |
| organizer_session | memory-organizer | 整理专用会话 id |

工具

| 工具 | 用途 |
| memory_brief | 读当前简报 |
| memory_recall | 按关键词或标签检索事实 |
| memory_note | 记一条事实（同主题自动出新版本） |
| memory_candidate | 记一条待确认的线索 |
| memory_promote | 把线索升格成正式事实 |
| memory_organize | 整理一次；dry_run 只报告不落盘，reshard 重排已有分片 |

一次整理做什么

顺序固定：

1. 归并同义的待确认线索（多余的标 merged 保留，不删）
2. 扫最近几场会话，按 id 剔掉整理会话自身和子代理会话
3. 把会话摘录 + 现有事实 + 现有候选 + 当前简报交给模型，要一份 JSON
4. 落地：事实追加版本、候选去重后新增、简报换新（旧的归档）
5. 事实超阈值时分片

它不会做的事（有负面清单约束）：

- 不把整理过程本身写进记忆（「扫了几场」「跑了几次」这类）
- 不记绝对路径、主机名、端口，除非用户明确要求长期记住某个地址
- 不把一次性状态写成事实
- 模型输出解析不了就什么都不写，宁可不记，不编造

所有更新都是只增不删：旧简报进 log/ 归档，旧事实版本留在 history，被合并的候选标 merged 仍可见。代码里没有删除历史条目的路径。

已知边界

- 检索是子串匹配，不是语义搜索。 换措辞可能查不到，所以 0 命中时会给升级路径。
- 候选去重只处理格式噪音。 会剥掉 （出现 N 次） 这类尾巴，真正换说法的仍可能分成两条 —— 这是有意的，误合并比多存一条更糟。
- 整理由模型判断「什么值得记」。 可能漏记也可能多记。文件是明文的，看不过去直接改。
- 分片后新增的事先进 unsorted，下次整理才按标签归位。这是为了布局稳定，不丢数据。
- reshard 只对已分片的库有效；空库不会凭空造片，首次分片由 shard_threshold 触发。

已知限制

L4 摘要只存结论，细节回不去

简报是压缩过的——它记得「做了什么」，但不记得「为什么那样做」。

干完一段活，那 100 多步的判断过程会被压成几行。下次遇到同类任务，它能想起「上次做过」，但想不起「上次那个坑是怎么绕的」。

这个需求是它自己在真机上提的（原文和截图在 docs/field-notes/）：

「干完活，这段经历就压缩成几行摘要，细节全丢了。下一代要是能记住『上次那个 docx 为什么那样排』『那次点击为什么没反应』，会比多两个工具管用得多。」

想好的方向是摘要里留指针，细节沉淀到原文，再给模型一个工具去翻。但还没做——原因和判据记在 TODO.md 第 8 条。

顺手能做的活，欢迎认领。

断档不可感知

服务重启或长时间没跑之后，它拿到简报看不出中间空了一段。它知道现在几点，但不知道自己上次醒着是几点。

对应 TODO 里同一节的后半条。

开发

npm run build # tsc
node e2e/run.mjs # 端到端，默认零网络

e2e 默认用桩数据跑通全链路。要对接真实模型：

E2E_LLM_URL=https://.../v1/chat/completions E2E_LLM_KEY=... node e2e/run.mjs

许可

MIT