插件安装生态报告
队列追平了注册表，但只有一半真正跑得起来
有真实安装记录的每个 dsh 版本、同一架梯子 —— 0.1.2-α.1 → 0.1.2-rc.1 → 0.1.3-α.1 → 0.1.3-α.2。分版本跑得起来：5,543 → 6,252 → 6,448 → 7,175。
- L5 优先——「运行已验证」要求 L5 通过（web 启动 · HTTP · 插件清单 active）；只有 L4 表示装得上，不等于跑得起来。
- 版本作用域——判定只对实测时的 dsh 版本有效；下面每个数字都锁定在 0.1.3-alpha.2。
- 灰不是坏——unknown = 装得上但未声明 dsh.bundle，dsh 不挂载任何能力：是普通依赖，不是失败。
A 各版本判定构成堆叠上限 14,494 · 当前 0.1.3-α.2
B L4 装得上 vs L5 跑得起来已判定通过率 · 当前 0.1.3-α.2
C 注册表构成 · 0.1.3-alpha.214,496
D 安装阶梯 L1 → L5 · 0.1.3-alpha.2条长 = 通过率
E 安装通道对决 · 0.1.3-alpha.2差 25.2%pp
F 运行失败画像 · 0.1.3-alpha.2记录原文
01 解读
这是解读，不是第二个数据源：下面每句结论都指回上方已出现的数字，不引入新数字。
队列追平了，损失不再是「没测」
覆盖率 99.99%：注册表 14,496 个可列表插件里，14,494 个在 0.1.3-alpha.2 上有真实判定（未测 2 个）。其中 7,175 个跑得起来（49.5%）、3,202 个失败（22.1%）、4,085 个是普通依赖（28.2%）。相对 Vol.1 收尾的版本，跑得起来从 6,448 涨到 7,175（+727，+11.3%）。
边界。 覆盖率是「队列」的属性，不是生态的属性：全部 L5 判定落在一个两天批次里（2026-09-08/09）。 局限。 未测 ≠ 失败——而且本期未测只有 2 个。悬而未决的问题已经从「有没有测到」变成「测出来的判定质量」。
通道差距是打包纪律，不是崩溃率
npm 固定安装的跑得起来比例是 71%，源码安装是 45.8%（差 25.2%pp）。但两边失败率几乎一样（npm 19.7% vs 源码 22.5%）——真正的分水岭是灰桶：源码安装有 31.5% 未声明 dsh.bundle，npm 只有 8.9%。
边界。 通道取获胜记录的 evidence.parsed.channel，缺证据时回看同版本记录；本期 other 桶为空。 局限。 是否声明 dsh.bundle 是打包选择，不是质量分：未挂载的普通依赖不等于坏插件。
运行失败是一种形态，不是长尾
3,202 个失败 = 115 个沙盒安装失败（L4）+ 3,087 个 web 运行门失败（L5）。运行失败里 2,853 个（92.4%）记录着同一句失败文本「plugin tree failed to load」（检查项 L5.2_WEB_BOOT_READY），其余 234 个散落在 6 种其他记录形态里。
边界。 分桶用的是失败检查自己的 summary 原文，逐字保留；页面没有把它们重新归并成一套自定义分类。 局限。 单一形态指向共同的运行门或共同成因，而不是 3,087 个互不相干的插件缺陷——这是症状盘点，不是根因分析。
版本列车跑在验证队列前面
受测版本之后又发了三个 dsh 版本——0.1.5-alpha.1（2026-09-08）、0.1.5-alpha.2（2026-09-09）、0.1.5-rc.1（2026-09-10）——它们在验证记录里是零。本报告所有数字都锁定在 0.1.3-alpha.2。
边界。 版本化口径是刻意的：判定只对实测时的版本有效；旧版本判定作为历史保留，绝不静默升级。 局限。 下次切换 dsh 版本，当前版本就会前移，上述覆盖率和跑得起来数字会先回落，等复测队列追上再回升。那是记账，不是退化。
02 方法论
- 判定（L5 优先）：每版本最新 L5 真测获胜，无 L5 退最新 L4；L5 通过 = 「运行已验证」。
- 状态分层（记录层口径不变）：失败 = 安装／启动／HTTP 实测失败；灰桶 = 装得上但未声明 dsh.bundle——dsh 按普通依赖安装、不挂载为插件（web 运行门不适用）。记录层称 unknown（既非过也非挂），本报告按主体语义命名为普通依赖（未挂载），不混为失败。
- 失败画像：当前版本的失败判定拆成 L4 沙盒安装失败与 L5 web 运行门失败；后者按失败检查自己的 summary 原文分桶（记录没有 summary 时用检查 id）。板上不额外发明分类体系。
- 窗口 / 版本口径：窗口 = 有真实运行记录的每个 dsh 版本，不固定个数——阶梯覆盖到新版本就自动扩列；判定只对实测版本有效；旧版覆盖率以当前注册表为分母。
- 历史卷不改写：更早的卷保持发布时的数字，不因注册表增长或当前 dsh 版本前移而回改。
Q 「装得上」（L4）等于「运行已验证」吗？
不等。L4 只是沙盒安装跑完；L5 要求 web 运行时启动、HTTP 可服务、插件出现在 loader 清单里。只有 L5 通过才算运行已验证——本期 13,683 个装得上，7,175 个跑得起来。
Q 明明有更新的版本，报告为什么停在 0.1.3-alpha.2？
因为 0.1.3-alpha.2 是记录里有真测的最高版本。0.1.5-alpha.1 / 0.1.5-alpha.2 / 0.1.5-rc.1 已经发布，但还没进过阶梯扫描，它们的列会是空的。覆盖率天然按版本作用域计算：下次切版本它会先回落，等队列追上再回升。
03 其它
- 数字从哪来：每个数字都在构建时从那 14,908 条 append-only 沙盒记录重新聚合；逐插件入口 GET /data/install/<id>.json。
- 实时视图：/zh/verification/ 对当前 dsh 版本用同一套判定口径，每次构建刷新。
- 更早的卷：Vol.1（0.1.2-alpha.1 → 0.1.3-alpha.1），按发布原样保留。
- 独立性：dsh.so 是独立项目，与 DeepSeek 无隶属关系；判定是对沙盒记录的观察，不构成背书。
Q 3,202 个失败该怎么读？
这是两类不同的事：115 个在沙盒里根本没装上；3,087 个装上了但没过 web 运行门——其中 92.4% 记录着同一句文本「plugin tree failed to load」。请把它读成同一道运行门的症状，而不是 3,087 个各自独立的插件质量判决。
Q 运行已验证的插件就安全吗？
不。验证与安全是两条独立的轴：运行验证只说它装得上、跑得起来，不说明它做什么。安全结果在插件详情页单列。
引用本报告
dsh.so — DeepSeek Harness 插件安装生态报告 · Vol.2（发布于 2026-09-10）。 窗口：0.1.2-alpha.1 → 0.1.2-rc.1 → 0.1.3-alpha.1 → 0.1.3-alpha.2 · 安装验证批次开始 2026-09-08 17:18:15（UTC+8） 注册表：14,496 · 跑得起来（L5）7,175 · 仅装得上（L4）13,683 · 失败 3,202 https://dsh.so/zh/reports/install-vol2/