dsh plugin market 自定义安装怎么用：npm、GitHub 与 dsh 命令

把 GitHub 地址粘进 NPM 包卡片，红框立刻弹出来——这不是插件坏了，而是 dsh plugin market 的自定义安装根本不打算替你猜格式。 它把入口拆成 NPM 包、GitHub 源码、DSH 命令三张卡片，每张只认一种输入；贴错就地拦下，连请求都不会发（2.2.5 索引）。这篇不做功能罗列，而是拿同一个插件分别走三条通道做对照：你会看到三种输入、三种代价、三种失败回显，最后落到同一个确认弹窗。入口在 DSH Plugin Hub 的「自定义安装」页签。

什么时候该绕过目录：DeepSeek Harness 自定义安装的边界

自定义安装不是「高级安装」，而是「目录外安装」：市场里有的一律先用市场，市场里没有的才轮到它。 判断标准只有一条——这个插件是否已经被市场索引到。被索引到的条目带版本、分类、已验证徽章与一键安装按钮，来源和确认弹窗都是现成的；目录外的包没有这些信息，才需要你手动提供来源。

对照三条通道之前，先把「什么时候不该用」说清楚：

1. 市场里能搜到、且版本满足需求时，直接用市场安装，不要为了「练手」走自定义安装。
2. 只想临时试一个插件、又不确定来源时，优先找它的 npm 预构建版本，少走源码构建。
3. 插件是私有仓库、需要凭据才能拉取时，自定义安装不会替你携带凭据，先解决访问权限。
4. 已经装过同名插件时，先卸载或更新，不要用自定义安装再叠一层。

这四条不是限制，而是把自定义安装留给真正需要它的场景。市场安装与自定义安装的差别，不只是入口不同，还有后续的来源标签、更新方式和卸载路径不同。

NPM 包通道：dsh plugin market 里最省事的一条

三条通道里，NPM 包的失败率最低：它装的是预构建产物，不需要本地构建，也不依赖仓库有没有提交产物。 代价是你得先确认这个包真的发布到了 npm，并且版本是你要的。

1. 在 npm 上确认包名与最新版本，记下完整包名（含 @scope/ 时不要漏）。
2. 回到自定义安装页，选 NPM 包卡片，粘贴裸包名或 npm install <包名> 形式的命令。
3. 等格式预检通过，核对确认弹窗里的插件名与来源。
4. 装完去「已安装」按「手动安装」筛选，确认条目出现且版本正确。

NPM 卡片不接受 GitHub 地址，也不接受以 - 开头的参数；这两类输入会被当成格式错误或 npm 参数而不是包名。它装的是当前 profile 的依赖，不是全局 CLI，所以不会出现在系统级命令里。

GitHub 源码通道：DSH plugin 只有源码时的代价

GitHub 源码通道解决的是「只有仓库、没有 npm 包」的情况，代价是 git 分发只带你提交过的文件，构建产物没提交就会缺入口。 这不是通道的 bug，而是源码分发本身的边界。

1. 确认仓库是公开可拉取的，私有仓库需要你自己处理凭据。
2. 选 GitHub 源码卡片，粘贴 owner/repo、https://github.com/owner/repo 或 git+https://github.com/owner/repo。
3. 格式预检通过后，留意服务端会先检查 package.json 声明的入口文件是否真的在源码包里。
4. 安装过程中如果依赖带构建脚本，确认是否允许执行；只对信任的仓库放行。
5. 装完如果提示缺入口文件，改用该插件的 npm 版，或本地构建后再装。

源码通道最大的坑不是网络，而是「装上了但加载不了」。装前多看一眼仓库有没有提交 lib、dist 这类产物，能省掉一次回滚。安全边界与构建脚本的判断，见 怎么安全安装插件。

DSH 命令通道：dsh plugin market 只认 add 与 update

DSH 命令卡片是三条通道里最窄的一条：只认官方 dsh plugin --profile <名字> add 与 update 两种动词，卸载不在里面。 这样做的好处是，一条从文档复制来的命令不会顺手删掉你已装的插件。

# 卡片接受的官方形式
dsh plugin --profile web add <包名>
dsh plugin --profile web update <包名>
# --profile 是必填长选项，没有 -p 简写

1. 从插件文档复制完整命令，确认 --profile 后面是你要装进去的那个 profile。
2. 粘贴到 DSH 命令卡片，等格式预检通过；缺 --profile 会直接报错。
3. 核对确认弹窗，确认后等待安装完成。
4. 回「已安装」列表确认条目出现；更新场景下确认版本号已经变化。

命令卡片的语义是「在该 profile 目录里把参数转发给 pnpm」，所以它和手敲 pnpm 装依赖等价，只是路径与 profile 由 CLI 对齐。要批量管理已装插件，见 已安装插件怎么管理。

安装确认与失败回显：DSH Plugin Hub 的三道关卡

自定义安装会执行第三方代码，所以它安排了三道关卡：客户端格式预检、GitHub 源码的入口预检、装后入口校验。 三道关卡各自挡不同的错误，读回显时先分清自己在哪一道。

1. 格式预检失败：红框提示推荐格式，请求没有发出。改格式，不要改网络。
2. 确认弹窗出现：核对插件名、来源仓库与将要执行的命令，确认前不会写入依赖。
3. 入口预检失败：只发生在 GitHub 源码通道，说明仓库声明的入口不在源码包里。换 npm 版或自行构建。
4. 装后校验失败：即使安装命令退出码为 0，宿主也会核对入口文件是否存在；缺失即判失败并撤销待重启。
5. 还定位不到：去通知中心复制完整日志，再按下载、解包、依赖、加载四阶段对照。

失败回显里最值得读的是「哪一道关卡拦下的」，而不是最后一行红字。格式问题改输入，入口问题换来源，依赖问题看日志，三类处理方式完全不同。

装完之后：DSH plugin 在已安装列表里的手动来源

自定义安装成功不等于生效：条目会带「手动安装」来源标签，插件要重启宿主后才会挂载。 这也是它和目录插件最直观的区别——来源不同，后续更新与卸载的路径也略有差别。

1. 进「已安装」，按来源筛选到「手动安装」，确认条目与版本。
2. 按提示重启 DeepSeek Harness，再打开插件提供的入口、命令或面板。
3. 入口出现才算生效；没出现就回已安装看版本，再去系统日志看激活阶段。
4. 后续更新优先走该插件自己的发布渠道；卸载走已安装列表的卸载按钮，先确认再移除。

手动来源的条目不会因为市场收录了同名插件就自动变成目录条目，别把两套来源混着管理。

最后一条判断标准：如果你说不清这个包是从 npm、GitHub 还是某条命令来的，就不该在确认弹窗里点「确认」。 来源清楚，后面更新、回滚、卸载才有依据；来源含糊，装得再快也只是把问题往后推。想从零走一遍「npx 启动后装第一个插件」，可以接着看 npx 启动后装第一个插件。