插件审计
我们如何审计每一个插件
目录的可信度，取决于它最薄弱的那一条。dshbase 上架的每个插件，发布前都要过三道独立审计，每条都带明确的验证状态——让你始终清楚什么已实测、什么还在待验证。
1,770 插件
15 分类
1,764 仓库
1,420 已验证
350 待验证
1,287 MIT 协议
数据截至 2026-08-16 · 每次构建时从插件数据集实时重算。
上架前的三道审计
我们不是抓个列表就发布。每条在进入目录之前，都要按三条标准核对。
1 · 来源审计
每条都必须对应一个真实、可访问的 GitHub 仓库。改名、删除或不可达的仓库会被移除——目录里不留死链。
2 · 生态归属审计
插件必须真正属于 DeepSeek Harness 生态。我们核对 DSH 专属清单（cordis.patch.yml、dsh.bundle 等根级标记）与对 DSH 的明确依赖，而不是只看仓库名或 topic 标签。只借标签、名不符实的仓库会被剔除。
3 · 元数据审计
license、star/forks/issues、最近更新时间、语言、archived 状态逐条记录，直接展示在每张插件卡片上。
我们如何验证
审计回答「它该不该在这里」，验证回答「它到底能不能跑」。
- 安装验证（
verified/pending）——最关键的证据。已验证指我们在干净 profile 里实测安装并成功启动；待验证指按仓库收录、尚未实测。两者绝不混为一谈，每张卡片都明确标注属于哪一种。 - 信任分级（
Silver/Bronze/Unrated）——一个简明的信心信号，是安装验证的补充。分级是起点，不是定论。 - 热度不等于背书——star、fork、issue 数取自 GitHub，只作热度参考。
全量验证报告 — 2026 年 8 月
2026 年 8 月，我们把所有待验证插件在干净、隔离的 profile 里做了一次完整的三阶段实测。以下是结果。
方法
- L1 · 安装 —— 插件在干净 profile 里，与固定版本的 DSH 运行时一起安装。
- L2 · 加载 —— profile 成功启动并导出配置。
- L3 · 运行 —— 载入插件后跑一句 headless 问答；必须干净退出并返回预期答案。
范围
923 个待验证条目 —— 878 个 GitHub 仓库 + 45 个 npm 包。
结果
551 通过
198 运行失败
164 安装失败
10 加载失败
其余为何未通过
每条失败都从其安装日志归类。以下数字按去重后的唯一插件统计。
安装失败（159）
- 68 —— 声明的依赖版本在 registry 上不存在
- 63 —— 构建 / prepare 脚本失败（常因依赖了未发布的 @deepseek-ai/* 包）
- 15 —— 依赖包或仓库返回 404
- 13 —— 不支持的依赖结构（workspace / linked / exotic）
运行失败（182）
- 107 —— 插件 entry 启动时激活失败
- 70 —— loader entry 应用失败（schema DSL 不支持、缺配置、版本不匹配）
- 5 —— 其他
加载失败（10）
- 10 —— overlay 文件缺失（ENOENT）
我们对可靠性的态度
- 收录不等于背书。进入目录只意味着它通过了上述审计、真实存在于 DSH 生态——仅此而已。
- 持续审计。新插件入库时完整过一遍，已收录条目也按固定节奏复核。失效或已脱离生态的插件会被下架。
- 诚实、可复现。每个判断都建立在可核查的证据上——清单文件、仓库状态、实测结果——而不是靠猜或批量爬取。