把「插件市场」本身做成一个插件（Plugin Marketplace as a Plugin）

[szx-a]

来自社区用户的建议，投在这里是希望和社区一起把它打磨成形，而非求立即实现。文中几处已刻意留白，标在"开放问题"里，欢迎维护者和社区一起讨论工程取舍。若我对现状理解有误，也请直接指出。

价值假设：将插件的发现、下载、安装、卸载封装成一个官方内置、可启停的元插件，让「一切皆插件」从技术事实变成可被普通用户使用的生态事实。

背景与动机

DeepSeek Harness 的「一切皆插件」在技术层面已经成立——ctx.registry / ctx.plugin / ctx.inject 让每个能力都是可替换的插件。但在分发层面，插件仍只能通过本地文件扫描被发现，没有下载、安装、卸载的用户路径：

• 现有插件设置页 ui-settings-plugin-inventory 是只读的 Loader 清单，其 Known Limitations 明确写着缺 provenance（出处）、grouping by source（按来源分组）、plugin mutation controls（安装/卸载）。
• 更硬的一个障碍在 ui-settings-plugins 的 Known Limitations 里：仓库外分发的插件无法把自己的配置暴露到设置页，因为配置暴露是 Host 白名单（packages/host/apiproxy 的 allowlist）而非插件声明。
• 官方 CONTRIBUTING.md 明确鼓励社区插件（关联 dsh-plugin topic 分享），并声明「不认为官方仓库的包天生比社区包更重要」「本仓库是 idea、官方 showcase、灵感来源，而非命令（mandate）」。

结论：分发与发现是当前生态链上缺失的一环。本文提议用「元插件」补上它，且不引入任何新特权。

提案：市场是一个插件

Plugin Marketplace = 一个官方内置的元插件，它做四件事：发现（浏览远程目录）、安装（拉取并落地）、卸载（移除）、信任呈现（标注来源与权限）。

因为是插件，所以：

• 可启停：用户不需要市场时可以禁用它，市场不成为强制常驻的负担——这与「一切皆插件」的自指哲学一致（连市场本身都是可替换的）。
• 挂进现有 slot：ui-settings-plugins 已声明 settings.plugins.tab 根列表 slot，现有 all（清单）和 configurable（配置）两个 tab 都是插件贡献的；市场就是第三个贡献同一 slot 的 tab，无需改造外壳。
• 复用既有读取：清单页已通过 ctx.remote.pluginInventory.list() 读 Loader 快照，市场在它之上增加写路径即可。

元插件的自指闭环

市场 UI 本身是一个插件 → 它出现在自己的清单里 → 用户能通过它禁用市场自己。这不是缺陷，而是「一切皆插件」哲学的可验证证明：没有不可替换的第一方能力。

清单规范：plugin.manifest.json

现有元数据散在 package.json 的 dsh 字段（如 dsh.client.inject、dsh.client.platform），但缺三样市场必需的声明：

字段	用途	现状
version / 兼容范围	校验能否装进当前 Harness 版本	无显式声明
dependencies	声明依赖哪些 seam / 其他插件	靠 peerDependencies 静态约束
permissions	显式的能力清单：这个插件要碰哪些 ctx 服务	无（靠 seam 注入隐式控制）

提议定义 plugin.manifest.json（或扩展 dsh 字段），让市场在安装前就能向用户展示「这个插件要什么权限、依赖什么、兼容什么」。

信任模型：判官 / 决策者 / 分发者三层

这是本提案与官方哲学咬合最紧的部分。信任不是「官方替你决定装什么」，而是「用户决定，官方和社区让这个决定成为知情的决定」。

角色	职责	现有依据
官方（判官）	签名、审查、信誉标注、下架恶意插件	官方市场目录
用户（决策者）	装什么、信谁、装后随时卸载	cordis 的 trust 字段「呈现差异而非强制执行」
社区（分发者）	任意 git / npm 源、dsh-plugin topic 自托管	CONTRIBUTING.md 鼓励的生态方向

关键原则沿用 agent-presets 的既有哲学：trust 字段用于呈现差异（标记 system / user / third-party），不是用于强制执行。用户看到「第三方、未审查、请求了 shell 权限」后仍可选择安装——选择是知情的，后果是用户的。

沙箱与依赖隔离

现状的沙箱是文件系统沙箱（fs-sandbox、sandbox-windows-acl、landlock-run），不是插件能力沙箱；依赖隔离靠 pnpm workspace 的 peerDependency 静态约束。

市场引入第三方代码后，需要补两件事，但建议分阶段、不阻塞 MVP：

1. 依赖隔离（先做）：安装时按插件独立解析依赖，避免版本冲突（pnpm 的孤立 node_modules 或 isolate realm 可复用）。
2. 运行时权限（后做，诚实标注难度）：cordis 插件是任意 JS，真正的运行时能力隔离在 Node 里是出了名的难做。第一阶段用「权限声明 + 知情同意」替代「强制隔离」——展示而非禁止，与信任模型一致；强制隔离（如 Worker/VM 边界）留作后续研究课题。

与现有架构的关系

组件	复用方式
ctx.registry / ctx.plugin	安装 = 注册一个新 Loader 条目；卸载 = 移除条目
ui-settings-plugin-inventory	市场在只读清单之上增加写路径 + 按来源分组 + 出处
ui-settings-plugins 的 settings.plugins.tab slot	市场作为第三个 tab 贡献
agent-presets 的 trust 呈现	沿用「标记而不强制」的 trust 哲学
apiproxy	解决「第三方插件无法暴露配置」的白名单问题（见开放问题）

开放问题（诚邀社区意见）

1. 配置暴露白名单：ui-settings-plugins 已点破——第三方插件如何在不改 packages/host/apiproxy 的前提下暴露自己的配置？这是第三方插件生态的第一道技术门槛，市场提案绕不开它。
2. 分发源协议：市场目录的数据源是什么形态——官方维护一个 JSON 索引？还是直接扫描 GitHub 的 dsh-plugin topic？如何防伪造与防篡改（签名、checksum）？
3. 安装后的信任持久化：用户对「第三方」的选择如何跨会话、跨重启记住；升级时如何重新确认。
4. 权限声明的粒度：permissions 声明到 ctx 服务级别，还是更粗/更细？如何防止插件声明与真实行为不符。
5. 运行时隔离的边界：若未来做强制隔离，cordis 的依赖注入模型如何在隔离边界内成立（服务注入天然要求共享内存）。

参考

• 官方 CONTRIBUTING.md：「不认为官方包天生比社区包更重要」「本仓库是 idea 而非 mandate」。
• ui-settings-plugin-inventory / ui-settings-plugins 的 Known Limitations（官方已列出 provenance / grouping by source / mutation controls 为 Deferred Work）。
• agent-presets 的 trust 哲学：the trust field exists so consumers can present that difference, not to enforce it.
• VS Code 扩展市场（权限展示 + 发布者 + 卸载）作为「知情选择」的成熟先例。

---

姊妹提案：记忆体（Memory Body）#1822

[Electricitysheep]

把插件市场做成官方内置、可启停的元插件——这个设计很妙：发现/下载/安装/卸载封装成一个插件，既满足市场诉求又保持"一切皆插件"的纯粹性。

我们第 7 章生态预测里提过"插件市场标准化是必然方向"（dsh-plugin topic + 数量增长催生市场），你这个方案把工程取舍（可启停/元插件）落地了。已收录进第 7 章作为生态方向参考：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/07-ecosystem.md

[szx-a]

感谢收录，很荣幸
另外我还有个姊妹提案《记忆体》#1822，欢迎顺手看看，也期待你的继续更新

[Electricitysheep]

谢谢！《记忆体》#1822 我看了——跨会话、隔离、用户显式挂载的记忆单元，正好戳中当前"记忆一锅乱炖"的痛点（会话结束日志就没了 / session-reference 只能 @提及 3 个源）。

这个提案和社区记忆家族（dsh-sgme 按场景注入/dsh-memory/AgentSoul）是同一方向的更底层设计——"记忆体"如果做出来，上面那些插件都可以挂在它上面。

已把 #1822 收录进手册第 8 章（记忆方向）+ 生态章节，会持续跟踪：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/08-tools-context.md

[szx-a]

朋友，打扰了，我刚初步搞完
有时间的话可以顺手看一下
#2468

这段时间我们把提案往前推了一步：记忆体（Memory Body）有了可运行的社区体验版 ，

核心我自已这边是还好的但目前考虑到npm中一些版本的兼容还没放开到npm里，所以暂时还没有一键下载，版本对齐的的情况下需要手动具体可见README.md
也可以先看这个了解情况：#2468

多记忆体 + 按会话挂载（/mount /unmount）
双权威记忆（用户钦定文档 / 模型总结）
自动总结 + 降权不删除
FTS5 检索（中英文子串）
GUI + 后台 JSONL 双编辑
源码：https://github.com/szx-a/ds

如果你有兴趣，欢迎看看，也期待你的反馈。handbook 后续若想收录记忆体相关的社区实践，我可以配合提供材料。