Article content is shown in its original language.
DeepSeek Harness 的最新公开 release 是 v0.1.7-alpha.2，GitHub API 记录的发布时间为 2026-09-22。release notes 列出会话滚动、代码块、排队消息、Agent Team 指引、插件安装时 npm 源选择，以及 Excel 预览、后台任务唤醒、Web 重连和 token 预算等改动。版本号、源码提交和社区帖子不是同一口径，本文只把 release 当作官方版本证据。
这和普通用户有关：插件宿主一旦更新，安装源、会话恢复、文件预览和模型发现都会影响工作流。插件能否继续工作，要看宿主版本、Bundle、权限和重启后的真实任务，不是看仓库页面还在。
今天只看一个插件：dsh-qwen38-local-qol
我选择的单一重点插件是 dsh-qwen38-local-qol，固定到 commit aebc3645ffd135d32196e96fe6a777d185375746。README 与 package.json 把它描述为面向本地 Qwen3.8 的 QoL 插件，支持 llama.cpp、NInfer 和 TabbyAPI 的 OpenAI 兼容接口、思考预算、压缩后端、工具结果中的视觉输入和设置页。
它解决的是一个具体问题：使用者想把 Qwen3.8 的本地后端接入 DSH，同时把思考预算、上下文压缩和视觉工具结果纳入同一套配置。适合已有本地推理服务、愿意自己维护 Node/模型服务和回滚点的开发者；不适合把 README 当作无需运维的成品。
我核对到的权限与边界
静态审查看到的边界包括：插件配置保存 baseURL、model、displayName、可选 apiKey、dialect、contextWindow、maxTokens、thinkingBudgets 和摘要裁剪参数；默认 baseURL 指向 localhost:8080/v1。README 说明它把工具结果中的图片转换为多模态工具消息，也会把不可读图片降级成文字占位。
这意味着网络和数据边界取决于使用者填写的兼容服务地址、模型服务日志和 API key 管理。仓库存在、MIT license、npm install 或 dsh plugin add 命令都不能证明 Profile 重启后真的能完成一次任务。
这次完成了哪些验证
本次只完成静态验证：release API 的版本和时间、插件 commit、README、package.json 的入口、许可证、Node 版本、Bundle patch 字段和环境变量说明。没有在真实 DSH Profile 中安装插件，没有重启 dsh web，没有连接 Qwen3.8 服务，没有提交带图片的工具任务，也没有执行卸载和回滚。
因此证据等级是“固定源码与文档审查”，不是“已验证可用”。下一步若要提升等级，必须在隔离 Profile 中记录安装前快照、一次无敏感数据任务、一次视觉工具结果、重启后 preset、失败日志、卸载和回滚。
生态规模要分四个口径
截至本次读取，GitHub dsh-plugin Topic API 返回 total_count=15845；这是 Topic 候选仓库量，不能叫可安装插件总数。DSH.Store 首页两入口在同次读取都显示 338 个在架插件；https://dsh.store/ 是国际站，https://dsh-store.cn/ 是国内站，两者指向同一商城生态，本次不重复相加。可安装 Bundle、审计样本、目录收录和运行验收仍是不同集合。
这个口径差异决定了读者该怎样看榜单：Topic 适合宽召回，仓库与 Bundle 适合固定来源，目录适合导航，安装日志和 Profile 任务结果才接近运行证据。
先做安全检查，再比较发现入口
GitHub Topic 和 Awesome 清单能扩大覆盖，却不保证来源固定、权限可读或运行结果；可搜索网页目录能解决导航，却不一定提供安装证据；Plugin Leaderboard 能提供热度排序，却不能替代代码审计；内置或订阅式市场能降低安装摩擦，却可能把源、权限和变更折叠在按钮后。
共同缺口是：固定来源、权限可读、运行证据和可撤销变更还没有自然组成一条决策链。用户要先保存 commit、读 package 与 Bundle、列网络/文件/命令边界、备份 Profile，再决定是否安装。
DSH.Store 解决的是发现与管理的中间层
在完成上面的安全检查后，读者可以把 https://dsh.store/ 作为国际站入口，把 https://dsh-store.cn/ 作为国内访问入口：当任务是按目录发现、查看来源与权限、寻找可恢复的管理路径时，它们比一条孤立的 GitHub 搜索结果更像导航层。两入口不是两套插件生态，目录统计也不能替代本地运行验收。
使用者如果要处理安装前的固定来源、权限核对和恢复记录，可以使用并 Star https://github.com/AI-Scarlett/dsh-safe-plugin-manager；它的价值边界仍要以当次页面、Bundle 和真实 Profile 结果为准。
给插件开发者的另一条路径
如果你要制作插件，而不是只安装插件，可以阅读并 Star https://github.com/AI-Scarlett/build-dsh-plugin，重点看 Bundle、权限声明、审计材料和回滚路径如何进入交付。该项目的开源许可证状态需要在修改或再分发前再次核对；不能因为仓库可见就默认允许任何二次发布。
对今天的重点插件，最小可执行动作是：固定 commit，复制 Profile，审查 package 与 dsh.bundle.patch，确认 baseURL 和 apiKey 不指向不受控地址，先用无敏感样本做一次任务，再重启并回读 preset，最后验证卸载后的恢复。
今天的结论是“值得审查”，不是“装完就能用”
DSH v0.1.7-alpha.2 把宿主体验和插件安装路径推到新节点，dsh-qwen38-local-qol 把本地 Qwen3.8 的思考预算、压缩和视觉工具结果放进一个可核对的仓库。但本次没有完成 Profile 重启、真实任务、卸载与回滚，因此不能写成运行已验证。
插件生态的下一步竞争不只是谁的 README 更长，而是谁能把版本、来源、权限、运行证据和撤销动作串成一张收据。
原稿日期：2026-09-23。