前言¶
DeepSeek Harness（DSH）的寫路徑相對寬鬆，讀路徑卻很嚴：一旦某條工具輸出或會話事件不符合內核契約，失敗往往落在整條會話上——歷史加載報錯、日誌無法解釋，而不是「只壞這一條記錄」。社區裏已有面向插件倉庫的發佈前審計（例如 omdsh-dev/dsh-plugin-check，覆蓋清單、patch、打包等 33 項），但插件安裝進 profile 之後，註冊表裏的 output.render() 和運行時寫入的會話事件類型，仍可能悄悄埋雷。
下面介紹維護者 imtokenxinluo 在工作流分類下的插件 dsh-contract-check：它不查惡意、不攔截執行，專門回答「當前裝着的插件有沒有違反 DSH 內核契約」；對外只通過日誌 warn，並可選在會話頭部顯示零 token 的「體檢」狀態。
這是什麼¶
dsh-contract-check 是 DSH 的契約合規檢查插件（GitHub：imtokenxinluo/dsh-contract-check）。定位可以概括爲：
- 掃描對象：運行中的工具註冊表（安裝後），而不是僅掃源碼樹。
- 檢查範圍：兩條硬契約——
output.render()應返回ContentBlock[]（而非字符串等）；會話事件類型是否落在內核KNOWN_SESSION_EVENT_TYPES詞彙表內。 - 行爲：只告警（warn-only），不阻止任何操作；不註冊模型工具，對每輪對話的 token 消耗爲零。
它與 dsh-plugin-check 互補：後者更適合發佈前查打包與生態合規；本工具側重裝進來之後、盯「會讓會話打不開」的那兩類問題，並對壓縮或無源碼插件仍可讀註冊表定義。
核心功能¶
1. render 契約¶
內核要求 output.render() 返回 ContentBlock[]。若返回裸字符串等，加載器可能拋出 SessionPersistenceCorruptionError，整條會話歷史無法加載（README 引述 2026-09 前後 dsh-ssh-ops 相關事故爲例）。
檢查手段包括：
| 手段 | 做法 | 侷限 |
|---|---|---|
| 靜態 | 讀 render 源碼，看 return 是否爲數組 |
對 defineTool 包裝後的殼函數往往看不透 |
| 實測（默認開啓） | 按 output.schema 造合法假數據，真調一次 render |
假數據不合形狀時拋異常 → 歸 unknown，不誤報爲 violation |
靜態對多數正經插件只能報 unknown；README 強調實測是必需品，可通過配置關閉（probeRender: false）。
2. 會話事件類型詞彙表¶
加載器對未知事件類型且未標記可忽略的類型會拒絕解釋整條日誌。README 說明：插件通過 Session.append 無法設置 ignorable；自定義類型若未註冊進宿主側的 KNOWN_SESSION_EVENT_TYPES，使用者的會話可能打不開。插件在運行期訂閱 session/event，發現表外類型即告警；措辭爲「看起來不在詞彙表內，請確認是否已註冊」，因爲運行時看不出作者是否已通過改 Set 等方式註冊過。
3. 三態判定與 GUI¶
| 判定 | 含義 |
|---|---|
ok |
返回值形態正確 |
violation |
證實返回字符串 / 非數組 / undefined 等 |
unknown |
判不準——寧 unknown，不 violation |
裝進 profile 並重啓後，會話頭部會出現「體檢」按鈕（顏色圓點 + 文字）。綠：驗過且 0 違規；黃：有違規；灰：尚未體檢、無法枚舉或全部判不準。狀態通過同源 HTTP GET /contract-check/status 與 POST /contract-check/audit 提供；客戶端產物需本地 npm run build 生成 lib/client.js，否則 DSH 可能報 client bundles not found。
4. 離線 CLI（無需跑 DSH）¶
dsh-contract-check scan <文件或目錄>
dsh-contract-check package <包目錄>
dsh-contract-check vocab
scan：遞歸掃源碼裏的 render 定義。package：輕量檢查 npm 打包是否漏發package.json聲明要用的文件（完整 33 項請用dsh-plugin-check）。vocab：打印內嵌詞彙表版本與條目數。
發現 violation 時 CLI 退出碼爲 1，便於 CI。
明確不做什麼¶
- 不檢測蓄意投毒、竊取或後門；進程內檢查器與惡意插件權限相同。
- 不註冊模型工具、不注入提示詞；唯一常見對外輸出是
ctx.logger.warn(...)。
安裝與啓用¶
官方 README 給出的方式是寫入 profile 的 package.json 依賴與 bundle 列表（非 dsh plugin add 一類命令）：
// profiles/<profile>/package.json
{
"dependencies": { "dsh-contract-check": "^0.1.0" },
"dsh": { "profile": { "bundles": ["...", "dsh-contract-check"] } }
}
本地開發可將依賴寫成 link: 指向倉庫路徑；修改客戶端源碼後需重新執行 npm run build 再重啓 DSH。package 元數據要求 Node >= 22。
啓用後插件會：加載時枚舉 ctx.tools.view() 做檢查；監聽 tools/change 與 session/event；註冊 Web 狀態路由供頭部按鈕使用。服務依賴通過 ctx.inject 延遲注入，避免 tools / webServer 未就緒時靜默失敗。
典型用法¶
進程內體檢：按上一節加入 profile，重啓 DSH，觀察會話頭部「體檢」狀態；需要即時複檢時點擊按鈕（進行中重複請求會返回 409，避免堆疊掃描）。
發佈或改插件前離線掃 render：
dsh-contract-check scan ./src
檢查自己的 npm 包會不會漏發 patch / exports 目標：
dsh-contract-check package .
覈對內嵌事件詞彙表：
dsh-contract-check vocab
適用場景與注意¶
適合誰
- 已在 profile 裏裝多個 DSH 插件，想低成本確認有沒有「寫壞會話歷史」的契約風險。
- 需要零 token 角標、又不想爲檢查器本身註冊
plugin_check一類模型工具的場景。 - 維護插件倉庫時，用 CLI 做 render 靜態掃或輕量 package 檢查（深度發佈審計仍應用
dsh-plugin-check）。
務必知曉
- 插件以當前 DSH 進程權限運行；安裝前應自行閱讀源碼與 MIT 許可證（見倉庫
package.json）。 - 告警不等於惡意；無告警也不等於安全審計通過。同組織 README 還提到
dsh-session-health、dsh-security-audit等分工不同的工具。 - 社區插件目錄爲獨立站點 SkillHub 條目，與 DeepSeek / 幻方無官方從屬關係。
結尾¶
dsh-contract-check 把「裝進來之後」的兩條內核契約——render 返回形態與會話事件詞彙表——做成零 token、只告警的體檢：進程內盯註冊表與實時事件，CLI 可離線掃源碼與打包遺漏。發佈前全量生態檢查請繼續用成熟工具；裝完插件後防「整條會話打不開」，可以用它做日常補位。
- 目錄頁：https://www.skillhub.cn/plugins/imtokenxinluo/dsh-contract-check
- 源碼與說明：https://github.com/imtokenxinluo/dsh-contract-check
