用 dsh-wsl-workspace 让 DeepSeek Harness 直接打开 WSL 工作区

DeepSeek Harness 插件 DeepSeek DSH WSL 界面增强 工作区 2026-08-18 125 阅读

前言

在 Windows 上跑 DeepSeek Harness（dsh），代码却放在 WSL 里，是很常见的组合。项目依赖 apt、gcc、Linux 路径和 POSIX 脚本，智能体却在 Windows 侧会话里工作：bash 工具对不上发行版，文件工具看到的是 C:\...，改完还得自己把改动同步进 \\wsl.localhost\...。反过来，把整套 dsh 再装进 WSL，等于维护两套运行时，路径、配置和网页界面也要来回切。

DeepSeek Harness 的官方定位是「一切皆插件」：模型、工具、会话、沙箱和 UI 都可以在配置层替换，不必改框架源码。社区目录 DeepSeek Harness 插件库 收录了一批这类扩展；需要说明的是，该目录是独立运营的社区站点，与 DeepSeek 或幻方没有从属、背书或赞助关系。本文介绍其中一款界面增强插件 dsh-wsl-workspace：装好之后，在网页界面里直接添加 WSL 工作区，整段 agent 会话（bash 与文件读写）都落到本机发行版里，WSL 内不用再装一套 dsh。

下面按插件目录页、GitHub 仓库 README / package.json / 设计文档，以及 DeepSeek Harness 官方仓库 交叉核对后整理。

这是什么

dsh-wsl-workspace 是一款面向 DeepSeek Harness Web 界面的插件，由 GitHub 用户 6Mikao9 维护，仓库为 6Mikao9/dsh-wsl-workspace，许可证 MIT，主要语言 TypeScript。目录页把它分在「界面增强」；package.json 当前版本为 0.2.3，并声明客户端平台为 web。截至 2026-08-18，目录页与 GitHub 仓库均显示 7 星。插件于 2026-08-14 收录进目录，仓库最近一次推送时间为 2026-08-16。

它要解决的问题可以概括成一句话：在 Windows 宿主机上的 dsh web 里，把整个工作区切进本机 WSL，而不是只多挂一个能跑 wsl.exe 的 shell 工具。维护者在 DESIGN.md 里写明目标运行形态是「Windows 上的 dsh web + 本机 WSL2 发行版」，并对比过只补额外 shell 工具的社区方案（例如 dsh-bash-terminal）：那些方案里，命令可以进 WSL，但 read / write / edit 仍在 Windows 文件系统上。本插件换的是一组按会话生效的能力提供者（ctx.shell + ctx.fs），模型看到的路径一律是 Linux 形式。

package.json 的描述把它类比为 VS Code 的 Remote-WSL：从 GUI 添加工作区，整段会话在发行版内执行。仓库 README 强调两点：WSL 内无需安装任何 dsh 工具链；同一会话还能通过 /mnt/ 访问 Windows 文件（例如 /mnt/c/Users/...）。

核心功能

从网页界面添加 WSL 工作区

安装并重启 dsh web 后，侧栏底部 Settings 旁边会出现一个 W 按钮。点击后打开「添加 WSL 工作区」对话框，文案跟随 DeepSeek Harness 的界面语言。

流程在 README 里写得很具体：

  1. 从下拉框选择一个本机 WSL 发行版。
  2. 浏览目录树，或直接输入 Linux 绝对路径（例如 /home/me/proj）。
  3. 用「检查」确认路径在发行版里确实存在。
  4. 用户名是可选项：留空则按该发行版的默认用户运行（README 注明默认用户常常是 root）；填写发行版里的某个 Linux 用户名，则等价于 wsl.exe -u <用户名>。
  5. 点「创建并打开」，新会话随即落在这个 WSL 工作区上。

用户名只改变 bash 工具的运行身份；文件工具走 Windows 侧的 WSL 共享，不受该字段影响。每个工作区对应的用户名会写入 wsl-workspaces.json，删掉对应条目或在对话框里重建工作区，即可回到默认用户。设计文档还写明：对话框会拒绝以发行版根目录 / 作为工作区。

整段会话跑在 Linux 路径里

新会话里，bash 工具在所选发行版内执行命令，read / write / edit 读写的是 WSL 文件，模型看到的全部是 Linux 路径。维护者在设计文档的 M1 验收里用 uname -a 作为检查点：会话里应当看到 Linux，而不是 Windows。

文件工具的实现路径是 Windows 侧的 WSL 9P 共享（UNC，形如 \\wsl.localhost\<发行版>\...），再在展示层翻译成 Linux 路径。这就是「WSL 内零安装」能成立的原因：不需要在发行版里再跑一套文件代理。

模式选择器仍可用

插件没有把「进 WSL」做成独占的单一预设、把标准 / PTC / 极简 / 创造挤掉。README 写明：模式选择器照常工作，标准、PTC、极简、创造会自动落到对应的 WSL 变体；选择器里的条目是中英双语，例如 WSL · Standard mode（标准模式）。

设计文档把这组变体称为「执行世界与模式正交」：WSL 是执行世界，标准 / PTC / 极简 / 创造仍是原有模式，二者组合后生成 wsl-<模式> 变体。对使用者来说，选工作区时进 WSL，选模式时仍按原来的习惯即可。

同时访问 WSL 和 Windows

会话可以同时够到两边。bash 命令在发行版内执行；Windows 上的文件通过 /mnt/ 访问，例如 /mnt/c/Users/...。设计文档把这称为联合访问：fs-wsl 会把 /mnt/<盘符>/... 映射回 Windows 盘直接读写，界面上仍显示 /mnt 形式。

这对「项目在 WSL、个别配置或素材还在 Windows 用户目录」的情况比较直接，不必为了读一个 Windows 路径再开一个本地工作区。

bash 与文件工具的权限边界不同

这一点 README 单独列了「行为与权限说明」，不宜忽略：

  • bash 工具：以配置的用户名在发行版内运行，可对发行版内任意路径读写。Windows 的 ACL 沙箱无法包裹 wsl.exe（子进程在 Linux 内核侧），因此隔离边界是 WSL 本身，DSH 的文件策略不作用于 bash。
  • 文件工具（read / write / edit）：经 Windows 侧 9P 共享访问，受 DSH 文件策略约束。在 workspace-write 下，读可以到任意位置，写仅限当前会话工作区；改成 danger-full-access 后，工作区外也可以写入。用户名设置不影响文件工具。

另外，若发行版当时还没启动，wsl.exe 有时会往 stderr 打出 localhost 端口转发提示，README 称其乱码但无害，可以忽略。

安装与启用

目录页给出的安装命令如下，在 DeepSeek Harness 终端中运行：

dsh plugin add github:6Mikao9/dsh-wsl-workspace

如需可复现安装，目录页建议固定 commit 哈希（把 commit 换成实际哈希，不要留这个占位符）：

dsh plugin add github:6Mikao9/dsh-wsl-workspace#commit

该插件挂在 Web 界面上。仓库 README 给出了三种装进 web profile 的写法，装完后需要重启 dsh web：

# 1) npm 包
dsh plugin --profile web add dsh-wsl-workspace

# 2) GitHub 仓库（仓库内已含预构建 lib/，无需本地构建）
dsh plugin --profile web add https://github.com/6Mikao9/dsh-wsl-workspace

# 3) 本地目录（开发 / 自用）
dsh plugin --profile web add D:\path\to\dsh-wsl-workspace

重启后，侧栏底部 Settings 旁出现 W 按钮，即说明客户端部分已挂上。目录页也提示：可以用 dsh plugins list 确认插件是否已加载到当前配置。

安装前请先阅读仓库源码和 MIT 许可证。插件以当前 dsh 进程的权限运行，安装时可能执行代码；社区目录和官方文档都建议只安装自己审查过的来源，并在需要可复现环境时固定 commit。

典型用法

下面按 README 的界面流程走一遍，不额外编造配置项。

  1. 确认本机已经有可用的 WSL 发行版（例如 Ubuntu）。插件不会在 WSL 里安装 dsh，但发行版本身需要存在，wsl.exe 要能被 Windows 侧的 dsh 进程调用。
  2. 在 web profile 安装插件并重启 dsh web。
  3. 打开网页界面，点侧栏底部 Settings 旁的 W。
  4. 选择发行版，输入或浏览到项目目录，例如：
/home/me/proj
  1. 点「检查」，确认路径存在后再「创建并打开」。
  2. 在新会话里让模型执行一条能表明内核的命令（维护者自己的验收方式是 uname -a），并读写工作区文件。此时路径应是 Linux 形式；若还要碰 Windows 上的文件，使用 /mnt/c/... 这类路径。
  3. 需要换模式时，直接在选择器里选 WSL · Standard mode（标准模式） 等对应条目，不必退出工作区。
  4. 若 bash 需要以非默认用户运行，在对话框填写该发行版中的 Linux 用户名；只影响命令执行身份，不改变文件工具的访问通道。

仓库 README 还配有界面截图（image-2.png、image-3.png），安装后可以对照按钮位置和对话框布局。

适用场景与注意事项

比较适合这些情况：

  • 日常在 Windows 上开 dsh web，但仓库、构建脚本和依赖都在 WSL 里。
  • 希望智能体按 Linux 路径和 bash 方言工作，又不想在 WSL 里再维护一套 dsh。
  • 同一任务既要改 WSL 项目，又要读 Windows 用户目录里的文件。

使用前需要清楚几条边界：

  1. 平台：面向 Windows 宿主机 + 本机 WSL。package.json 的关键词包含 windows；设计文档写的是 WSL2。macOS / Linux 本机没有 wsl.exe，这个插件没有对应能力。
  2. 不是只加一个 WSL shell：如果只想在 Windows 会话里偶尔跑几条 Linux 命令，社区里还有只注册额外 shell 工具的插件。本插件会按会话切换执行世界，文件工具也会进 WSL。
  3. bash 不受 DSH 文件策略约束：Windows ACL 沙箱包不住 wsl.exe。把工作区交给默认用户（尤其是 root）时，发行版内的读写范围由 WSL 自己决定。需要收紧时，应在对话框里指定普通 Linux 用户，并审慎使用 danger-full-access。
  4. 文件策略仍然管文件工具：workspace-write 下不能靠 write / edit 改工作区以外的 WSL 文件；那不是 bug，是策略。
  5. 权限与来源：插件与当前 dsh 进程同权。安装前检查 源码仓库 和许可证；不要把社区目录当成官方应用商店。
  6. 路线图中尚未作为 README 用法写出的部分：设计文档把侧栏文件树面板、交互式终端、SSH 远程工作区列为后续里程碑。当前 README 的用法止于「添加 WSL 工作区」对话框和会话内的 bash / 文件工具，本文不以设计稿未交付能力为准。

再分发或二次开发时，仓库要求保留 LICENSE 与 NOTICE。NOTICE 列明：执行器机制改编自 DeepSeek Harness 的 dsh-bash-local，WslFileSystem 子类化 dsh-fs-local，并参考了 dsh-bash-terminal（WSL argv / WSLENV）和 dsh-side-panel（Host 路由模式）的设计，但后两者未复制源码。

小结

dsh-wsl-workspace 做的事情很集中：让 Windows 上的 DeepSeek Harness 网页界面能直接打开 WSL 工作区，bash 和文件工具都在发行版里跑，路径是 Linux 的，WSL 里不用再装 dsh，Windows 文件仍可通过 /mnt/ 够到。对已经把开发环境放在 WSL、却希望继续用 dsh web 的人，可以少维护一套运行时。

目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-wsl-workspace/

GitHub：https://github.com/6Mikao9/dsh-wsl-workspace

相关文章

快速从零部署一个DeepSeek-R1服务 2025-04-05 使用 dsh-anchored-standard 为 DeepSeek Harness 配置两阶段 Agent 预设 2026-08-17 用 dsh-web-ui 把 DeepSeek Harness 网页界面补成工作台 2026-08-17 用 modlens 给 DeepSeek Harness 的纯文本模型补上视觉 2026-08-17 用 dsh-TUI 给 DeepSeek Harness 补上全屏终端界面 2026-08-17
羽毛球分组比赛记分
小程序二维码

欢迎使用《羽毛球分组比赛记分》微信小程序

小夜