dsh memory plugin 记不住或记错：DeepSeek Harness 写入、索引与召回三段排查

上周让 DeepSeek Harness 记住的一条构建命令，今天再问，它却回答「没有相关记忆」，而我明明能在记忆文件里搜到那句话。 这不是记忆丢了，更像是记忆没有被送到它该被看见的位置。dsh memory plugin 的链路比大多数人以为的长，文件存在只是第一站。

记忆明明在，DeepSeek Harness 的 dsh memory plugin 却答不上来

先把现象钉死：文件里有原句，模型回答里却没有它，问题落在「取用」而不是「保存」。

我先做了最笨的验证，在记忆目录里用 grep 搜那条命令的关键词，几秒就搜到了，连写入日期都能看到。这个结果排除了最坏的情况：插件确实把内容写下来了，目录权限、磁盘空间、插件加载这些常见的写入故障都不成立。可当我原样再问一次，回答依旧是「没有找到相关记录」。

接着我意识到自己问错了方向。模型并不是在回答时逐字读取记忆文件，它读到的是一段被检索出来、再塞进上下文的片段。文件与上下文之间隔着索引和排序两步，任何一步出问题，表现都像是「记不住」。把「文件在」当成「能想起来」，是这类排查里最常见的误判。

还有一个细节值得记下来：同一句话在 A 会话能答，在 B 会话答不出。这说明存储层没有坏，坏的是这次检索的条件。会话不同、问题措辞不同、当前项目目录不同，都会改变候选片段的范围和排序。

于是我把模糊的抱怨改写成一句可以检验的话：这条记忆有没有进入索引，进入索引之后有没有排进本次召回的前几名。后面的检查都围绕这一句展开，不再反复重装插件。问题一旦写成可验证的形式，情绪就退场了。

先问一句：DeepSeek Harness 里这条记忆是没写进去，还是没被找出来

写入和召回是两条独立的失败路径，混在一起查只会把范围越查越大。

写入通常发生在会话结束或显式调用记忆工具的时候。那次会话如果被中断、插件还没加载完、或者目录不可写，原文根本不会出现。反过来，只要原文出现了，写入这一段基本可以判定为通过，不必再纠结插件开关和权限设置。

召回发生在每次提问之前。插件会拿当前问题去索引里找候选片段，按分数排序，再按上下文预算截断。索引缺失、作用域设错、相似度阈值过高、预算太小，都会让正确的片段落选。它的失败方式很安静，日志里往往只有一行「未命中」，不会有红色报错。

我的判断顺序很土，但一直有效：先 grep 原文，再查索引文件，最后看召回日志。原文在而索引没有，问题在第二段；原文和索引都在而回答没有，问题在第三段。每一次只查一段，结论才不会互相污染。

这一步做完，疑问从「为什么记不住」缩小成「为什么没取到」。范围一小，后面的动作就具体了：要么重建索引，要么换问法，要么调整作用域。每排除一段，就在纸上划掉一段，剩下的自然浮出来。

查文件与索引：DSH插件 写下的东西停在了哪一层

原文与索引的时间戳对不上，是「文件在但搜不到」最常见的原因。

记忆目录通常按会话、项目、全局分层，我逐层看了修改时间。原文的最新时间就是刚才那次写入，没有问题；索引文件的生成时间却停在两天前，正好是我升级插件的那天。这个时间差已经把嫌疑指得很清楚。

索引不是原文的附属品，它有自己的生成逻辑和存放位置。插件升级、修改数据目录、或者换了一台机器之后，索引可能还指向旧路径，也可能因为格式变化而读不出来。文件在、内容对，搜索却为空，多半就是这里断了。

重建之前我先复制了整个记忆目录，原文、索引和配置一起备份。然后在 DSH Plugin Hub 对照当前插件版本，确认重建方式属于这个版本，而不是照抄半年前教程里的命令。版本对不上时，重建命令本身就可能失败。

重建完成后，我用原句里的独特词又搜了一遍，这次命中了。索引层确实是断点，但它还解释不了另一件事：有些换了说法的提问，仍然答不出来。那已经不属于索引问题，而是召回排序。

召回顺序才是关键：DeepSeek Harness 先给谁、后给谁

索引只回答「有没有」，召回顺序回答「轮不轮得到」，后者才是答非所问的高发区。

一次提问往往能匹配到很多片段，插件必须给它们打分，再按上下文预算截断。排在前面的片段被送进模型，排在后面的等于不存在。所以真正要问的不是「索引里有没有」，而是「正确的那一条排第几」。

排序里通常混着几类信号：字面相似度、时间新近程度、作用域远近、是否被多次引用。新写入的记忆不一定占优，因为它的措辞可能和当前问题不够接近。时间新近只在分数接近时才起作用，它救不了一条字面完全不沾边的记忆。

我那条构建命令写在「环境约定」里，问的却是「上次那个打包参数是什么」。两者共享的字面词太少，排序自然靠后，最终被预算截掉。换回原句里的「构建命令」再问，它立刻出现了。同一份记忆，两种问法，两个结果。

这也解释了为什么这类问题总让人觉得玄学。召回不是确定性的数据库查询，它更像一次带预算的排序。理解这一点，排查才不会陷入「明明有」的争执，而是去调整措辞、作用域或者阈值。

证：用一条带标记的记忆，把 DeepSeek Harness 的链路复跑一遍

要证明某一层修好了，最好的办法是造一条只可能来自记忆的答案，然后看它能不能被取回。

我选了一个不会出现在训练数据里的标记，让插件记住「部署代号是 ORBIT-7」。这条信息没有现实含义，模型不可能猜中，一旦答对，就只能是从记忆里取出来的。复跑的顺序如下，每一步都要留下证据再往下走。

1. 写入后先在记忆目录里搜索 ORBIT-7，确认原文落盘，且时间戳就是刚才。
2. 用「部署代号是什么」提问，观察回答里有没有 ORBIT-7。
3. 打开召回日志，看这次注入了哪些片段，ORBIT-7 排在第几位。
4. 换一种问法，例如「上次说的那个代号」，比较两次命中的差异。
5. 如果前四步有一处不成立，回到对应层；全部成立后重建索引再跑一次，确认结果稳定。

这条最小案例的价值在于可重复。修复前后各跑一次，结论不靠感觉，也不靠「好像好了一点」。如果第二次仍然失败，日志会告诉你断在哪一步，而不是让你从头再猜一遍。

我还把标记换成中文词试了一次，召回结果明显变差。这提醒我，排查时用的问法要贴近真实使用场景，否则修好的是测试用例，不是日常体验。这不是说中文不能搜，而是说明索引里的分词与匹配方式跟英文并不相同。

复跑时也要留意作用域。同一个标记写在项目层，换个目录提问就可能超出范围；写在全局层，才有机会跨项目命中。如果日志里连候选片段都看不到，先别怀疑排序，去看这条记忆被写进了哪一层。

下次再遇到 DSH插件 答非所问，我会先做这三件事

先看原文时间，再看索引时间，最后看召回片段，三眼就能判断该修哪一段。

第一眼看原文的修改时间，确认那条记忆确实在最近的写入里；第二眼看索引的生成时间，确认它没有停在升级之前；第三眼看召回日志里的片段顺序，确认正确片段有没有进入预算。三眼都不需要改配置，却能决定后面是重建、换问法还是调整作用域。看到的都是事实，推论才不会跑偏。

如果三眼都正常，才考虑插件之间的竞争。多个 DeepSeek插件 同时提供记忆能力时，召回结果可能被另一个插件挤掉，日志里看起来每个插件都没错。用隔离 profile 只留一个再复跑，结论会干净很多。

排查过程中最好把证据记下来：原文路径、索引时间、命中片段和当时的问法。下次再出现类似现象，这份记录能省掉一半时间，也能避免在同一处反复试错。证据越具体，越不容易被印象带偏。

最后留一句经验：不要用重装来掩盖索引问题。重装清掉的是现场，索引该落后还是落后，问法该不匹配还是不匹配。把最小案例留住，比多装一遍插件有用得多。

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