用 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
羽毛球分组比赛记分
小程序二维码

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

小夜