只卸了一个 profile 的 dsh 插件，为什么别的环境里还在加载？

因为插件是按 profile 各自安装的。DeepSeek Harness 每个 profile 都有自己的 package.json 与 node_modules，你在当前 profile 卸载，只影响这一个 profile；另一个 profile（例如桌面端独占的 profiles/desktop，或另一个命令行 profile）若也装过，它那边依旧会加载。要彻底移除，得逐个 profile 检查并卸载。

DeepSeek Harness 的 dsh.profile.bundles 和 cordis.patch.yml 有什么区别？

两者都是配置层。dsh.profile 是 profile 的清单文件，其 bundles 列表声明这个 profile 启用哪些插件包；cordis.patch.yml 是覆盖层，用来对配置做补丁式修改。插件卸载没清干净时，任一处残留引用都可能让插件「复活」，所以要两处一起核对。

dsh 插件卸载后还在，反复执行 remove 有用吗？

反复卸载通常没用，因为残留的是配置引用而不是包。命令行的 remove 会处理包与依赖，但不会自动清掉你手工加在 dsh.profile.bundles 或 cordis.patch.yml 里的引用；只要引用在，插件就会继续被加载。正确做法是用 --dump-config 找出引用来源，手工清掉后再核对。

dsh 插件卸载了怎么还在？DeepSeek Harness 与 DSH plugin「复活」排查

Q: 为什么 dsh 插件卸载了还在加载？

dsh 插件卸载了还在加载，最常见的原因是配置层还引用它。DeepSeek Harness 的 profile 里，dsh.profile 的 bundles 列表与 cordis.patch.yml 覆盖层共同决定加载哪些插件；只把包移出 node_modules 而没清掉这些引用，插件仍可能被解析到并加载。需要同时清掉包与引用才是真卸载。

Q: 怎么验证 DeepSeek Harness 插件真的被移除了？

验证真移除要看合并后的配置，而不只看目录。用 --dump-config 输出当前 profile 合并后的配置树，确认该插件不再出现；再核对 profile 的 package.json 里是否还留着依赖声明；最后回已安装列表核对。三者都干净，才算真正移除，而不是只删掉了包目录。

dsh 插件卸载了还在加载，多半不是卸载命令失效，而是配置层还留着引用：profile 里 dsh.profile 的 bundles 列表或 cordis.patch.yml 覆盖层仍指向它，或者你只卸了当前 profile，另一个 profile 那边还装着（来源）。

这篇按「为什么卸载后还在 → 怎么验证真移除 → 怎么清残留引用」三步讲。remove 报错与卡住的排查见《DSH plugin 卸载失败排查》《dsh plugin remove 卡住排查》。

dsh 插件卸载了为什么还在：配置层残留与多 profile

profile 里由 dsh.profile 的 bundles 列表与 cordis.patch.yml 覆盖层共同决定加载哪些插件；把包移出 node_modules 但没清掉这两处引用，插件仍可能被加载（来源）。

先判断是哪种「还在」：

看是不是引用残留 — 检查 profile 的 dsh.profile 里 bundles 是否还列着它。预期：列出说明是配置引用问题，不是包还在。
看是不是覆盖层残留 — 检查 cordis.patch.yml 是否还引用它。预期：覆盖层里有引用同样会让插件复活。
看是不是别的 profile 装的 — 列出所有 profile 逐一核对。预期：当前 profile 干净、另一个 profile 还装着，就是「只卸了一个」的典型。
看桌面端那套是否有独立副本 — 桌面端独占 profiles/desktop，与命令行各 profile 分开。预期：两边分开核对，别拿一边的结果推断另一边。

第 3 步最容易漏：插件按 profile 各自安装，卸载只影响被操作的那个 profile。桌面端 profiles/desktop、命令行的各个 profile 都可能各装一份，所以「卸载了还在」经常只是「另一个环境里还有」。

怎么验证 DeepSeek Harness 插件真的被移除了

验证要看合并后的配置，而不是只看目录：用 --dump-config 输出当前 profile 合并后的配置树，确认插件不再出现；再核对 profile 的 package.json 是否还留依赖声明，最后回已安装列表核对（来源）。

按三步交叉验证，每步都有可核对预期：

看合并后的配置树 — 跑 --dump-config 找到该插件的引用。预期：完全搜不到，说明多层叠加后已无引用。
看 profile 的 package.json — 检查依赖声明里是否还留着它。预期：声明已移除，说明包层面的依赖也清了。
回已安装列表核对 — 桌面端打开 DSH Plugin Hub 已安装列表。预期：列表里不再有它，与配置层结论一致。
换个 profile 再验一遍 — 对每个装过它的 profile 重复前三步。预期：所有 profile 都干净，才算彻底移除。

第 1 步是核心：--dump-config 看的是配置叠加后的结果，比翻单个文件更能说明「到底还加不加载」。目录里没了、配置树里还在，就是典型的残留引用，也是反复卸载无效的原因。

残留引用怎么清干净、下次别只删一个 profile

清理顺序是「先定位引用 → 再清 bundles → 再清 cordis.patch.yml → 最后复验」，并且要逐个 profile 处理，因为每个 profile 各有一套配置与依赖（来源）。

按顺序执行，每步核对预期：

定位引用来源 — 用 --dump-config 与逐文件检查确定引用在哪一层。预期：明确是 bundles 还是覆盖层。
清 bundles 引用 — 从 dsh.profile 的 bundles 列表移除该插件。预期：清单不再声明启用它。
清覆盖层引用 — 从 cordis.patch.yml 移除相关补丁。预期：覆盖层不再对它做修改或引用。
复验 — 再跑 --dump-config 与已安装列表核对。预期：配置树与列表都无该插件，插件不再加载。
处理其他 profile — 对每个装过它的 profile 重复前三步。预期：所有环境一致移除，不再出现「这边没了那边还在」。

第 5 步是根治：「卸载了还在」最省事的解法不是反复卸载，而是逐个 profile 清干净。下次卸载前先想清楚它可能装在几个 profile 里，一次清完，省得来回猜。

dsh 插件卸载后仍加载的注意事项

分清包与引用：包移出 node_modules 不等于引用清掉，两者都要处理。
两处引用都查：dsh.profile.bundles 与 cordis.patch.yml 任一处残留都会让插件复活。
按 profile 逐个清：每个 profile 各有一套配置与依赖，只清一个不够。
以 --dump-config 为准：合并后的配置树才是「是否加载」的最终依据。
反复卸载无效：残留的是引用而非包，反复 remove 不会自动清引用。

核对插件到底还在不在，桌面端打开 DSH Plugin Hub 的已安装列表最直观；命令行侧则以 --dump-config 的合并结果为准，两边分开看才不会被「按 profile 各自安装」绕进去。

来源：DeepSeek Harness 命令行 README（官方仓库）、DeepSeek Harness 桌面端 README（官方仓库）、DeepSeek Harness 源码仓库