几千个插件,为什么 DSH-Store 只让两百多个进场,DSH插件正在破坏你的DSH

DeepSeek Harness 的插件生态正在以一种典型的开源速度膨胀：先有仓库，再有清单；先有清单，再有商城；商城之后，又会出现聚合站、推荐榜和“一键安装”。截至这次核验，Awesome DSH Plugin 的机器目录已经列出 1411 个条目。把多个站点、GitHub Topic、合集仓库和子目录索引叠在一起，原始记录很容易达到数千条。

这些候选并不是我凭空搜索出来的。发现阶段，我先从多个社区较知名的公开 GitHub 目录和插件商城仓库中取得候选清单并交叉核对，主要包括 awesome-dsh-plugin/awesome-dsh-plugin、dsh-market/dsh-market、Sanqi-normal/dsh-webui-market-plugin，以及采用固定目录与 GitHub Topic 采集思路的 hrhgit/deepseek-harness-plugin-manager。随后按仓库规范地址、包名、子目录和插件入口合并去重，再送进 DSH-Store 的准入审查。

为了避免把多个目录中的重复记录相加后制造一个虚高数字，我把 Awesome DSH Plugin 的固定机器快照作为第一轮 1411 条审核清单的统计基线；其他商城与目录用于交叉发现、补充来源线索和验证目录关系。换句话说，它们负责扩大“看见什么”的范围，但不会因为某个项目已经出现在知名商城，就自动获得 DSH-Store 的安全背书。

但“记录数”不是“独立插件数”，“能搜到”也不是“能安装”。同一个仓库可能在多个目录重复出现，一个仓库也可能包含多个子插件；搜索结果里还混有桌面应用、插件合集、基础设施、教程、失效仓库，以及只有 DSH 关键词、没有标准 DSH Bundle 契约的项目。

DSH-Store 的公开目录在本轮收口后共有 253 个条目。其中 248 个进入受保护的安装路径，5 个仍可被发现，但商城明确拒绝为其生成受保护安装计划。这个数字不是“我们只找到这些”，而是“截至这个固定快照，只有这些项目达到了对应状态的证据门槛”。

这也是 DSH-Store 与“把全网链接装进搜索框”的根本差别：后者优化的是发现效率，前者要回答的是另一个问题——这段代码凭什么获得进入用户 Agent 环境的机会？

普通内容平台收录一篇文章，最坏结果通常是信息错误、版权争议或低质量体验。Agent 插件不同。它可能跟随宿主进程启动，读取 Profile 和文件，向外部服务发起网络请求，调用命令，接触 API Key，修改工具列表，甚至影响下一次冷启动。

Node.js 的官方文档明确列出，preinstall、install、postinstall、prepare 等生命周期脚本会在不同安装路径中执行；Git 依赖如果带有 prepare，还会先安装依赖和开发依赖，再运行脚本。也就是说，“点一下安装”不是把几份静态文件放进目录，而可能是在本机触发一串有环境权限的程序。

开源提供了可检查性，却不会自动产生安全。代码公开，不等于有人看过；有人看过，不等于看的是今天准备安装的那个 Commit；仓库有很多 Star，不等于安装脚本、权限边界和回滚路径已经被验证。许可证解决的是使用与再分发授权，也不负责证明代码没有恶意逻辑。

NIST 对开源供应链的建议强调完整性、来源和可信获取渠道，也提出把经过批准、审核的开源组件放入受控仓库，在进入开发环境前进行收集与扫描。OpenSSF Scorecard 的定位同样是帮助使用者评估并决定是否接受风险，而不是给项目颁发一张“绝对安全证书”。

因此，DSH-Store 把每个插件当成一份权限申请，而不是一张商品卡。申请要回答：你是谁，来自哪里，要改什么，需要什么权限，失败后如何退出，我们能拿什么证据证明这些说法。

三道安全闸分别位于三个不同时间点。

第一层在开发期，解决“插件从一开始应当怎样被造出来”；第二层在上架期，解决“当前这个不可变版本是否满足商城契约”；第三层在用户本机，解决“这个版本在这个 Profile、这个时刻、这台机器上能否被安全地执行”。

它们面对的故障也不同。开发层防止错误架构和越权设计；上架层防止身份漂移、来源不明和元数据失真；本地层防止环境变化、并发修改、安装中断和冷启动失败。少任何一层，前一层留下的盲区都会在下一阶段放大。

这叫纵深防御。不是相信某一道门永远不会失手，而是假设任何单点判断都有可能不完整，于是让不同机制在不同生命周期相互校验。

第一道门由 build-dsh-plugin 开发 Skill 承担。它的意义不是替开发者多写一份规范，而是把安全边界变成生成代码、选择架构和验收时不可跳过的条件。

第一步不是写代码，而是证明宿主适配。一个 Obsidian 插件、浏览器扩展、桌面应用或独立 MCP 服务，功能上可能与 DSH 插件相似，却不因此具备 DSH Bundle 契约。只有能够通过标准 dsh.bundle.patch、包内 Patch、唯一入口 ID 和公开 Host 服务组合进 DSH 的项目，才会进入直接开发路径；否则只能走适配器，或被判定不兼容。

第二步是风险分级。只读元数据和界面投影属于 R0；使用 Host 服务或插件自有状态可能进入 R1；外部进程、网络、凭据、设备桥接属于 R2；Profile 生命周期、重启、远程控制和广泛管理属于 R3。风险越高，需要的负面测试、故障注入、真实环境确认和恢复证据越多。

第三步是硬边界。插件不能修改 DSH 源码或 @deepseek-ai/* 官方包，不能停用、替换或遮蔽官方插件清单，不能调用 Loader/Fiber 内部变更接口；浏览器 Client 不能导入 Node、Host 模块或得到完整 Profile 和凭据。包操作必须由官方 DSH CLI 用固定参数数组执行，不能拼接 Shell 字符串。

第四步是最小权限和证据阶梯。每项文件、网络、命令或凭据能力都要对应一个用户结果和一个可复核测试；没有用途和测试的权限应当被删除。E1 的源码审查、E2 的自动化测试、E3 的一次性 Profile 运行、E4 的真实 Profile 验收和 E5 的外部/设备/恢复证明不能相互冒充。

这里必须说明一个边界：第三方插件未必真的使用过这个 Skill 开发。对于外部项目，DSH-Store 只能把同一套契约作为回溯审查标准，不能把“符合部分结构”说成“从出生起就受控”。第一层对自研和新建插件是开发约束；对外部插件是兼容性与边界复核。

第二道门由 publish-dsh-plugin 上架 Skill 承担。它把上架拆成 inspect → prepare → submit → verify，并坚持把源码发布、Catalog PR、Catalog 合并、商城页面出现和真实 Profile 安装视为五件不同的事。

一个项目想进入 approved，首先要有公开、可验证的 GitHub 来源，并固定到完整的 40 位 Commit。商城不安装浮动的 main，因为同一个链接明天可能指向另一段代码。固定 Commit 也不是安全证明，它只解决“我们审的是不是将要装的那一份”这一前提。

随后要把 manifest、包名、版本、许可证、dsh.bundle.patch、实际 Patch、入口 ID、安装路径和生命周期脚本逐项对齐。Catalog 声明“没有安装脚本”，而固定 Commit 里出现 prepare，不是小疏漏，而是供应链身份不一致；入口 ID 与受保护组件冲突，可能直接导致冷启动失败或遮蔽官方能力。

权限、外部依赖和兼容性不能靠搜索不到就填“无”。没有证据时必须保持 unknown、unverified，必要时进入 blocked。Stars、截图、README 自述、作者知名度和“官方同款”措辞都不能替代安装契约。

上架层还会给更新分流。没有文件、网络、命令、凭据或安装生命周期能力的低风险插件，才有资格进入 source-verified 普通固定源更新路径；拥有更高能力但来源合法、契约完整的项目进入 user-reviewed，每次更新都要展示变化并由用户单独确认；修改 DSH 原生代码、冒用受保护命名空间或干预官方组件的项目只能走 external-only 或被阻断。来源关系、版本、Patch 或入口无法验证时则是 update-blocked，用户点击“我愿意承担风险”也不能绕过身份失败。

最终，只有 Registry 校验、固定来源回读、合并后的远端 Catalog 和公开商城页面都匹配，才能说“已上架”。一个本地 JSON 候选、一次测试通过或一个尚未合并的 PR，都不能提前领取这个结论。

第一轮是全量目录审核。固定清单共有 1411 条记录，归并后对应 1365 个独立仓库。它们依次经过来源同源、安装结构、npm 源码边界、GitHub 固定 Commit 与入口冲突检查：492 项进入 npm 同源核验，335 项通过结构门，230 项通过 npm 源码边界，192 项通过固定 Commit 审查，最终只有 186 个新增插件进入目录。商城由 48 项增至 234 项。

其余 1225 条没有上架：其中 919 条没有同源 npm 或未进入结构审查，157 条缺少可接受的固定 Commit、安装契约或网络证据，105 条未通过 npm 源码边界，38 条未通过 GitHub 固定源码边界，另有 5 个入口冲突和 1 个入口 ID 不符合 schema。这里的“不上架”是证据和契约结论，不等于给项目贴上“恶意”标签。

第一轮合并后，234/234 个固定 GitHub 源全部 SOURCE_OK，npm run check 为 82/82。批量扩容也没有稀释推荐位：推荐列表仍保持 DSH-Store、DSH WeCom CLI、Build DSH Plugin、DSH 插件开发工作流。

第二轮才是这次 99 个地址的追加审核：共处理 99 个 GitHub 地址，其中 19 个此前已经收录，61 个不予收录，最终新增上架 19 个，目录因此由 234 项增至 253 项。拒绝原因包括缺少 manifest 或许可证、来源声明不匹配、入口冲突、安装产物缺失、修改 Profile、停用官方组件等。第二轮结束后，253/253 个固定来源通过回读，npm run check 为 85/85。

能通过清单和许可证检查仍不等于上架。复核会继续读取固定 Commit 的实际源码和 Patch，检查 Profile 写入、Loader/Fiber 调用、动态执行、命令与网络边界、生命周期脚本和可复现安装条件。第二轮新增的 19 个条目全部被标为高权限 user-reviewed，不会获得静默安装资格。两轮数据分别描述全量目录审核和追加地址审核，不能混成一个“全生态安全通过率”。

这个漏斗说明两件事。第一，大量“插件”在安全问题之前就已经败在身份和工程契约上：它可能有功能，却没有可复现的 DSH 安装边界。第二，通过不等于低风险。高权限项目可以是合法、有价值的插件，但必须让权限和变化保持可见，把最后决定留给用户。

没有通过也不等于项目“有毒”。blocked、待补资料、adapter-required 和“非 DSH 插件”描述的是证据与兼容状态，不是对作者动机的指控。严谨的商城既不能把不确定性包装成安全，也不该把证据不足写成恶意判决。

前两层面对的是源码与目录，第三层面对的是用户的现实：本机 Profile 可能已经安装了其他插件，Patch 顺序可能发生变化，本地来源可能漂移，五分钟前生成的计划也可能因另一个进程写文件而过期。

因此，DSH Safe Plugin Manager 在安装、更新、迁移、启停或卸载前，会重新读取在线 Catalog，并再次核对固定 Commit 下的 manifest、版本、许可证、Bundle Patch、入口 ID 与生命周期脚本。官方包、官方清单和关键入口永久只读；目录中的 blocked 项不会因为在本机被搜到，就突然获得受保护安装按钮。

真正的写操作必须先生成一份短时有效、单次使用的 typed plan。计划列出目标 Profile、固定来源、当前与目标版本、可能修改的文件、安装脚本、重启要求和一条精确确认语。用户输入不匹配、计划过期、被使用过一次，都会失效。

执行前，商城会计算 Profile 关键文件的哈希并获取文件锁。如果计划生成后 package.json、锁文件、workspace 或 Patch 被别人改过，操作直接停止；不会用旧授权覆盖新状态。随后创建备份，通过官方 DSH CLI 的固定 argv 执行包操作，不使用 bash -c 或拼接命令。

安装结束还不是成功。商城继续检查 Profile 清单、依赖解析、托管 Patch、配置合成和冷启动入口冲突。健康检查失败则恢复备份，并尝试让依赖回到操作前状态。需要重启时，由进程外 Guardian 接管有界启动、心跳、稳定观察、失败次数和熔断；Host 不能在关闭自己之后假装仍能完成救援。

权限页面也刻意不输出一个轻率的 pass。目录内第三方插件的文件、网络、命令和凭据能力需要逐项允许或拒绝；目录外插件缺少权限声明时，必须由用户明确决定是否接受未知。这个选择只改变个人审核结论，不会神奇地给插件加上系统级沙箱。真正的权限隔离仍取决于宿主与操作系统能力。

第一，失败关闭。来源、路径、官方组件、权限或状态不清楚时，默认停止，而不是猜一个最方便的答案。

第二，不可变身份。Catalog、源码、版本和安装目标必须指向同一个固定 Commit，避免今天审核、明天换货。

第三，最小权限。能力必须与用户结果一一对应；“以后可能用到”不是申请文件、网络、命令或凭据权限的理由。

第四，证据不越级。源码扫描不能冒充运行时，安装成功不能冒充界面可用，HTTP 200 不能冒充业务正确，公开上架也不能冒充真实 Profile 已安装。

第五，可逆优先。高风险变更必须有哈希、锁、备份、健康检查和回滚。不能恢复的便利功能，不应轻易进入用户状态。

第六，用户保留决定权。商城负责把来源、权限、脚本、依赖、变化和失败边界说明白；对于身份可验证但权限较高的合法插件，最终是否接受由用户逐次决定。

它能显著降低错误宿主、核心修改、官方组件遮蔽、浮动来源、身份不一致、隐藏生命周期脚本、入口冲突、并发覆盖和安装失败造成的风险。它能让一次决定绑定到明确版本、明确 Profile 和明确时间点，也能让失败更容易恢复。

但它不能证明插件没有任何未知漏洞，不能证明维护者未来不会变更方向，不能证明外部服务永远可信，也不能证明高权限代码在所有输入下都不会滥用能力。自动扫描会有误报和漏报，人工检查会受证据和时间限制，本地健康检查也只能证明已经执行的结构与事务检查，没有独立业务探针时，插件功能仍应显示“未验证”。

所以 DSH-Store 不把“通过”写成终身认证。审查结论只对固定 Commit 和当时证据负责；版本、依赖、DSH 契约、权限或安装路径变化，都可能让旧证据失效。真正可信的开源治理，不是声称零风险，而是让风险可见、变化可追踪、失败可停止、状态可恢复。

开源 Agent 的繁荣离不开低门槛。任何人都能写插件、分享插件、改进插件，生态才会出现长尾创新。但低门槛创作不等于低门槛获得执行权。越是开放的生态，越需要在“任何人都能贡献”和“任何代码都能进入用户环境”之间建立清晰边界。

很多商城用数量证明繁荣，这并没有错。发现层本来就应该尽可能广。但如果发现、审核和安装被压成同一个“一键”，用户看到的丰富度就可能变成维护者无法承担的信任承诺。

DSH-Store 选择的是一条更慢的路：让开发 Skill 先约束出生条件，让上架 Skill 再复核不可变身份与商城契约，让本地插件商城在安装时重新检查环境并执行可回滚事务。它会错过一些暂时无法证明的好项目，也会增加开发者和用户的摩擦，但这种摩擦本身就是安全成本。

插件商城最终售卖的不是插件，而是信任的组织方式。数量可以快速复制，信任只能用明确边界、可复核证据和一次次不越权的操作慢慢积累。

DSH-Store 已开放：https://dsh.store/。

插件目录：https://dsh.store/plugins/。

安全开发 Skill 与使用入口：https://dsh.store/build/。

项目源码：https://github.com/AI-Scarlett/dsh-safe-plugin-manager。

本文作者参与 DSH-Store、DSH Safe Plugin Manager 及相关安全 Skill 的开发与维护。推荐它，不是要求你跳过审查，而是邀请你查看源码、核对固定 Commit、阅读权限与状态，并用同样严格的标准检验这套机制本身。