DeepSeek Harness 插件生态与 WSL 开发实测
原创 · 约 26 分钟阅读 · 阅读 --

DeepSeek Harness 插件生态与 WSL 开发实测

作者: Alex Xiang

人工智能工程实践

本文完全由 WorkBuddy 独立收集资料、调试代码并完成文章写作。

扫码注册 WorkBuddy 即可获取 2000 积分

我是 Alex Xiang，前百度/微博工程师，现在专注于 AI 工程与工具产品。更多文章欢迎关注微信公众号「字与码」。

上一篇《DeepSeek Harness 实用指南》讲的是怎么装、怎么配。这篇只讲两件具体的事：能不能像 VSCode 那样在 dsh 里编辑文件，以及能不能直接写 WSL 发行版里的代码。全部结论都有实测支撑，数据截至 2026 年 10 月 9 日。

结论速览

问题结论
官方支持文件编辑吗内置文件树与文档预览，但只读。可写编辑全靠第三方插件
该装哪个dsh-better-sidebar，近 30 天 25.9 万次下载，事实上的生态底座
官方支持 WSL 吗不支持。桌面版 runtime 全是 win32，但这个能力被设计成了可替换的插件缝
想真原生写 WSL 代码桌面版装 dsh-wsl-desktop；web 版装 dsh-plugin-wsl-env
Web 方案有侧边栏文件编辑吗有，而且 web 才是这类插件的主场
装插件报 ERR_PNPM_ADDING_TO_ROOTpnpm 低于 10.5.0。加一个 -w 就能过

文件编辑：官方只读，可写靠插件

官方从 0.1.5 起内置了工作区文件树与文档预览两个包，就是右侧栏那个「文件」页。但它只能看不能改。

所以「像 VSCode 那样编辑文件并保存回磁盘」这件事，官方给不了，必须装插件。

dsh-better-sidebar 补的正是这块：内置「文件」页被它接管，补上可编辑的 CodeMirror 编辑器（保存、语法高亮、Markdown 预览切换），另加 Git 变更着色与状态字母、多选批量复制路径与删除、拖拽上传、压缩打包下载。它同时开放 ctx.betterSidebar 服务（registerTab 与 registerFileViewer），GitHub 上已有 28 个以上插件挂在它上面——这是它成为底座的原因。

其他可选：dsh-file-review（Shiki 高亮编辑器，删除走系统回收站）、dsh-code-ui（Cursor 风格多标签）、dsh-file-manager、dsh-explorer-editor、dock-editor。能力差距不大，但下载量差两个数量级。

热度：别信聚合站，看 npm

这个生态的插件数据有个陷阱：目前至少有四个聚合站在收录（dshpluginhub.ai、dshpluginhub.dev、dsh.deepseek404.com、dsh.bestsvps.com），同一个插件的 star 和下载数互相打架——有的站点显示 25 万下载 3753 星，有的显示 5.8 万下载 4.1 千星。

唯一可比的口径是 npm 官方接口：api.npmjs.org/downloads/point/last-month/<包名>。跑一遍就清楚了。

DSH 文件编辑类插件热度

三个结论：

  • 第一梯队断层领先。 better-sidebar 25.9 万次 / 月，第二名 dsh-codex-ui 25.8 万次，但后者是侧栏与会话树，不是文件编辑器。这两个是生态里唯二的十万级插件。
  • 第二梯队只有几千。 dsh-file-review 4,173 是独立编辑器里最高的，其余都在 300 到 1,600 之间，属于个人作品，维护看作者心情。
  • 官方内置包 140 万次 / 月，那是随 Harness 分发的量级，不代表使用热度，只说明内置预览已覆盖九成场景。

生态总量：聚合站收录约 12,715 个插件，按 editor 检索出 212 个，真正有人用的不到 15 个。

还有个信号值得留意：dsh-plugin-workbench 的作者已经主动停更，理由写得很直白——官方 0.1.5 起已内置工作区文件树与文档预览。同类插件正在被官方能力吃掉。

WSL 开发：三种架构，只有一种等价 VSCode

VSCode 的 WSL 远程之所以是「原生」，是因为它把 server 与扩展宿主搬进了发行版，文件语义完全是 Linux 的。所以判断 dsh 上的方案好不好，也只看一件事：执行面在哪。

在 DSH 上写 WSL 里的代码的三种架构

架构 A，UNC 直连。 工作区直接指向 \wsl.localhost&lt;发行版>\home…，文件树和编辑工具确实读到真实 WSL 文件。但它走 9P 共享：慢、没有 POSIX 权限、文件名大小写不敏感、没有 inotify 文件变更通知，而且 Windows 的 Workspace Write ACL 沙箱管不住它，会话必须开 Full access。代表插件是 GitHub 上的 dsh-for-wsl 和 web 侧的 dsh-wsl-workspace。这也是 VSCode 官方不建议直接开 \wsl$ 的原因。

架构 B，执行世界搬进发行版。 把 fs、shell、subprocess、终端、沙箱整体换成「在发行版内执行」的实现，Windows 侧只留 UI，两者之间走一条只传显示与按键的 PTY 桥。这才是 VSCode 模式的等价物，文件读写落在 ext4 上，拿得到原生 symlink、mode bits 和 inotify。代表插件是桌面原生的 dsh-wsl-desktop，和 web 侧的 dsh-plugin-wsl-env。

架构 C，整个 dsh 进程跑在 WSL 里。 零跨边界，最干净，代价是要往发行版里再装一份 dsh。

插件为什么做得到这件事？因为官方把 fs、subprocess、sandbox、directory-picker、bash 全都做成了可替换的能力缝（能力缝的架构决策见官方 ADR 0009）。抽象缝是 @deepseek-ai/dsh-fs，而 dsh-fs-local 只是它的一个实现。所以 dsh-for-wsl 的做法就是在预设里把 dsh-fs-local 一行换成自己的 fs——官方没有 WSL 一等支持，但架构上预留了位置。

选 B 方案前要知道三个真实回退，这几条是作者自己在 README 里列出来的：

  • WSL 会话里 grep 与 glob 工具不可用，因为工具链打包的是 Windows 版 rg.exe，在发行版里根本跑不了，模型只能退回 bash 的 grep / find；
  • 终端走 PTY 桥，stdio.control 这条文件描述符通道明确不支持；
  • mount namespace 约束覆盖不到 /dev、/proc、/sys，所以沙箱档位如实报 partial 而不是 full。

另外它要求发行版内有 bash、python3 和 NOPASSWD sudo，而且每个 minor 版本对应一个桌面大版本——桌面升级后要先跑作者提供的验证脚本，全绿才能继续用。

Web 方案下的侧边栏文件编辑

有，而且 web 才是主场。证据很硬：dsh-better-sidebar 的 package.json 里明写 dsh.client.platform 为 web——DSH 的客户端插件平台本身就是 web，侧栏这类 UI 插件天然是 web 插件。唯一 desktop 独占的是它外链接管里的浏览器 tab，与文件编辑无关。

WSL 场景下，web 路线还要再分两种：

路线 B′：harness 在 Windows，把 provider 换进发行版路线 C′：整个 dsh web 跑在 WSL 里
代表插件dsh-plugin-wsl-env（2,785 次 / 月）、dsh-wsl-workspace（4,304 次 / 月）dsh-web-tray、dsh-wsl-launcher
侧栏文件树由谁服务由发行版内的组件提供本来就是 Linux 原生 harness
文件语义真 ext4，原生 symlink 与 mode bits全原生，零 9P
代价需要发行版内装 bubblewrap，否则命令沙箱 fail-closed 直接拒绝执行要往 WSL 里再装一份 dsh

dsh-plugin-wsl-env 的设计值得单独提一句：它已经明确废弃了走 9P 的历史选项，读写一律走发行版内的常驻进程，落在 ext4 上。它的环境是会话的属性而不是进程的属性——同一个进程里，Windows 文件夹的会话照旧用宿主 provider，发行版文件夹的会话自动切到 WSL provider，两者并存。

在 WSL 里装插件：一个 pnpm 版本坑

这条是本次实测最有价值的部分。在 WSL 里执行安装命令：

dsh plugin --profile web add dsh-better-sidebar@latest

会直接失败：

ERR_PNPM_ADDING_TO_ROOT  Running this command will add the dependency to the workspace root...

不是 dsh 的 bug，也不是插件的问题，是 pnpm 版本。

ERR_PNPM_ADDING_TO_ROOT 的根因是 pnpm 版本边界

pnpm 源码里这个守卫的触发条件是：

!opts.recursive
  && opts.workspaceDir === opts.dir
  && !opts.ignoreWorkspaceRootCheck
  && !opts.workspaceRoot
  && opts.workspacePackagePatterns.length > 1

最后那行「单包 workspace 豁免」是 pnpm 10.5.0 才加进去的。而 dsh 初始化 profile 时写的 workspace 文件是：

packages:
  - .

nodeLinker: hoisted
autoInstallPeers: false

包模式只有一个 .，长度正好是 1。于是 pnpm 10.5.0 之前一律拒绝，之后一律放行。

逐版本实测的结果：

pnpm 版本结果
9.15.9报错，与上述一字不差
10.3.0报错，与上述一字不差
10.4.1报错
10.5.0通过
10.34.6 / 11.7.0 / 12.10.1通过

修复有两条路，第一条立刻可用：

dsh plugin --profile web add dsh-better-sidebar@latest -w

-w 就是报错信息里建议的 —workspace-root。它安全，因为 dsh 的参数解析对它无感：预检用 namedSpecs() 取包名时会过滤掉所有以 - 开头的参数，路径锚定 anchorPathSpec() 只重写 . 和 ./x 这种形态，-w 原样透传给 pnpm。装完依赖会正确落进 profile 的 dependencies。

第二条是根治：把 pnpm 升到 11.x，与 dsh 自己运行时钉的 11.7.0 对齐。顺带说明，pnpm remove 没有同类守卫，所以只有 add 需要这个参数。

还有一个连带的坑：npm i -g pnpm@11 之后版本号可能纹丝不动。 这说明 PATH 上有个更靠前的 pnpm 在赢，常见四种来源：corepack 的 shim、官方安装脚本装到 ~/.local/share/pnpm 的独立版本、npm 全局 prefix 与 PATH 不一致、以及 nvm / fnm / mise 之类的多版本管理器。用 type -a pnpm 配合 command -v pnpm 看它指向哪个文件，一眼就能认出是谁。

几条可以复用的判据

  • 插件热度只认 npm 官方下载接口。 聚合站的 star 数互相矛盾，不可比。
  • dsh plugin 管不了 desktop profile。 官方明确拒绝针对它的启动、配置导出与插件管理请求，要改用桌面版自带的那份 CLI。
  • 装插件前先让 profile 存在。 对不存在的 profile 直接执行 dsh plugin add，会初始化出一个 base 系而非 web 系的 profile，路径就歪了。
  • WSL 里的 $DSH_HOME 与 Windows 完全独立。 两边各有一份 ~/.dsh，互不干扰，可以并存。
  • 官方不会自动修复被改过的 profile 文件。 初始化逻辑对已存在的文件一律跳过，所以排障时值得直接 cat 一眼 workspace 文件。

参考链接

打开原图 ↗