PelyDeng/dsh-plugin-manager 预览 preview

PelyDeng/dsh-plugin-manager

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

Project Overview项目介绍

This is a plugin development and deployment framework for DeepSeek Harness (DSH). It enables individual developers and small teams to develop plugins, and uniformly handles installation, updates and management. It suits scenarios of developing multiple plugins or delivering AI apps to teams and clients. It is community-maintained non-official, so compatibility with host DSH version needs verification.

这是面向DeepSeek Harness的插件开发与部署框架,核心能力是帮助个人开发者和小团队开发插件,统一完成插件的安装、更新与管理。适合需要开发多个插件或向团队/客户交付应用的场景,注意这是社区独立维护的非官方项目,需验证与宿主DSH版本的兼容性。

Or use CLI install (for developers)或使用命令行安装(适合开发者)

CLI Install命令行安装

dsh plugin --profile web add github:PelyDeng/dsh-plugin-manager

PelyDeng/dsh-plugin-manager 加入你的 DSH 配置(web profile)即可启用。

READMEREADME

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/ 只放外部作者的完整发布目录。把随包的 optional/authpublic-apps(同一批插件)再放进去会因插件 id 重复被组合清单拒绝。

  4. 在部署根执行:

    bash build.sh
    

    Windows PowerShell 执行 .\build.ps1

  5. 按 build 输出访问站点,并请求插件 README 声明的实际端点。

部署机器需要 Node.js、系统 tar、本机 Linux Docker 引擎及 Compose。普通源码 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

上一个 Prev dsh-task-status 下一个 Next dsh-chat-outline