前言¶
DeepSeek Harness（dsh）把模型、工具、技能、會話和界面都做成可替換插件。社區倉庫增長很快，作者卻經常在裝進 profile 之後才發現問題：清單缺 main / types、cordis.patch.yml 的 name 和包名對不上、tsconfig 缺關鍵項、構建產物裏還留着 .ts 文件——運行時直接崩。
這些坑本可以在提交前攔下來。社區插件 dsh-plugin-check 把清單協議、patch 格式、構建陷阱和 hub 收錄狀態收成一次掃描：模型或 CI 對着倉庫目錄跑 plugin_check，拿到 JSON 合規報告和修復建議。檢查過程只讀，不改文件，也不對被檢倉庫執行構建。
本文按社區目錄頁、GitHub 倉庫 README、package.json 和源碼交叉覈對後整理。社區目錄站點 deepseek-harness-plugin.com 是獨立收錄頁，與 DeepSeek / 幻方沒有官方從屬關係；官方運行時仍以 deepseek-ai/deepseek-harness 爲準。
這是什麼¶
dsh-plugin-check 是一款 DeepSeek Harness 的「工具與能力」插件，由 GitHub 組織 omdsh-dev 維護，倉庫地址是 omdsh-dev/dsh-plugin-check，許可證爲 MIT。目錄頁收錄日期爲 2026-08-15；本稿覈對當天，GitHub 倉庫爲 23 stars（目錄頁仍顯示 17，以倉庫頁面爲準）。
它解決的是插件倉庫的發佈前門禁，而不是給智能體增加業務工具。安裝後註冊名爲 plugin_check 的工具，row id 爲 tool-plugin-check，npm 包名聲明爲 @deepseek-ai/dsh-plugin-check。這個作用域名稱來自倉庫 package.json，維護者仍是社區組織 omdsh-dev，不要把它理解成 DeepSeek 官方包。
當前 package.json 版本爲 0.0.1，private 爲 true，主要語言 TypeScript。倉庫 README 寫明已按 @deepseek-ai/dsh@0.1.0-rc.6 依賴線做過隔離消費驗證。
核心功能¶
只讀、零業務依賴¶
README 把安全模型寫得很明確：
- 只讀：對被檢倉庫只做
readdir/stat/readFile，不修改、不構建。 - 零業務依賴：檢查邏輯只用 Node 內置模塊（
fs/path/child_process）。作爲插件掛載時，仍聲明瞭 peer：@deepseek-ai/cordis@^4.0.1、@deepseek-ai/dsh-tools、@deepseek-ai/dsh-invariants；缺失項由 profile 的node_modules回退提供。 - 不跑 tsc：構建陷阱全部是靜態文本掃描。
- hub 檢查離線優先：先讀本地 catalog（環境變量
DSH_HUB_SOURCE或當前目錄下的hub/），gh調用只作 fallback；全部失敗則標爲skipped，不算警告。
源碼註釋還寫了路徑 containment（防止逃出目標目錄 / 跟隨 symlink）和資源預算。plugin_check 的工具超時是 5000 毫秒。scan 最多處理 50 個倉庫，遇到符號鏈接目錄會跳過。
三種 action¶
| 參數 | 類型 | 必填 | 說明 |
|---|---|---|---|
action |
string | 是 | check / scan / schema |
path |
string | 否 | check 時爲插件倉庫目錄，scan 時爲父目錄；默認當前工作目錄 |
strict |
boolean | 否 | 把 warning 升級爲 error 並影響 verdict，默認 false |
三種 action 的含義：
check：檢查單個插件倉庫，輸出verdict/errors/warnings/suggestions。scan：掃描父目錄下以dsh-開頭的子目錄。README 概括爲「有package.json者」；源碼還會接受帶dsh.plugin.json、SKILL.md或catalog.json的目錄。schema：輸出全部檢測項清單、嚴重級別和適用形態，方便人和模型覈對規則。
verdict 規則：0 條 error 爲 pass；有 error 爲 fail；只有 warning 爲 warn。strict=true 時 warning 會升級，從而改變結論。
按形態套檢查項¶
插件會先識別倉庫形態 kind：registry / skill / collection / tool-bundle / bundle / infra / unknown。README 寫共 33 項檢測，按形態適用，不是所有倉庫都跑同一套 TypeScript bundle 規則。源碼裏的分流是：
registry：校驗dsh.plugin.json契約skill：檢查SKILL.md是否存在，以及 frontmatter 是否有name/descriptioncollection：檢查catalog.json的collection與pluginsbundle/tool-bundle：清單 + patch + 構建陷阱 + Profile Bundle 生態合規unknown/infra：標unsupported-kind，跳過詳細檢查，也不做 hub 查詢
bundle / tool-bundle 上，README 列出的主要類別是：
| 類別 | 作爲 error 的例子 | 作爲 warning 的例子 |
|---|---|---|
| 清單協議 | no-manifest、invalid-name、missing-main-or-types、no-patch |
incomplete-files、missing-peer、no-bundle-decl |
| patch 格式 | malformed-patch、patch-name-mismatch、duplicate-row-id |
unexpected-fields |
| 構建陷阱 | no-source-entry、no-tsconfig、missing-ts-ext-imports、lib-layout-mismatch、stale-ts-imports |
missing-rewrite-imports、types-path-mismatch、implicit-node-types、no-build-script |
| 生態合規 | core-row-id（patch 佔用官方核心 row：tools / session / llm / web / permission） |
missing-profile-install-example、manual-install-only、core-modification-required |
| hub 收錄 | — | not-in-hub（hub-skipped 爲 info） |
報告裏的 checks 是固定檢查項的執行結果（total / passed / failed / warned / skipped），不是 issue 條數。
倉庫 README 還記載：2026-08-08 對組織內 8 個插件（time / encoding / json / calculator / csv / regex / markdown / session-health）自檢，結果全部 pass；過程中修過 4 箇舊插件的真實缺陷（tsconfig 缺三件套、缺 build / prepack scripts）。這是維護者自述，不是第三方評測。
安裝與啓用¶
社區目錄頁給出的安裝命令是：
dsh plugin add github:omdsh-dev/dsh-plugin-check
在 DeepSeek Harness 終端裏運行即可。需要可復現安裝時，按目錄頁說明固定 commit：
dsh plugin add github:omdsh-dev/dsh-plugin-check#<commit哈希>
倉庫 README 推薦按 Profile Bundle 裝到具體 profile（針對 DSH 0.1.0-rc.6）。web 和 headless 是兩套配置，裝到 web 不會自動覆蓋 headless；dsh run 默認走 headless：
# 交互式（web）profile
dsh plugin --profile web add github:omdsh-dev/dsh-plugin-check
# 一次性任務（headless）profile
dsh plugin --profile headless add github:omdsh-dev/dsh-plugin-check
包內 dsh.bundle.patch（倉庫文件是 cordis.patch.yml）會在安裝後把插件插入 profile 的 layer stack，id 爲 tool-plugin-check。
不走 GitHub、改用本地 tarball 時，README 的寫法是：
npm pack
dsh plugin --profile web add <npm pack 產物 tarball 路徑>
驗證 row 是否掛上：
dsh --profile web --dump-config | grep tool-plugin-check
運行時冒煙可以用：
dsh run "使用 plugin_check 工具檢查一個插件倉庫"
package.json 聲明的 Node 引擎是 ^22.19.0 || >=24.0.0。README 建議用 npx -p @deepseek-ai/dsh@0.1.0-rc.6 dsh web 啓動 lib 生產模式，不要 npm install -g 全局安裝。Windows 路徑請用正斜槓，例如 C:/Users/...。
典型用法¶
裝好之後，把工作目錄指到要檢查的插件倉庫，讓模型調用 plugin_check。下面兩個例子直接來自倉庫 README。
檢查單個倉庫：
plugin_check { action: "check", path: "C:/Users/admin/Desktop/dshext/dsh-tool-csv" }
README 給出的成功形態類似：
{"repo":"dsh-tool-csv","kind":"tool-bundle","verdict":"pass","checks":{"total":24,"passed":24}}
掃描父目錄下一批 dsh-* 倉庫：
plugin_check { action: "scan", path: "C:/Users/admin/Desktop/dshext" }
返回結構是 root、scanned 和 reports 數組。不合規倉庫會帶上 error 和 suggestions。
先看規則再掃倉庫時，把 action 設爲 schema。path 省略則使用當前工作目錄。需要把 warning 也當成失敗時，加上 "strict": true。
適用場景與注意事項¶
適合這些情況：
- 自己寫 DSH 插件，提交或打包前做一次門禁
- 維護一組
dsh-*倉庫，用scan看彙總 - 讓智能體在改插件代碼後自己跑
plugin_check，按 suggestions 修清單和 patch
使用前注意：
- 權限：插件以當前 dsh 進程的權限運行，安裝時可能執行代碼。安裝前應閱讀源碼和 MIT 許可證；生產環境建議固定 commit 哈希。
- 它不是官方 CLI：本插件註冊的是工具
plugin_check，和社區討論裏有人提議的dsh plugin check子命令不是一回事。 - 只讀不等於零風險：檢查邏輯聲稱不改被檢倉庫，但插件本身仍運行在 dsh 進程裏，能讀你指定的路徑。
- 形態識別會跳過：
infra/unknown不會套 bundle 那套 33 項；hub 查不到只標skipped，不要當成「已收錄」。 - 掃描上限：一次
scan最多 50 個倉庫，工具調用超時 5 秒；倉庫很多或磁盤很慢時，拆目錄分別check更穩。 - 運行時仍在預覽期：README 針對的是 npm 線上的
0.1.0-rc.6。DeepSeek Harness 還在開發者預覽，peer 範圍和 patch 協議都可能變，以倉庫當前 README 爲準。
小結¶
dsh-plugin-check 把「插件裝上去才發現清單和產物不對」提前變成一次只讀掃描。它按倉庫形態套規則，輸出 JSON 結論和修復建議，適合插件作者和批量維護場景。
目錄頁：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-plugin-check/
GitHub：https://github.com/omdsh-dev/dsh-plugin-check
