DSHL · DeepSeek Harness Launcher

别名：dshl、DSHL、PCL-Deepseek-Harness-Launcher、PCL2 魔改启动器

Windows 上一站式安装、启动与管理 DSH 的启动器（PCL2 魔改），canonical ID 是 `dshl`；它不解析 manifest，只负责把包装上并让其版本自报（四段式，如 `0.1.1.2`）参与安装端的 `minVersion` 提示。

一句话

DSHL 是 Windows 上「装上并起得来」那一步的承载者：它不是一个 DSH 插件，而是 DSH 外面的启动器（照上游说法是 Plain Craft Launcher 的二次开发）。在 .dspack 生态里它的身份是 canonical ID dshl——这个 ID 才是整合包能声明「我支持谁」的凭据。

身份：为什么 ID 比仓库名重要

整合包的 manifest v5 有一个可选的 launchers 字段（§13），键就是启动器 ID：简式是 ID 列表（["dshl","hdsl"]），全式是 ID → 支持声明（{"dshl": "0.2.0", "official-desktop": false, "dsh-cli": {"supported": false, "reason": "…"}}）。所以「某个包支不支持 DSHL」在规范里是可判定的事实，而不是读 README 得出的印象。

本机市场索引里实测只有 2 个包写了 launchers（快照 2026-09-30，8 个包中）：

包	manifest	`launchers` 实测值
`hxh230802.smoother-deepseek-harness`	v5	`{ "dshl": true, "hdsl": true, "dsh-packforge-app": true, "official-desktop": true }`（全式，四个 ID 全 true）
`yukitakasama.better-deepseek-harness-codex`	v5	`["dshl", "dsh-packforge-app"]`（简式）

这张表说明的是生态现状：dshl 两次都被写上，是最常被声明的启动器之一；但其余 6 个包一个都没写——不写等于「通用包」，任何启动器都按现状装。所以「包没写 launchers」不是「不支持 DSHL」。

版本自报与判定规则

DSHL 是唯一一个把自报格式写进规范表的条目：注册表名称 PCL-Deepseek-Harness-Launcher（PCL2 魔改），ID dshl，版本自报 ✅ 四段式（如 0.1.1.2）（specs/launcher-registry.md §1）。

判定规则（launcher-registry.md §3 + pack-structure/v3.md §9.1）：

比较方式：按 . 分段、逐段数值比较、缺段视为 0（1.2 ≡ 1.2.0）；
不做预发布语义：rc / beta 在启动器版本上不被解释（那种形态只出现在 DSH 版本里）；
只提示、不硬拒：不满足 minVersion 轻提示后放行；supported:false 是重警告、也放行；放行必须在安装日志留痕；
自报不出来 = 版本未知：minVersion 一律按「版本未知」处理，轻提示后放行。

这四条合起来是一句设计声明：启动器兼容声明不是门禁。 你也可以用 DSHL 装一个「声明要更高版本 DSHL」的包，只是会看到提示——但这意味着警告要真读，它是唯一的反馈渠道。

与它的同音邻居：hdsl

规范表专门写了防混淆警告：dshl（PCL 系）与 hdsl（Hello 系）一个字母之差、完全无关。这不是洁癖——两个 ID 在 issue、README、launchers 字段里互相写错，后果是「声明支持的启动器其实没被声明」。写包时请从注册表复制 ID，不要手打。

与其它东西的关系

关系	对象	说明
上游契约	[[spec/2	manifest v5]] §13	`launchers` 字段与归一化规则在这一层
同层分野	client/1 官方 Web UI	启动器管「装上与起得来」，界面管「用起来什么样」
生态入口	source/2 dsh-pack-market	包的来源与索引在这条链上
装的包长什么样	dsh-packforge-app（GitHub）	它自己也认领了一个启动器 ID（见工具链分区），但不是插件词条

未核实 / 未声明

仓库归属：url 取自本机分区文件与市场注册表（Loliyer520/DSHL-Deepseek-Harness-Launcher）；规范表的 ID 表行里并没有链接——§2 的认领规则要求「附仓库链接」，表里 dshl 这一行却没写，属于表与规则的不一致，本站不替它补。
仓库内容未读：本轮没有读该仓库的 README、Release、LICENSE，所以许可证、最近提交、是否归档、是否有安装器二进制全部未核实。分区条目给它挂了 risk: [desktop-control, network]，那是分区层的风险标注，不是代码审查结论。
platforms：写的是 [windows]，来源是注册表 support: "Windows 一站式" 的措辞与市场 launchers.json 的同一句话——注册表里没有 platforms 这样的键。所以严格说 macOS / Linux 的支持情况未核实。
supportedManifest：未核实。没有任何一处声明 DSHL 支持哪几版 manifest。manifest v5 规格只写了整条工具链「导入侧兼容 v4 / v3」，不能直接套到 DSHL 头上。
是否支持 .dspack：支持——编辑确认（2026-10-02）。此前分区文件里这一项是 importSupport: null（未声明），所以本词条原来把它列在「未核实」里；现在有结论了。这件事实本站用标签表达（分区卡片上的 支持 .dspack 标签），没有为它单开字段——标签能筛选、能上色，够用。与之并列的另一条轴是 canonical ID：dshl 已认领，整合包能在 launchers 字段里声明它。
四段式自报的机器可读依据：0.1.1.2 只出现在注册表表格文本里；市场 launchers.json 只有 id / name / url / support / desc，没有版本字段。
名称三处不一致：规范表写 PCL-Deepseek-Harness-Launcher（PCL2 魔改），市场与分区文件写 DSHL · DeepSeek Harness Launcher，desc 写「Windows 上一站式安装、启动与管理 DeepSeek Harness」——三处措辞不同、指向同一个 ID，本站保留上游各自的原文。

谁引用了这一条

信息表

category: launch.wrapper
launcherId: dshl
platforms: windows
support: Windows 一站式
supportedManifest: 未核实：注册表与市场索引都没有声明条目给出它支持的 manifest 版本；官方 manifest v5 规格只说「生成侧以 v5 产出、导入侧兼容 v4 / v3」，那是整条工具链的口径，不是 DSHL 的声明
titleEn: DSHL · DeepSeek Harness Launcher
updatedAt: 2026-10-02
url: https://github.com/Loliyer520/DSHL-Deepseek-Harness-Launcher

标签：启动器、整合包安装、Windows

按标签浏览：启动器（9） · 整合包安装（2）