从系统服务到桌面应用：DeepSeek Harness 部署与多形态使用指南

背景

DeepSeek Harness（简称 DSH）是 DeepSeek 推出的 AI 编程助手工具，通过 dsh web 可以在浏览器中访问其 Web UI 界面。但源码编译版本没有现成的桌面客户端，每次都需要手动敲命令启动，终端关闭后服务也就断了。

本文将完整记录如何通过 WinSW 将源码编译的 DSH 注册为 Windows 系统服务实现开机自启，并进一步利用 Edge 浏览器的"新建应用"功能，将 Web UI 封装为独立的桌面应用。最终效果是：开机后 DSH 自动在后台运行，双击桌面图标即可使用，体验接近原生客户端。

一、WinSW 服务化部署

1.1 为什么选择 WinSW

WinSW 是一个轻量级的开源工具，可以将任意可执行文件包装成 Windows 原生服务，使其在系统后台自动运行，无需用户登录或手动干预。与使用 pm2、nssm 等方案相比，WinSW 的优势在于配置简单（单个 XML 文件）、原生服务集成、支持开机自启和崩溃自动重启。

1.2 核心配置要点

首先在 WinSW 的 GitHub Releases 页面下载最新版本的可执行文件，将其重命名为 deepseek-harness.exe，并在同目录下创建同名 XML 配置文件 deepseek-harness.xml。

配置文件的核心内容如下（请将示例路径替换为你自己的实际路径）：

xml 复制代码

<service>
  <id>deepseek-harness</id>
  <name>DeepSeek Harness Service</name>
  <description>DeepSeek Harness Web UI Service</description>

  <!-- 替换为你的 node.exe 绝对路径 -->
  <executable>C:\path\to\node.exe</executable>

  <!-- 替换为你的项目入口文件路径 -->
  <arguments>"D:\path\to\deepseek-harness\apps\cli\lib\bin.js" --profile web --no-open</arguments>

  <!-- 替换为你的项目根目录 -->
  <workingdirectory>D:\path\to\deepseek-harness</workingdirectory>

  <startmode>Automatic</startmode>

  <logmode>rotate</logmode>
  <onfailure action="restart" delay="10 sec"/>
</service>

几个容易踩坑的地方：

<executable> 必须指向 node.exe 的绝对路径 ，不能直接写 node，因为服务模式下 PATH 环境变量可能不完整。通过 nvm 管理的 Node.js 路径通常在用户目录下，需要写完整路径。
<arguments> 不要有多余的子命令 。DSH 的 CLI 入口 bin.js 本身就是命令入口，不需要再传 dsh 作为子命令，否则会导致参数解析错位。
<startmode> 设为 Automatic 才能实现开机自启。
<workingdirectory> 设为项目根目录，确保程序在相对路径下查找资源时不会出错。

1.3 安装与管理

以管理员身份打开 CMD，进入 WinSW 所在目录后执行：

bash 复制代码

.\deepseek-harness.exe install
.\deepseek-harness.exe start

如需卸载，执行 .\deepseek-harness.exe uninstall。启动后访问 http://127.0.0.1:3080 即可看到 Web UI。

二、理解 DSH 的认证机制

2.1 为什么直接访问 3080 会被拒绝

DSH Web UI 内置了浏览器启动令牌认证机制。每次服务启动时，DSH 进程会生成一个随机的启动令牌，只有通过带令牌的 URL 访问（格式为 http://127.0.0.1:3080/?token=...），浏览器才能将令牌交换为一个持久化的 Cookie。

这是 DSH 的安全设计：Web Host 以当前操作系统用户的权限运行工具型会话，如果仅凭 loopback 地址就授予本地权限，任何能向该端口发请求的进程都可以调用工具。启动令牌认证确保只有真正通过 dsh web 命令启动的浏览器会话才能获得访问权限。

理解这两者的关系对日常使用非常重要：

启动令牌 ：每次 dsh web 进程启动时随机生成，进程结束后即消失，绝不持久化。
会话 Cookie ：通过令牌交换得到的签名 Cookie，其 HMAC 密钥持久化存储在 $DSH_HOME/.credentials.yaml 中。Cookie 的默认有效期为 30 天，绑定到具体的主机名和端口。

因此，重启系统后启动令牌会失效，但已签发的 Cookie 不会失效 。只要 .credentials.yaml 文件未被删除，且 Cookie 未过期，浏览器再次访问时无需重新认证。

2.3 作为系统服务时如何首次认证

由于配置中使用了 --no-open 参数，DSH 不会自动打开浏览器，启动令牌 URL 会输出到 WinSW 的日志文件中。首次使用时，打开 deepseek-harness.out.log，搜索 ?token= 找到完整 URL，复制到浏览器打开即可完成首次认证。之后 Cookie 会持久保存在浏览器中，日常使用无需再关心令牌。

三、多种使用方式

3.1 方式一：浏览器直接访问

最基础的方式：打开浏览器，输入 http://127.0.0.1:3080，完成首次令牌认证后即可使用。

3.2 方式二：Edge 将 Web UI 安装为桌面应用

这是体验提升最明显的一步。Microsoft Edge 内置了将网站安装为独立应用的功能，可以将 DSH Web UI 变成一个拥有独立窗口、独立任务栏图标的桌面应用，就像本地软件一样从桌面直接启动。

操作步骤：

在 Edge 中打开 http://127.0.0.1:3080 并完成首次令牌认证；
点击浏览器右上角的三个点菜单按钮；
依次选择"应用" → "将此站点安装为应用"；
在弹出的对话框中输入应用名称（如"DeepSeek Harness"），确认安装；
安装完成后，桌面上会生成应用图标，也可以右键选择"固定到任务栏"。

安装后的应用窗口没有浏览器地址栏和标签栏，只展示 DSH 的 Web UI 界面，视觉上就是一个独立的桌面程序。由于 Cookie 是持久化的，通过应用图标打开的窗口会直接进入 UI，无需重新认证。

如果需要使用多个 DSH 实例（例如不同的 profile 或端口），可以利用 Edge 的多配置文件功能。为每个实例创建一个独立的 Edge 配置文件，然后分别将其安装为独立应用，每个应用都有自己独立的 Cookie 存储，互不干扰。

3.3 方式三：批量管理脚本

如果需要在多台机器上部署，可以编写批处理脚本简化服务安装流程。创建一个 install.bat：

batch 复制代码

@echo off
cd /d %~dp0
deepseek-harness.exe install
deepseek-harness.exe start
echo 服务安装并启动完成。
pause

以及对应的 uninstall.bat：

batch 复制代码

@echo off
cd /d %~dp0
deepseek-harness.exe stop
deepseek-harness.exe uninstall
echo 服务已卸载。
pause

将 WinSW 可执行文件、XML 配置和这两个脚本放在同一目录，双击即可完成部署。

3.4 方式四：结合第三方桌面壳（进阶）

社区已经有一些项目将 DSH Web UI 封装为桌面程序，例如 dsHell 通过薄壳设计复用已安装的 Node.js 和 DSH，双击 exe 即可启动，自动完成令牌交换流程。还有 dsh-window 插件，提供基于 WebView2 的 Windows 原生窗口，安装插件后 DSH 会自动确保桌面应用就绪。这些方案适合希望进一步简化操作的用户，但需要额外安装第三方组件。

四、总结

使用方式	启动方式	适用场景
浏览器直接访问	手动输入 URL	临时使用、调试
Edge 安装为应用	双击桌面图标	日常使用，体验最佳
多 Profile 独立应用	多个图标独立启动	多实例并行使用
第三方桌面壳	双击 exe	追求开箱即用

整体方案的核心链路是：源码编译 → WinSW 服务化 → 开机自启 → 首次令牌认证 → Edge 应用化 → 日常双击使用。这套方案充分利用了 Windows 原生的服务管理和 Edge 浏览器的 PWA 能力，在不引入额外框架的前提下，将 DSH 从一个需要手动管理的命令行工具，变成了开机即用、体验接近原生客户端的桌面应用。

需要注意的是，当前 DSH 仍处于 developer preview 阶段，后续版本可能带来破坏性变更，升级时建议关注官方 release notes。