建议：提供官方插件更新生命周期与“重启扩展服务”能力

[GXX182]

这是对 #1231 的中文补充。#1231 主要讨论安全重启宿主；这里希望进一步讨论从“发现新版本”到“安全生效、失败回滚”的完整插件更新链路，以及长期是否需要类似 VS Code Extension Host 的独立扩展宿主。

背景

我正在为一个第三方插件增加基于 GitHub Tags 的版本检查。实际开发中发现：

• 检查新版本比较容易；
• 把新版本安全安装并立即生效很难。

当前已加载的插件代码涉及 ESM 模块缓存和仍在运行的 Cordis 注册。插件直接覆盖自身文件后，很难保证旧代码已完整卸载；使用 cache-busting 重新导入还可能产生重复模块实例。另一方面，让普通插件自己处理 Windows、Linux、Docker、systemd、PM2 等环境下的进程重启，也会带来权限、安全和可靠性问题。

因此，插件更新流程往往只能停在“更新已安装，请手动重启 DeepSeek Harness”。

已有社区实践

社区已经出现了相关尝试：

• #1812 dsh-check-update 已实现 DSH 与插件的新版本检测，但更新后仍需要用户执行命令或手动重启；
• #2687 社区插件市场 展示了插件安装、启停、卸载、备份回滚和一键重启的完整流程。

这些实践说明插件更新和生命周期管理存在明确需求。但目前相关能力由社区插件自行实现，不同插件需要分别处理包管理、配置修改、进程重启和跨平台兼容，也需要获得较高的系统权限。

因此，这些案例更适合作为官方提供统一、最小权限生命周期接口的依据，而不是长期让每个插件重复实现一套进程管理方案。

建议：分阶段提供官方能力

第一阶段：官方的安全重启能力

可以先提供一个由宿主控制的生命周期接口，例如：

await ctx.appLifecycle.requestRestart({
  reason: "Plugin update installed",
  waitForIdle: true,
})

建议同时提供：

• 设置页中的“重启扩展服务”或“重启 Harness”按钮；
• 重启前检测正在运行的任务，并允许等待任务结束或由用户确认中断；
• 保留会话、配置和轨迹数据；
• Web 页面在短暂断开后自动重连；
• 为 PM2、systemd、Docker、Windows 等环境定义统一的重启契约，例如稳定退出码或官方 launcher 行为；
• 仅允许经过授权的插件请求重启，真正的进程控制仍由宿主执行。

即使第一阶段暂时只能重启整个 Harness，也能先解决社区插件“更新后无法安全生效”的核心问题。

第二阶段：标准插件更新生命周期

建议由 Harness/CLI 提供统一的更新执行能力，而不是每个插件自行调用包管理器或修改运行目录：

1. 从 npm、GitHub Releases/Tags 等来源发现版本；
2. 下载到临时目录；
3. 校验插件清单、版本兼容性、校验和（未来可加入签名）；
4. 备份当前版本并原子替换；
5. 等待活动任务结束；
6. 重启扩展服务或 Harness；
7. 执行健康检查，失败时自动回滚。

插件可以负责展示版本信息和发起请求，但安装、替换、重启、回滚应由官方宿主能力完成。

长期方向：独立的扩展宿主进程

如果架构允许，可以考虑类似 VS Code Extension Host 的模式：

• 插件运行在独立进程；
• 更新插件时只重启扩展宿主，不必重启 Web UI 和核心服务；
• 单个插件崩溃不直接拖垮整个 Harness；
• 更容易实现权限隔离、资源限制和故障恢复；
• 从根本上避免已加载模块缓存导致的更新困难。

这会明显增加架构复杂度，因此可以作为长期方向；短期先落地官方的安全重启接口。

期望的用户体验

检查更新 → 查看版本与变更 → 用户确认 → 宿主下载并校验 → 备份旧版本 → 等待活动任务结束 → 重启扩展服务/Harness → 自动重连并健康检查 → 失败自动回滚

这样既能接近 VS Code 插件更新的体验，也能避免普通插件自行获得过大的文件系统和进程控制权限。

想请教维护者

1. 官方是否认可类似 appLifecycle.requestRestart() 的宿主能力？
2. 当前架构是否计划支持独立的插件/扩展宿主进程？
3. 官方期望的插件更新来源和安装接口是什么：npm、GitHub Release，还是统一 registry？
4. 是否可以采用“插件只能请求，宿主负责执行”的权限模型？

与 #2714 的关系

#2714 社区插件互操作标准 主要解决插件 Manifest、Capability 协商、兼容性判断与确定性生命周期问题；本提案聚焦其上层的实际更新执行链路，包括安装替换、安全重启、健康检查和失败回滚。

如果 #2714 的契约方向得到采用，本提案中的 plugin.update、lifecycle.restart 等能力可以作为独立 Capability Contract 接入其协商机制，两者可以互补而不必形成两套体系。

相关讨论

• #2714 社区插件互操作标准 v0.15
• #1231 Host capability: graceful self-restart for plugin managers
• #1812 dsh-check-update：DSH 更新检查器
• #1846 Community plugin registry contract + first-class plugin checks
• #2687 社区插件市场：生命周期管理与一键自动重启

[tianyicui]

感谢建议，把Cordis的HMR能力在DSH中使用得更好的确是我们正在做的事情，会持续优化相关的功能

[tianyicui]

关于你提出的四个具体技术问题，说实话我们也还没想好

[ylwl1997]

这条我很有共鸣——我们 dshbase 每天都在做「插件更新」这件事，而且是批量做：compat-check 每天对全部 npm 插件做 fresh-profile 安装验证，写回测试结果。几个月下来踩的坑基本就是这条帖子里描述的难点，补几个具体例子：

1. 旧代码卸载是真的难。node-pty/koffi 这类 native 模块，更新后 require 缓存 + 编译产物（pty.node）路径错位，会导致「明明装的是新版本，跑的还是旧二进制」。我们现在每次更新后强制 pnpm rebuild，否则静默用旧模块。
2. @deepseek-ai 的 dist-tag 是个隐形地雷。latest 指向坏的 rc 版本，插件声明 >=0.1.0 按 semver 解析不到正确版本，pnpm 报 "No matching version"。更新链路如果没处理 overrides，会把「升级」变「直接装不上」。
3. 验证 = 更新的最后一道保险。每次大版本更新，光 install 通过不算数，必须跑一次真实问答（L3）才能确认没有行为回归。我们验证了 1,777 个插件，失败案例大多集中在「作者更新了依赖但没重测」。

所以「重启扩展服务」之外，我们更希望官方提供一个可复用的更新验证基线（装→载→跑的最小流程），而不是让每个插件自己搞更新逻辑。我们的验证清单在 dshbase.com/plugins 开源，欢迎参考。