dsh memory plugin 数据存在哪：DeepSeek Harness 记忆的备份、迁移与彻底清除

把 dsh memory plugin 的记忆目录整个拷到新机器后，模型开始一本正经地「失忆」，而旧机器上一切正常。 备份看起来完整，问题却出在数据生命周期的顺序上：原文搬过去了，索引和配置没有跟上。DeepSeek Harness 的记忆不是一堆静态文件，它从写入那一刻起就在经历一条有先后关系的链路。

写入：DSH插件 把一句话放进哪个目录

写入决定了记忆的归属和范围，选错层，后面无论怎么备份都找不回正确的上下文。

写入通常发生在会话结束或者显式调用记忆工具的时候。插件会把内容整理成一条记录，按作用域放进对应的目录：会话层只服务当前对话，项目层跟着项目走，全局层跨项目可见，习惯层则记录经过确认的行为规则。四层不是四个版本，而是四种可见范围。

定位这些目录的第一步是确认 DSH_HOME。记忆、插件配置和会话数据通常都在它下面，但具体子目录由插件自己决定，不能照搬别人的路径。可以先在 DSH Plugin Hub 对照插件版本与说明，再在文件系统里确认目录结构，比凭印象搜索可靠。

写入还有一个容易被忽略的条件：并发。两个会话同时写同一个命名空间，后写的可能覆盖先写的，日志里未必有冲突提示。内容莫名缺失时，先回想那段时间有没有并行会话，再去看文件时间。

想确认写入是否正常，可以记住一条带唯一标记的内容，再去目录里搜这个标记。标记出现且时间正确，说明写入链路是通的；标记不出现，问题就在插件加载、权限或作用域，而不是后面的索引。标记里最好带日期或随机串，避免和旧内容混淆。

索引：DeepSeek Harness 搜索的不是原文，而是另一份结构

索引是原文之外的第二份数据，它决定记忆能不能被搜到，却不随原文自动更新。

插件写入原文后会生成索引，把文本切成便于检索的片段并记录位置。搜索时命中的是这些片段，而不是逐字扫描整个目录。所以原文完整、索引缺失时，表现就是「文件在但搜不到」，这一点在迁移后尤其常见。

索引有独立的生成时间和存放位置。插件升级、修改数据目录或者换机器之后，索引可能仍指向旧路径，也可能因为格式变化而无法读取。检查时把原文时间与索引时间放在一起看，时间差往往比错误日志更能说明问题。

重建索引是常规修复手段，但它不是无损操作。重建前先复制整个记忆目录，确认原文、索引和配置都有副本，再执行重建。重建后用原文里的独特词搜索一次，能命中才算恢复，不要只看命令返回成功。

索引体积也会影响体验。长期积累的会话层记忆如果全部纳入索引，搜索会变慢，排序也会被稀释。定期清理过期会话，比单纯重建更治本。

召回：DeepSeek Harness 每次只取回一小把记忆

召回是在预算内做取舍，正确片段存在，不代表它一定排得进上下文。

每次提问前，插件会拿问题去索引里找候选，按相似度、时间新近程度和作用域排序，再按上下文预算截断。排在前面的片段进入模型，后面的等于没被记起。用户感知到的「记不住」，多数时候是排序与预算的结果。

作用域在召回阶段再次发挥作用。项目层的记忆换个目录就可能不参与检索，全局层的记忆则有机会跨项目出现。迁移后如果只搬了原文却改了目录结构，作用域会跟着变，召回结果自然和旧机器不同。

同一条记忆，换个问法就可能从「想不起来」变成「答得很准」。这不是模型不稳定，而是字面匹配对措辞敏感。排查时用原文里的独特词提问，能区分「索引里没有」和「排序没排上」。

理解召回有预算，也就理解了为什么记忆不是越多越好。无关片段太多，会挤占真正有用的位置。生命周期管理的一部分工作，就是让索引里留下仍然有效的记忆。

清理：dsh memory plugin（DSH插件）的删除要覆盖四处

删除只处理原文会留下索引和缓存，旧内容仍可能被召回，看起来像「删了但没删干净」。

第一处是记忆原文，按会话、项目、全局与习惯逐层确认，避免只清了当前项目。第二处是索引，索引不删或未重建，搜索仍会返回已经删除的片段。第三处是插件缓存与临时文件，它们可能保存了摘要或中间结果。

第四处是插件配置与 profile 引用。有的配置里写着存储根目录或命名空间，目录删了、配置还在，下次启动插件可能重新创建一个空目录，让人误以为数据自己回来了。清理前先确认没有其它 profile 指向同一位置。

删除前先备份，哪怕最终确定不再需要。记忆是长期资产，误删之后很难从会话历史里完整还原。备份成本很低，恢复成本很高，这个账不难算。

清理完成后不要只看目录是否为空。用旧关键词搜索一次，确认不再召回，再检查插件启动日志有没有重建索引的动作。搜索为空、日志安静，才算清理完成。

备份：DSH插件 的数据要连索引和配置一起搬

备份的对象是整条链路，不是单个目录；原文、索引、配置和版本信息缺一项，恢复就可能不完整。

最稳妥的方式是停止写入后复制整个记忆目录，保留原有层级，不打平、不挑选。层级本身就是作用域信息，打平之后即使文件都在，插件也未必能正确归类。复制完成后对比文件数量与大小，再记录插件版本和本体版本。

跨机器迁移时，按下面的顺序做，能把「文件在但搜不到」的概率降到最低。顺序本身不复杂，关键是不要跳步。每一步都留下可以复查的结果，再进入下一步。

1. 在旧机器上停止会话写入，确认没有正在运行的任务会继续修改记忆目录。
2. 复制整个记忆目录，包含原文、索引、缓存与插件配置，保留目录层级。
3. 记录插件版本、本体版本与 DSH_HOME 的实际路径，随备份一起保存。
4. 在新机器上恢复目录，确保 DSH_HOME 与插件配置指向新的实际路径。
5. 启动后先重建一次索引，再用旧环境里的典型问题测试召回。
6. 对比新旧环境的回答，确认记忆能读、能搜、能召回，再清理临时副本。

只迁移部分项目时，可以按层导出，但要记得把对应的配置一起带走。只带原文的迁移，在新机器上通常表现为记忆文件齐全、提问却答不出来。导出清单里要写明每一层来自哪个目录，恢复时才不会放错位置。

备份不必每次全量，但升级和迁移前的那一次应该是全量。保留最近两三个版本，既能回退，也不会让目录无限膨胀。备份文件本身也要放在记忆目录之外，否则一次误删会连副本一起消失。

把生命周期走一遍，dsh plugin 的记忆才可迁移

写入、索引、召回、清理、备份是一条闭环，任何一段单独处理都只能得到局部正确。

这五段里，写入和索引发生在保存侧，召回发生在使用侧，清理与备份则决定数据能不能长期留存。排查问题时按这个顺序走，先确认数据在不在，再确认能不能搜到，最后才怀疑模型有没有用上。顺序反过来，容易把索引问题误判成模型问题。

不管称它为 DSH插件 还是 DeepSeek插件，记忆数据的组织方式都绕不开原文与索引的分离。理解这一点，备份时就不会只复制 Markdown，清理时也不会只删一个目录。叫法不同，这条结构关系不会变。

验证恢复时不要只看文件数量。打开一条旧记忆，确认内容完整；搜一个独特词，确认能命中；再提一个依赖它的问句，确认召回成功。三步都过，备份才算可用。

最后留一个习惯：每次升级插件或迁移机器之前，先做一次完整备份，再用一条带标记的记忆验证恢复。验证通过再删旧副本，比事后补救从容得多。备份不是一次性任务，而是每次变更前的固定动作。

来源：dsh-memory-plugin 插件条目、插件与生命周期、DeepSeek Harness 快速开始。