DeepSeek Harness 插件推荐与安装教程

📚 系列导航：上一篇 DeepSeek Harness 插件架构教程 已经解释 Profile、Bundle 和 Cordis 插件树；本篇从社区插件清单中筛选实用插件，并完成安装、验证与卸载；下一篇 DeepSeek Harness Python SDK 使用教程 会用程序接口启动同一套运行时。

DeepSeek Harness 插件不用一次装满。刚开始最值得装的是 dsh-at-file 和 dsh-notification；需要撤回文件修改时再考虑 dsh-turn-rewind，需要可视化、分享或自定义能力时按场景增加其他插件。 本文参考 Awesome DSH Plugin 精选列表，但推荐不代表官方背书，安装前仍要检查源码、版本和权限。

DeepSeek Harness 插件怎么选

选插件先看自己每天重复遇到的问题，不要只看演示是否炫酷。一个插件会进入指定 Profile 的依赖和配置层，可能同时贡献宿主能力、模型工具与浏览器界面，因此它比普通网页扩展拥有更深的执行位置。

安装前至少确认四件事：仓库是否公开源码，README 是否写明兼容条件，安装是否会执行构建脚本，以及插件会接触哪些文件、网络或凭据。精选列表只是发现入口，不能代替安全审查。

dsh-at-file 和 dsh-notification 如何提升日常操作

dsh-at-file 解决的是“怎样准确告诉 Agent 看哪个文件”。在 Web 输入框键入 @ 后，可以搜索工作区文件或目录并附加内容，省去手打长路径，也减少模型猜错文件的概率。目录引用会递归展开，所以大型仓库不要直接附加顶层目录；插件还会拒绝超过上限的单个文件。

它目前不支持在 @path 中使用空格或另一个 @，新创建的文件也可能要等索引缓存刷新后才出现。文件名包含空格时，可以改用文件工具读取，或先用不含空格的相对路径验证。

dsh-notification 解决的是“长任务结束时怎样及时知道”。浏览器在回合完成、报错或其他选定结果出现时发送桌面通知，还能用关键词包含和排除规则过滤消息。它依赖浏览器 Notification API，需要授权通知权限；默认只在页面位于后台时提醒，适合边等待边处理其他工作的场景。

这两个插件都面向 web Profile，而且功能单一、学习成本低，适合作为第一批插件。先分别安装和验证，再决定是否增加更复杂的恢复或自定义工具插件。

dsh-turn-rewind 如何恢复项目文件

dsh-turn-rewind 会在用户消息旁增加回退入口，让你先预览受影响文件，再选择“恢复文件并重新开始”或“只恢复文件”。它在真正恢复前还会建立救援点，并检查预览后文件是否又发生变化，适合 Agent 连续修改多个文件后回到明确边界。

它不是 git reset 的图形按钮。插件不会提交、stash、切换分支或修改 Git 索引，也不会自动决定要撤销哪些内容。当前恢复范围以 Git 工作区文件为边界，不支持非 Git 目录、被忽略文件和 Git 元数据；如果未管理文件占用了待恢复路径，操作会失败，而不是擅自删除文件。

因此，回退插件适合给正常 Git 项目增加一层交互式保护，但不能代替提交、分支和远程备份。第一次使用时先在临时仓库制造一个可丢弃改动，确认预览和恢复结果符合预期，再放到重要项目中。

dsh-visualize 和 dsh-share 如何展示结果

dsh-visualize 让模型调用 visualize 工具，把工作区中的 HTML 片段渲染成对话内交互卡片。图表、对比面板、简单模拟器和 UI 原型比纯文字更容易理解，明暗主题也会跟随 Web UI。

卡片运行在带 CSP 的沙箱 iframe 中，不能随意发起网络请求，数据要内联并控制体积。该能力只完整显示在 Web UI；TUI 和 headless 会降级为工具结果文本，所以不要把它当成跨客户端通用输出格式。

dsh-share 则把一轮问答生成 PNG，可以保留 Markdown、代码块、表格和工具摘要，也能隐藏过程，只分享提问与最终回答。它适合把排障结论或方案发给同事，不需要修改 Harness 核心代码。

复制图片依赖浏览器剪贴板权限，权限不足时仍可下载 PNG。分享前仍要检查图片里是否包含密钥、内部路径、客户数据或未公开代码；“不展示过程”只改变导出内容，不能自动完成脱敏。

dsh-custom-tool 适合哪些进阶场景

dsh-custom-tool 允许在设置页用 JavaScript 创建持久工具，也允许模型通过 custom_tool_create 和 custom_tool_remove 管理它有权管理的工具。常见用途是封装一个固定 API、重复的文本处理逻辑，或工作区里的小型文件流程。

它把代码放进独立 Worker 和 node:vm 环境，限制执行时间、内存与结果大小；但这不等于可以运行不可信代码。插件默认允许 fetch，工作区作用域还能读写当前会话目录，而且仓库明确说明路径约束不是防符号链接逃逸的完整沙箱。

如果只是偶尔执行一次脚本，先使用现成 Shell 或 Code Mode 工具。只有逻辑会反复调用、输入输出契约稳定，并且你能审查 JavaScript 与网络目标时，才值得把它做成自定义工具。启用后先用无敏感数据的测试输入检查返回结构和失败行为。

DeepSeek Harness 插件如何安装

官方 CLI 的基本格式是 dsh plugin --profile <name> <pnpm 参数>。它会把参数转发给 Profile 目录中的 pnpm，并在安装成功后把声明了 Bundle patch 的依赖加入配置层。上面大多数界面插件只装进 web Profile，不要因为同时存在 headless 就机械地装两遍。

先确认 CLI 和 Profile 可以正常运行，再挑一个插件安装：

dsh --version
dsh --profile web --dump-config

# 文件引用
dsh plugin --profile web add \
  https://github.com/omdsh-dev/dsh-at-file/archive/refs/heads/main.tar.gz

# 桌面通知
dsh plugin --profile web add \
  https://github.com/omdsh-dev/dsh-notification/archive/refs/heads/main.tar.gz

# 自定义工具
dsh plugin --profile web add \
  https://github.com/omdsh-dev/dsh-custom-tool/archive/refs/heads/main.tar.gz

这些 main.tar.gz 地址会随主分支变化，适合体验，不适合追求可复现的团队环境。正式使用时应改为作者发布的 tag、固定提交或经过审查的本地 checkout。比如 dsh-share 仓库给出了固定版本安装方式：

dsh plugin --profile web add \
  --ignore-scripts --config.auto-install-peers=false \
  'github:hellodigua/dsh-share#v0.1.0'

dsh-turn-rewind 当前需要先在本地 checkout 中安装依赖并运行检查，再把目录加入 Profile；dsh-visualize 也采用本地 clone 和 link: 安装。遇到这类流程，不要跳过仓库 README 中的构建、兼容性与重启说明。

安装完成后重启正在运行的 dsh web。浏览器端插件通常在进程启动时组合客户端 bundle，只刷新页面不一定会加载新插件。

DeepSeek Harness 插件如何验证、升级和卸载

不要一次安装六个插件再统一排错。每装一个就重启、检查配置树和最小功能，这样能判断失败发生在依赖安装、Bundle 激活、浏览器权限还是插件自身。

# 查看插件是否进入 web Profile 的最终配置
dsh --profile web --dump-config

# 查看 Profile 为什么安装了某个包
dsh plugin --profile web why dsh-at-file

# 删除插件依赖和它贡献的配置层
dsh plugin --profile web remove dsh-at-file

通过包名安装的插件可以使用 dsh plugin --profile web update <package>；通过分支 tarball、Git spec 或本地目录安装的插件，应按作者说明重新执行 add，必要时加 --force。升级前记录当前版本并备份 Profile 配置，升级后重复最小验证。

卸载时要使用 package.json 中的真实包名，而不是只凭仓库名猜测。例如 dsh-share 的包名是 @dsh-external/dsh-share。移除后重启 Web Profile，再检查设置入口、工具 Schema 和最终配置是否消失。

常见问题

Awesome DSH Plugin 中的插件都是官方插件吗？

不是。该仓库是社区精选列表，插件由不同作者维护。是否兼容当前 DeepSeek Harness、是否安全和是否持续维护，都要回到具体仓库核实。

插件安装成功，为什么页面没有变化？

先重启 dsh web，再确认插件装进的是正在使用的 web Profile，并通过 --dump-config 检查 Bundle 是否进入最终配置。涉及通知或剪贴板时，还要检查浏览器权限。

可以一次安装所有推荐插件吗？

不建议。先装 dsh-at-file 或 dsh-notification 验证基本链路，再按实际需求增加插件。插件越多，版本冲突、权限范围和排障成本也越高。