DeepSeek Harness 桌面端更新是整包升级吗？DSH plugin 桌面版版本绑定与签名更新单元

DeepSeek Harness 桌面端更新是一个整包动作：它不是让你单独替换一个 dsh 版本，而是把 Electron 壳、匹配的 dsh 运行时、Node.js 与 pnpm 作为一个已签名更新单元一起换新，四者始终使用同一精确版本（来源）。

如果你只想看「怎么点更新、多久轮询一次」，那是操作层面的事，见《DeepSeek Harness 桌面端怎么更新》。这篇讲的是背后的机制：为什么桌面端更新一定是整包、启动时靠什么校验运行时、为什么升级 dsh 必须发布新的 Desktop 版本。桌面端、dsh 本体与 DSH插件 是三层独立的更新，横向对照见《DeepSeek Harness 自动更新怎么开》。

DeepSeek Harness 桌面端更新为什么是整包：一个已签名更新单元

桌面端更新的最小单位不是一个 npm 包，而是一个已签名更新单元，它由 Electron 壳、匹配的 dsh 运行时、Node.js 与 pnpm 共同组成，四者使用同一精确版本一起下发（来源）。

先把「谁来自哪里」拆开看，就不会误以为升级桌面端等于单独换一个 dsh：

这解释了五个容易踩的认知：

1. 桌面端不是「壳 + 你机器上的 dsh」 — 它是一个包裹 dsh Web UI 的 Electron 壳，dsh 以生产依赖树的形式随包携带，不依赖你去全局装一个 dsh。预期：你在一台全新机器上装完桌面端就能直接跑，不需要先 npm i -g。
2. 内置运行时和系统运行时互不干扰 — dsh 通过内置的上游 Node.js 运行，所有包操作都使用内置 pnpm；Electron 的 Node.js、系统 Node.js、系统 pnpm 与用户的包管理器配置都不进入执行路径。预期：你系统里装了别的 Node 版本，也不会把桌面端跑起来的内核带偏。
3. 版本是绑定的，不是拼装的 — Electron 壳与 @deepseek-ai/dsh 始终使用同一精确版本，所以更新桌面端就等于把整条运行时一起换新。预期：桌面端设置里的 dsh 版本号，永远和桌面端自身的发布版本对得上。
4. Web 客户端、后端与插件依赖图同批验证 — 一次发布会把桌面壳 API、Web 客户端、后端与插件依赖图作为一个组合完成验证。预期：你看到的桌面端版本号，就是这一整组关系的名字，而不是某一个包的版本。
5. 分块复用只是省流量，不是换版本 — 平台更新产物会复用未变化的数据块以减小下载体积，但复用只发生在文件层面。预期：复用数据块不会让桌面端偷偷切到另一个 dsh 版本。

想直接确认内置运行时是哪一版，跑 dsh --version（等价 dsh -V）即可拿到该运行时的 dsh 版本（来源）。

启动时怎么校验运行时：desktop-runtime.json 绑定哪些版本

桌面端启动时会读取签名资源里的 resources/dsh/desktop-runtime.json，这份清单绑定了 shell 版本、内置 Node 版本、平台、架构、共享包版本和最终文件清单，用来确认运行时没有被替换或损坏（来源）。

这份清单你是可以自己打开核对的（macOS 在应用包内的 Contents/Resources/dsh/ 下，Windows 在安装目录的 resources\dsh\ 下），按顺序看这六点：

1. 定位并打印清单 — macOS 执行 cat <应用包>/Contents/Resources/dsh/desktop-runtime.json；Windows 执行 type <安装目录>\resources\dsh\desktop-runtime.json。预期：打印出一份 JSON，能看到 shell、Node、平台等字段。
2. 读取运行时元数据 — 启动会先读这份清单。预期：拿到 shell 版本、内置 Node 版本、平台与架构这一组基础信息。
3. 核对 shell 版本 — 把清单里的 shell 版本与桌面端「检查更新…」里显示的版本比对。预期：两处一致，说明壳没有被替换过。
4. 核对共享包记录 — 桌面端把每个内置第一方包通过目录软链接（Windows 上用 junction）连接到当前 profile，启动时检查这些共享包记录。预期：第一方包都指回签名资源，而不是被复制进 profile 或经 pnpm 重装。
5. 确认文件完整性 — 发布 schema、shell 版本、目标兼容性和文件完整性在打包阶段就已验证。预期：任何一项对不上，运行时就无法按预期加载，问题在启动阶段暴露而不是运行中途。
6. 首次启动不重装核心包 — 首次启动不会把核心包复制到 profile 存储，也不会通过 pnpm 安装核心包。预期：profile 里只会出现你额外装的外部插件，核心包始终来自签名资源。

想亲眼看看共享链接，对 profile 目录执行 ls -l（Windows 用 dir /AL）就能列出这些软链接 / junction：预期：它们都指向签名资源；链断了通常意味着资源被手动改过。

为什么升级 dsh 必须发布新 Desktop 版本：版本选择不脱离发布

因为桌面端的运行时版本选择绝不脱离 Desktop 发布：即使桌面壳代码本身没变，只要 dsh 运行时升级，就必须发布新的 Desktop 版本，把新运行时随签名更新单元一起下发（来源）。

这条约束决定了四件事：

1. 不能自行替换内置 dsh 来「升级」 — 手动替换应用内的运行时会破坏版本一致性，桌面端的 dsh 版本跟着桌面端走。预期：想升级 dsh，正确做法是升级桌面端，而不是去动 extraResources 里的文件。
2. 命令行的 dsh 与桌面端的 dsh 不是同一份 — npm update -g @deepseek-ai/dsh 只更新你全局安装的那一份，桌面端内置的运行时不受影响。预期：终端里 dsh --version 前进，不等于桌面端版本前进，两者必须分别更新。
3. 平台更新产物可以复用未变化的数据块 — 为了减小下载体积，平台更新产物可以复用未变化的数据块，但复用只发生在文件层面。预期：复用数据块不会让桌面端切换到另一个 dsh 版本，版本选择仍由发布决定。
4. 发布身份是一组被验证的关系 — 桌面壳 API、Web 客户端、后端与插件依赖图作为一次发布组合完成验证，Electron 与 @deepseek-ai/dsh 的精确版本关系是其中一环。预期：你看到的桌面端版本，就是这一整组关系的名字。

判断「这次到底该更新哪一层」时，先看清命令命中哪条链路：终端里 which dsh（Windows 用 where dsh）显示的是全局入口，npx @deepseek-ai/dsh web 走的是临时解析，桌面端则完全走内置运行时。预期：三条链路的版本各自独立，改错一条不会顺带修好另一条。

DeepSeek Harness 桌面端更新单元的注意事项

1. 把桌面端当成一个整体升级 — 不要试图只升 dsh 或只升壳，版本绑定决定了它们必须一起走。
2. 不要用系统 Node / pnpm 干预运行时 — 内置 Node.js 与内置 pnpm 才是执行路径，系统工具改了也不影响桌面端。
3. 插件是独立的一层 — 桌面端更新只换运行时，已装 DSH plugin 的版本变化要在插件管理里单独处理，更新后的具体处理见《DeepSeek Harness 桌面端更新后插件会怎样》。
4. 校验失败优先重装而非手改 — 一旦 desktop-runtime.json 对应的文件完整性对不上，回到官方安装包重装，比手改运行时更可靠。
5. 分清三条链路的版本 — 全局 CLI、npx 临时解析与桌面端内置运行时各自独立；用 dsh --version 核对时，先确认它命中的是哪一份，别把其中一条的版本当成全部。
6. 更新前留一份当前版本安装包 — 桌面端不支持锁版本，手头留一个当前版本的官方安装包，校验失败或需要降级时可直接回装，比事后找旧版本更省事。

想把插件这层也一起理清，与其逐个记住每个 DSH plugin 装了什么版本，不如用 DSH Plugin Hub：它在已安装列表里直接标出「可更新」的插件，点一下就能处理，更新前还有确认弹窗，省去手动比对版本。

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