前言¶
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
