PelyDeng/dsh-plugin-manager

DSH 插件管理器

English · 部署已打包插件 · 开发自己的插件 · 作者指南 · 部署指南 · Releases

基于 DeepSeek Harness（DSH）的插件交付与运维框架。插件作者在自己的项目里构建和打包，部署者只接收完整发布目录，不依赖作者源码。

社区维护的非官方项目，不代表 DeepSeek 官方产品或推荐。

先选择你的角色

| 角色 | 你要做的事 | 先看 | 不需要先处理 |
| --- | --- | --- | --- |
| 插件作者 | 编写、检查、打包插件 | 作者指南 和起步包 README | 站点迁移、服务器源码发版 |
| 部署者 | 安装、更新、验证插件 | 产物部署指南 | 插件源码、作者构建工具链 |
| 站点维护者 | 维护源码站点、失败后重跑普通 build、迁移数据 | 部署与管理 | 每个业务插件的内部实现 |

第一次使用不必读完所有文档。先完成下面两条最短路径之一，再按需要进入高级文档。

部署已打包插件

适用场景：作者已经交付包含 manifest.json 和全部 .tgz 的完整发布目录。

1. 从同一版本 Release 下载 dsh-plugin-manager-deployment-.zip 并解压。
2. 把每个应用的完整发布目录放入 incoming//。
3. 内置 auth、example 由本次构建产出（archives 用随包公开构建视图），已经在候选里；incoming/ 只放外部作者的完整发布目录。把随包的 public-apps（同一批插件）再放进去会在准备输入阶段被拒绝，并指明与哪个内置插件重复。
4. 在部署根执行：

bash build.sh

Windows PowerShell 执行 .\build.ps1。
5. 按 build 输出访问站点，并请求插件 README 声明的实际端点。

部署机器需要 Node.js、系统 tar、本机 Linux Docker 引擎及 Compose；首次 build 会在随包公开构建视图内安装框架工作区依赖（需要网络或完整缓存），站点自身目录不装依赖。普通源码 ZIP、单个 npm tgz 或只有前端 dist 的压缩包不能代替标准发布目录。完整配置、升级和恢复见产物部署指南。

开发自己的插件

新建插件先从 Release 的 dsh-plugin-manager-starters-.zip 开始：

| 起步包 | 适用场景 |
| --- | --- |
| standalone-plugin | 公开 readiness endpoint，不使用 kit 或登录 |
| standalone-kit | 复用登录、应用授权和可信账号身份 |

在作者项目之外创建独立工具目录并安装同版 manager：

pnpm init
pnpm add --ignore-workspace /absolute/path/plugin-manager-.tgz

在作者项目执行：

pnpm install --ignore-workspace

在工具目录执行：

pnpm exec dsh-plugin-manager list --root /absolute/path/my-plugin --package .
pnpm exec dsh-plugin-manager pack --root /absolute/path/my-plugin --package . --output .local/artifacts/release/v1

pack 只做构建、打包与内容寻址（归档按实际字节摘要命名），不附赠检查：类型检查用 check，归档与源码一致用 verify-package，交付目录合规用 verify-release，三件事分别执行，完成后生成 manifest.json。交付整个输出目录，不要单独抽走 tgz。当前直接支持独立 pnpm 单包；npm、yarn 或 monorepo 不承诺相同的一步流程。

可以接入什么

| 已有项目 | 接入方式 |
| --- | --- |
| 自己开发的 DSH 插件 | 放在独立仓库或框架 plugins/builtin/（内置）或 plugins/external/（自己的源码），按声明、构建和打包规范交付 |
| 第三方 DSH 插件或官方 Bundle | 确认宿主兼容性；已有合规完整发布目录可直接部署 |
| 普通 Node.js 项目 | 改造为官方 Cordis 插件，提供 Bundle 入口和构建产物 |
| Java、Python 或已有 HTTP 服务 | 服务继续独立部署，由一个 DSH 适配插件调用其接口 |

它不做什么

- 不把任意源码 ZIP、jar、前端 dist 或普通 npm 包自动变成可运行插件。
- 不因为插件声明了 permissions 就自动保护业务路由；访问控制和数据权限仍由插件实现。
- 不把构建、健康检查、登录或模型可用性混同于业务验收。
- 不自动回滚业务数据；更新前需要按数据所有者要求独立备份。
- 不要求部署者理解作者源码，也不在部署端构建作者项目。

架构分工

flowchart LR
A["作者独立项目"] -->|pack| B["完整发布目录manifest + tgz"]
B --> C["incoming / archives"]
D["框架源码站点"] -->|source 固定全量构建| E["插件归档"]
C --> F["manager 统一校验、配置、安装与恢复"]
E --> F
F --> G["官方 DSH profile"]
G --> H["Agent、模型、会话与业务插件"]

DSH 负责 Agent、模型、会话和插件运行。manager 负责打包、配置、安装、更新和恢复。kit 可选提供身份、HTTP、工具、模型和会话接口。业务插件继续负责自己的业务规则与数据权限。详细边界见架构说明。

高级入口

| 目的 | 入口 |
| --- | --- |
| 体验 auth/example 登录和问答 | 登录与问答 · 图文导览 |
| 查插件声明和实例配置 | 插件配置规范 · kit 文档 |
| 手工组合清单或直接管理宿主 | 独立 CLI 交付 |
| 源码发版、固定全量构建、失败后重跑普通 build | 部署与管理 |
| 查站点字段、凭据和默认值 | 框架配置 |
| 查故障和验证边界 | FAQ · 宿主兼容 · 验证记录 |
| 查全部文档 | 文档导航 |

贡献与许可

公共库在 packages/，内置示例插件在 plugins/builtin/，独立起步包在 examples/*。参与开发前先读贡献说明和架构。使用 Apache-2.0 许可，第三方来源见 THIRD_PARTY_NOTICES.md。