前言¶
DeepSeek Harness（DSH）的插件机制允许通过组合文件挂载多个插件。实际开发中，同一模块可能被重复挂载，某个插件激活时抛错，也有插件等待一个无人提供的注入服务而保持 pending。若依赖人工检查组合文件、加载器状态和错误信息，排查链路较长。
dsh-conflict-guardian 把这类检查放到 DSH 每次启动时执行：先扫描加载器中的插件状态，再对重复挂载、激活失败、依赖缺失和未运行实例做自动处理，最后在 Web 界面弹出冲突报告。
这是什么¶
dsh-conflict-guardian 是 baisama-cloud 维护的一个 DSH 插件，许可证为 MIT。它解决的是启动阶段插件冲突不易被发现、处理不及时的问题。
它不会改写插件源码，也不解析插件源码内的服务注册；检测对象是加载器运行时状态与组合文件中的静态配置。
核心功能¶
下面介绍几类检测和处理方式。
重复挂载¶
- 同一模块以完全相同配置重复挂载时，视为重复实例；
- 自动停用后加载的实例，并保留第一份；
- 不同配置的 Cordis 多实例不会被误判。
激活失败与依赖缺失¶
- 激活时抛出错误的 failed 插件会被自动停用，并报告失败原因；
- 因等待无人提供的注入服务而 pending 的插件会被自动停用，并列出缺失的服务名。
自动恢复¶
- 对启用但没有运行实例的条目，插件会尝试恢复；
- 恢复成功与否会提示。
组合文件静态检查¶
- 静态扫描组合文件；
- 发现同一文件内配置行 id 重复时给出警告；
- 不修改配置文件。
Web 界面与接口¶
- 打开 DSH 页面时，若有冲突即弹出报告；
- 报告逐条显示冲突位置与处理结果；
- 支持「重新检测」或「知道了」关闭。
接口方面，静态安装时宿主 lib/index.js 在 webServer 上注册：
POST /conflict-guardian/report
POST /conflict-guardian/rescan
动态插件运行时提供以下 harness.handle 调用入口：
harness.handle('conflict-report')
harness.handle('conflict-rescan')
动态插件运行时还会额外注册模型可调用的 conflict_check 工具。
安装与启用¶
已核实资料中给出的安装/打包步骤为：
npm pack
运行环境要求：
node >= 20
启用方式是在 DSH 配置的插件列表中加入该包，并在 cordis.patch.yml 中声明插入条目：
- insert:
- id: dsh-conflict-guardian
name: 'dsh-conflict-guardian'
如果以静态安装方式运行，lib/client.js 是已打包的浏览器 bundle；宿主 lib/index.js 提供上述路由入口。
如果以动态插件方式运行，宿主同样提供 harness.handle 调用入口，并注册 conflict_check 工具。
典型用法¶
- 安装并挂载后，每次 DSH 启动时插件自动扫描加载器；
- 发现冲突后立即自动处理，例如停用冲突实例或恢复未运行实例，并生成报告；
- 打开 DSH 页面时，若有冲突即弹出报告弹窗，可点击「重新检测」或「知道了」关闭；
- 在动态插件运行方式下，模型可通过
conflict_check工具随时检查； - 如需永久禁用某个冲突插件，可在组合文件中为该行设置
disabled: true，或删除多余行。
适用场景与注意¶
它适合维护 DSH 插件组合、希望减少启动阶段冲突排查成本的开发者。
需要注意：
- 停用与恢复均为运行时操作，不修改任何
cordis.yml； - 重启后仍按原配置加载，并再次运行检测；
conflict_check工具仅在动态插件运行方式下注册；静态安装不引入额外依赖；- 冲突检测基于加载器运行时状态与组合文件静态分析，不解析插件源码内的服务注册；
- 插件以当前 dsh 进程权限运行，安装前应检查源码、依赖与许可证。许可证为 MIT。
结尾¶
dsh-conflict-guardian 的价值在于把重复挂载、激活失败、依赖缺失和未运行实例这几类启动问题集中到一次扫描中处理，并通过 Web 报告给出位置与结果。
GitHub 仓库：https://github.com/baisama-cloud/dsh-conflict-guardian 。社区目录页地址未在已核实资料中给出，本文不补充链接。
