DeepSeek Harness 用 dsh plugin 更新插件后需要重启吗？

需要。DeepSeek Harness 在启动 profile 进程时加载插件，dsh plugin update 只改变 profile 里的依赖文件，不改变已运行的进程，所以要重启对应的 profile 才加载到新版本。桌面端也一样，它在改 profile 前后会停止和重新启动 Host。

桌面端更新插件时为什么必须先停止 Host？

因为插件更新是对当前 profile 的一次包事务：桌面端会先停止 Host，再直接修改 profile，改完再启动 Host。先停 Host 能避免进程一边读文件一边被改，也说明桌面端插件变更本身不是热更新，改完必须重新加载。

重启对应的 profile 进程即可，例如重新运行 dsh web 让 web profile 重新加载插件。只刷新浏览器页面通常不够，因为页面刷新只重连前端，后端插件进程没有重启，仍在使用旧版本。

刷新页面只重建前端连接，不重启加载插件的后端 profile 进程，所以插件版本可能还是旧的；重启 dsh 进程才会让 profile 重新初始化并加载新插件。判断标准很简单：改的是插件本体，就重启进程，不是只刷新页面。

不能。HMR 是开发态机制，服务于插件作者改源码时的即时预览，不在生产更新的路径上。生产环境用 dsh plugin 更新后仍然要重启 profile 进程，HMR 不会把已装的插件包自动替换成新版本。

DeepSeek Harness 更新插件后要重启才生效：插件在 profile 进程启动时加载，dsh plugin update 只改 profile 里的依赖文件、不改已运行的进程；桌面端更直接——它会先停止 Host，再修改当前 profile，改完重新启动 Host（来源）。

「装完怎么还用旧版本」几乎都源于这一层：以为 DSH插件更新等于热更。桌面端更新后插件为什么会原地保留、什么时候才重装，见《DeepSeek Harness 桌面端更新后插件会怎样》。这篇只讲一件事：什么时候必须重启、什么时候刷新就够。

桌面端把插件变更当成对 profile 的包事务：先停止 Host，再直接修改当前 profile，改完再启动 Host——这个「先停后改再启」的顺序本身就说明插件变更不是热更新（来源）。

五步看清生效时机：

更新触发时停止 Host — 插件新增、更新或删除前，桌面端先停止 Host。预期：变更期间不会有进程一边运行一边被改文件。
直接修改当前 profile — 用内置 pnpm 与 Desktop 包管理器状态就地改 profile。预期：改完的文件就是下次启动要加载的内容。
重新启动 Host 加载新版本 — 变更结束后桌面端重新启动 Host。预期：这时插件才是新版本；不重启就不会生效。
包事务锁贯穿整个变更 — 事务期间独占 $DSH_HOME/profiles/desktop/lock，直到 pnpm 退出。预期：变更过程中命令行碰不到该 profile，也不会有人读到写了一半的状态。
核对生效用只读命令 — 执行 cat "$DSH_HOME/profiles/desktop/package.json"（Windows 用 type）。预期：文件层面已经是新版本，而这正是重启后要加载的那一份。

命令行与 Web 侧同理：插件在 profile 进程启动时加载，更新后要重启对应的 profile 进程，只刷新页面不够（来源）。

按五步做：

确认更新已落到 profile — dsh plugin --profile web list 看目标插件版本。预期：文件层面已是新版本。
重启对应 profile 进程 — 结束当前进程后重新运行 dsh web（或你的 profile 启动方式）。预期：profile 重新初始化并加载新插件。
验证新版本确实加载 — 在界面里触发该插件的行为，或再查一次版本。预期：新功能 / 新版本号生效，而不是仍旧行为。
用只读命令看依赖是否落下 — 执行 ls -l "$DSH_HOME/profiles/web/node_modules"。预期：目标插件目录已是更新后的内容，而不是还指向旧版本的链接。
分清要重启的是哪一层 — 要动的是承载插件的 profile 进程。预期：新起的 dsh web 进程加载新插件，浏览器只是连上去的客户端，重启它没有用。

HMR 只覆盖开发态源码，不覆盖生产更新：它是插件作者改源码时的即时预览机制，不会把已安装的插件包自动替换成新版本，所以生产更新后仍要重启（HMR 机制见《DeepSeek Harness 插件热更新 HMR》）。

划清五条边界：

开发态用 HMR — 你在写插件源码、想即时看效果时用 HMR。预期：不用每次手动重启。
生产态用重启 — 你通过 dsh plugin 更新已安装插件时，重启对应 profile 进程。预期：版本真正切换。
页面刷新不等于进程重启 — 刷新浏览器只重连前端，不重载后端插件。预期：更新插件只刷新页面仍可能看到旧行为。
用只读命令核对部署来源 — 生产更新读的是 profile 的 node_modules，HMR 服务的是源码目录。预期：两条路径不同，ls -l "$DSH_HOME/profiles/web/node_modules/<pkg>" 能看出生产装的是包而不是源码。
改源码后仍要走一次更新 — HMR 只在开发会话里生效，会话结束就没了。预期：要让改动沉淀进安装态，仍要重新构建 / 发布并 dsh plugin update，再重启。

先更新、后重启 — 顺序反了会加载到旧版本，白重启一次。
桌面端交给应用自己处理 — 桌面端会自己在改 profile 前后停启 Host，你不用手动重启 Host。
多 profile 要分别重启 — 每个 profile 有独立进程，更新了哪个就重启哪个，细节见《dsh plugin 按 profile 更新怎么操作》。
卡在旧版本先查进程 — 如果重启后版本没变，先确认是不是还有旧的 profile 进程在跑。
别把「重启」当成「重装」 — 重启进程只重新加载已落盘的依赖，不会去 registry 拉新版本。预期：要换版本仍要先用 dsh plugin update。
开发态和生产态别用错机制 — HMR 服务写插件的开发会话，重启服务已安装插件。预期：用错机制就是「改了却没生效」的典型来源。

与其更新完还要记住重启哪个环境，用 DSH Plugin Hub 更省心：已安装列表集中显示可更新的 DSH plugin，更新确认后还会给出待重启提醒，不容易漏掉生效这一步。