多台机器统一更新 DeepSeek Harness：DSH plugin 版本对齐与漂移排查

多台机器上的 DeepSeek Harness 一定会漂，因为它有三个独立来源：更新方式不同、安装入口不同（全局与 npx 并存）、升级时机不同。 只盯着「我升过了」不够，入口没统一时两台「都更新过」的机器仍可能跑不同版本。解法是把版本与 DSH plugin 清单写进可执行清单，并固定三张核对表。

多机上的 DeepSeek Harness 为什么一定会漂：三个来源与三种对齐方案

一句话结论：漂移 = 更新方式差异 + 安装入口差异 + 升级时机差异；三者里最容易被忽略、也最容易造成「同版本不同行为」的是入口差异。

方案 A：清单驱动对齐（推荐，可审计）

一句话结论：把「本体版本 + 插件清单」写成一份可执行清单，各机器照单执行，并把输出归档——这是投入最小、收益最稳的方案。

1. 建一份对齐清单（示例结构）：

# dsh-align.txt
本体: @deepseek-ai/dsh@0.2.0-rc.2
插件: <插件包名>@<版本>
插件: <插件包名>@<版本>

2. 把执行写成一个脚本（关键是钉死入口与数据目录）：

set -euo pipefail
export DSH_HOME="$HOME/.dsh"          # 统一数据目录，别让默认值决定
npm i -g @deepseek-ai/dsh@0.2.0-rc.2
dsh plugin add <插件包名>@<版本>
dsh --version && dsh plugin           # 输出归档，便于比对

3. 各机器跑同一脚本，输出写进同一份归档位置（哪怕是贴进群里也行，关键是有可比的文本）。
4. 升级 = 改清单 + 重跑，旧清单留档作为回退点。
5. 插件清单先在 DSH Plugin Hub 里敲定，再写进脚本——比在命令行里边翻边装可靠。

方案 B：镜像 / 分发包对齐（机器多时最省事）

一句话结论：把本体与常用插件预置成镜像或内部包，机器只拉分发物——省带宽、省时间，也让版本天然一致。

1. 做一份内部镜像（写法见 DeepSeek Harness 容器化安装 的方案 C），打上版本标签。
2. 分发路径写进文档：机器统一从内部源拉取，不再各自访问公网。
3. 升级 = 发布新标签，机器改标签即可；旧标签保留用于回退。
4. 注意数据与载体分离：分发物承载程序，数据目录（DSH_HOME）仍在各机器本地卷上——升级不该动数据。

方案 C：配置管理工具接管（团队规模更大时）

一句话结论：机器数量上去之后，把「设数据目录 + 装固定版本 + 装插件清单 + 校验」写成一个幂等任务，交给配置管理工具跑。

1. 把第 A 节脚本改造成幂等任务：重复执行不产生副作用（已装则跳过）。
2. 先在一台机器上验证任务，再推到全量——避免一次性把所有机器搞成同一状态。
3. 任务里保留输出采集，把版本与插件清单回传到中心，便于随时审计。
4. 配合分发方案：任务是执行者，镜像/内网源是供给方，两者组合效果最好。

DeepSeek Harness 对齐后的三张核对表

一句话结论：对齐不是「升完就完」，而是能随时回答「这台机器装了什么、和标准差在哪」——三张表分别管版本、插件、配置。

1. 本体版本表：dsh --version + which -a dsh（确认唯一入口）。入口不止一个就是没对齐。
2. 插件清单表：dsh plugin 的输出逐台收集，比对数量与版本。
3. 配置差异表：DSH_HOME 指向、代理/镜像源设置、profile 选择——这三项解释「同版本不同行为」。

DSH plugin 漂移排查的四个判据

一句话结论：四个判据由外到内——入口是否唯一、版本是否一致、插件是否齐、配置是否同；前两个解决「明显差异」，后两个解决「隐性差异」。

1. 判据一：which -a dsh 只应有一个结果（多个即存在双入口）。
2. 判据二：dsh --version 与清单一致（不一致说明更新没落到实际执行的那份）。
3. 判据三：dsh plugin 清单与标准清单一致（缺项说明漏装或装到了别的 profile）。
4. 判据四：echo $DSH_HOME 与代理/源设置一致（不同则行为差异与版本无关）。
5. 排查顺序建议：先跑判据一、二（一分钟内可完成），再看三、四——不要一上来就重装。

DSH plugin 排查注意事项

一句话结论：多机场景里，「版本一致」只是起点；真正决定表现的是入口、数据目录与插件清单三者的一致。

1. 先统一入口：全局安装与 npx 只留一个（见 npx 与全局混装的版本漂移）。
2. 再统一数据目录：不设 DSH_HOME 就等于把目录交给默认值决定，各机器可能不同。
3. 插件清单要能一键导出：导出不了就无法比对，这也是把 Hub 的已安装列表当基准的原因。
4. 升级后重启服务，并把重启写进脚本，避免「升了但没生效」。
5. 记录验证过的版本组合，这是回退时唯一的依据。
6. 修复状态如实：本文方案与命令基于官方 CLI 的版本查询与插件管理说明；多机统一没有官方专文，具体包名、版本与参数请以你环境中的实际输出为准。

两台机器要比对时，直接对照 DSH Plugin Hub 的已安装列表截图，比在两边命令行里各敲一遍再肉眼比快得多。

来源：apps/cli/README.md、apps/desktop/README.zh.md、npm @deepseek-ai/dsh。