发现、核验并安装社区插件

截至 2026-08-30，Awesome DSH Plugin 的固定提交 64b4c2831fcd 中包含 2,666 个插件 manifest 文件、22 个分类，覆盖 UI、模型、记忆、工具、工作流、远程访问和插件市场等方向。这个数字来自仓库树快照：它说明可发现规模，不保证每个条目都独立、兼容、安全或仍适合当前版本。

插件之外还存在桌面客户端、TUI、Skill、MCP Server、Profile / Preset、兼容性工具和社区手册。DSH101 本次从公开仓库中筛出 22 个新增代表项目，生态目录合计 31 个入口；目标是给出不同形态的起点，而不是制造排行榜。

被目录收录，只能证明它可被发现。它不等于源码审计、安装测试、安全背书或长期维护承诺。

先选发现入口

四条入口适合不同阶段：

入口	适合什么情况	你会得到什么
Awesome DSH Plugin	想浏览声明了 Bundle manifest 的插件	2,666 个 manifest 快照与 22 类插件入口
Awesome DeepSeek Harness	想把插件以外的项目一起看	Skill、MCP、Profile、编排器、客户端与资料入口
`dsh-market`	想在 Web 设置内浏览和管理插件	搜索、分类、安装确认、更新与移除界面
`dsh-find-plugin`	已经能描述需求，但不知道包名	Agent 按关键词搜索 Topic，返回仓库、简介和安装命令

安装发现工具本身也属于安装第三方插件：

dsh plugin --profile web add dshmarket
dsh plugin --profile web add dsh-find-plugin

这两条命令来自对应社区仓库，不是 DSH101 的独立运行结果。执行前同样要完成下文检查。

本次新增项目怎么选

DSH101 优先保留“用途明确、公开源码、存在可核验入口”的代表项目，并按形态分开：

方向	本次纳入的代表入口
桌面与终端	DSH Desktop、dataelement DSH Desktop、Tauri Desktop、Harness Studio、dsh-TUI
Web 与工作台	dsh-web、Better Sidebar、dsh-context
视觉与本机能力	ModLens、dsh-image-gen、dsh-computer-use
Agent 与状态	dsh-agent-teams、dsh-routing-suite、dsh-knowledge-sqlite
集成与开发	dsh-lark-link、dsh-plugin-check、upstream-radar、dsh-plugin-graph
学习与规格	DSH Plugin Development Guide、dsh-specs、DeepSeek Harness 橙皮书、广义生态目录

在生态目录中可以按插件、客户端或指南筛选，并搜索名称、用途和安装命令。所有新增第三方项目都保持“仅收录”：本站核对了公开说明、入口和核验日期，但没有把项目自述提升为独立安装或任务实测。

没有纳入也可能是有意为之。例如 dsh-at-file 的仓库已明确说明，当前官方版本内置 @file 与 @session 引用；新安装应优先使用官方实现。仅仅在 README 提到 DSH、但没有清晰兼容入口的通用项目，也不会因此被当成 DSH 插件。

安装前检查五件事

1. 仓库与包是否对应

确认 README 中的包名、仓库地址和安装命令一致。检查 package.json 是否声明 dsh.bundle，以及它指向的 patch 文件会加载哪些模块。没有 Bundle manifest 的包可以成为普通依赖，但不会自动贡献可启用的配置层。

2. 安装脚本会执行什么

从 GitHub 安装拿到的是源码。TypeScript 插件常用 prepare 在安装后构建；pnpm 10 及以上默认阻止这类脚本，只有你在 Profile 的 pnpm-workspace.yaml 中加入 allowBuilds 后才会执行。

这项授权发生在 Agent Sandbox 之外。先阅读 prepare、它调用的脚本及依赖，再决定是否允许；不要把“安装成功”误认为“代码安全”。

3. 插件会获得什么能力

插件代码运行在 Harness 进程里，可以注册服务、事件和工具，也可能读取进程可见的文件、凭据与网络。工具审批约束 Agent 的工具调用，并不会自动隔离插件自身的代码。

优先选择职责单一、配置边界明确的插件。远程访问、Shell、凭据、自动更新和消息转发类插件需要更严格的检查。

4. 是否能固定到确定版本

GitHub 安装应固定完整 commit，避免上游后续推送静默改变你实际运行的代码：

dsh plugin --profile review add github:owner/repository#<full-sha>

记录仓库、commit、核验日期和允许的构建脚本。npm 包也应固定版本，并确认注册表包确实由目标仓库维护。

5. 是否能在隔离环境验证

第一次安装使用单独的 review Profile、一次性 checkout 或容器，不要直接进入保存真实密钥和未提交工作的主环境。安装后先检查最终组合，再运行最小任务：

dsh --profile review --dump-config
dsh --profile review

确认新增层、网络监听、文件写入和卸载行为符合预期，再考虑迁移到日常 Profile。

给每个候选项一个证据等级

DSH101 使用四级状态，避免把“见过”写成“验证过”：

仅收录：目录里有链接，但未检查源码。
已核源码：读过入口、manifest、脚本和主要权限边界。
已验安装：在记录过的系统与版本中完成安装和卸载。
任务实测：在最小真实任务中观察到预期结果，并保存环境、命令和日期。

生态目录中的所有新增社区项目，以及 dsh-market 与 dsh-find-plugin，目前都保持“仅收录”。本站核对了公开说明、安装或下载入口与仓库状态，但尚未把它们标成独立安装或任务实测。

出问题时先撤回

从测试 Profile 移除插件：

dsh plugin --profile review remove <package-name>

随后重新执行 --dump-config，确认对应 Bundle 层已经消失。如果安装脚本在 Profile 目录之外写入了文件，CLI 移除依赖并不保证清理这些副作用；这也是首次验证应放在可丢弃环境中的原因。