切换手册章节
桌面端装好的插件，为什么 Web 里看不到？
同一台电脑可以用两种方式打开 Harness。若浏览器连接的是 npm 启动的 Web，桌面应用和浏览器各有一个运行宿主、各读一份插件配置。即使两边都能看到同一段会话，也要在实际工作的那一端安装和启用所需插件。先辨认浏览器连的是哪台主机，再查那台主机上的目录。
本篇目录 6 节
用一个例子认清根目录
把 DSH_HOME 想成这台主机上 Harness 的用户数据目录。默认是当前操作系统用户的 .dsh 文件夹。macOS 或 Linux 常写作 ~/.dsh；Windows 当前用户可在资源管理器地址栏输入 %USERPROFILE%\.dsh。设了 DSH_HOME 时以实际值为准，空值会回退到默认目录。
假设你在同一账号下，用本机 npm 启动 Web，同时安装了 Desktop。桌面应用取 profiles/desktop，默认的 dsh web 取 profiles/web。如果浏览器访问同事服务器、容器或其他操作系统用户启动的 Web，应该在那个环境里查目录。浏览器本机的 .dsh 未必与它相干。
| 以数据根为起点 | 它管什么 | 先看哪条线索 |
|---|---|---|
| profiles/desktop/ | 桌面应用专用的插件配置和外部依赖 | 在桌面应用的「插件」页核对 |
| profiles/web/ | 默认 npm Web 的插件配置和外部依赖 | 查启动命令使用的 profile |
| profiles/node_modules/ | Node 查找依赖时可能经过的共同父级位置 | 物理目录可能不存在；见后面的解析示例 |
| cordis.patch.yml | 根目录级的额外配置覆盖（如已设置） | 它可能影响这一数据根下的多个 profile |
作者提供的 Windows 实图，账号名已遮盖。目录位于同一父级，各端的安装状态需进入对应配置核对。
- 1desktop 配置档
- 2web 配置档
打开一份 profile，可以查到什么
两份 profile 都从相同的 Web 基础组合包清单初始化，因此初次打开会很像。之后在某一端添加插件，只改变目标 profile 的依赖和启用清单。桌面应用的核心运行时随安装包提供；npm Web 的核心运行时来自启动它的 npm 安装。
| profile 内的项目 | 读法 |
|---|---|
| package.json → dependencies | 通过该 profile 安装的第三方依赖及来源。一个已安装的包仍可能处于停用状态。 |
| package.json → dsh.profile.bundles | 按顺序参与组合的 bundle 名称。RC5 新 Web 默认从 @deepseek-ai/dsh-base、@deepseek-ai/dsh-web-app 开始。 |
| cordis.patch.yml | 本 profile 对组件行的设置，例如单独禁用某个组件。改动生效还取决于是否有更高层覆盖。 |
| node_modules/、pnpm-lock.yaml | 添加外部包后常会出现，前者承载本 profile 安装的包，后者记录包管理器解析的版本。 |
| pnpm-workspace.yaml、cordis.yml | 前者是包管理配置；CLI 生成的 cordis.yml 是启动根文件，日常排查以清单、覆盖文件和有效配置为主。 |
为什么 profiles/node_modules 会被误认成共享插件库
普通 Node 包从发起 import 或 require 的文件往上找依赖。以 Web 插件自己的模块为例：先看插件私有依赖，再到 profiles/web/node_modules，再到父一级 profiles/node_modules。RC5 在父一级的这一步加入了运行时映射，每个宿主根据自己的安装和选中的组合包构建映射表。
若某个包名在映射表里，走到这一级会选择表里记录的包，就算磁盘上的父目录残留同名副本也一样。没有映射的名字才可能命中该父级中的真实文件。生产运行时无需把全部依赖复制到这个父目录，开发链接、旧版本升级和本机手动放置的内容可能让目录外观不同。
例如查一个给模型用的工具，应分别确认该端已选择组合包、配置树有对应的组件行、插件已挂载；要在特定会话里使用，还要检查会话的预设和权限。能从某个目录解析到 JavaScript 包，只能说明代码可找到。
先用 GUI 对比两端，再用命令核对
- 在桌面应用打开「关于 DeepSeek Harness」记下版本；在要对比的 Web 终端运行 dsh --version，并记下启动命令中的 profile。若终端用了 npx，核对当时调用的包版本。
- 分别进入桌面和 Web 的侧栏「插件」。核对同一个包的完整名称、版本、来源、组合包开关和具体组件状态。若只有一端装过，应在另一端自己的插件页按相同来源安装，再确认该端组件成功运行。
- Web 若显示已启用但界面仍不同，可用本节命令输出该 profile 的有效配置，搜索组件行的 id 和 disabled。依次叠加的是组合包、profile 的 cordis.patch.yml、根目录的 cordis.patch.yml、启动命令的 --patch。实际任务仍需在相同的会话预设与权限下核对。
- 遇到正在被其他进程写入的会话，先让原进程结束该会话的工作，再重试。Desktop 的关闭窗口可能只把它隐藏到后台；真正退出可用应用菜单的「退出」。
dsh --version
dsh --profile web --dump-config终端的 dsh 究竟属于哪个安装
Desktop 和 npm 都可以提供名为 dsh 的终端命令。同样是 dsh --version，版本号也可能恰好相同；应再看命令实际路径。Windows PowerShell 可以运行 Get-Command dsh -All，macOS 的 zsh 可以运行 type -a dsh。桌面应用菜单的「管理 dsh 命令…」还能查看、安装或修复桌面版提供的命令。
管理 Desktop 插件时，先打开一次桌面应用让它初始化，再完全退出；使用已注册的 Desktop 内置命令运行 dsh plugin --profile desktop list。核实清单后重新打开桌面应用。Desktop 的内置命令用它自己的 Electron 和 pnpm；npm 安装的 dsh 对 desktop 的启动、配置导出和插件管理会报该 profile 由 Electron 独占。
管理 npm Web 插件时，可在相应 Web「插件」页操作，或用 npm 的 dsh plugin --profile web list 查看已安装包。命令结果列的是包依赖；插件有没有启用、组件有没有挂载，要再看该端的清单、插件页或实际调用。
实际验证了安装、加载和移除哪几步
使用 Linux 下真实的 npm 发行版 0.2.1-rc.5，在临时 DSH_HOME 创建 web 和另一份从同一 Web 模板建立的配置。制作了一个只记录自身加载位置的小插件，打成本地压缩包，通过 dsh plugin --profile web add 安装。没有使用用户账号、业务文件或模型。
| 核验动作 | 实际观察 |
|---|---|
| 对比两份清单 | web 的 dependencies 增加包和来源，dsh.profile.bundles 新增其名字；对照 profile 保持初始组合。 |
| 核对清单之后再检查组件 | 样例第一版只给不存在的组件 ID 写了覆盖，包虽已被选中，配置树里仍没有该行。改用 insert 明确插入组件、重新打包安装后才加载成功。 |
| 分别真实启动两个 Web 宿主 | web 的有效配置出现对应组件行，小插件的加载函数执行成功；对照 profile 同样启动成功，但未出现该行，也没有执行小插件。 |
| 人为在共同父级放两份标记包 | 小插件加载映射内的 @deepseek-ai/dsh-commands 时，命中运行中的发行安装；另一个没有映射的测试名字才命中父级物理包。 |
| 由 Web 移除小插件并重启 | 依赖、选中列表和外部包目录中的对应项均移除；两个宿主重新启动后均未执行小插件。 |
| 用 npm 的 dsh 检查 desktop | plugin --profile desktop list 与 desktop --dump-config 均返回 Electron 专属提示，未创建 desktop 目录。 |
来源与延伸阅读
知识库与演示素材
知识库附录含录屏分镜。练习包里的 INDEX.md 可按题目查找会议简报、只读目录核对、Cordis 报销回执，以及门店销售和团队练习。