更新deepseek harness后,直接启动失败了

[jeffsui]

各种插件报错,是因为dsh 修改了插件加载方式的原因吗？

[ciceroyang]

这条信息里还缺一个最关键的东西:启动失败时报错信息的前几行。DSH 的加载失败一般会把出问题的 loader entry 和插件 id 直接写在里面,形如:

plugin tree failed to load: failed to apply loader entry <entry> (<plugin>): <reason>

把这段贴出来基本就能定位类别。在你贴之前,升级后启动失败通常落在三类,可以按顺序自查:

1. 插件声明的 host 范围与新版 harness 不匹配

dsh plugin add 目前对 @deepseek-ai/* peer 范围不做校验也不给警告(我刚报了 #6680)。查法:打开出问题 profile 的 package.json,看 dependencies 里那个插件自己的 peerDependencies,再和实际安装的 host 版本比:

# 插件声明的范围
node -e "console.log(require('<profile>/node_modules/<plugin>/package.json').peerDependencies)"
# 实际安装的 host 版本
node -e "console.log(require('<DSH_HOME>/profiles/node_modules/@deepseek-ai/cordis/package.json').version)"

典型症状是加载时报某个 host 包 API 不存在。想一条命令看完所有不兼容项:

node doctor.mjs --profile ~/.dsh     # peer_range 项直接列出「插件声明 / 已装版本 / 不兼容」

2. profile 里固定的 bundle 还是旧版

升级 CLI 后,profile 的 dsh.profile.bundles 若仍指向旧版本,组合层时会失败。看实际组合结果:

dsh --profile <name> --dump-config

若某层版本明显落后,重新解析一次(例如 dsh plugin --profile <name> add @deepseek-ai/dsh-base@<新版>)。

3. 会话日志损坏也会阻断启动

和插件无关,但症状同样是「起不来」:会话日志的第一个 zstd 帧必须恰好一行 session header,否则整个启动/会话列表会失败(#6651)。确认与临时隔离的办法是把那个会话目录移出 sessions/(不要删),再看是否恢复。

方便的话把这三样贴上来——错误头部、上面的 doctor 输出、--dump-config 的层列表——我可以对着看。只贴「各种插件报错」的话,大概率是在这三类里,但无法区分是哪一类。

[ciceroyang]

补一条更直接的恢复路径(在 @moonquake2004 刚发的 #6678 里):

npx @moonquake2004/dsh-doctor --boot-check --profile web        # 离线模拟加载,直接指出哪个 entry 失败
npx @moonquake2004/dsh-doctor --quarantine <pkg> --profile web  # 把坏插件移出启动列表,dsh 先恢复可用

我上面那条是「查清原因」,这两个命令是「先让 dsh 起来」。你现在卡在起不来,建议先用 --boot-check 拿到失败的 entry,再决定是修插件还是隔离。

[shubham-kr2002]

我们在安装许多插件时都会遇到这种情况，这可能是 Node.js 兼容性问题导致的；我使用的是 Node.js 24 版本，有些插件无法正常工作，所以我把它们卸载了。希望这对你有帮助。

[moonquake2004]

接着 @ciceroyang 的方案补两条更直接的，因为"升级后启动失败"这个场景有两个特点：原因通常就写在报错行里，而要修的是"环境里到底变了什么"。

1. 那条报错行本身就能定类。 形如 plugin tree failed to load: failed to apply loader entry <entry> (<plugin>): <reason> —— 把 reason 那半句对照下面即可，不必先跑任何工具：

reason 里出现	类别	通常的修法
does not provide an export named …	插件用了已被移除/改名的 API	升级该插件到匹配版本
ERR_MODULE_NOT_FOUND	依赖或包本身没装全	在该 profile 里重装它
NODE_MODULE_VERSION / compiled against a different Node.js version	Node 升级后原生模块失配	重装该插件（rebuild）
ERR_PACKAGE_PATH_NOT_EXPORTED / ERR_REQUIRE_ESM	上游未适配模块格式	升级该插件
加载卡住、超时	插件在加载期做阻塞操作	需上游修；先隔离

2. "升级后"这三个字意味着还有一个可查的东西：变化本身。 如果之前记过基线，--post-upgrade 会把核心版本、每个插件的版本、以及 entry 列表的增删一次列出来——它直接回答"这次升级动了什么"，比逐个插件猜要快：

npx @moonquake2004/dsh-doctor --pre-upgrade  --profile web   # 升级前（下次升级前记得跑）
npx @moonquake2004/dsh-doctor --post-upgrade --profile web   # 升级后：对比 + 逐条模拟加载

没有基线也能用 --boot-check：它不依赖任何历史记录，直接逐条 import 当前启动列表里的 entry，失败的会连同类别一起打印。

3. 关于"先恢复"的一点安心话：--quarantine 只改 profile 的启动列表，不动任何包文件，且必定先写 package.json.bak.<时间戳>；要放回是一条 --unquarantine <pkg>。所以"先隔离让 dsh 起来、之后再慢慢修"这条路是可逆的，不必担心弄丢什么——修复过程中 dsh 不可用才是真正的成本。

如果你把 npx @moonquake2004/dsh-doctor --boot-check --json --profile web 的输出贴出来（或就贴上面那条 loader 报错行），我可以直接告诉你属于哪一类、哪个插件、以及是"升级插件"还是"先隔离"。