DeepSeek Harness官方桌面端曝光，插件、运行环境全部独立！

智猩猩AI整理 编辑：林夕 近期，DeepSeek 官方 GitHub 仓库出现了一个单独的 apps/desktop 目录，并公开了完整的 Desktop README 。 按照官方描述，这是一套 基于 Electron 构建的桌面应用 ，负责承载 dsh Web UI。 官方给出的架构是：Electron 作为桌面 Shell，内部运行打包后的 dsh，同时自 带一套 Node.js 和 pnpm 。 桌面端不会启动一个对外监听的 Web 服务，而是通过 dsh-app:// 提供客户端资源，再利用进程间通信和数据管道完成请求与响应，界面和 Web 端几乎没什么区别。 如果桌面端继续依赖用户电脑上已经安装好的 Node.js、pnpm 以及各种 npm 包，开发环境不同，很容易出现版本冲突。 DeepSeek 因此选择把运行所需的 Node.js、pnpm、dsh 以及相关生产依赖一起放进桌面应用里。 这样一来，用户本机的 Node.js、pnpm 和包管理器配置都不会进入 Desktop 的执行路径。 同时，DeepSeek 把 Desktop 和 dsh 的版本绑定在了一起。 官方明确规定，Electron Shell、Web Client、Backend 和 Plugin Graph 被视为一个 完整的 Release Identity 。 即便某次更新没有修改 Electron Shell，只要 dsh 本身发生升级，也会被视为一次 Desktop Release。 DeepSeek 的方案是直接把这些组件锁在同一个版本组合里。 桌面端还拥有独立的运行目录。官方设计中，CLI 和 Desktop 虽然共享 Harness 的部分用户数据，但不会共享可执行包、插件激活状态、lockfile 和 node_modules 。 Desktop 会独占自己的 profile ，并通过单实例锁避免多个桌面进程同时修改同一套环境。 插件系统也被单独考虑了。 官方 README 显示，桌面端的核心 dsh 和第一方组件会随应用一起打包， 外部插件则在用户需要时安装 。 插件的安装、更新和删除由 Desktop 自己管理，并使用内置 pnpm 完成。 同时，插件窗口不会直接获得文件系统、Shell 或原始 Electron IPC 权限。 开发流程也已经完整写进了官方仓库。 开发者可以直接运行 pnpm run dev:desktop 启动桌面端开发环境；完成构建后，也可以通过 pnpm run start:desktop 启动已经生成的应用。 而 正式打包 则有独立的 package:desktop 流程。 目前官方列出的正式 Desktop Release Target 包括 macOS ARM64、macOS x64 和 Windows x64 。Linux 暂时没有被列入 Desktop 的正式发布目标。 macOS 版本还已经准备了完整的签名、公证流程，Windows 则准备了 EV 签名方案。 这意味着 DeepSeek 考虑是进一步 把桌面应用按照真正的软件发行流程来设计 ，包括安装包、代码签名、更新元数据、自动更新以及不同平台的发布。 官方还设计了 自动更新机制 。 打包后的 Desktop 会检查对应平台的 Release Stream，如果发现新版本，可以直接通过桌面端触发更新。 更新包经过验证后，应用会停止 dsh 子进程，由 electron-updater 完成安装并重启。 目前官方甚至已经 把生产环境的更新地址写进了配置流程 ，生产环境使用的是 download.deepseek.com 。 不过，现阶段还不能把它理解成已经面向普通用户正式发布的桌面客户端。 从官方仓库目前公开的 README 来看，Desktop 仍然主要服务于开发和构建流程。 另外， 当前版本也存在一些限制 。 比如 Desktop 暂时关闭了 Web 的“Open In...”功能，因为对应 Host Plugin 需要 HTTP 路由，而 Desktop 本身不提供 webServer 。 插件如果包含需要执行生命周期脚本的依赖，也必须通过 Desktop 审核过的 allowBuilds 策略，否则无法安装。 官方 README 有一句很有意思： Use an unpacked application to exercise the bundled Node.js, bundled pnpm, bundled dsh resources, plugin installation and repair paths. 也就是说， 真正想测试“桌面端最终用户运行环境”的话，官方其实更推荐用 unpacked application，