realguan 的 dsh-dock 是给 DeepSeek Harness 用的桌面壳，技术栈为 Tauri v2、Rust 与 React 19。官方 CLI 能启动工作台，却没有提供列举、重命名、克隆或删除工作台的命令；dsh-dock 补的正是这层可视化管理，同时把插件、凭据、MCP 和诊断收进一个窗口。
三个主模块
控制中心的 Profile 列表负责工作台生命周期：创建、克隆、重命名、删除、启动，以及单个工作台的插件、实验能力、MCP 与 Patch 配置。克隆时会排除 node_modules 并改写包名，运行中的工作台会被锁定，避免误删。
插件中心直通社区 Registry，README 记录其覆盖 3,400 多个插件，支持按分类、关键词和下载量检索，安装源可以是 npm 包名、GitHub 仓库或 tarball 直链，安装任务在后台排队，不阻塞界面。
系统控制台偏运维：录入和清除各厂商 API Key 时只显示掩码；查看和编辑 settings.yaml 前会确认并备份；健康大盘检查 Node、pnpm、DSH 的版本与路径，并展示 DSH_HOME 的存储分布；运行日志支持关键词过滤和尾部追踪。关闭主窗口只是隐藏，工作台进程继续运行，真正退出要用托盘或菜单栏的退出。
首次启动会自己补齐运行时
安装包只有几十 MB，因为不内置 Node.js 与 DSH 引擎。第一次启动时，ds-dock 通过镜像链拉取 Node、安装 DSH，补齐后才能离线启动，后续升级需要显式触发。发布产物覆盖 macOS（Apple Silicon 与 Intel 分开构建）、Windows x64 和 Linux x64；Linux 托盘依赖 libayatana-appindicator3，缺失时应用仍能运行，只是没有托盘图标。
Windows 安装包目前未做代码签名，SmartScreen 可能提示“未知发布者”，README 给出的处理方式是“更多信息 → 仍要运行”。这一点在企业环境里需要提前和终端安全策略确认。
日常操作也不只靠菜单：工作台页面里有 Shadow DOM 悬浮胶囊，应用内快捷键 Cmd/Ctrl + , 可呼出控制中心；拉起的子进程会登记 PID 并在退出时回收，60 秒内连续崩溃三次则停止自动重启，避免死循环。DSH 版本管理器还能按 Stable、RC、Alpha 通道安装或回退引擎。
一个多工作台的用法
可以为每个项目建一个独立工作台：项目 A 装数据库和浏览器插件，项目 B 只留最小工具集，桌面端则保留那个标记为“官方保留”的 desktop 工作台。每个工作台的插件列表能直接看到运行态、版本和更新提示，MCP 服务器支持当前工作台与全局两层范围，改完还能就地探测工具列表。切换时从启动中心按数字键进入，不必记 --profile 参数。
和官方 CLI、dsh-market 的分工
官方 CLI 适合脚本化和远程环境，--profile 与 --from-default-profile 是它的入口；dsh-market 是装在 DSH 里的插件市场，解决“在会话界面里发现插件”；dsh-dock 则是壳层，解决“本机有几套工作台、引擎是什么版本、凭据放在哪里”。三者可以同时存在，但都操作同一份 ~/.dsh 数据，改动前最好只留一个管理入口。
风险与限制
项目版本迭代很快，README 的路线图已排到 v1.5，宿主 DSH 升级后可能出现兼容问题。desktop 工作台被官方桌面端独占，ds-dock 会关闭它的启动、重命名和删除，只保留内容管理。首次启动依赖网络，镜像链不可用时需要自己处理。凭据只存本机，Unix 下强制 0600 权限，Windows 则依赖用户 profile 的默认 ACL。本文按官方 README 与仓库元数据整理，未在本机完整实测。
适合谁
适合同时维护多套 DSH 配置、经常安装插件、又不愿手改 YAML 的用户，以及需要给团队统一运行时和诊断入口的人。只用一套默认配置、偶尔对话的用户，官方 CLI 已经够用，额外装一个桌面壳反而多一层升级负担。
官方入口
- 仓库：realguan/dsh-dock
- 下载：GitHub Releases
- 许可证：MIT