DeepSeek Harness 桌面端更新后，已装的 DSH plugin 会不会被重装或重置？

通常不会。DeepSeek Harness 桌面端做兼容的应用升级时，插件文件、配置、版本和锁文件都留在原处，只在当前 profile 刷新共享链接并检查已启用插件的 peer 要求，不会重装或清空你的 DSH plugin。

为什么 DeepSeek Harness 桌面端更新通常不运行 pnpm？

因为兼容升级不需要重建插件依赖，DeepSeek Harness 桌面端只在当前 profile 刷新共享链接并检查 peer 要求，不运行 pnpm。只有内置 Node 版本、平台或架构变化时，才会禁用脚本重装锁定的插件依赖图，让依赖与新运行时重新对齐。

什么情况下 DeepSeek Harness 桌面端会自动重装插件依赖？

当签名更新单元里的内置 Node 版本、平台或架构发生变化时，DeepSeek Harness 桌面端会禁用脚本重装锁定的插件依赖图到当前 profile。流程是重装依赖、验证并链接宿主包、运行已批准的插件构建，最后再次验证。

DeepSeek Harness 桌面端里插件依赖为什么要解析到 profile 内部？

因为桌面端要求普通插件依赖必须解析到 profile 内部，嵌套副本或别名会被验证拒绝。这条规则让每个 profile 的插件依赖彼此隔离，避免多个 profile 之间互相污染，也让更新与卸载行为可预测。

DeepSeek Harness 桌面端更新后，插件配置和工作区还会在吗？

会在。DeepSeek Harness 桌面端更新只换运行时这一层，插件配置、会话和工作区数据都放在共享的 $DSH_HOME 下，兼容升级刷新共享链接后原样保留。只有你手动重置 Desktop 时，才会删除 $DSH_HOME/profiles/desktop 下的内容。

DeepSeek Harness 桌面端更新后插件会怎样？DSH plugin 共享链接、peer 校验与重装时机

DeepSeek Harness 桌面端更新后，已装 DSH plugin 大多是原地保留的：兼容的应用升级只在当前 profile 刷新共享链接并检查已启用插件的 peer 要求，插件文件、配置、版本和锁文件都留在原处，也不运行 pnpm（来源）。

上一类问题看的是「桌面端更新为什么是整包」，见《DeepSeek Harness 桌面端更新是整包升级吗》。这一篇接着往下问：更新换掉了运行时，那我装在里面的 DSH plugin 会怎样——会不会被重装、配置会不会丢、什么时候才会真正重建依赖。

DeepSeek Harness 桌面端更新后插件为什么会原地保留：共享链接与 peer 校验

桌面端把「换运行时」和「重建插件」拆成了两步：兼容升级只刷新共享链接并做兼容性检查，不动插件本身（来源）。

一次兼容的应用升级，桌面端会做这几件事：

刷新共享链接 — 在当前 profile 里，把内置第一方包通过目录软链接（Windows 上用 junction）重新指向新的签名资源。预期：插件引用的宿主包指向新运行时，而插件自己的目录没有被改写。
检查已启用插件的 peer 要求 — 逐个核对插件声明的宿主包兼容范围。预期：兼容的插件继续可用；范围不匹配时在这一步暴露，而不是等运行中途才报错。
保留插件文件、配置、版本与锁文件 — 这些内容原地不动。预期：更新完打开应用，已装插件列表里的版本号和更新时间和更新前一致。
整个过程不运行 pnpm — 因为依赖没有变化，只有链接需要刷新。预期：更新耗时不随插件数量线性增长，也不会因为重装依赖而失败。
不重写 profile 的依赖清单 — 插件版本记录留在 profile 的 package.json 与锁文件里，更新应用不会改写它们。预期：升级前后对比这两个文件，插件依赖那几行版本没有任何变化。
想手动核对就做一次只读检查 — 先 cat "$DSH_HOME/profiles/desktop/package.json" 看依赖版本，再 ls -l "$DSH_HOME/profiles/desktop/node_modules" 看共享链接。预期：链接仍指向签名资源，插件版本与更新前一致。

这里有一条边界要记住：桌面端独占 profiles/desktop（Electron 在访问任何 profile 前先拿单实例锁），所以上面两条是安全的只读命令；要真正增删改插件，回到应用内的插件管理，不要用命令行去写这个 profile。

什么情况下 DeepSeek Harness 桌面端才会重装插件依赖

只有签名更新单元里的内置 Node 版本、平台或架构发生变化时，桌面端才会禁用脚本重装锁定的插件依赖图，让依赖与新运行时重新对齐（来源）。

先分清两种升级，才知道会不会被重装：

这次升级动了什么	会不会重装插件依赖	你要做什么
只换壳与 dsh 运行时（内置 Node / 平台 / 架构不变）	不会	什么都不用做，插件原地保留
内置 Node 版本、平台或架构发生变化	会，禁用脚本重装锁定依赖图	等重建与验证跑完，再核对插件列表

触发了重建时，按顺序走完：

禁用脚本重装依赖图 — 把锁定的插件依赖图重新装进当前 profile，安装期间不执行生命周期脚本。预期：依赖与新内置 Node 对齐，且安装过程不对第三方脚本放行。
验证并链接宿主包 — 确认依赖关系后，把宿主包链接回 profile 存储。预期：插件能继续解析到正确的宿主包。
运行已批准的插件构建 — 只执行被批准的构建步骤。预期：需要构建的插件在受控范围内完成构建。
再次验证 — 重建结束后再验证一遍。预期：验证通过才对外可用，没通过则停下并报告。
重建后核对结果 — 看已安装列表，或读 $DSH_HOME/profiles/desktop/package.json 里的依赖版本。预期：依赖版本与锁文件一致，插件能正常加载。

想提前判断这次更新会不会触发重建，看两点：这次桌面端发布有没有更换内置 Node 版本，以及是否为你的平台发布了新的架构产物。拿不准就更新完核对一遍列表，比事前猜测可靠。

DeepSeek Harness 桌面端新增、更新与删除插件走哪条路径

插件的新增、更新与删除使用内置 pnpm 以及 Desktop 独有的包管理器状态，而且普通插件依赖必须解析到 profile 内部，嵌套副本或别名会被验证拒绝（来源）。

先记住边界：桌面端独占 profiles/desktop，所以这套增删改在应用内的插件管理里完成；命令行的 dsh plugin --profile <name> ...（add / update / remove / list）对应的是 web、headless 这类你自己管控的 profile，参数会原样转发给 pnpm。

四条共同规则：

走内置 pnpm，不走系统工具 — 插件包的安装与更新由桌面端内置的 pnpm 配合 Desktop 包管理器状态完成。预期：你在系统里换 npm 镜像或包管理器，不会改变桌面端的插件安装路径；换源要在桌面端自己的设置里做。
依赖必须解析到 profile 内部 — 普通插件依赖要落在当前 profile 里，出现嵌套副本或别名会被验证拒绝。预期：不同 profile 的插件依赖彼此隔离，不会互相污染。
插件变更会先停 Host 再改 profile — 桌面端在直接修改当前 profile 前会先停止 Host。预期：插件变更不是热更新，改完要重新启动 Host 才生效，生效细节见《DeepSeek Harness 桌面端更新后插件要重启吗》。
新增与更新走同一条包管理路径 — 装新插件和升级已有插件都落进同一份 profile 依赖。预期：装完立即出现在已安装列表，列表里的版本号就是 profile 里记录的版本，不会两处打架。

DeepSeek Harness 桌面端更新后插件的注意事项

兼容升级不重装插件，不等于插件永远不用管 — 桌面端只换运行时，DSH插件自身的新版本仍要在插件管理里单独更新。
重建依赖是有前提的 — 只有内置 Node 版本、平台或架构变化才触发重装，普通的应用升级不会走这条路。
失败不回滚 — 插件包操作失败时会保留已修改的文件并报告错误，未完成操作留标记供下次启动重试，所以更新前留好可回退的版本更稳妥。
想确认插件是否跟上了新运行时 — 逐个比对插件声明的宿主版本很费劲，用一个能统一看「可更新」状态的工具更快。
核对用只读命令，改动回应用内 — cat 读 package.json、ls -l 看链接都不影响运行；但不要用命令行去写 profiles/desktop，那会和应用的单实例锁冲突。
多 profile 场景要分开核对 — 桌面端和 web / headless 各自有插件依赖，升级桌面端只影响 desktop 这一套，别把别的 profile 的版本也一起算进来。

与其逐个记住每个 DSH plugin 声明了什么宿主版本，不如用 DSH Plugin Hub：它的已安装列表直接标出「可更新」的插件，点一下就能处理，更新前还有确认弹窗，省去手动核对兼容范围。

来源：DeepSeek Harness 桌面端 README（官方仓库）、Electron 桌面端打包与更新 Agent Note