DSH plugin 的 dsh-purge 是什么？DeepSeek Harness 清理与卸载的区别

DeepSeek Harness 官方 CLI 里没有 purge 这个子命令，dsh-purge 是一个社区 DSH plugin（红队 / 破甲提示词管理向），既不是缓存清理工具也不是卸载命令（来源）。 搜这个词的人多半想解决「怎么把 DSH plugin 清干净」——真正的清理与卸载分别是 pnpm store prune 与 dsh plugin --profile web remove <包名> 两件事（这里的插件，中文也常写作 DSH插件、DeepSeek插件）。下面从四个方向讲全：① 官方有没有 purge 命令、dsh-purge 究竟是什么；② 清理与卸载边界怎么分；③ 清理前后怎么校验；④ 插件「消失」后怎么装回。想横向核对同类插件条目，可以到 DSH Plugin Hub 按名字查。

DeepSeek Harness 没有 purge 命令：dsh-purge 到底是什么

官方入口只有寥寥几类，其中并不包含 purge（来源）。 官方 README 列出的入口模式就那么几种，摊开看更直观：

表里没有 purge、没有 clean、也没有「清缓存」这类子命令——所以任何以 dsh purge 形式存在的说法，都不是官方命令。

那 dsh-purge 是什么？它是社区里的一个 DSH plugin。按它的仓库与插件市场条目的定位，这类插件做的是面向安全的红队用途：管理破甲 / 越狱类提示词，并改写宿主策略（默认副本、权限策略、工具限制）。它的名字里带 purge，容易让人误以为「一键清干净」，但功能与磁盘清理无关：

1. 不清理缓存：它不碰 pnpm store，也不回收 node_modules 占用的空间；
2. 不代替卸载：插件本身的装卸仍然走 dsh plugin --profile web add / remove；
3. 会改宿主行为：它改的是默认副本与权限、工具限制这类策略面，属于「改配置」而不是「删文件」。

所以第一件事是纠正认知：把 dsh-purge 当成清理工具会误判风险。这类插件的使用风险、合规边界与它为什么容易被安全策略拦截，站内破甲系列已经讲透，这里不重复：机制见《DeepSeek Harness 破甲是什么》与《破甲提示词原理》，装不上 / 被拦截的排查见《破甲插件装不上或失效》。

DSH plugin 清理与卸载的区别：三类操作别混用

「清理」改的是可再生的文件，「卸载」改的是清单与加载层，两者互不替代。 把 DeepSeek Harness 相关的「删除」拆开看，其实只有三类（外加一个容易被漏掉的覆盖层）：

1. 卸载插件（改清单）：dsh plugin --profile web remove <包名>。它一次清两样——profile 的 pnpm 依赖，以及 dsh.profile.bundles 里那一项加载层。细节见《dsh plugin remove 怎么卸载插件》。
2. 清缓存（只动可再生文件）：pnpm store prune。它回收 pnpm 存储里没有被任何项目引用的包内容，是内容寻址存储，正在被 profile 引用的包不会被删（来源）。因为 dsh plugin 会把参数整段转发给 pnpm，你也可以进到 profile 目录执行这条命令。
3. 整体卸载（动应用本体）：卸载 npm 安装的 CLI 或桌面端程序，这是另一个量级的操作，与单个插件无关。
4. 手写覆盖层（容易被漏掉）：profile 目录里的 cordis.patch.yml 是你自己写的覆盖，remove 不会替你清它；清了缓存更不会。残留该怎么查、清哪些、留哪些，见《卸载后残留怎么彻底清理》与《卸载后磁盘没释放》。

一句话记住边界：想省磁盘去清缓存，想真正移除插件去 remove，想改宿主策略那是 dsh-purge 这类插件做的事，与清理无关。

三类操作各自「动」了哪儿：一张心智模型

理解边界的捷径，是记住 DeepSeek Harness 里一份插件其实由三处记录共同定义：

1. 文件（node_modules / node_modules/.pnpm）：包的真实内容与符号链接——清缓存删这里。
2. 依赖清单（profile 的 package.json 的 dependencies）：声明「这个包要装」——remove 会摘它。
3. 加载清单（同一个 package.json 的 dsh.profile.bundles）：声明「启动时要激活它」——remove 同样会摘它。

所以：清缓存只碰第 1 处，remove 同时碰第 2、3 处。 这就解释了两个常见现象：

• 清了缓存后插件「还在」→ 因为第 2、3 处清单没变，系统仍按清单去解析它；
• 手删目录后启动报找不到包 → 同样是清单还在，但第 1 处的文件被删了。

DSH plugin 清理前后怎么校验

校验看三处：已装列表、profile 清单、组合树；恢复则看清单是「没了」还是「文件被删了」。

清理 / 卸载前后按顺序查：

# 1. 已装列表：这一层的账
dsh plugin --profile web list
# 应能在列表里看到目标插件

# 2. profile 清单：dependencies 与 dsh.profile.bundles 两处
cat ~/.dsh/profiles/web/package.json
# 应在 dependencies 里看到目标包名

# 3. 组合树：不启动就能看到实际加载的层
dsh --profile web --dump-config | grep -n "<包名>"
# 应能打印出该插件对应的加载层行号与内容

预期：清理前，三条都应命中；执行 remove 后，第 2、3 条应不再出现该包名，第 1 条列表里也应消失。哪一条在你预期之外，就说明你动手的那一层不是你以为的那一层。

插件「消失」了怎么装回

如果清理之后某个插件「看起来消失」了，先判断是哪一种：

1. 清单还在、文件没了（清缓存、手删 node_modules 的典型结果）：此时 DeepSeek Harness 仍会照着 bundles 去解析那个包，启动或加载时报找不到。进 profile 目录重跑一次 pnpm install，按清单把依赖装回来即可；
2. 清单里也没了（真的 remove 过）：重新安装。dsh plugin --profile web add <包名>，或者到 DSH Plugin Hub 的插件市场按名字搜回来装，装完用上面的 list 再确认一次。

两种恢复方式的区别，正是前面「三处记录」模型的应用：文件没了就补文件（pnpm install），清单没了就重装（add）。

关于 DSH plugin dsh-purge 与清理卸载的常见误解

下面是搜索与讨论里最常出现的误解，逐条对照一遍：

1. 「dsh-purge 是官方清理命令」——不是。 官方 CLI 没有 purge 子命令，它是社区插件。
2. 「它叫 purge，应该能清磁盘」——不能。 它做的是提示词管理与宿主策略改写。
3. 「清缓存等于卸载」——不等。 清缓存动文件，卸载动清单与加载层。
4. 「手删目录就等于卸载干净」——不等于。 清单里仍有记录，启动时还会去找那个包。
5. 「清了之后插件还在，说明没生效」——其实是正常。 清单没动，插件自然被认为「还在」。

关于 DSH plugin dsh-purge 与清理卸载的注意事项

把「清理」「卸载」「策略改写」三件事分开，是这一篇的全部要点。

1. 别把 dsh-purge 当清理工具：它不是官方命令，也不清磁盘，功能是红队向的提示词管理与宿主策略改写；
2. 清理只删可再生文件：pnpm store prune 清的是没被引用的缓存内容，清了只是下次重新下载；
3. 卸载要连清单一起清：remove 同时摘掉 dependencies 与 dsh.profile.bundles，手删目录会留下空壳清单；
4. 记住三处记录：文件、依赖清单、加载清单——先想清楚要动哪一处，再动手；
5. 自己的覆盖层自己清：cordis.patch.yml 里手写的引用不由 pnpm 管理，remove 不会替你处理；
6. profile 要对准：--profile 决定去哪份清单上动手，装在其他 profile 里的插件不受影响；
7. 想装回从市场找：DSH Plugin Hub 里能按名字核回插件与来源仓库。

来源：DeepSeek Harness CLI 官方 README、社区插件仓库 - dsh-purge、dsh-purge 插件条目、pnpm store 命令文档。