2026 年 9 月雷峰网的一篇实测报道给整个插件生态泼了一盆冷水：下载量前 10 的 DSH 插件装进同一个配置里起不来——第 2、3、6 名互相抢同一个界面 slot，而运行时没有任何仲裁者告诉用户发生了什么。
需求信号
- 雷峰网《DeepSeek Harness 的插件体验短板》（2026-09）：实测三档文件权限对插件完全无效、头部插件 slot 冲突无仲裁、装插件会静默让 KV 缓存前缀失效。这不是用户抱怨，是媒体实测。
- dshfind 论坛的真实案例：dsh-agent-teams 在桌面版 0.1.2-rc.1 上因为一个被移除的 API（registerContinuableSetup）直接挂掉。
- 官方 Discussion #5120 的评论区里，插件作者集体诉苦：「typecheck 全绿，跑起来才炸」。
缺口在哪
没有一个专注的兼容性工具。LX2000WASD/dsh-web-plugin-manager（68★）内置了冲突分析但只是大而全管理器的子功能。官方运行时的设计理念是组合优于仲裁，所以「装之前体检」这个生态位大概率长期留给社区。
建议形态
Host service / 诊断工具：读当前 cordis 组合（所有已装插件的注册声明），静态检测三类冲突——slot 抢占（多个插件注册同一界面位置）、服务名冲突、版本依赖与 dshTarget 矩阵；输出一份「这个配置能不能起、哪里会炸、建议怎么调」的报告。
实现要点
- 组合解析看官方 capability-seams.md 与 docs/subsystems/slots.md。
- 做「只读体检」，绝不在用户机器上自动改配置——信任是这类工具的全部。
- 报告给出证据链：哪个插件的哪一行声明导致了哪个冲突。没有证据的告警等于噪音。
最小可行版本
CLI 形态：指向一个 profile，输出 slot/服务冲突清单。UI 留到 v2。
风险与边界
难点不在检测在跟进：harness 每周都在变，组合语义变了体检规则就得变。这是一个「需要长期陪跑」的项目，适合真正想深耕插件生态的作者。
FAQ
官方为什么不自己仲裁？
从架构文档看，运行时把组合正确性留给了声明与约定；短期内出现一个官方仲裁者的概率不高，这正是社区工具的空间。
这和安全扫描器是一回事吗？
不是。安全扫描看「插件能碰到什么」，兼容性体检看「插件们凑在一起会不会打架」。两个方向都需要，后者目前完全没有供给。