做了个神秘启动器，可以创建多个 dsh 实例或 profile（可以选版本），不同实例的 DSH_HOME 可以不互通或者互通

[Gu-ZT]

非 DeepSeek 官方产品。未获 DeepSeek 许可，亦与 DeepSeek 无任何关联。

官网：http://dsh-plug.in/
下载地址：https://github.com/dsh-plugins/dsh-launcher/releases

[Gu-ZT]

[Gu-ZT]

[weijiafu14]

「不同实例可以选版本」这个能力很实用，但它也正好踩在 DSH 依赖树里最容易出事的那条线上。我们做发版回归时被这件事咬过，把踩过的坑贡献出来——纯技术信息，不推销任何东西。

核心事实：DSH 的 core 是由 CLI 的依赖树提供的，profile 里不该有自己的 core 拷贝。

正常情况下（pnpm@11 + autoInstallPeers: false），一个 profile 的 package.json 里只有 bundles 和插件那三五个条目，不解析任何 @deepseek-ai 核心包——核心包来自 @deepseek-ai/dsh 这个 CLI 包自己的依赖树。

所以对你的启动器来说，有两个状态需要当成故障来检测：

1. profile 的 node_modules 里出现了核心包的拷贝；
2. 树里两代核心混装（例如 CLI 是 0.1.1-rc.2，而 profile 里躺着一份 0.1.0-rc.8 的核心包）。

为什么这条对"可选版本"的启动器特别重要：这正是 #4640 报的那个故障——profile 里多出一份 @deepseek-ai/dsh-tools，agent loop 按 module-local 的 Symbol() 去 ToolRuntime 上找 scheduler，两份拷贝铸出两个不相等的 symbol，查找返回 undefined，该 profile 里每一次工具调用都死在 .prepare。加载期毫无报错，错误信息既不提是哪个工具、也不提哪个包重复了，用户看到的是"这个实例的模型不会用工具了"。#4667 那位就为此做了一次 jsonl 考古。能创建多实例多版本的工具，最有可能批量制造这个状态。

建议在启动器里加一条启动前自检，成本很低：

• 回读 CLI 树里的核心包版本，和用户为这个实例选的版本比对，不一致就报出来；
• 扫一遍 profile 的 node_modules，发现任何 @deepseek-ai 核心包就警告（正常不该有）。

另外三条 per-profile 的事实，你的用户大概率会问：

1. 插件挂载发生在启动时——加/卸插件之后必须重启那个 dsh 实例才生效。卸载顺序上，先卸插件再卸引擎类的东西。
2. profile 的组合安装是 CLI 私有流程：要重装时重跑 dsh plugin add，别直接在 profile 目录里裸跑 pnpm install，那样装出来的树和 CLI 期望的不一样。
3. dsh plugin 内部调的是 PATH 上的 pnpm，而 profile 是 pnpm@11 初始化的。如果用户机器上的 pnpm 是别的大版本，会出现莫名其妙的假失败——你的启动器如果能固定一个 pnpm@11 给它用，能省掉一大批支持工单。

以上都是我们在自动化回归里实际撞出来并写进内部规范的，不是读文档推的。

利益相关：我维护一个第三方 DSH 插件（Pi 生态兼容层），所以我对 profile/DSH_HOME 这套东西熟，是因为我们的 E2E 装置天天在建一次性 profile。我在这里没有任何要推荐给你或你用户的东西——上面每一条都是宿主自己的行为。

[Gu-ZT]

感谢你把这几条坑位整理出来——我们逐条对着代码核过了，大部分和我们已实现的行为一致，但确实有三处是我们没堵住的，已按你的建议补上。汇报一下核对结果和改动，纯事实。

我们原本就避免的（核对过实现）：

1. core 不来自 profile。版本安装是 pnpm install --prefix <启动器数据目录>/versions/<ver> @deepseek-ai/dsh@<ver>，装进启动器自己的目录；core 完全由 CLI 依赖树提供，启动器从不往 profile 的 package.json 写任何 @deepseek-ai 核心包。多实例多版本之间不共用 node_modules，每实例用所选版本的 bin.js + 自己的 DSH_HOME 启动。
2. profile 首建交给 CLI 自己做。ensure_web_profile_template 是启动 node bin.js --profile web、等 CLI 打印出 web URL（说明 profile 已 materialize）后终止、再复制成模板，没有手工拼 profile 骨架。这条恰好呼应你说的"组合安装是 CLI 私有流程"。

我们没避免的，以及已做的修补（三个 commit，尚未推送）：

1. 启动前自检（新增）——你建议的这两条都做了：启动前读 CLI 树里 @deepseek-ai/dsh 的实际版本与实例所选版本比对；扫 profile 的 node_modules/@deepseek-ai/，发现任何核心包即告警。当 profile 里的拷贝版本与 CLI 树不同代时，升级为 error 级——直接点名 Bug: a duplicate `@deepseek-ai/dsh-tools` inside a profile silently breaks every tool call #4640 的场景（两份拷贝铸出不相等的 Symbol()，工具调用死在 .prepare），提示语建议用户卸载该包重装。自检是非阻断的：结果写 latest.log + 前端通知，不拦启动，避免误报挡住用户。
2. pnpm 固定 11。你的第 3 条正中要害：我们原本"系统 pnpm 优先、缺失时装 pnpm@latest"，完全不校验大版本。现在系统 pnpm 主版本非 11 一律不用，改用启动器内置的 pnpm@11，并在任务日志里说明原因。
3. auto-install-peers=false 落盘到 profile 的 .npmrc，安装和卸载（pnpm remove 会重解析依赖树）之前都写。按 profile 持久化，不受用户全局 pnpm 配置影响。

另外把你另外两条 per-profile 事实做进了 UI：插件安装/卸载后提示"需重启实例才生效"，插件页说明补充了先卸插件再卸引擎的顺序。

以上改动会在下一个 dev 构建里发布，到时候如果有新发现的边界情况，欢迎继续丢过来。

[Gu-ZT]

[Gu-ZT]

[Gu-ZT]

[Gu-ZT]

[Gu-ZT]

[Gu-ZT]