[Proposal] WebUI 应具备插件故障隔离：非核心插件加载失败不应导致整个 WebUI 无法启动

[ANITOCE]

问题描述

DeepSeek Harness 的 Web 应用（dsh web）在启动时会按 profile 配置（dsh.profile.bundles、cordis.patch.yml、--patch 覆盖层）加载组合中的全部插件。目前任何一行插件在加载或初始化阶段出错（例如：依赖缺失、配置错误、apply() 抛异常、代码语法/运行时错误），都会导致整个应用启动失败：

• 整个 WebUI 无法启动；
• 终端输出的错误信息非常简短，通常只有几条笼统的异常，难以判断是哪个插件、来自哪个配置层（bundle / cordis.patch.yml / --patch）出错；
• 只能手动排查（逐行注释 cordis.patch.yml、卸载插件等）并重启，恢复成本高。

在「多个 bundle + 用户 patch 覆盖」的大规模组合下尤其脆弱：任何一个非核心插件的问题都会拖垮整体。

期望行为

希望 WebUI 的启动做到「核心优先、故障隔离」：

1. 启动只硬依赖核心插件：Web 应用骨架、路由、基础服务等核心插件（如 dsh-web-app 提供的部分）正常加载即可启动界面；非核心/可选插件不阻塞启动。
2. 插件错误不拖垮整体：某个插件加载失败时，将其捕获并标记为「加载失败」，该插件被禁用/降级，但 WebUI 照常启动，其余插件正常工作。
3. 启动后集中报错、便于定位：WebUI 启动完成后，在界面内展示故障详情（通知条 / 插件状态面板 / 诊断页面），至少包含：
   • 出错的插件名称 / 插件 ID；
   • 错误来源（哪个 bundle、cordis.patch.yml 或 --patch 中的哪一层/哪一行）；
   • 完整的错误信息与堆栈，而非当前的一条笼统信息。
4. 运行时崩溃隔离（延伸）：插件运行期抛出的未捕获异常也不应导致整个 WebUI 崩溃，而是标记该插件异常并提示用户。

整体思路类似 VS Code 的插件系统：扩展运行在独立的 Extension Host 中，扩展启动失败或崩溃只提示「扩展 xxx 已终止」，编辑器界面本身始终可用，通知中给出错误详情，用户可查看日志或禁用该扩展。

建议的实现方向（供讨论）

1. 插件分级：为插件行增加「关键/核心」标记（如 critical: true 或核心插件白名单），只有核心插件加载失败才中止启动，非核心插件失败走隔离路径。
2. 加载隔离：为每个插件的加载/初始化捕获异常，失败后将其从组合中移除或降级，并记录结构化错误（插件 ID、来源层、message、stack）。
3. 错误诊断面板：在 WebUI 中增加「插件状态 / 诊断」入口，汇总启动期与运行期的插件错误；同时在 dsh web 终端输出中给出带插件标识的详细错误。
4. 错误信息增强：所有插件错误输出应包含插件标识与配置来源（哪个文件、哪一行、哪个层），帮助用户直接定位。

边界情况

• 核心插件失败仍应阻止启动（缺少核心能力时 UI 无意义），但错误信息必须足够详细；
• 插件间依赖：若 A 依赖 B，B 失败导致 A 连锁失败时，诊断信息应展示失败链（A 失败原因 → 依赖 B 加载失败 → B 的错误详情）；
• 修复插件后应能恢复正常（热重载或重启即可），不需要清空数据。

收益

• 可用性：单个插件问题不再导致整个 WebUI 不可用；
• 可诊断性：错误定位从「手动逐行排查」变为「界面直接指出插件与原因」；
• 可维护性：降低用户在多层组合、第三方插件场景下的试错成本；
• 与「Everything is a Plugin」的定位一致：插件生态越大，越需要健壮的故障隔离。

补充说明

• 复现方式（示例）：在 cordis.patch.yml 中新增一个存在问题的插件后运行 dsh web，进程直接失败，界面无法打开，终端错误难以定位具体插件。
• 相关概念：profile 由 bundle patch 层与 cordis.patch.yml、--patch 覆盖层组合而成，报错时标注来源层即可大幅降低定位成本。

[weijiafu14]

这个提案我强烈支持，而且可以提供一个存在性证明：故障隔离是能做的，我们在自己的挂载路径上就是这么做的。

一个已经在跑的对照实现

我维护的兼容层在挂载它负责的那批插件时，挂载失败不炸启动、也不炸 Agent：按能力缺口分级捕获，记进一个账本，然后一次性告诉用户"哪个包的哪个能力不可用、其余照常、如果这就是你装它的主要用途、建议卸载它"。也就是你提案里的第 2 条 + 第 3 条。

做下来有两个经验值得写进你的提案：

1. 分级比二元的"成功/失败"有用得多。 同样是"没挂上"，"这个包整个起不来"和"这个包的某个能力不可用、其它照常"对用户的动作完全不同——前者该卸载，后者可能根本不影响他的用法。只报一个"加载失败"会让用户过度反应。
2. 报错要说"哪个功能不工作、以及要不要紧由你判断"。 我们踩过的坑是替用户判断"这是不是核心能力"——判不了。文案改成陈述事实 + 给出卸载建议，比替他下结论好。

但这条不覆盖你要的场景，必须说清楚

我们的隔离只作用在经这座桥挂载的那批插件上。DSH 原生的 cordis 插件行仍然是全有全无——你在提案里描述的那个"任何一行插件出错就整个 WebUI 起不来"，我们改不了，那在宿主的加载器里。

所以我这条只能作为"这件事可行"的旁证，不是替代方案。

给现在被卡住的人（这帖搜到的人多半是）

在官方做隔离之前，恢复和预防的办法：

• 恢复：把出错那条从当前 preset 的 agent.cordis.yml 里注释掉或删掉再重启；或 dsh plugin --profile <p> remove <包名>。（我让dsh给我装插件，自己把自己装死球了。 #708、在尝试让其链接yakit的mcp服务后出现错误，导致无论是新建会话还是项目都会出现同一个错误，无法让会话进行下去 #522、在让dsh 开发一些插件的时候，或者对dsh本身做一些操作的时候，应该加上一些限制 #1838 都是同一族现象，那几帖里有更细的步骤。）
• 预防：新插件先装进一个单独的 profile 试（dsh plugin --profile dev add ... → dsh --profile dev）。profile 之间的插件组合是隔离的，炸了不影响主力那个。

你提案里的第 3 条（报出是哪个 bundle / 哪一层 / 哪一行）我觉得是最值钱的一条——现在这个"逐行注释二分排查"的过程，本身就是把定位成本转嫁给了用户。

利益相关：我维护 pi2dsh。上面"给被卡住的人"那段全是 DSH 官方机制，跟我的包无关；对照实现那段只是设计参考，不是让你装什么。

[leenkcool]

我是插件库，我感觉你的插件很好，我想收录，可以提ISSUE。 具体提的方法如下。
#4456