dsh plugin 装到自定义 DSH_HOME：DeepSeek Harness 路径、权限与多环境隔离

上个月我把开发机上的 DeepSeek Harness 从系统盘挪到了一块独立 SSD，起因是系统盘只剩几个 GB，而会话记录和插件缓存长得比我预想快。挪完之后我才发现，dsh plugin 装在哪里并不由安装命令决定，而是由当前进程读到的 DSH_HOME 决定。

我为什么把 DeepSeek Harness 挪到自定义 DSH_HOME

换目录的直接动机是磁盘空间，真正让我下决心的是环境混乱。

默认的 DSH_HOME 落在用户主目录下，和浏览器缓存、下载文件挤在同一个分区。DeepSeek Harness 本身不大，但会话快照、插件包和构建缓存会随着使用时间累积，几个月就能吃掉十几 GB。系统盘一满，编辑器索引和构建都会跟着变慢，排查起来很费时间。把数据根目录挪到独立磁盘，至少能让空间问题变成一次性的迁移成本。

另一个原因是项目隔离。我当时同时维护两套配置，一套跑稳定版插件，一套试新版本，之前靠改环境变量来回切，经常忘了自己处在哪一套里。后来我把它们分别放到两个 DSH_HOME，启动时明确指定，误装和串数据的情况就少了很多。这个做法对 DSH插件 的调试尤其有用，因为出问题时可以直接对比两份目录。

还有一点比较隐蔽：备份。默认目录混在用户主目录里，备份工具往往把缓存一起打包，增量备份越来越大。独立目录之后，我可以只备份配置和插件清单，跳过大体积缓存。这个习惯后来在换机器时帮了大忙，恢复时间从半天缩短到十几分钟。

需要说明的是，换目录不会自动搬走已有数据。第一次迁移时我以为改个变量就完事，结果新目录是空的，旧插件一个都不在。后来才明白，DSH_HOME 只是一个指向，指向哪就只有哪里的内容。

换掉 DSH_HOME 后，dsh plugin 的安装位置跟着走

安装、运行和插件数据读的是同一个 DSH_HOME，所以它们会一起搬过去。

迁移完成后的第一件事是确认新的安装位置。dsh plugin 的包写在新根目录下的 profile 里，常见落点是 $DSH_HOME/profiles/<名字>/node_modules。旧目录里的东西不会消失，但新的安装命令也不会再往那里写。换句话说，位置跟着变量走，内容跟着位置走。

我在新终端里先打印当前值，再执行安装，避免出现命令在一个终端、安装却落到另一个目录的错位。下面这几条是我当时实际敲过的命令，顺序不重要，重要的是它们都在同一个 shell 里完成。如果中途换了窗口，最好重新确认一次环境变量。

echo "$DSH_HOME"
export DSH_HOME="$HOME/.local/share/dsh-alt"
mkdir -p "$DSH_HOME"
dsh plugin --profile web add <插件包名>@<版本>
dsh plugin list

执行完之后，dsh plugin list 应该能看到刚装的条目，具体名称可以在 DSH Plugin Hub 里对照。如果列表是空的，先别怀疑包本身，回头看看当前 shell 的 DSH_HOME 是不是你以为了的那个。这一步看起来琐碎，却能挡掉大部分「装完找不到」的疑问。

值得一提的是，图形客户端和命令行可能读到不同的环境。系统级启动的客户端继承的是登录环境，终端里 export 的变量只影响这个终端会话。我在 macOS 上就遇到过终端里一切正常、客户端里插件列表为空的情况，原因是客户端从 Dock 启动，没有拿到我后来加进 shell 配置的变量。

不跟着走的东西：DeepSeek Harness 的会话与旧缓存

换 DSH_HOME 不会自动搬运旧数据，会话、缓存和凭据都要单独处理。

最容易误解的是会话记录。它们确实在 DSH_HOME 下面，但只存在于旧目录，新目录不会凭空长出一份。要保留历史会话，得手动把对应子目录复制过去，复制前先确认新旧两边的结构与版本一致。

缓存则是另一个极端：能不带就不带。旧缓存里可能残留不完整的构建产物，迁移后直接复用，反而会把问题带进新环境。我当时的做法是新目录从空开始，让安装过程重新生成需要的文件。

凭据和凭据文件的位置也值得单独确认。有些配置引用了绝对路径，复制之后仍然指向旧目录，表面上迁移成功，实际运行时会去读旧位置。这类问题不会立刻报错，往往在切换机器或删除旧目录之后才暴露。

为了方便判断，我后来把迁移涉及的内容分成了两类，每次换目录前照着过一遍。插件包和配置可以重建，会话和凭据则要单独确认。这张表不是规范，只是我自己的检查顺序。

DeepSeek Harness 的 DSH_HOME：环境变量与启动参数怎么选

长期固定用环境变量，临时切换用启动参数，两者不要在同一进程里打架。

个人开发机适合把变量写进 shell 配置，一次设置，之后所有终端都生效。容器里也一样，把 DSH_HOME 写进镜像或编排文件，重建环境时不会丢。缺点是作用域偏大，同一用户下所有 dsh 进程都会读这个值。

需要并行跑两套环境时，启动参数更合适。每次启动显式传入目录，进程之间互不影响，用完即弃。代价是命令变长，容易漏写，所以我后来把它固定成脚本，而不是靠记忆。

两者同时存在时，优先级要以实际输出为准，不要凭文档想当然。我的习惯是先打印再启动，确认进程真正读到的值。下面这段是我现在常用的写法，方便对比变量和临时参数的差别。

export DSH_HOME="$HOME/.local/share/dsh-alt"
dsh plugin list
DSH_HOME="$HOME/.local/share/dsh-lab" dsh plugin list

注意第二种写法只对紧跟其后的那条命令生效，不会污染当前 shell。用它做对比测试很方便，但也提醒我，看到插件列表变化时先想想是哪一层在起作用。确认清楚之后，再决定要不要把它写进长期配置。

迁移已有 DSH插件 到新目录

迁移靠清单重装，不靠整目录复制。

整目录复制看起来省事，实际会把旧路径、旧权限和旧缓存一起带过来。我更愿意先在新目录里重建，再按清单逐项补齐。对 DeepSeek插件 来说，这一步还能顺便确认哪些包在新版本下已经不兼容。

清单不需要很正式，包名、版本和来源记清楚就够了。我一般从旧环境的插件列表导出，再和新环境逐条对照。下面这组步骤是我实际执行的顺序，重点是每一步都能验证。

1. 在旧环境执行 dsh plugin list，把包名与版本记下来。
2. 新建 DSH_HOME 目录，确认当前用户对它可写。
3. 在新终端设置 DSH_HOME，逐条安装清单里的包。
4. 复制需要保留的配置，检查里面有没有旧绝对路径。
5. 运行 dsh plugin list 与一次简单调用，确认插件可加载。

五步里最容易跳过的是权限检查。新目录如果是 root 创建、普通用户只读，安装会在写配置时失败，报错位置还未必直观。提前 ls -ld 看一眼，比事后翻日志省事。验证环节同样不能只看列表，因为列表能显示条目，不代表插件能被真正加载。我会额外跑一次最小调用，观察有没有缺文件或路径错误。确认无误后，旧目录可以保留一段时间再删，给自己留条退路。

整件事做完，我的体会是 DSH_HOME 更像一个边界，而不是一个开关。边界划定之后，安装、运行和备份才有稳定的落点；至于具体用哪个路径，反而是最不重要的决定。如果哪天再换机器，我会先画清这条边界，再动手装第一个包。

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