背景
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 命令启动的浏览器会话才能获得访问权限。
2.2 Token 与 Cookie 的生命周期
理解这两者的关系对日常使用非常重要:
- 启动令牌 :每次
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。