把插件目录搬进 dsh：严选插件库的架构取舍
在 DeepSeek Harness（下文简称 dsh）里找插件，长期是一件尴尬的事：你知道自己要装什么能力，却不知道去哪儿翻。严选插件库（仓库 zhanghao3693/dsh-dpharness，版本 0.4.2，MIT 许可）做的就是这一层——它不生产插件，而是把 dpharness.com 的 dsh 插件目录搬进 dsh 界面，让你在会话里搜索并一键安装。需要先讲清楚：这是本站作者自己维护的插件，GitHub Star 目前是 1，属于早期项目；本文只拆解它的设计，不做推荐排名。
把它当成「目录客户端」而不是「安装器」来看，几乎每个决策都能解释通。它的核心矛盾是：目录数据在远端，安装动作在本地，而本地环境高度不确定——有没有装 dshmarket、此刻有没有 agent 在跑、Node 与 dsh 是什么版本，都不由它决定。下面按这个矛盾逐层拆。
两个视图：全量目录与月度策展回答的不是同一个问题
面板顶部只有两个视图，定位刻意不重叠。
「严选推荐」接全量目录接口，支持搜索、可按 Star 排序。它服务的是「我知道我要什么，帮我找到它」——输入关键词，直接装。数据是全集，所以结果规模与耗时都由查询参数控制。
「分类精选」接的是月度策展数据，与站点 /best 页同源：按大类到小类分组，每个小类只留 2~3 个，并刻意保留两项元数据——小类内名次和上榜理由，例如「小类第 1 · 实装验证通过 · 周下载 12.8 万」。它服务的是另一个问题：「我不知道该装什么，你先给我几个候选」。
两个视图共用同一套渲染组件，浮窗与页签是同一个实现。之所以不合并成一个列表加筛选项，是因为两者的结构本来就不同：一个靠排序维度，一个靠名次与理由。硬合并只会让策展数据丢掉最有价值的那部分信息。
入榜门槛也值得写下来：站点侧规则是「通过静态安装检查或 CI 实装验证 + 汉化完成」，每月 1 日重算，并且公开淘汰原因。所以分类精选不是热度榜，而是有明确准入条件的子集。
三个入口：同一套组件，三种使用节奏
插件在界面里挂了三个入口，分别对应三种节奏。
页签「严选插件」位于会话视图区，是完整版——搜索、排序、批量浏览都在这里；左下入口在侧边栏底部，只做一个触发器，点开的是全站浮窗；全站浮窗挂在右下角，跨路由常驻（含首页），用于随手查、随时装。
这三个挂载点的差别不只是位置：页签是视图级挂载，跟着会话视图走；侧边栏底部是导航级挂载，长期可见但只承担触发；浮窗是外壳级挂载，必须跨路由存活。客户端入口因此单独拆成 lib/client.js，平台声明为 web，注入列表里带上 UI 插槽、会话视图、运行时与本地化四个包——这也是它能同时挂在三类 slot 上的前提。
一键安装为什么设计成两条路径
这是全篇最值得看的一段。
路径一：优先复用 dshmarket 的同源 HTTP 路由。好处实在——免重启热挂载、可回滚、带供应链校验。代价同样明确：它只接受 dshmarket 自己那份 curated registry（awesome 目录）里的 URL。
路径二：当目标不在目录里、或本机没装 dshmarket 时，降级到插件自己的子进程，执行 dsh plugin --profile web add <包名>。代价是它改的是 profile，装完必须重启 dsh 才生效。
「优先复用、失败再降级」看着是常规写法，但这里有一条反常规的例外：dshmarket 返回 409（有 agent 正在运行）时不降级，直接报错。理由是——和正在工作的 agent 抢插件文件，风险远大于让用户多等一会儿。宁可失败得干脆，也不要引入一个难以复现的损坏状态。
安装按钮的硬门槛：只有校验通过的才显示
卡片上那个安装按钮不是谁都有。只有站点给出 installCheck 状态为 pass 的条目才会渲染它，其余条目只能看到可复制的命令。
这条规则容易被误读成「质量筛选」，其实它是身份筛选：静态安装校验没过时，npm 上的同名包可能属于别人。按钮缺席表达的是「现在按这个名字去装，装到的可能不是你以为的那个东西」，与好不好用无关。
围绕这个动作还有几处加固：安装前二次确认并展示将要执行的完整包名；包名过字符白名单；子进程环境会剥掉宿主的 safe-delete 钩子，否则 pnpm 清理临时文件时会被拦；失败时只展示 pnpm 的错误码行，例如 [ERR_PNPM_FETCH_404]，而不是几十行进度日志。最后一条对排障的价值最高——错误码是稳定的，进度日志不是。
host 侧 5 条路由：谁该缓存，谁绝对不能
host 侧只暴露 5 条路由，职责划分得很干脆：目录查询支持关键词、取数与排序参数，返回前做字段裁剪，并按「关键词 + 取数 + 排序」三元组缓存 5 分钟；埋点代理转发到站点端点；安装接口接收包名，启动子进程后立刻返回 202 与任务标识；安装进度与结果单独一条 GET，供前端轮询；元信息接口返回版本、profile、路由清单、缓存与安装状态。
缓存只用了一处，但用得克制：只有搜索是可重复的读操作，所以只有它缓存；安装与状态类接口反映的是会变的本地状态，一条都不能缓存。而安装采用「202 + 独立进度查询」而不是长阻塞请求，等于在插件内部做了一层极简作业模型——请求不背任务，任务有自己的查询入口。
埋点：为什么绕本地一圈，而且只传长度
埋点有两个不太常见的选择。
第一，事件不直接发往站点，而是先打到本地 host 再转发。原因是站点端点不带 CORS 头，浏览器侧直连会被拦；经本地转发后，失败可以静默忽略，绝不阻塞任何一次点击。
第二，不上报搜索关键词原文，只上报动作类型、关键词长度与命中数。复制或安装命令的上报口径与站点一致，copy_install 的值为整条命令，来源靠 path=/dsh-plugin 区分。也就是说，它能回答「有多少人搜了、搜了多长、搜到没有」，但回答不了「他们在搜什么」。浮窗与页签底部都提供匿名统计开关，可随时关闭。
总结
严选插件库的价值不在「装得多快」，而在于它把远端目录、本地安装与不确定环境之间的边界写清楚了：能校验身份的才给按钮，能让 dshmarket 干的就不自己干，冲突时宁可直接失败；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。它仍然是个 Star 数 1 的早期项目，读它的设计比抄它的用法更有意义。
适合与不适合
适合：想在 dsh 会话里直接搜索并安装 dpharness.com 目录内插件的人；需要按大类快速挑候选、不想自己逐个比对的人；希望失败时拿到一条明确原因（而不是一屏进度日志）的人；对插件来源身份敏感、认可「校验未过就不给安装按钮」这条底线的人。
不适合：已经知道确切包名、不在意图形界面的用户，直接敲命令更省事；环境较旧且不想先确认版本的——本包 package.json 并未声明 engines，装到过旧的 Node 或 dsh 上不会得到明确的不兼容提示；以及期望装完立刻生效的人，本地降级路径必须重启 dsh，等不了这一下就别走这条路径。
标签：严选插件库、DeepSeek Harness、插件目录客户端、架构设计、dsh 插件
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页；本插件由本站作者维护。