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。