用 dsh-plugin-development 给 DeepSeek Harness 装上插件开发与审计技能

DeepSeek Harness 插件 DeepSeek DSH 插件开发 界面增强 Agent Skill 2026-08-18 95 阅读

前言

DeepSeek Harness（以下简称 DSH）的核心理念是「一切皆插件」。官方仓库 deepseek-ai/deepseek-harness 把运行时、工具、界面能力都做成可组合的 Cordis 插件；社区里也出现了大量可安装 bundle。动手写第一个插件时，问题通常不是「会不会写 TypeScript」，而是分不清三种形态：进程内动态插件、仓库里的 workspace 包、以及用 dsh plugin 装进 profile 的外部 bundle。三种形态的源码格式、加载路径、验收证据都不一样，把一种规则套到另一种上，很容易写出能编译、却装不进去或无法卸载的包。

dsh-plugin-development 就是为这件事准备的。它不是又一个改网页皮肤的界面插件，而是一份可移植的 Agent Skill：把设计、实现、打包、审查和诊断 DSH 插件的流程写进 SKILL.md，让 Codex、Claude Code 和 DSH 共用同一份规范。仓库另外提供一个可选的 DSH bundle 适配器，方便用 dsh plugin 做 profile 级安装和卸载。本文按社区目录页、GitHub README、package.json、SKILL.md 和 v0.2.0-beta.1 发行说明交叉核对后整理。

这是什么

dsh-plugin-development 由 GitHub 用户 w2112515 维护，许可证为 MIT。社区目录 deepseek-harness-plugin.com 把它归在「界面增强」，收录时标注的安装命令是 dsh plugin add github:w2112515/dsh-plugin-development。GitHub 仓库创建于 2026-08-14，截至 2026-08-17 有 10 颗星，当前包装版本是 0.2.0-beta.1（预发布）。

仓库 README 把产品边界写得很清楚：真正维护的是一份符合 Agent Skills 规范 的 canonical Skill 目录 skills/dsh-plugin-development；index.js 和 cordis.patch.yml 只是薄适配层，把这份 Skill 注册进 DSH 的 ctx.skills。它不引入 MCP 服务，也不依赖账号、密钥或远程接口。项目声明自己是 Beta、非官方社区项目，与 DeepSeek 没有从属或背书关系；DSH 目前仍处于 developer preview，插件清单、类型和 Loader 行为以当前 DSH 仓库为准，而不是以这份 Skill 的记忆为准。

它解决的是这类任务：

  • 在活的 DSH 进程里用 cordis_define / cordis_run 做动态 Cordis 插件
  • 改 DSH 仓库 packages/ 下随发行版一起走的 workspace 插件
  • 给外部包补上 dsh.bundle 和 cordis.patch.yml，做成可安装 bundle
  • 审查 Loader 导出、Service / Provider / Consumer 归属、Client Slot、CLI 表面、配置、生命周期和 profile 合成

明确不做的事：市场上架、整合包、dsh.pack.json、dsh-plugin-pack。那一类工作属于另一个仓库 dsh-marketplace-publish。

核心功能

先分类，再写规则

SKILL.md 要求助手在动手前先判定插件模式，不要把一种模式的规则直接搬到另一种上：

模式 典型信号 完成时要拿出的证据
动态运行时 Cordis 插件 cordis_define、cordis_run、活的 Host / Client、Slot、@pluginId 现场 Provider 与 Slot 检查、define/run 状态、最终诊断
DSH workspace 插件 目标在 packages/ 下，作为 DSH 仓库能力一起发布 当前仓库权威文件、针对性测试、真实 Loader 合成、生命周期证明
可安装 DSH bundle dsh.bundle、cordis.patch.yml、dsh plugin、npm / tarball 打包文件列表、隔离 profile 安装、--dump-config、打包入口启动与清理证据

模式选错时，产物会完全不同。证据不够、三种模式会写出不同文件时，Skill 要求只问一个问题：结果应该是进程内的、随 DSH 仓库发布的、装进 profile 的，还是市场上的整合包。

固定工作流：发现到汇报

选定模式之后，流程是固定的六步：

  1. 发现：看目标、当前配置、邻近实现、仓库状态和真实加载路径。
  2. 规划组件：找出消费者、当前所有者、需要的插件角色、配置所有者、生命周期所有者、可观察结果和证据。跨角色时用一张简表。
  3. 敲定决策：入口与前置条件、动作与输入、结果或状态、失败与恢复、清理、对模型可见的副作用、授权边界。
  4. 实现：只改必要组件，并按所选模式更新对应文档。
  5. 验证：走真实的动态工具、Loader、打包或消费者入口；静态检查不能代替这条路径。
  6. 汇报：先写结果、所选模式、改动或审计发现、实际跑过的检查、未关闭风险和下一步。

授权也一次性写死：问答、审查、诊断默认只读；创建和修复可以改本地文件并跑非破坏性检查；发布、外部写入、破坏性删除、执行不可信依赖的安装期脚本，必须先确认。

三种模式各自卡什么

动态插件只存在于当前进程。参考文档要求先检查活的 Host / Client Provider，再用 cordis_define 定义不可变包、用 cordis_run 激活。函数体必须是普通 JavaScript，不能用 import、require、TypeScript 或 JSX；Client 侧用 React.createElement，UI 只能挂到查询到的 Slot。没有现场 cordis_inspect_* 工具时，Skill 只允许做设计和诊断，并明确写出哪些激活结果尚未核实，不能假装插件已经跑起来。

workspace 插件跟 DSH 仓库走，权威来源是当前 checkout 里的文档、类型和 Loader，而不是教程里抄来的旧清单。

可安装 bundle 是 profile 上的一层配置，不是 profile 本身。package.json 里声明 dsh.bundle.patch，profile 的 dsh.profile.bundles 由 dsh plugin 维护，不要手改。这个仓库自己的适配器就是这种形态：package.json 指向 ./cordis.patch.yml，补丁插入一行 id: dsh-plugin-development-skill、name: dsh-plugin-development。index.js 读打包进去的 SKILL.md frontmatter，调用 ctx.skills.register()；卸载时只撤销这次注册，不会删除用户另外装到个人目录或项目目录里的 Skill 副本。项目本地的同名 Skill 仍可按宿主发现规则覆盖这次运行时注册。

自带的静态预检脚本

Skill 目录里有只读脚本 scripts/check-artifact.mjs，给插件作者做早期检查，不能当成完成证据：

node skills/dsh-plugin-development/scripts/check-artifact.mjs workspace-function path/to/index.ts
node skills/dsh-plugin-development/scripts/check-artifact.mjs bundle path/to/package
  • workspace-function：检查 workspace 函数插件源文件
  • bundle：检查 package.json、dsh.bundle.patch 和补丁文件是否对得上

bundle 模式的参考文档写明：它不能证明 npm 打包文件列表、运行时模块解析、补丁语义、profile 优先级或启动行为。发布前仍要在隔离 profile 里安装真实产物，跑 dsh --profile --dump-config，再验证注册、Fiber 清理和卸载。

安装与启用

社区目录页给出的安装命令如下，在 DeepSeek Harness 终端里运行：

dsh plugin add github:w2112515/dsh-plugin-development

如需可复现安装，目录页建议固定 commit：

dsh plugin add github:w2112515/dsh-plugin-development#commit

把 commit 换成已经审过的 SHA，不要钉会移动的分支。

仓库 README 把 DSH 适配器写成可选路径，只在希望由 dsh plugin 管理 profile 安装、版本、合成和卸载时使用。当前发行是 v0.2.0-beta.1，上一个 v0.1.0-beta.1 保持不可变。推荐用发行 tarball：

dsh plugin --profile web add https://github.com/w2112515/dsh-plugin-development/releases/download/v0.2.0-beta.1/dsh-plugin-development-0.2.0-beta.1.tgz
dsh --profile web --dump-config

导出的配置里应出现 dsh-plugin-development 这一层，以及行 ID dsh-plugin-development-skill。也可以钉标签从 Git 安装；适配器是普通 JavaScript 和 Markdown，没有 prepare、install 或 postinstall：

dsh plugin --profile web add github:w2112515/dsh-plugin-development#v0.2.0-beta.1

本地开发适配器时，在仓库根目录执行：

dsh plugin --profile web add .

不经过 bundle、只把 Skill 目录交给宿主发现也可以。DSH 会从项目下的 .dsh/skills/dsh-plugin-development、.agents/skills/dsh-plugin-development 或 skills/dsh-plugin-development 读取同一份目录。.agents/skills 可与 Codex 共用。Codex 还可装到 ~/.codex/skills/dsh-plugin-development，用 $dsh-plugin-development 显式调用；Claude Code 可装到 ~/.claude/skills/dsh-plugin-development 或项目内 .claude/skills/dsh-plugin-development，用 /dsh-plugin-development 调用。仓库刻意没有 .codex-plugin / .claude-plugin，这两个宿主都不需要再包一层插件才能用这份 Skill。

package.json 声明运行环境为 Node.js ^22.19.0 || >=24.0.0。仓库自检命令是：

npm test
npm pack --dry-run

有一份已构建的 DSH checkout 时，还可以跑：

node scripts/verify-dsh-runtime.mjs path/to/deepseek-harness

典型用法

装好之后，直接向当前助手描述 DSH 插件任务即可。Skill 的 description 会匹配设计、创建、修改、打包、安装、审查、审计、诊断这类请求；也可以在 Codex 里写 $dsh-plugin-development，在 Claude Code 里写 /dsh-plugin-development。

下面是 README 和 SKILL.md 里能直接复现的用法，不是虚构案例。

  1. 先让助手判定模式。 例如：「给当前 DSH 进程加一个 Client Slot 面板」应走动态运行时；「改 packages/ 里某个随仓库发布的包」应走 workspace；「把这个外部 npm 包做成 dsh plugin add 能装的 bundle」应走可安装 bundle。如果其实是整合包或目录上架，助手应按 Skill 要求停下来，改用 dsh-marketplace-publish。

  2. 动态插件按现场工具走。 参考文档给出的顺序是：cordis_inspect_list 列出 Provider → 只查询会用到的 Service / Event / Slot / Tool → 已有 @pluginId 时用 cordis_inspect_self 读源码和诊断 → cordis_define 定义包 → cordis_run 激活。awaiting-approval 和 starting 都不是成功，这一轮应结束等待系统引导，而不是在同一回合里轮询。停用走 cordis_stop；cordis_undefine 是破坏性删除，需要明确授权。

  3. bundle 先做静态预检，再装隔离 profile。 在包根目录运行上面的 check-artifact.mjs bundle，然后 npm pack --dry-run 看打进去的文件是否包含补丁和运行时入口、是否混入密钥或本机文件。真正验收要按发行说明：把精确 tarball 装进一次性 DSH home，检查 --dump-config，加载已安装入口，验证注册、销毁和卸载。不要为了取证去覆盖用户正在用的 profile。

  4. 审查请求默认不改代码。 把仓库或补丁交给助手做审计时，Skill 要求只检查并汇报，除非请求里同时要求修改。

适用场景与注意事项

适合这些人：

  • 要在 DSH 里写第一个插件，但分不清动态插件、workspace 包和 bundle
  • 已经有一个外部包，想按当前 DSH 的 dsh.bundle 合同打包、安装和卸载
  • 需要审查别人的 DSH 插件：Loader 导出、依赖注入、生命周期、Git 安装是否会执行构建脚本
  • 同时用 Codex / Claude Code / DSH，希望三份宿主读同一套插件开发规范

不适合、或者说会主动拒绝的任务：做市场上的整合包、把教程或过期 Agent Note 当成当前 API、在没有现场 Cordis 工具时声称动态插件已经运行。

使用前注意下面几点。

插件以当前 dsh 进程的权限运行，安装时可能执行代码。目录页和仓库都要求先检查源码与许可证。本仓库适配器没有安装期脚本，但这只说明这一份包的声明；第三方依赖仍要单独看。Git 安装若带 prepare 构建，等于允许在本机执行依赖代码，需要明确授权，并钉 commit。

DSH 和这份 Skill 都还在预览 / Beta。Skill 明确禁止用记忆中的包列表或教程清单覆盖当前仓库里的可执行约束；文档和实现冲突时必须同时引用两边，不能 silently 调和。社区插件目录是独立站点，不是 DeepSeek / 幻方的官方应用商店。

卸载 bundle 只会撤销适配器注册的那条 Skill，个人目录或项目目录里另行放置的 dsh-plugin-development 不会被删掉。

小结

dsh-plugin-development 把 DSH 插件开发里最容易混的三件事分开了：进程内动态插件、仓库 workspace 包、profile 可安装 bundle，并给审查和诊断补上「证据是什么」而不是「代码能不能编译」。同一份 Skill 目录可以给 Codex、Claude Code 和 DSH 用；可选的 bundle 适配器只负责把它注册进当前 profile，并在卸载时干净地撤掉。

目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-plugin-development/

GitHub：https://github.com/w2112515/dsh-plugin-development

相关文章

快速从零部署一个DeepSeek-R1服务 2025-04-05 使用 dsh-anchored-standard 为 DeepSeek Harness 配置两阶段 Agent 预设 2026-08-17 用 dsh-web-ui 把 DeepSeek Harness 网页界面补成工作台 2026-08-17 用 modlens 给 DeepSeek Harness 的纯文本模型补上视觉 2026-08-17 用 dsh-TUI 给 DeepSeek Harness 补上全屏终端界面 2026-08-17
羽毛球分组比赛记分
小程序二维码

欢迎使用《羽毛球分组比赛记分》微信小程序

小夜