卸载 deepseek harness 后重装还是旧版：npx 缓存、PATH 与全局包三处残留

一位同事把 deepseek harness 卸载、重装、再卸载，终端里的 dsh 却始终报同一个旧版本号。 真正的问题不在安装命令，而在三处没有被清掉的残留：PATH 里的旧入口、npx 的包缓存，以及全局目录里半套包文件。它们各自独立，又能互相掩护。

案发现场：卸载 DeepSeek Harness 后 dsh 命令还活着

卸载动作看似成功，实际只删掉了其中一条入口，另外两条仍在参与命令解析。

事情从一次普通的升级开始。用户先执行全局卸载，再从官方文档复制安装命令，终端回显一切正常，可 dsh --version 仍然停在旧版本。重启终端、重开编辑器都没有变化，于是「装不上新版」被当成了网络问题。

真正的线索来自 which -a dsh。它一次列出了三个路径：一个在旧 Node 版本的 bin 目录，一个在包管理器管理的全局目录，还有一个来自项目内的 node_modules/.bin。三个路径按 PATH 顺序竞争，最先命中的那个决定了用户看到的版本。

这就是残留问题的典型形态：不是新版本没装上，而是旧版本始终排在前面。安装日志越干净，这种错位越容易被忽略，因为每一步看起来都成功了。只有把命令来源、安装目录与运行版本三样并排，才能看出它们根本不指向同一个地方。

更让人困惑的是，三条路径并不总是同时存在。有时只有旧软链，有时只有缓存，有时是某个 Node 版本下的全局包没删。每清掉一处，现象可能短暂变化，于是排查者以为修好了，过一天又复发。这正是把三处放在一起看的原因。

PATH 里那条 DeepSeek Harness 旧命令，为什么总被先找到

shell 只认 PATH 顺序，不认安装时间，旧路径排在前面就会一直赢。

先看 which -a 的输出顺序，再回头看 shell 配置里对 PATH 的追加方式。很多环境把旧版本目录写死在配置文件靠前的位置，后来安装的新路径只能排在后面。另一类情况是软链接还留在 /usr/local/bin，而链接目标早已被删除，命令却仍能被解析。下面的命令块可以一次性看清命令来源、全局包和显式版本，建议原样保存到排查记录里。

确认归属之后，处理方式要克制：只删除命令入口或失效软链，不动数据目录和配置文件。删完执行 hash -r 或重开终端，让 shell 忘掉缓存的命令位置。很多「删了还在」的错觉，其实是 shell 的命令哈希没有刷新。

which -a dsh
dsh --version
npm ls -g --depth=0
npx @deepseek-ai/dsh@latest --version

命令输出里如果出现两个以上不同的版本号，就说明残留已经存在，不需要再猜。把这些输出贴进工单，比描述「我重装了但还是旧版」更容易让别人接手。版本号、路径与安装方式三样齐全，后来的人才能复现你的现场。

另外要检查 shell 配置本身有没有把旧路径写死。有些人是在 .zshrc 里手工 export 过一次，之后每次开终端都会把旧目录重新排到前面，删掉文件也无效。改配置比删文件更根本，也更不容易在下次登录时复发。

npx 缓存：DeepSeek Harness 被悄悄复用的旧包

不带版本号的 npx 会优先复用本地缓存，看起来像安装失败，其实是根本没去取新包。

npx 的设计目标是把包临时拉下来跑一次，但它同时保留了缓存以加速后续调用。当命令写成 npx @deepseek-ai/dsh 而不带版本时，缓存命中旧包的优先级可能高于远程查询。用户以为自己在「重新安装」，实际执行的是缓存里的旧二进制。

验证方法并不复杂：先用显式版本运行一次，再与默认命令的输出版本对比。如果显式版本是新的、默认命令还是旧的，缓存嫌疑基本成立。清理时优先使用包管理器提供的缓存清理命令，而不是手工删除目录。

需要提醒的是，npx 与全局安装是两条独立路径。只清其中一条，另一条仍可能把旧版本带回终端。清理之前先想清楚用户平时用的是哪条命令，否则会把仍然有效的安装一起删掉。

缓存的存在还会制造一种假象：安装命令执行得很快，终端也没有报错。实际上可能根本没有访问远端仓库，所有内容都来自本地已经下载过的旧版本。排查时看到「秒装完成」，反而应该多看一眼版本号。

全局目录：DSH plugin 卸载后留下的半套文件

用删除目录代替卸载，会留下软链、bin 入口和包元数据，下一次安装就会撞上它们。

全局包的真正位置由 npm root -g 决定，而可执行入口在另一个 bin 目录。使用版本管理器时，每个 Node 版本都有一套独立的全局目录，切换版本就等于切换了一整套命令。用户在一套目录里卸载，却在另一套目录里运行，这种错位非常常见。

正确的顺序是先用 npm ls -g --depth=0 找到包名，再用 npm uninstall -g 卸载，最后确认全局目录里没有同名残留。如果曾经手工删过目录，还要检查 bin 下的软链是否已经悬空。DSH plugin 的配置目录通常不在包目录内，清理时要与包文件区分开。

清干净之后再做一次全新安装，版本号才有意义。否则新包装在另一个 Node 版本下，用户切回旧版本又会被打回原形。安装完成后先别急着宣布成功，回到实际使用的那套环境里再跑一次版本命令。

三处残留为什么互相掩护：DSH plugin 的排查顺序

单独清任何一处都可能让现象短暂消失，只有三处一起核对，才能解释「重装还是旧版」。

PATH 负责决定「先找到谁」，npx 缓存负责决定「临时运行时用谁」，全局目录负责决定「安装到了哪里」。三者覆盖的是命令生命周期的不同阶段，所以只修一处，另外两处仍会在别的调用方式里暴露旧版本。用户看到的不是稳定复现，而是时好时坏。

排查顺序应当从最外层往内收。先固定当前终端里实际命中的命令，再看这条命令指向的文件属于哪次安装，最后确认该安装目录下是否真有目标版本。反过来做，很容易在清理缓存时把仍然有效的全局包一起弄乱。

判断是否清干净，不靠记忆，靠同一组命令的前后对比。清理前保存一份 which、版本和全局包列表，清理后再跑一遍，差异就是证据。没有基线，就只能凭「感觉好像新了」下结论。

这也是 DSH plugin 升级相关工单里最常见的沟通成本。用户说已经重装，支持同学看到的是安装日志，双方都没有错，只是讨论的不是同一个运行路径。把三处路径写进回复模板，能省掉大半来回。

版本核对：DSH插件 重装后要回读的三处

安装日志只能证明命令执行过，不能证明终端实际运行的是新版本。

重装完成后，按下面的顺序回读，任何一处对不上都说明还有残留。这个顺序的价值在于从命令追到文件，再追到运行时，而不是停在安装成功那一行。每一步都留下输出，后面如果再次复发，至少有一份可以对比的基线。

1. 执行 dsh --version，记录实际版本号，而不是安装日志里的版本。
2. 执行 which -a dsh，确认所有命中路径都属于新安装。
3. 执行 npm ls -g --depth=0，确认全局目录里没有旧包。
4. 启动一次 dsh web，确认界面能正常打开且插件可加载。
5. 对照 npm 上的最新版本，确认本地版本与目标一致。

五步都通过之后，再去 DSH Plugin Hub 核对插件条目的版本说明。DeepSeek插件 的升级问题里，至少一半不是安装失败，而是旧入口仍在生效，这一点值得写进团队的操作手册。核对时顺手把结果记在工单里，下一次换人处理就不用从头再查一遍。

来源：deepseek-harness CLI README、npm @deepseek-ai/dsh、DeepSeek Harness 快速开始。