DSH plugin 破甲插件装不上或失效？DeepSeek Harness 安装失败与安全拦截排查

DSH plugin（中文也常写作 DSH插件、DeepSeek插件）破甲插件装不上，通常不是单一故障，而是三类原因之一：包名或来源不可达、profile 与依赖问题、被安全策略拦截（来源）。 前两类是常规安装故障，可以按图谱修；第三类是平台主动拦下，属于预期行为。下面从四个方向把它讲全：① 三类原因怎么分，各自的典型特征；② 按报错原文逐层收敛的完整排查流程；③ 常见报错关键词对照表；④ 为什么策略拦截是预期行为、合规替代怎么走。破甲插件本身值不值得装，见《DeepSeek Harness 破甲是什么》。

DSH plugin 破甲插件装不上，先分清三种原因

「装不上」先按来源、依赖、策略三分，因为三者的处理方式完全相反：前两类要修，第三类要放弃（来源）。 三类的典型形态与「能不能修」可以先摊成一张表：

1. 包名或来源不可达：包名拼错、仓库被删或转私有、README 里的安装命令与实际包名不一致、npm 未发布、网络或镜像取不到——报错会指向「找不到 / 取不到」。
2. profile 与依赖问题：profile 目录里的依赖与当前 pnpm 大版本对不上、插件声明了未发布的依赖、构建脚本没被授权——表现为安装中断或装完不生效。
3. 被安全策略拦截：插件本身能取到，但平台按规则拒绝它安装或生效。这类不是 bug，重试、换源、改命令都不会有用。

先看清属于哪一类，再决定要不要继续折腾——把第二类当第三类会白费功夫，把第三类当第二类更可能踩到不该踩的操作。

先读报错原文：DSH plugin 常见报错关键词对照

排查顺序是「先读报错原文，再逐层收敛」：原文指出哪一层，就只查那一层，不要一上来就重装。 把常见关键词与类别对应起来，能省掉大量试错：

用法很简单：在输出里找这几组词，命中哪一组就跳到对应那一节；一组都没命中，才需要回到「检查 profile 是否正确」这一步。

DSH plugin 逐条排查：从包名与来源到 profile 与 allowBuilds

按下面顺序走，绝大多数安装失败都能定位到唯一原因：

1. 读报错原文。执行 dsh plugin --profile web add github:<owner>/<repo> 后，先看输出里关键词指向哪一类：404 / not found 偏来源，build / allowBuilds / dependencies 偏依赖，not permitted / denied / policy 偏策略。通用报错的总表与分流见《插件安装失败的排查总表》。
2. 核实包名与来源。对照插件 README 里的安装命令，确认仓库是否为公开存在、包名大小写与拼写是否一致；github: 直装与 npm 包名是两套来源，不要混用。
3. 检查 profile 与依赖。确认目标是 $DSH_HOME/profiles/web 这一 profile；若是 pnpm 大版本导致的依赖对不上，或依赖未发布，这类问题有专门解法，见《DSH plugin 安装卡在依赖》。
4. 看构建授权。若报错围绕构建被阻止，它属于 allowBuilds 授权问题而非包错误，逐档处理见《DSH plugin add 安装 Git 插件失败却提示 allowBuilds》。
5. 确认是不是策略拦截。若以上都对不上，而报错措辞是「不被允许 / 被拒绝」，就直接跳到下一节，不要继续尝试强制安装。

把「来源是否可达」和「装完是否生效」两步的校验点写清楚，排查会更快：

# 1) 装完后确认包确实进了这个 profile 的依赖
dsh plugin --profile web list
# 应看到目标插件出现在列表里；看不到就说明装到了别的 profile 或根本没装上

# 2) 确认它是否真的被加载（而不是只写进了 node_modules）
cat "$DSH_HOME/profiles/web/package.json"
# 应看到 dsh.profile.bundles 里包含该插件；只有 dependencies 有、bundles 没有，就是「装了没加载」

预期：第 1 步能看到插件名与来源，第 2 步能看到它出现在 dsh.profile.bundles 里。两步只要有一处对不上，就回到上面的顺序重查对应那一层。

被安全策略拦截是预期行为：DSH plugin 合规替代怎么走

当破甲插件的安装或生效被安全策略拦下，这是预期行为而不是故障——这类边界由框架执行，模型话术与安装技巧都改不了（来源）。 需要接受两点：

1. 拦截不是可修的 bug：平台按规则拒绝越权能力，这是有意的设计；重试、换源、改 profile 都无法让它通过。
2. 装上也未必有用：即使某条路径装上了，破甲插件能影响的也只是提示词或界面，改不了工具门禁与沙箱——这就是「装上了却不生效」的常见原因。

换句话说，「装不上」和「装上了不生效」在这一类插件上，往往是同一个事实的两种表现：它想绕过的边界根本不在插件能触及的范围内。

因此卡在策略拦截时的正确做法是换需求实现方式：用提示词工程类插件调整角色、语气与输出格式，它们只改提示词内容，不碰安全与权限边界。这类插件可以在 DSH Plugin Hub 的插件市场里按用途筛选，安装走标准 dsh plugin --profile web add 即可，一般不会再触发策略拦截。

关于 DSH plugin 破甲插件安装与拦截的常见误解

下面是搜索与讨论里最常出现的误解，逐条对照一遍：

1. 「装不上一定是插件坏了」——不一定。 先分类：来源、依赖、策略三类的成因与处理完全不同。
2. 「策略拦截换个源就能绕过去」——错。 拦截是平台规则，不随来源或重试改变。
3. 「构建失败说明包不可用」——错。 allowBuilds 是授权问题，包其实已经取到。
4. 「装上了就等于生效了」——错。 还要看它是否进了 profile 的加载列表，以及它承诺的能力是否在插件可及的层面。
5. 「强制装上就能用」——基本无意义。 破甲插件改不了工具门禁与沙箱，装上也不生效，还带来账号风险。

关于 DSH plugin 破甲插件安装与拦截的注意事项

把「装不上」先分类，再把「被拦截」当预期行为，绝大多数困惑就解开了。

1. 先分类再动手：来源、依赖、策略三分，处理方式相反。
2. 先读报错原文：原文指向哪层就查哪层，别一上来重装。
3. 别混来源：github: 与 npm 包名是两套来源，混用会并存冲突。
4. 构建授权不是包问题：allowBuilds 类报错按授权处理，不是仓库不可用。
5. 装完要看两处：list 里有名字、bundles 里有条目，才算真的装上并加载。
6. 拦截别硬来：策略拦截是有意边界，没有可靠的强制安装路径。
7. 装上也未必生效：破甲插件改不了工具门禁与沙箱。
8. 合规替代：提示词工程类插件风险可控，通用安装故障见《插件安装失败的排查总表》。

来源：DeepSeek Harness CLI 官方 README、DeepSeek Harness 官方文档 - 进程沙箱。