zdjmrq/dsh-pluginmanager

README 摘要

dsh-pluginmanager · 插件架构师 你的 DSH 装了 100 多个插件？恭喜，你现在拥有了一座没有楼层指示牌的摩天大楼。 这个插件就是那张楼层指示牌——顺便把"哪层能拆、哪层是承重墙"给你标得明明白白。 dsh-pluginmanager 是 DeepSeek Harness Web 的设置页插件管理器。它把全部插件从一张 100+ 行的大平铺（谢谢你，原生 all 标签页）整理成 三层架构视图 ，让"看懂 DSH 的插件体系"这件事从"考古"变成"观光"。 npm 包名与 GitHub 仓库名均为 dsh-pluginmanager 。安装、卸载与 dsh.profile.bundles 里请使用这个名称。 🏗️ 它到底解决了什么 DSH 的插件体系很强大，但原生的插件清单长这样： 谁负责 Agent 大脑？谁负责界面？谁是模型能调的工具？你装的扩展又混在哪？—— 都看不出来 。 这个插件把混沌整理成了架构： 🧭 三层架构，一眼看懂 1. 原生扩展（只读，承重墙） 原生插件按职责自动分成三层， 不提供任何卸载按钮 ——防止手滑把 Agent 的脑干摘了： 层 是什么 例子 系统层 Agent 系统运转的核心：模型、会话、沙箱、审批、子代理 dsh-llm 、 dsh-agent-loop 、 dsh-sandbox WebUI 层 浏览器界面的一切 dsh-client-ui- 、 dsh-client-connection 工具层 模型能调用的原生工具 dsh-tool-bash 、 dsh-tool-fs 、 dsh-tool-web 分层靠"包名前缀 + 官方 bundle 来源"判定，绝对 不会 因为你的扩展名字里带个 ui 就混进 WebUI 层——原生是原生，扩展是扩展，楚河汉界。 2. 用户扩展（自由区，可拆） 你自己装的一切：补丁行插件（手工放置的 balance、terminal 之类）、扩展包（bundle）、依赖插件。每行都有： - 停用 / 启用 ：只摘激活行，配置保留，可随时反悔 - 彻底卸载 ：激活行 + 依赖声明 + node modules 三连清，二次确认 - 补登记 ：把"手工丢进 node modules、没写进 dependencies"的插件正式登记进依赖——从此插件市场（marketplace）也认得它 - 未登记依赖 标签：一眼看出哪些是规范安装、哪些是野路子 3. 运行中（临时） 当前会话创建并运行的动态 Cordis 插件（ @pluginId 那些），只读展示，进程没了它们也就没了。 📝 描述系统：插件终于会说话了 - 内置 90+ 个核心原生插件 的中文名 + 一句话简介（比如 dsh-agent-loop = "Agent 主循环：调度模型步骤、并行分发工具调用"） - 每个插…

分类