最近在学用 DSH（DeepSeek Harness）做智能体，学着学着就把实践攒成了一个开源仓库：PelyDeng/dsh-plugin-manager。这篇算是一次复盘，主要想理清楚三件事：它是什么、解决什么问题、和官方 DSH 是什么关系。

先说它是什么

简单讲，它是给个人开发者和小团队用的插件开发与交付框架。注意它不是插件本身，而是一套工程约定：作者怎么接入、怎么打包、怎么交付，运行端怎么统一安装、配置和启停。我拿它做出来的典型产物，是知识库助手、报表助手这类带独立页面的智能体应用。

它到底解决了什么

官方 DSH 的底层机制其实挺全的：Cordis 插件运行、Bundle 组合、Agent、模型、会话都有。但真到自己要开发多个插件、还要交付给团队或客户的时候，中间就缺一层工程约定，这个仓库补的就是这层。README 里列了六项能力，我挑着说：

作者在自己维护的 pnpm 单包项目里声明一下就能接入，不用改管理器名单；plugins/* 目录的自动发现、选集和批量构建保留了；构建时按插件声明执行 build、必要的 check 和 pack，输出清单和归档；多个作者的交付目录可以拼成一份站点发布物，运行端不需要作者源码；实例配置、安装、启动、停止和就绪探针统一管理；认证是可选的，复用账号、登录和应用访问授权，业务接口由作者自己接入 kit。

仓库结构

项目分层很清楚：packages/plugin-kit（@dsh-plugin-manager/plugin-kit）是插件作者真正要依赖的开发套件，管身份、权限、HTTP 和工具登记；packages/plugin-manager 是管理器 CLI 本体，负责发现、打包、安装和受控启停；plugins/dsh-auth 提供可选的账号、登录与插件授权；plugins/dsh-example 是个完整示例，包含开发者答疑、流式对话、历史记录和可选认证；integrations/docker 和 deploy/ 提供官方宿主镜像的 Compose 集成，以及 Bash、PowerShell、Node 三种部署入口。

我个人最喜欢的一个设计是：发布运行端不需要作者源码。作者在自己仓库跑 dsh-plugin-manager pack，生成版本化交付物（清单加归档），运行端把这些交付目录组合一下就能部署。开发和交付就这么解耦了。

和官方 DSH 怎么分工

README 把责任划得很清楚，我直接搬过来：官方 DSH 管 Cordis 插件运行、Bundle 组合、Agent、模型与会话；这个框架管作者接入约定、发布物组合、配置和交付管理，外加可选的基础认证；业务插件管工具、页面、业务参数、数据授权和验收。

换句话说，它沿用官方机制而不魔改，接新插件不用动 DSH 或管理器源码。但它也不越界——可信身份不等于业务数据许可，应用还是得自己检查用户能读哪些文档或报表。README 也声明了这是社区独立维护的非官方项目。

对我自己学智能体开发有什么帮助

最大的收获是它给了一条"从插件到应用"的完整参考路径。examples/ 和 plugins/dsh-example 从最小独立 Bundle、复用统一登录的 kit 示例，一直到带流式对话和历史记录的完整问答应用，基本是渐进式的模板，照着走就行。

再就是它把智能体应用当工程对象来对待。声明、打包、版本化交付、就绪探针、受控启停，这些环节恰恰是 demo 变成可交付产品时最容易缺的。模型凭据管理也有一套完整约定：私有 .local/env.conf 和公开模板分开，网页只显示状态和不可逆指纹，改密钥走受控重启。接 DeepSeek、智谱这些不同提供方的时候很省心。