DeepSeek Harness 安装报 ERESOLVE？DSH plugin npm latest 冻结排查

DeepSeek Harness 装插件报 ERESOLVE unable to resolve dependency tree 或 ERR_PNPM_FETCH_404，根因几乎都在官方包族的 npm dist-tag：绝大多数 @deepseek-ai/dsh-* 包的 latest 冻结在首次公开发布版 0.0.1-rc.1，而这条旧线的 peer 元数据引用了改名前的死包名（npm 上 404）。 解析器一旦走到这条线，就同时拿到两条版本线或直接 404。避开的办法是把整个包族钉在同一条当前版本线上，并对已建好的 profile 用 pnpm.overrides 兜底。

DeepSeek Harness 安装报错长什么样：三种形态

同一个根因在三种入口下表现为三种报错，先认出形态再动手，能省掉大半试错。 社区实测记录（#2763、#984）：

1. ERESOLVE 版本树冲突：全新项目里裸装 @deepseek-ai/dsh-agent-spine-demo 等包，报 npm error ERESOLVE unable to resolve dependency tree，明细里能看到 peer @deepseek-ai/dsh-bash-env@"^0.0.1-rc.1" from @deepseek-ai/[email protected]——即旧 line 的 peer 声明；而 @deepseek-ai/dsh-bash-env 在 npm 上根本不存在（npm view 返回 404）。
2. pnpm 直接 404：ERR_PNPM_FETCH_404 GET https://registry.npmjs.org/@deepseek-ai%2Fdsh-type-meta: Not Found。缺的是 dsh-type-meta，它由 dsh-tools / dsh-session 的 peer 链间接拉取；@deepseek-ai/dsh-tasks、@deepseek-ai/[email protected] 也是同一形态。
3. 装到老版本误以为包不存在：dsh plugin --profile <name> add @deepseek-ai/dsh-base 装到的是 latest 解析出的 0.0.1-rc.1，随后报「没公开 / 不存在」——包是有的，只是 latest 指错了地方。

一个关键的判别信号：npm install 能过、pnpm 必挂。npm 走宽松解析，pnpm 默认严格解析 peer 范围并重解析整棵依赖树，所以同一个仓库用不同包管理器会给出完全相反的结论。对 DSH插件 和 DeepSeek插件 的安装脚本而言，这个信号同样成立。

DSH plugin 安装中为什么 npm latest 会冻结在 rc 线：dist-tag 与发布链机制

latest 不是「最新版本」，而是一个可以长期不动的标签；官方发布脚本对 prerelease 从不推进 latest，只把它们挂到 alpha / next，于是 latest 就一直停在早期 rc 线。 拆开看两层机制：

1. 标签层：latest 与 next / alpha 指向哪个版本，需要显式操作（npm dist-tag add）才会变（npm 文档）。实测抽查 13 个包时，dsh-agent-spine-demo / dsh-tool-bash / dsh-llm / dsh-session 等的 latest 都是 0.0.1-rc.1，只有 dsh-agent、dsh-app-boot 例外，next 则统一指向当前线——包族内部不一致，裸装自然混线。
2. 元数据层：0.0.1-rc.1 这条线的 peer 范围按改名前的包名书写（dsh-bash → dsh-shell、dsh-tasks → dsh-jobs、dsh-bash-env → dsh-shell-env），这些旧名在 npm 上从未发布，404 不可避免；作为对照，当前线的元数据本身是正确的，问题只在 latest 指向哪里。
3. pnpm 版本差异放大了它：profile 的 autoInstallPeers: false 写在 pnpm-workspace.yaml，而该 key 只在 pnpm ≥10 生效，pnpm 9.x 只从 .npmrc 读，于是被静默忽略，pnpm 回退到自动安装 peers，把整棵 peer 树（含 404 包名）都拉一遍（#984 机制补充）。
4. 发布节奏造成的时差是另一面：npm publish 先于 release 分支合入 tag，会出现「npm 上有包、GitHub 看不到对应 dsh-v* tag」的窗口；latest 冻结在 rc 线期间，npm i -g @deepseek-ai/dsh 装到的版本也会与仓库代码相差两条线（#5417）。

DSH plugin 怎么对齐 npm tag 安装：钉同一条线、@alpha 与 pnpm.overrides

核心做法只有一句：先查清 tag，再把「整个包族」钉在同一条线上，不要依赖默认解析。 社区已验证的步骤：

1. 查 tag：npm view @deepseek-ai/dsh-tools dist-tags，把 latest / next / alpha 各自指向的版本看清楚；npm view <包名> version 只会报告 latest 那条线，容易误判。
2. 全族统一钉线：在项目的 package.json 里把用到的 @deepseek-ai/* 全部写成同一条当前线（实测 ^0.1.0-rc.6 一版全新项目解析出 81 个包、正常安装并跑通含工具调用的完整回合）。只钉其中几个包、其余留给默认解析，仍旧混线。
3. 按需选线：想跟官方开发线就装 @alpha（实测窗口内 @deepseek-ai/dsh@alpha = 0.1.2-alpha.5），想稳就接受 latest 的 rc 线；要与仓库代码一一对应，以 GitHub 的 dsh-v* tag 为基准，alpha 可能领先半天到一天。
4. 已建 profile 不必重建：在 profile 的 pnpm.overrides 里为卡住的那个包指定可用版本即可。实测案例：[email protected] 声明 @deepseek-ai/dsh-tool-subagent": "*"，"*" 被解析到 0.0.1-rc.1、进而拉出 404 的 dsh-tasks；覆写为 0.1.0-rc.6（第一个去掉该 peer 的版本）后安装恢复。
5. 插件走本地安装也能绕开：dsh plugin --profile <name> add . 从本地 checkout 安装时，@deepseek-ai/* 由 harness 安装目录的 fallback node_modules 解析，缺失的 peer 根本不需要下载（#984）；插件依赖安装的其它失败形态另见 插件依赖安装失败排查。
6. 长期解法在官方：一次性把包族所有 latest 对齐当前线（或与 next 一致）即可消除绝大部分默认安装失败；社区量化口径是 325 个 npm 可装插件中 160 个受影响、全族 tag 对齐后可恢复 100 个。给插件市场提安装入口时，用 DSH Plugin Hub「设置 → 插件市场」装插件更稳——它安装失败会回滚 manifest，profile 不被污染，只是被卡住。

版本漂移还会引出另一类症状（装到旧版核心包导致工具调用崩溃 reading 'prepare'），机制与本文相关但不是同一件事：核心包版本漂移排查。

DSH plugin 排查注意事项

别拿 latest 当「当前版本」，也别只钉一部分包——混线比落后更危险。 五条要点：

1. 不要用 npm install @deepseek-ai/dsh-*@latest 判断「当前版本」，latest 可能落后两条线；npm view <包名> dist-tags 才是完整视图。
2. 混线比落后更危险：只钉部分包会同时装到两条线的 peer 范围，冲突是必然而非偶发。
3. 404 包名不要试图强行安装：dsh-type-meta、dsh-tasks、dsh-bash-env 等是改名前的历史名，npm 上没有对应实体，只能等发布链补齐或换成当前名的包。
4. pnpm.overrides 属临时措施：它让当前 profile 能用，但不会修好上游元数据；官方 tag 对齐后建议移除，避免长期钉住旧版本。
5. 安装失败后先确认 profile 未被写坏：pnpm 会在失败时中止整棵树，社区实测插件市场会回滚 manifest，但自行手工编辑过 profile 的话，装完先开一个全新会话验证工具调用是否正常。

来源：Discussion #2763、Discussion #984、Discussion #5417、npm dist-tag 文档。