在命令行更新了 dsh，DeepSeek Harness 桌面端会跟着更新吗？

不会。DeepSeek Harness 桌面端与命令行是两条独立的更新链路，桌面端内置的 dsh 与它发布的 @deepseek-ai/dsh 始终是同一精确版本，跟着桌面端发布走。在命令行里用 npx 或 npm 更新 dsh，只影响命令行这条链路，桌面端仍运行自己签名更新单元里的运行时。

DeepSeek Harness 桌面端和命令行的插件是同一套吗？

不是同一套。DeepSeek Harness 桌面端与命令行共享 $DSH_HOME 下的产品数据，但插件激活、可执行包、锁文件与 node_modules 都不共享，各自按自己的 profile 安装插件。所以桌面端装了某个 DSH plugin，不代表命令行环境里也有。

DeepSeek Harness 桌面端和命令行会共用同一份会话和设置吗？

会。会话、设置、凭据与任务这类受支持的产品数据放在共享的 $DSH_HOME 下，所以 DeepSeek Harness 桌面端与命令行读到的是同一份。但可执行部分不共享，换句话说数据在一起、运行时各走各的。

为什么命令行不能修改 DeepSeek Harness 桌面端的 profile？

因为 Electron 在访问任何 profile 之前会先取得单实例锁，并独占 profiles/desktop，命令行不得启动或修改该 profile。这是为了保证桌面端运行时的一致性，避免命令行和桌面端同时改同一个 profile 造成冲突。

同时用 DeepSeek Harness 桌面端和命令行更新会冲突吗？

正常不会冲突，因为两条链路各自更新各自的运行时部分。唯一需要注意的是别在桌面端更新或卸载时让 CLI 命令还在跑，安装程序不与运行中的命令协调；先结束命令行里的 dsh 进程，再更新桌面端即可。

DeepSeek Harness 桌面端和命令行更新冲突吗？DSH plugin 两套更新体系与共享数据边界

DeepSeek Harness 桌面端与命令行是两条独立的更新链路：命令行走 npx、npm 或源码更新，桌面端走整包签名更新单元，升级互不联动；它们共享 $DSH_HOME 下的受支持产品数据，但绝不共享可执行包、插件激活、锁文件或 node_modules（来源）。

很多人以为「我更新了命令行，桌面端应该也新了」，于是两边对不上版本时反复折腾。桌面端为什么更新是整包，见《DeepSeek Harness 桌面端更新是整包升级吗》。这篇专门讲两条链路之间的关系：哪些是各走各的、哪些是同一份。

DeepSeek Harness 桌面端和命令行是两条更新链路

桌面端和命令行各自维护自己的可执行部分，更新方式完全不同，任何一个升级都不会带动另一个（来源）。

先按「更新对象」把两条链路摆开：

	命令行链路	桌面端链路
更新对象	你机器上的 dsh（npx / npm / 源码）	整条签名更新单元（壳 + 运行时 + Node + pnpm）
更新方式	重跑 `npx`、`npm update -g @deepseek-ai/dsh`、`git pull` 后重建	应用内检查更新，或重装桌面包
生效范围	只影响命令行环境	只影响桌面端

三条结论：

命令行链路 — 用 npx、npm 或从源码构建来更新 dsh。预期：新版 dsh 只出现在命令行环境里，桌面端不受影响。
桌面端链路 — 通过应用内更新或重新安装桌面包，换掉整条签名更新单元。预期：新版 dsh 随桌面端一起换，命令行环境不受影响。
版本不会互相拉动 — 桌面端内置的 dsh 与它发布的 @deepseek-ai/dsh 始终是同一精确版本。预期：桌面端版本号与桌面端发布对齐，与你在命令行装了什么无关。
同一台机器可以并存三个 dsh 版本 — 全局 npm 装的、npx 临时解析的、桌面端内置的，这三份彼此独立。预期：which dsh 给出的版本与桌面端「检查更新…」显示的版本可以完全不同，这不是故障。
想两端一致只能分别更新 — 没有任何一条命令能同时刷新两条链路。预期：把「更新命令行」「更新桌面端」当两件事，各自做完各自验证。

两条链路共享什么：$DSH_HOME 下的产品数据

会话、设置、凭据与任务这类受支持产品数据放在共享的 $DSH_HOME 下，所以桌面端和命令行读到的是同一份（来源）。

共享边界要看清：

会话共享 — 两端的会话数据来自同一个 $DSH_HOME。预期：命令行里跑过的会话，桌面端能看到。
设置与凭据共享 — 设置和凭据也在共享目录里。预期：改一处两端都生效，不用分别配一遍。
任务也共享 — 受支持的产品数据都放在这个根目录下。预期：一端产生的任务记录，另一端打开时同样可见。
默认路径是 ~/.dsh — 没设环境变量时 $DSH_HOME 就是 ~/.dsh。预期：你能在同一个位置确认两端读的是同一份数据。
先确认两端指向同一个根目录 — 终端执行 echo "$DSH_HOME"（输出为空即用默认 ~/.dsh），再 ls "$DSH_HOME"。预期：能看到 profiles、会话与设置等条目，说明共享确实发生在这一层。

两条链路绝不共享什么：可执行包、插件激活与 profile 独占

可执行包、插件激活、锁文件与 node_modules 都不共享，而且 Electron 在访问任何 profile 之前先取得单实例锁并独占 profiles/desktop，命令行不得启动或修改该 profile（来源）。

五条硬边界：

可执行包不共享 — 桌面端把 dsh 作为生产依赖树随包携带，不读你全局装的 dsh。预期：命令行升级 dsh，桌面端里的 dsh 版本纹丝不动。
插件激活与依赖不共享 — 插件激活、锁文件与 node_modules 各自独立，桌面端用内置 pnpm 在自己的 profile 里装插件。预期：同一台机器上，桌面端和命令行的插件清单可以完全不同。
profile 被独占 — profiles/desktop 由桌面端独占，命令行不能启动或修改它。预期：想在命令行里操作桌面端 profile 会被这条边界挡住，这是有意的隔离。
锁文件也不共享 — 命令行与桌面端各自持有自己的包事务锁，互不等对方释放。预期：桌面端正在跑，不影响你在命令行里更新 dsh；反过来也一样。
用只读命令核对边界 — 执行 ls -l "$DSH_HOME/profiles" 能看到都有哪些 profile，桌面端那份叫 desktop。预期：确认桌面端只动 desktop，你自管的 web、headless 等 profile 与它各自独立。

DeepSeek Harness 桌面端与命令行并用的注意事项

别指望一端更新带另一端 — 想两端都新，就分别更新两条链路。
更新桌面端前先停 CLI — 安装程序不与运行中的命令协调，先收工再更新。
DSH插件要按环境分别装 — 桌面端和命令行的插件不共享，不要假设某插件在另一端也已装好；按 profile 分别更新插件见《dsh plugin 按 profile 更新怎么操作》。
看清版本报错来自哪一端 — 两端版本号对不上是正常现象，排查时先确认报错的是桌面端还是命令行。
分清三份 dsh 的版本 — 全局 npm、npx 临时解析与桌面端内置是三个独立来源，dsh --version 只反映其中一份，别用一个数字给全部下结论。
数据虽共享，别两端同时写 — $DSH_HOME 是同一份，但桌面端独占 profiles/desktop；不要在命令行里改这个 profile，改动交给应用自己做。

想同时管好两端的插件，与其来回切换命令行，不如用 DSH Plugin Hub：已安装列表把当前环境装的 DSH plugin 和可更新状态集中展示，确认弹窗后再动手，比两端各自比对版本省事。

来源：DeepSeek Harness 桌面端 README（官方仓库）、DeepSeek Harness CLI README（官方仓库）