npx @deepseek-ai/dsh web 与全局安装混装：DeepSeek Harness 版本漂移排查

npx @deepseek-ai/dsh web 和全局安装的 dsh，是同一件事的两种跑法——但混在一起就会出现「版本漂移」和「插件不见了」这两类典型的伪故障。 前者是版本不确定（npx 每次可能解析到不同版本），后者更常见、也更容易误判：DSH plugin 的清单跟着数据目录（DSH_HOME）走，不跟着可执行文件走，所以当你用两种入口启动、恰好读到两个数据目录时，插件看起来就「丢了」，这跟版本其实没关系。本文先讲三种跑法怎么选，再给「查当前跑的是哪一个」的三套方法，最后是统一入口的四条迁移路线。

DeepSeek Harness 的两种跑法到底差在哪：三条使用路线

一句话结论：差别只有三点——是否落全局安装、版本是否固定、缓存与解析时机；但它们足以制造「命令行为不一致」和「插件清单不一致」两类问题。

方案 A：只用 npx（最干净，但版本随发布漂）

一句话结论：只用 npx 能保持机器干净，代价是每次启动的版本不确定——如果你要装 DSH plugin，这条路的「不确定性」会被放大成兼容问题。

1. 固定版本再试（把版本号写全，避免每次换版本）：

npx -y @deepseek-ai/dsh@0.2.0-rc.2 web --port 3080

2. 清缓存时要知道影响：清 npm 缓存会让下次启动重新下载（慢），但也能解决「缓存里是坏产物」这类偶发问题。
3. 明确它的弱点：npx 路线下装插件，插件记录仍进 DSH_HOME——所以务必显式设置 DSH_HOME，否则换一个终端/容器就换了数据目录。

方案 B：只用全局安装（最稳，但要自己升级）

一句话结论：日常长期用就装全局、把版本钉住、升级当显式动作执行——这是最不容易出意外的一条。

1. 安装并验证：

npm i -g @deepseek-ai/dsh@0.2.0-rc.2
dsh --version        # 预期：与上面钉的版本一致

2. 升级只需一条命令，升级后必须重启 dsh web 才生效。
3. 装插件前后各记一次清单：装之前 dsh plugin 记下现状，装完再对一次——出问题时能立刻判断是「没装上」还是「装到了别处」。
4. 多版本对照的场景别用这条路：要在两个版本之间来回验证，全局安装反而麻烦（要反复替换），这时用 npx 钉版本更合适。

方案 C：npx 钉版本当「准全局」（推荐的折中）

一句话结论：不想落全局安装、又怕版本漂移，就把 npx 的版本号写全并放进脚本/别名——你得到的是「版本固定的免安装入口」。

1. 做成别名（写进 ~/.bashrc / ~/.zshrc）：

alias dshx='npx -y @deepseek-ai/dsh@0.2.0-rc.2'
dshx web --port 3080

2. 配合固定的 DSH_HOME，避免「同一台机器两套插件清单」。
3. 升级 = 改别名里的版本号，比全局升级更可控、也更容易回滚。
4. 注意缓存体积：钉多个版本会各占一份缓存，定期清理不用的版本。

混装 DeepSeek Harness 后必踩的三类症状与逐个排查

一句话结论：先分清是「版本不一致」还是「数据目录不一致」——后者更常见，而且修法完全不同。

1. 症状一：同一台机器两个 dsh。表现为命令行 dsh 与某个脚本里的行为不一致。查法见下一节；修法是统一入口（第 6 节）。
2. 症状二：插件装到了另一个 profile / 数据目录。表现为「刚装完就找不到了」。先查 DSH_HOME 与 --profile 参数，再谈版本——十条里有八条是这条。
3. 症状三：版本号对不上。表现为 A 处显示旧版本、B 处显示新版本；插件兼容状态跟着忽好忽坏。用三套方法定位（下一节），然后钉版本。

怎么查「现在跑的是哪一个 DSH plugin 入口」

一句话结论：三套方法由快到慢——which -a 看有几个实体、dsh --version 对全局版本、看进程启动方式区分是否由 npx 拉起。

1. 看有几个可执行文件与命中顺序：

which -a dsh
# 预期：可能同时列出全局目录与 npx/本地安装目录的多个路径

2. 对版本：

dsh --version                      # 当前命令行的版本
npm ls -g @deepseek-ai/dsh         # 全局安装的版本
# 两者不一致 → 命令行命中的不是全局那一份

3. 看进程是怎么起来的（区分 npx 与全局）：

ps -ef | grep -i dsh | grep -v grep
# 预期：能看出可执行文件路径；npx 拉起的会带 npx 的中间层

4. 顺手核对数据目录：echo $DSH_HOME——如果为空，说明用的是默认目录；此时若你之前用别的方式设过，就会指向不同位置。

把 DeepSeek Harness 统一到单一入口的四条迁移路线

一句话结论：统一的目标是「一个入口 + 一个数据目录 + 一个固定版本」，四条路线按你的使用强度选，别一次全改。

1. 路线一（最省事）：只保留全局安装，删掉别名与 npx 用法；升级走显式命令。
2. 路线二（想保持免安装）：只保留钉版本的 npx 别名，卸载全局安装。
3. 路线三（多版本对照）：全局装「日常版本」，npx 钉版本只用于对照验证；两者用不同 DSH_HOME 明确隔离，并在 README 里写清哪个目录属于哪个版本。
4. 路线四（容器化彻底隔离）：把版本差异交给镜像处理，宿主不再装（见 DeepSeek Harness 容器化安装）。
5. 迁移后必做一次核对：which -a dsh 只剩一个、dsh --version 与 npm ls -g 一致、dsh plugin 清单与迁移前一致——三条都对上，才算迁移完成。
6. 顺手把插件清单留档：用 DSH Plugin Hub 的已安装列表截图或导出，迁移后对照重装，比重敲包名可靠。

DSH plugin 排查注意事项

一句话结论：混装排查的第一件事是「确定唯一的入口与唯一的数据目录」，而不是急着重装——重装往往会把两套环境都搞乱。

1. 先固定变量：which -a dsh、dsh --version、echo $DSH_HOME，三条命令的结果先记下来。
2. 再分方向：插件不见了 → 查数据目录与 profile；行为不一致 → 查版本。
3. 别急着卸载重装：重装会因为入口不确定而落到另一处，问题更难查。
4. 升级后必须重启服务：dsh web 常驻时不会自动换版本。
5. 写进团队约定：一个项目只用一个入口、一个版本、一个数据目录，能省掉绝大多数「玄学」问题。
6. 修复状态如实：本文行为描述基于 npm 的 npx 文档与官方 CLI 包说明；具体版本号与参数名请以你机器上的 dsh --version、dsh --help 输出为准。

还没决定用哪种安装方式的话，先看全局、npx 与桌面三种方式对比，再定迁移目标。

来源：apps/cli/README.md、npm @deepseek-ai/dsh、npm Docs · npx。