返回目录
其他 基础设施

dsh-plugin-manager

PelyDeng/dsh-plugin-manager

Deploy and manage DeepSeek Harness apps with shared authentication, plugin packaging, and Docker deployment.

Stars
8
Forks
0
Issues
0
更新
1 天前

PROJECT TOPICS

项目标签

PROJECT README

README

DSH Plugin Manager

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["完整发布目录<br/>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

CLASSIFICATION EVIDENCE

分类依据

项目类型基础设施
功能分类其他
规则置信度

系统优先读取 GitHub Topics,再与站内分类词典和词根规则比对。当前命中: dsh-plugin-manager、plugin-manager。