开源项目第239期：Awesome DSH Plugin —— 5000+ 插件的 DeepSeek Harness 生态精选列表

引言

"这个列表不给插件打分、不做质量排名，我们也不想做这件事。"

这是「每日一个开源项目」系列的第 239 篇 。今天的项目不是某个单一工具，而是一份精选列表（Awesome List）------ Awesome DSH Plugin ，由同名组织维护，面向 DeepSeek Harness（简称 dsh，DeepSeek 开源的 Agent Harness）的插件生态，19,015 颗 Star，CC0-1.0 协议，README 收录条目数已超过 5000 个。

DeepSeek Harness 是 DeepSeek 开源的一个可运行的 Coding Agent（支持 Web 和无头模式），架构上贯彻"一切皆插件"的理念：模型、工具、沙箱、会话存储、UI，甚至 Agent 循环本身都可以被插件替换或扩展。这种彻底的插件化设计催生了一个异常繁荣的第三方插件生态------而 Awesome DSH Plugin 要解决的问题很具体：在几千个插件里，怎么找到你需要的那一个，并且知道它真的能装上、真的做了描述里说的事。

你会学到什么

一份"不排名、只验证"的 Awesome List 维护哲学：收录标准到底是什么
一个插件化 Agent Harness 的生态能长成什么规模（22 个分类，5000+ 条目）
dsh-market、dsh-find-plugin 这类"元插件"如何反过来服务这份列表本身
项目如何用"一插件一文件"的 YAML 数据结构解决大型 Awesome List 的 PR 冲突问题
第三方插件生态里一个绕不开的现实问题：安全风险该怎么被诚实地摆在明处

前提知识

对 AI Coding Agent（如 Claude Code、Codex、Cursor）的基本使用经验，便于理解 DeepSeek Harness 的定位
了解插件/扩展系统的一般概念（manifest、注册、安装流程）
不需要读过 DeepSeek Harness 源码，但知道"Agent Harness"大致是什么会更容易进入上下文

项目背景

概述

Awesome DSH Plugin 本质上是一个数据聚合 + 静态站点生成 项目：真正的数据源是 data/plugins/ 目录下的几千个 YAML 文件（每个插件一个文件），README.md 和 README.zh.md 由脚本从这些 YAML 自动生成，网站 awesome-dsh-plugin.com 同样基于这份数据渲染。项目本身不托管任何插件代码------它只是一份带有验证流程的"链接目录"。

与大多数 Awesome List 不同的是，这个项目明确拒绝"质量排名"这件事：一个插件被收录只代表它满足了几条客观、可核查的标准，不代表它比另一个插件更好。

作者 / 团队

维护方 : awesome-dsh-plugin 组织（Organization 账户，社区共同维护，非单一个人项目）
主要语言: JavaScript（主要用于生成脚本和自动化检查）
许可证: CC0-1.0（Creative Commons Zero，公共领域贡献，与大多数开源项目使用的 MIT/Apache 不同，CC0 放弃几乎全部版权主张）
创建时间: 2026-08-13
当前状态: 活跃维护中，GitHub Actions 自动化程度很高，最近一次推送在近日

项目数据

⭐ GitHub Stars: 19,015+
🍴 Forks: 4,310+
📄 许可证: CC0-1.0
📅 创建时间: 2026-08-13（不到两个月已增长到 5000+ 插件条目）
👥 核心贡献者：fkysly（1505 次提交）领衔，github-actions $bot$ 的 838 次提交反映出高度自动化的生成流程，另有 173787247、PerryLink、zhengjy01 等多名活跃贡献者
📬 Open Issues: 836（规模本身也说明了这个生态有多活跃）
🏷️ Topics: awesome, awesome-list, deepseek-harness, dsh, dsh-plugin
📊 官方插件计数接口（awesome-dsh-plugin.com/count.json）实时显示：5065 个插件

快速上手

方式一：直接浏览列表

最简单的用法就是打开 README 或官网 awesome-dsh-plugin.com，按分类（AGI 架构探索、UI 增强、模型与提供商、安全与权限等 22 个大类）浏览，找到想要的插件后用 dsh plugin add 安装：

bash 复制代码

# 以安装官方推荐的插件市场为例
dsh plugin --profile web add dshmarket

方式二：用 dsh-market 图形化市场浏览安装

安装上面这一步之后，Settings 里会出现一个可搜索的插件卡片市场，支持分类筛选、一键安装/升级、一键切换主题------相当于把这份 Awesome List 做成了图形界面。

方式三：让 Agent 帮你找插件

如果不想离开对话界面去翻列表，可以装 dsh-find-plugin：

bash 复制代码

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

装好之后直接用自然语言跟 Agent 说"我想要一个能在任务完成时放提示音的插件"，Agent 会在这份精选列表里检索并给出安装命令------这也是整个生态"用 Agent 管理 Agent 插件"的一个缩影。

给自己的插件提交收录

如果你开发了一个 dsh 插件想收录进来，流程被设计得极其轻量：往 data/plugins/<owner>__<repo>.yml 新增一个文件 ，写清 url、name、category、英文（必填）和中文（选填）描述，提 PR 即可，两个 README 会在合并后自动重新生成。

核心剖析

不排名、只验证：一份 Awesome List 的收录哲学

Awesome DSH Plugin 在 README 里把收录标准写得非常直白："An entry is added when the plugin installs with dsh plugin add, does what its one-line description says, sits in the right category, and is maintained." 每一条提交都会被拿去对照源码核实------如果描述里写"46 个工具"，维护者真的会去数。

但紧接着的声明更值得注意："This list doesn't rank plugins or judge their quality, and we don't want to. "（这份列表不给插件排名或评判质量，我们也不想这么做。）这是一个克制且诚实的定位：很多"Awesome X"类项目会不自觉地滑向"推荐榜"或"最佳实践清单"的角色，而这个项目明确划清边界------被收录只证明"它干净地满足了几条客观规则"，不代表它比列表里其他插件更值得用。失效、停更或被证实有问题的条目会被移除，但"活跃"本身也不是质量背书。

这种克制在一个 5000+ 条目、22 个分类的规模下尤其重要：排名和评分在插件数量指数增长时会迅速失真（刷榜、马太效应、维护者精力有限导致评审深度不均），而"客观核查 + 不做主观判断"的规则反而更能长期维持下去。

"一插件一文件"：用数据结构解决大型协作列表的根本矛盾

Awesome List 这类项目有一个经典的协作痛点：所有贡献者的 PR 都在修改同一个 README 文件的同一个分类区块，第一个合并的 PR 几乎总会让后面排队的 PR 产生冲突，需要重新 rebase。Awesome DSH Plugin 的解法很直接------README 本身不再是数据源，而是生成产物 。真正的数据拆分成 data/plugins/<owner>__<repo>.yml，每个插件独占一个文件：

yaml 复制代码

url: https://github.com/owner/repo
name: owner/repo
category: ui
description:
  en: One-line description ending with a period.
  zh: 一句话描述，以句号结尾。

CONTRIBUTING 文档里的解释很到位："独立文件永不冲突，而生成出来的 README 行总是相撞 "。两份 README（英文和中文）在 PR 合并后由脚本在 main 分支自动重新生成，贡献者既不需要本地跑脚本，也完全不该手动编辑 README------这是一个把"人类编辑冲突"问题转移成"纯数据追加"问题的典型工程手法，在条目数量达到五千级别后，这种设计几乎是必需品而非可选优化。

第三方插件生态绕不开的问题：安全风险的坦诚披露

这份列表最值得称道的地方，是它没有回避"收录一个插件 ≠ 这个插件是安全的"这个核心矛盾。README 顶部用 [!WARNING] 标注了一段很直接的提示：

安装一个插件，就是在用你自己的权限运行第三方代码------它能读你的文件、用你的凭证、访问网络。工具审批机制不会把插件代码隔离在沙箱里。被收录在这份列表上并不代表经过了安全审查：装之前自己看源码，陌生插件先在不碰你密钥的环境里试。

这段措辞不是走流程式的免责声明，而是明确指出了一个容易被忽略的技术细节：Harness 层面的"工具调用审批"（Tool Approval）管的是 Agent 调用工具时的权限确认，和插件代码本身的运行时隔离是两件完全不同的事------装上一个插件之后，它的代码就以你的用户权限直接跑在你的机器上，审批机制根本不覆盖这一层。这也解释了为什么 "Security & Permissions" 分类下聚集了大量第三方插件------静态扫描插件安装包（lifecycle scripts、动态执行、凭证泄露组合）、沙箱逃逸检测、权限分级网关、审批前的 LLM 预审------本质上都是社区在自发补上 Harness 本身没有提供的那层信任边界。

从生态健康的角度看，这是一个相当成熟的信号：当一个插件生态繁荣到需要专门的"插件安全审计插件"类目来对抗插件本身的风险时，说明这个生态已经大到足以吸引真实的攻击面考量，而不只是玩具项目。

项目地址与资源

🌟 GitHub : awesome-dsh-plugin/awesome-dsh-plugin
🌐 官网 : awesome-dsh-plugin.com
🛒 插件市场 : dsh-market
💬 对话式插件检索 : dsh-find-plugin
📖 贡献指南 : contributing.md
🖥️ 兼容的桌面客户端: dsh-desktop、deepseek-harness-desktop（hairyf 版 / anywhere-labs 版）等，均内置 dsh-market
⚠️ 免责声明：社区维护索引，收录不代表安全审查或质量背书，安装第三方插件风险自负

总结

Awesome DSH Plugin 回答了一个"插件化 Agent Harness"生态发展到一定规模后必然会遇到的问题：当插件数量从几十个涨到五千个，列表本身的可信度和可维护性要怎么保证，而不是沦为一个无人管理的死链接堆砌？

三点值得注意：

"不排名、只验证"的收录哲学，是一个在五千条目规模下依然成立的克制选择。 很多 Awesome List 项目一旦规模变大，就会不自觉地加入 star 数排序、"编辑精选"之类的主观判断，而这个项目明确把自己限定在"客观核查 + 不评判质量"的边界内------这个边界反而是它能在两个月内收录五千插件还保持可信度的原因之一。

"一插件一文件"的 YAML 数据结构，是一个值得被更多大型协作列表借鉴的工程设计。 把 README 从"数据源"降级为"生成产物"，用独立文件取代共享文本区块的追加式编辑，从根本上消除了大规模协作下的合并冲突问题，这个思路不止适用于插件列表，也适用于任何"多人往同一份清单里加条目"的协作场景。

对第三方代码执行风险的坦诚披露，补上了插件化架构里最容易被忽视的一环。 "一切皆插件"的架构在赋予生态极强扩展性的同时，天然带来了供应链和运行时信任的问题------这份列表没有把这个问题藏起来，而是在最显眼的位置用 WARNING 标注说清楚审批机制覆盖不到插件代码本身，这种透明度在"Awesome List"这个品类里并不常见，却恰恰是用户最需要的信息。

如果你正在用 DeepSeek Harness，或者只是对"一个彻底插件化的 Agent 系统能长出多繁荣的生态"感到好奇，Awesome DSH Plugin 这份列表本身------以及它背后"如何可信地维护一份五千条目的社区目录"的工程思路，都值得花时间看一看。

探索 PrimeSkills ------ 精选 AI agent 和技能工具，每一个都经过真实工作流验证。没有炒作，只有真正好用的工具。

访问我的个人主页，获取更多见解和有趣的产品。