DeepSeek Harness 16 个热门插件整理：能力扩展、界面增强与安全安装指南

如果你把 DeepSeek Harness（简称 DSH）当成一个“能聊天的编程工具”，很容易低估它的扩展方式。它更像一个可以不断加装能力、替换界面和组合工作流的 Agent 运行环境：模型、工具、会话、Agent 循环和 Web 界面，都可以通过插件继续扩展。

本文整理自程序员鱼皮的公众号文章《16 个超火的 DeepSeek Harness 插件，大肥鱼已经落后 2 个版本了。。。》，把原文提到的 16 个插件按使用目的重新分组，并补充一条更稳妥的选择和验证路径。插件仓库、安装方式、依赖和兼容性会持续变化，下面的链接用于定位项目，实际使用前仍应以仓库 README 和本地版本为准。

先看结论：不要从“装满插件”开始

这 16 个插件大致可以解决三类问题：

目标	优先考虑	适合的任务
让 Agent 获得新能力	ModLens、ModSearch、dsh-browser、Agent Teams	看图、检索资料、操作真实网页、多 Agent 分工
让日常工作更顺手	dsh-market、dsh-web-ui、DSH-better-sidebar、dsh-context、dsh-TUI、dsh-genui、dsh-pocket	找插件、管理任务、查看文件和 Git、控制上下文、切换终端或手机
改变使用氛围	dsh-deep-whale、whale-girl、dsh-liang-skin、dsh-deepcel、dsh-ads	主题、桌宠、皮肤和社区创意玩法

最短成功路径是：

明确一个刚需
  → 只选一个插件
  → 阅读仓库 README 和权限说明
  → 安装并重启 DSH Web
  → 用一个可验证的小任务测试
  → 确认兼容后再组合第二个插件

如果只是想让 DSH 更像一个日常开发工作台，可以先从 dsh-market、dsh-context 或 DSH-better-sidebar 中选一个；如果要提升 Agent 的实际能力，优先从 ModLens、dsh-browser 或 Agent Teams 中选择与任务直接相关的插件。

DeepSeek Harness 是什么？

原文将 DeepSeek Harness 描述为 DeepSeek 的开源 AI Agent 运行环境，并将它与 Claude Code、Codex 一类 AI 编程工具放在一起比较。它的核心思路可以概括为“一切皆插件”：

模型适配器
工具注册表
会话日志
Agent 循环
Web 界面
      ↓
都可以被替换、扩展或组合

这类架构的好处是，用户不必等待官方把所有功能做进核心产品。社区可以分别补充视觉理解、浏览器操控、上下文分析、终端界面、多 Agent 协作等能力。代价是插件质量、维护状态、依赖和版本兼容性并不统一，需要把插件当作第三方代码来审查和管理。

插件从哪里找？

原文给出了三种发现方式：

1. GitHub 的 dsh-plugin 主题：更新快、数量多，适合发现新项目，但标签由项目作者自行添加，不能当成质量认证。
2. 社区维护的 Awesome DSH Plugin 清单：通常会按用途分类，适合快速浏览热门项目，但仍不是官方审核结果。
3. dsh-market 插件：把插件搜索和安装入口放回 DSH 内部，可以按功能关键词查找，也能根据已安装插件继续推荐相关项目。

发现插件时建议记录四个字段：仓库地址、最近维护时间、安装依赖、能访问或修改哪些数据。只看演示截图而不看 README，往往会把“能运行一次”误认为“适合长期使用”。

第一类：扩展 DSH 的实际能力

这一组插件会改变 Agent 能做什么，适合先围绕具体任务选择。

1. ModLens：让文本模型获得图像理解入口

ModLens GitHub 仓库

原文把 ModLens 定位为视觉能力补充插件。它的工作方式不是简单把图片变成一段 OCR 文本，而是把图片交给外部视觉模型解析，再将识别到的文字、布局区域和语义内容整理成结构化上下文，继续提供给 DSH。

它更适合：

• 把网页截图交给 Agent 检查页面还原度；
• 读取图片中的文字、组件和布局关系；
• 让 AI 编程任务拥有基本的视觉反馈；
• 处理“代码已经生成，但需要根据截图继续修改”的循环。

使用前要确认外部视觉模型的配置、图片是否会离开本机，以及视觉模型输出的结构是否足够稳定。对于包含密钥、个人信息或内部页面的截图，应先脱敏。

2. ModSearch：接入更多搜索源

ModSearch GitHub 仓库

ModSearch 用于扩展 DSH 的搜索渠道，原文提到可以接入 Firecrawl、Tavily、Exa 等搜索源，并继续扩展 Twitter 搜索能力。

它和浏览器操控插件的边界很重要：

需求	更适合的工具
从多个搜索服务检索公开资料	ModSearch
直接操作已经登录的网站	dsh-browser
需要深度检索或特定平台数据	ModSearch + 对应服务 API Key

如果没有配置相关搜索服务的 API Key，部分能力可能只能跑通基础路径。不要把“能找到一个链接”当成“实时搜索和完整检索已经可用”，应记录搜索来源、时间和是否经过原文核验。

3. dsh-browser：操作真实 Chrome 标签页

dsh-browser GitHub 仓库

dsh-browser 的重点不是启动一个全新的无头浏览器，而是连接电脑上正在使用的 Chrome 标签页。这样 Agent 可以复用已有的 Cookie、Session 和登录状态，读取网页、点击链接、填写表单、跳转页面，完成需要登录态的操作。

原文描述的组成是：

• DSH 侧的桥接插件；
• Chrome MV3 扩展；
• 两者之间的本地 WebSocket 通信；
• 把网页内容转换成带编号的可交互元素列表。

典型任务包括：

• 在 GitHub 页面中定位仓库、打开详情和读取信息；
• 在已登录的网站内搜索内容；
• 填写后台表单或执行重复的网页操作。

安装时除了 DSH 插件本身，还需要在 Chrome 扩展页面加载本地扩展目录。原文提到，扩展显示 Connected 后才算连接成功；实际使用中最好先打开目标网站标签，再从 Chrome 侧边栏发起控制，避免活动标签页切走 DSH 对话页面。

浏览器控制的风险高于普通问答。点击、输入和页面跳转应保留人工确认；发送内容、提交表单、发布帖子、删除数据等操作建议始终由人最终确认。

4. Agent Teams：把任务拆给一支 Agent 团队

Agent Teams GitHub 仓库

Agent Teams 用一个 Captain（队长）节点负责拆分任务、分配工作和汇总结果，再由多个成员 Agent 分别处理不同方向。

它适合：

• 代码审查：分别检查功能、性能和安全；
• 多维度调研：分别收集资料、验证事实和整理结论；
• 大型项目检查：按模块或职责并行推进。

这类插件的价值不只是“同时启动几个对话”。原文特别提到，团队和成员可以保留，后续只调度需要继续工作的成员。因此它更接近一个可复用的协作结构。

但多 Agent 不是越多越好。任务很简单时，增加成员会带来额外的调度时间、上下文消耗和结果合并成本。建议先把任务拆成两个或三个互相独立、能够分别验收的子任务，再决定是否需要团队。

第二类：增强工作台、界面和操作体验

这一组通常不会改变模型本身的推理能力，但会降低管理会话、文件、Git 和上下文的成本。

5. dsh-market：把插件发现做成工作流

dsh-market GitHub 仓库

dsh-market 相当于 DSH 内置的插件市场，主要解决两个问题：

• 按功能关键词搜索插件；
• 根据当前已安装的插件推荐相近项目。

如果你经常需要“先找一个能完成某项任务的插件”，它比手动翻 GitHub 更适合作为入口。不过推荐结果仍然只是发现线索，安装前仍应回到项目仓库检查来源、权限、依赖和维护状态。

6. dsh-web-ui：一套更完整的 Web 工作台

dsh-web-ui GitHub 仓库

dsh-web-ui 是功能较多的 Web 增强方案，原文提到它集成了：

• 任务看板；
• Git 管理；
• 工作台和状态信息；
• 皮肤主题；
• 桌宠；
• 侧边栏开发工具。

它适合希望把 DSH 当成长期开发工作台的人。任务看板可以把任务状态和实际执行会话关联起来；Git 图谱和分支操作则方便在一个界面里查看项目演进。

由于它更像“全家桶”，安装后要先确认自己真正需要哪些模块，并留意它可能会一起安装其他界面插件。功能越多，和 DSH 核心版本发生交互的地方通常也越多。

7. DSH-better-sidebar：把开发面板集中到右侧

DSH-better-sidebar GitHub 仓库

这个插件更专注于侧边栏：文件树、终端和 Git 状态集中在 DSH 右侧，减少在编辑器、终端和 Agent 对话之间来回切换。

和 dsh-web-ui 相比，它的范围更窄，适合只想补齐开发面板、不想安装任务看板、皮肤中心或桌宠的用户。可以把它理解为轻量版本的工作台增强。

8. dsh-context：查看上下文到底被什么占满

dsh-context GitHub 仓库

长时间使用 AI 编程工具后，速度变慢、回复质量下降或上下文接近上限，常见原因可能来自历史消息、文件内容、工具返回值或长日志。dsh-context 的作用是把这些隐藏在后台的上下文组成可视化出来，帮助判断主要占用来自哪里。

它适合：

• 长会话排查；
• 频繁调用工具的 Agent 工作流；
• 决定应该清理历史消息、缩小文件范围，还是开启新会话；
• 复盘一次任务为什么变慢。

一个实用的判断顺序是：先看占用来源，再只缩减最大的一类内容，最后重新执行同一小任务比较速度和结果。不要因为一次变慢就盲目更换模型或重装所有插件。

9. dsh-TUI：切换到终端交互

dsh-TUI GitHub 仓库

dsh-TUI 为习惯 Claude Code 一类终端工作流的用户提供全屏终端界面，原文提到它可以显示当前模型、推理强度和上下文占用比例等状态。

它适合已经熟悉终端操作、希望减少鼠标交互的人。新手不建议把它作为第一款插件，因为它对 DSH 的界面和交互改动较大，核心产品快速迭代时更容易出现兼容问题。安装前要确认自己有清晰的回滚方式。

10. dsh-genui：在回复中渲染交互式组件

dsh-genui GitHub 仓库

dsh-genui 让 Agent 的回复不再局限于文字和 Markdown，而可以渲染卡片、图表和选项按钮等界面元素。它适合：

• 生成数据展示面板；
• 做模型或方案对比；
• 把结构化结果转换成可交互的视图；
• 快速验证一个内部工具的界面想法。

这类能力的验收重点不是“页面是否好看”，而是数据是否完整、交互状态是否可解释、失败时是否仍能回到纯文本结果。对于重要结论，始终保留可复制的结构化数据或文本备份。

11. dsh-pocket：把 DSH 临时带到手机上

dsh-pocket GitHub 仓库

dsh-pocket 可以把电脑上运行的 DSH 连接到手机浏览器。原文提到它支持：

• 局域网模式：手机和电脑连接同一个 Wi-Fi，通过二维码打开；
• 公网模式：通过 Cloudflare Quick Tunnel 建立临时公网通道，不要求额外购买服务器。

手机端可以继续查看 Agent 的工作状态、发送消息，并通过 WebSocket 接收流式输出。它适合远程观察耗时任务，或者在离开电脑后继续处理低风险对话。

公网模式同时扩大了暴露面。二维码、公网地址和访问密码不能分享给不可信的人；如果 DSH 具备操作本机文件和代码的能力，远程入口就应当按高权限管理。生产环境不要把临时隧道误当成长期远程办公方案。

第三类：社区整活和视觉主题

这一组插件不一定增加核心生产力，但能体现 DSH 社区的可定制性，也适合做主题实验和界面原型。

12. dsh-deep-whale：鲸鱼娘主题

dsh-deep-whale GitHub 仓库

这是一个 Web 主题插件，会把 DSH 界面改成鲸鱼娘风格。它不增加 Agent 能力，主要价值是视觉定制和社区传播。

13. whale-girl：跟随 Agent 状态变化的桌宠

whale-girl GitHub 仓库

whale-girl 更像一只可以在 DSH 中互动的桌宠。原文提到它会根据 Agent 的思考、等待、完成和空闲状态做出不同动作，也提供投喂、玩耍等互动。

它的价值主要是情绪体验，而不是任务效率。对于正式工作台，建议把这类插件和高权限工具分开管理，避免为了主题或桌宠引入不必要的依赖。

14. dsh-liang-skin：把推理强度滑块做成主题玩法

dsh-liang-skin GitHub 仓库

这是一个皮肤插件，把推理强度滑块做成更具社区梗文化的视觉控件。适合尝试主题和组件替换，不适合拿来判断模型能力或推理质量。

15. dsh-deepcel：Excel 风格界面

dsh-deepcel GitHub 仓库

dsh-deepcel 会把整个 DSH 页面改成 Excel 风格的表格界面。它更偏向主题实验，也可以作为一个很直观的案例，观察插件如何替换工作台的视觉层。

16. dsh-ads：复古广告整活

dsh-ads GitHub 仓库

dsh-ads 会向界面中加入复古互联网风格的广告、弹窗和横幅。它适合演示 DSH 的可玩性，但不建议在真正的开发环境、演示环境或需要专注的工作台中长期启用。

怎么选：按任务，而不是按热度

可以用下面的决策表快速缩小范围：

你现在遇到的问题	建议先试	先验证什么
Agent 看不懂截图或界面	ModLens	图片是否外发、布局信息是否能被正确理解
需要搜索更多公开资料	ModSearch	搜索源、API Key、结果时间和来源
需要操作已登录网页	dsh-browser	Chrome 扩展连接、人工确认和会话权限
一个任务可以拆成多个独立方向	Agent Teams	子任务是否可独立验收、汇总是否可追溯
不知道插件去哪里找	dsh-market	推荐来源、仓库质量和安装依赖
想把 DSH 变成开发工作台	dsh-web-ui 或 DSH-better-sidebar	是否真的需要全家桶功能
长会话越来越慢	dsh-context	上下文占用最大的来源
想用终端操作	dsh-TUI	是否有版本回滚和替代入口
想在回复里展示图表或组件	dsh-genui	失败时是否仍能获得纯文本结果
需要远程查看任务	dsh-pocket	访问密码、公网暴露面和任务权限
只是想换主题或增加趣味	主题类插件	是否会影响核心工作流和稳定性

一条稳妥的安装和验证流程

原文展示了一个比较省事的方式：把 GitHub 仓库地址交给 DSH，让 Agent 阅读 README、查找安装方式、执行安装命令，完成后按提示重启 DSH Web。这个方式适合减少手动操作，但不能替代人工审查。

建议按以下步骤执行：

第一步：先记录当前可回滚状态

在安装前保存：

• DSH 当前版本；
• 已安装插件列表；
• 配置文件和 API Key 的位置；
• 当前项目分支或 Git 提交；
• 能代表正常状态的一次最小测试结果。

第二步：审查仓库，而不是只复制安装命令

至少看四件事：

1. 项目是否说明了支持的 DSH 版本；
2. 是否需要额外 API Key、浏览器扩展或公网隧道；
3. 代码会访问哪些文件、网络、浏览器会话或本地服务；
4. 是否提供卸载、禁用和故障恢复方式。

第三步：一次只安装一个

第一个插件安装后重启 DSH Web，确认基础界面可以打开，再测试插件自己的最小功能。一次安装多个插件会让故障定位变成猜谜：你无法判断是哪个插件、哪个依赖或哪个版本组合导致问题。

第四步：用最小任务验证

不要一上来就把插件放进大型项目。可以这样测：

输入：一个无敏感信息的截图 / 一个公开网页 / 一个小型仓库
动作：只执行一个目标操作
检查：结果是否正确、权限是否符合预期、日志是否可解释
结论：保留、禁用或回滚

第五步：再组合工作流

只有当单个插件稳定后，才组合多个能力。例如：

ModSearch 找到资料
  → dsh-browser 在已登录页面核对信息
  → Agent Teams 分别做事实核验和代码改动
  → dsh-context 检查长会话占用

组合时每一步都要有独立的输入、输出和验收标准，不要让多个高权限插件同时自动执行不可逆动作。

兼容性和安全边界

原文特别提醒，DSH 插件生态迭代很快，测试时可能遇到插件版本不兼容，甚至导致 Web 无法正常启动。下面几条建议值得直接保留：

• 把插件当第三方代码：不要因为它出现在社区清单里，就默认它经过官方审核。
• 最小权限：浏览器、Shell、文件系统、远程访问类插件只在需要时开启。
• 检查外发数据：图片、网页 Cookie、Session、项目源码和日志都可能包含敏感信息。
• 分离测试环境：先在无敏感信息的项目或单独分支中测试。
• 保留回滚点：管理 DSH 本地版本和配置，出现启动失败时回到上一个可用状态。
• 谨慎使用公网访问：临时隧道适合低风险观察，不应替代完整的身份验证、网络隔离和审计方案。
• 明确人工确认点：发送消息、提交表单、发布内容、修改或删除文件等动作不应默认无人值守。

可以把风险分成三档：

风险	典型能力	建议
低	主题、上下文只读展示、纯界面布局	可先在本地测试，但仍要检查依赖
中	搜索、生成 UI、Git 辅助、任务分工	记录数据来源和写入范围
高	浏览器登录态、Shell、文件修改、公网远程控制	人工确认、最小权限、独立测试和可回滚

出问题时怎么恢复？

当安装后出现 Web 无法启动、插件不生效或功能异常时，按这个顺序排查：

1. 确认核心产品是否能单独启动：先判断是 DSH 本体还是插件导致的问题。
2. 查看最近一次安装的插件：优先禁用或移除最后添加的插件。
3. 核对版本和依赖：检查 DSH 版本、插件 README、额外扩展和 API Key 配置。
4. 恢复到上一个 Git 状态或备份配置：不要在损坏状态上继续叠加安装。
5. 重新安装最小组合：验证单个插件，再逐个加回。

判断标准不是“插件是否能启动”，而是：

核心 DSH 可启动
  + 插件能力可重复
  + 权限范围可解释
  + 失败可以禁用或回滚

如果做不到最后一条，就不适合把插件放进长期开发环境。

推荐的第一次练习

选择一个公开的小型仓库，完成下面的练习：

1. 安装并验证 dsh-context，记录一次短会话的上下文组成；
2. 安装 dsh-browser 或 ModSearch 其中一个；
3. 用它完成一个公开、可重复的小任务；
4. 检查 Agent 访问了哪些数据、做了哪些动作；
5. 主动禁用插件，再确认 DSH 核心功能是否仍然可用；
6. 把成功条件、失败现象和回滚步骤记录到项目文档。

验收清单：

• 我知道插件来自哪个仓库；
• 我看过 README、依赖和权限说明；
• 我只安装了一个插件并验证过；
• 我使用了无敏感信息的测试输入；
• 我知道如何禁用或回滚；
• 我能解释插件带来的实际价值；
• 我没有把社区热度当成安全或兼容性保证。

最后：把插件当成可维护的 Agent 能力层

DeepSeek Harness 的插件化设计最值得关注的地方，不是“能不能把界面变得更花”，而是它把 Agent 的能力、工作台和协作方式拆成了可以独立演进的模块。

一个成熟的使用顺序通常是：

先解决一个真实问题
  → 只增加一个能力
  → 观察效果和权限
  → 固化成功配置
  → 再考虑组合和规模化

如果你的目标是建立更完整的 Agent 工作流，可以继续阅读 Agent 专题，从工具调用、上下文、权限、可观察性、恢复和生产验收等基础概念开始，再决定哪些插件值得加入自己的环境。

来源说明

本文是对公众号文章《16 个超火的 DeepSeek Harness 插件，大肥鱼已经落后 2 个版本了。。。》的结构化整理和实践化改写。文章中提到的插件名称、仓库链接和体验描述以原文发布时的状态为准；插件版本、依赖、模型支持、权限和可用性请以对应 GitHub 仓库当前说明为准。