前言¶
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 。社區目錄頁地址未在已覈實資料中給出，本文不補充鏈接。
