夜雨聆风DeepSeek Harness（dsh）发布快一周了，作为以“万物皆插件”为设计哲学的 deepseek 专武，连用法都要用户深度求索，自由度和可定制化程度高到离谱，不过目前它依然没有官方插件市场。这时候就轮到开源社区发挥威力了，模型能力没有充分发挥？社区开发！没有插件市场？社区开发！
到今天（8 月 19 号），社区至少有八十来个项目来尝试解决这个问题。
* 数据为在 GitHub 上进行关键词匹配搜索获得，清单获取时间为 8 月 19 日上午。
爬完相关项目，可以发现挂着“插件市场”名号的项目主要分为这三类：
市场：能在 dsh 界面里浏览，点一下它帮人装好。搜出 39 个项目，实际能装的有 32 个。
目录：只做发现和展示。用户（或者 agent）看中一个，自己复制并执行安装指令。31 个项目（另有 3 个只有网站、找不到公开仓库）。
管理器：管用户已经装好的插件——开关、配置、卸载、调加载顺序，不负责帮人找新的。9 个。
星数分布如下：
而 32 个市场插件项目里，一半不到 6 星。
目前 Star 数最多的是 awesome-dsh-plugin/awesome-dsh-plugin，这是一个目录类项目。
收录了 1.5k 左右个项目，star 数飞涨，早上看还是 9k 左右，现在（18:40）已经是 9.7k，占了目录类项目的 star 数大头，而且已经有其他市场类插件引用它作为数据源，如 dsh-subscribe、Sanqi-normal 等。
同作者 @fkysly 的市场插件dsh-market/dsh-market star 的star 数上升也很快，上午看是 1k 左右，现在是 1.2k。可以说这个作者的项目收获了大部分的 star。
75% 的项目只有 1 个贡献者，AI 时代，软件的开发与实现真的非常非常快，生产力可以说是过剩的，发现需求、占领心智可能在 AI 时代更加重要。
* 贡献者这一栏，因目录类项目多数靠 PR 收录，每个来提交自己插件的人都会算成一个贡献者，排在前面那几个插件清单项目动辄九十几个人，所以目录类项目大部分贡献者应该大于 1 人。市场类项目没有这种机制。
39 个扫出来的“市场插件”里，
叫 dsh-plugin-marketplace的有 5 个，
叫 dsh-plugin-market的也有 5 个，
dsh-plugin-store3 个，
dsh-market、dsh-plugin-hub、dsh-plugins-store各 2 个。
把连字符和单复数归一化之后，12 个项目挤在同一个名字上。npm 包名也开始撞了。
另外有 29 个仓库的名字是 awesome-dsh-plugin的各种变体。
还有一个包把自己的名字写成了 @deepseek-ai/开头。这个 scope 归 DeepSeek 所有，所以它发不到 npm，但用 GitHub 地址安装照样能进去——装完之后它就躺在官方包的目录里，从名字上看不出是第三方。
一个“市场”主要做这三层工作：
索引：插件名单从哪来。
安装：怎么把包弄到你机器上。
管理：安装后的各种管理，如报错处理、卸载等。
打开任何一个市场或目录，首页都会告诉你收录了多少插件，而且口径大不相同：三千九、四千七、两千五，五花八门。
那么差异在哪？主要是各个目录收录的标准不同。
有的比如星数最高的那份清单，它的收录规则是：提一个 PR，加一个 YAML 文件，填上仓库地址、名字、分类、一句英文描述。现在收了 1494 条。
一个插件一个文件所以 PR 不会互相撞，README 由脚本生成，还有定时任务扫失效链接。它数的是“有多少人交了 YAML”。
有的目录已帮人做检测。
另一份榜单 AdamPlatin123/awesome-dsh-plugins，1238 星，做了很实在的事：把插件一个一个丢进容器里，真的装一遍，看能不能跑起来。
它的测的项目数据是这样的（截止 8 月 19 日下午）：
1673 个装机项目测试的基准是 star 数，它有一道 star 数门槛，够星的才进测试池（少数功能稀缺的类别可以豁免）。所以 979 比 1673 这个通过率，是“星数比较高的那批”的成绩，不能拿去推算全部 9247 个。剩下七千多个低星的还没有人测过。
首先说明 dsh 装插件的两步走：
第一步，把包下载到 profile 目录的 node_modules里。
第二步，把包名写进一份名单——dsh 启动时按这份名单加载插件。
只做第一步，包躺在磁盘上，dsh 不看它，等于没装。只做第二步，名单里有而文件不在，dsh 启动时找不到，整棵插件树加载失败，起不来。
▲ dsh 装插件的两步，以及第二步的两个登记处
麻烦在于第二步登记有两个地方：一个是 profile 的 package.json里一份叫 dsh.profile.bundles的包名清单，官方文档说它“从不需要手写，由 dsh plugin命令维护”；另一个是同目录下的 cordis.patch.yml，那是留给用户自己改的配置层。官方的插件安装命令只动第一个（dsh.profile.bundles）。而自己实现安装的那些市场，有的动第一个，有的动第二个（cordis.patch.yml），有的两个都动。
所以第一个分岔就是：这两步交给官方，还是自己动手？
32 个市场插件的选择如下：
调官方的那 16 家，自己只做界面和目录，真装的时候起一个子进程去跑官方命令。好处是官方以后怎么改，它们都跟得上。不过是要求你机器上有 pnpm（官方命令要求的包）。
自己实现的那 12 家，自己跑包管理器、自己复制文件、自己往名单里写条目。好处很实际：不需要 pnpm，装机门槛最低。代价是把官方的目录结构和文件格式抄进了自己代码里，官方大更新以后可能报错。
混合的 4 家是在官方管不到的地方补一手——比如目标插件没按官方格式声明自己，官方命令装完不会激活它，市场就自己补一行。
这 16 家里还有一个特别的：它不起任何子进程，而是把安装命令排进你当前的 agent 会话，让模型自己去执行。充分用上了“宿主本身就是个 agent”这个很有趣的事情——反过来说，装插件也要花钱 (◐‿◑)
放需要编译的源码可能影响插件安装。
有些插件在 GitHub 上放的是源码，装的时候要先编译。编译靠包里的一段脚本自动跑，安装插件需要的 pnpm 包从第 10 版起默认不信任这类脚本——因为它能在机器上执行任意代码。所以第一次装会失败，pnpm 要求用户去配置文件里手动写上“我允许这个包跑脚本”，再装一次。至少四家市场把这一步自动化了。往好里说是省掉一次失败重试，也可以说它们替用户写了那句“我允许”。
比较头部的插件市场已经不只是浏览、安装插件的页面，通常还有比较好的安装状态和卸载管理功能，比如区分：已安装、已安装但没生效、已安装但校验没过、装了要重启才生效。它还会在你点安装之前先看一眼这插件是不是命令行用的——如果是，它会拦一下，告诉你装进网页版可能没用，甚至会导致启动失败。装的过程里，pnpm 内部走到哪一步、下了多少字节，都透传到界面上。装坏了它有个诊断面板，检查插件之间有没有冲突、加载顺序对不对，然后生成一段话让你交给 agent 去修。
在 dsh 官方 GitHub 下面的 discussion 里，至少有三起用户报告，都是装完插件之后 dsh 起不来。
第一起
某个市场往配置文件里追加内容时，写出了非法的 YAML。那个文件的默认内容是一个空数组 []，在它后面直接追加新条目，语法上是冲突的。用户升级完开机就报错。这起已经修了，作者把成因和恢复方法都写在了更新日志里——手动删掉文件里单独那行 []就能起来。
第二起
某个安装流程在 dsh 自己的安装目录里跑了 npm。npm 会把它认为多余的包删掉，而 dsh 有一批核心包是运行时注入的、没写在依赖清单里，于是被当成垃圾清掉了，结果 dsh 找不到自己的模块。这起的触发方到现在没查清楚——官方那条命令走的是 pnpm，而且在另一个目录里执行，不会碰到全局安装。
第三起
插件被写进了加载清单，但那个包的入口文件根本不存在。就是前面说的“只做了第二步”。
另外还有一家，界面上显示的是官方命令，点下去实际跑的是别的，而且全程不往加载清单里写东西——包装到了磁盘上，但 dsh 不知道要加载它。用户虽然看到安装成功，但是实际上不能加载。
所以装插件之前，把 profile 目录下这两个文件都备份一下：
前者是官方命令维护的插件清单，后者是你自己的配置层——不同的市场往不同的地方写，所以两个都要留。
装完先别关终端，另开一个窗口跑一次 dsh web，确认能起来再走。真出问题的时候，把这两个文件还原回去，多半就能启动。