夜雨聆风DeepSeek Harness 开源之后，插件数量最先爆发。
截至 2026 年 8 月 18 日，GitHub 的 dsh-plugin Topic 已经出现 6918 个仓库。社区维护的精选目录收录了 1305 个插件，其中 477 个提供 npm 包。这个速度很容易让人产生一个印象：DeepSeek Harness 的插件生态已经成了。
但把数字拆开看，结论会更具体。精选目录里有 935 个插件不足 5 星；官方项目仍是开发者预览版，8 月 17 日才推进到 0.1.0-rc.7；官方负责提供插件架构和安装命令，可视化市场、精选目录、更新诊断和安全提醒，主要由社区补上。
所以，这份报告不比较哪个插件更好，也不拿仓库数量当繁荣指数。更值得回答的是：这些插件进入了 Harness 的哪一层，社区最想补什么，以及数量快速增长之后，分发和信任怎样跟上。
插件到底怎样装进去
DeepSeek Harness 的插件不是浏览器扩展那种外围小工具。官方所说的「Everything is a plugin」，覆盖模型适配器、工具、沙箱、会话存储、界面，甚至 Agent 循环本身。底层 Cordis 负责把这些部件组合成一个可以运行的系统。
证据来源：https://raw.githubusercontent.com/deepseek-ai/deepseek-harness/master/README.md
外部插件通过 dsh plugin --profile <name> add <package-or-git-spec> 安装。这个命令会把后面的参数交给 pnpm，因此 npm 包、Git 仓库和本地目录都能成为安装来源。
安装完成还不代表插件已经进入运行链。只有在 package manifest 里声明 dsh.bundle.patch 的依赖，才会被加入 Profile 的 bundle 层栈。插件贡献自己的 cordis.patch.yml，Profile 里的多个 bundle 按顺序叠加，用户自己的配置还能继续覆盖。
证据来源：https://raw.githubusercontent.com/deepseek-ai/deepseek-harness/master/apps/cli/reference/README.md
这套机制解释了生态为什么长得这么快：一个 GitHub 仓库就能成为分发单元，不必等官方商店审核；插件接口又不只开放一个工具按钮，而是可以替换模型、Host 服务、记忆、执行环境和界面。
代价也来自同一个机制。层栈有先后顺序，依赖有版本，Web 插件还可能同时包含 Host 和浏览器端 bundle。某个包在 rc.6 能装，不代表 rc.7 一定兼容；某个后端服务启动了，也不代表设置页能显示它的配置卡片。
1305 个插件，主要在补什么
社区精选目录比 GitHub Topic 更接近「可安装插件」的范围。它要求插件能通过 dsh plugin add 安装、声明 dsh.bundle，并且基本符合仓库里写出的功能描述。以 8 月 18 日的数据看，1305 个插件已经分出二十个类别。
最大的三个类别是 UI 增强 173 个、工具与能力 164 个、开发与运行时 115 个。随后是会话 79 个、工作流 79 个、用量管理 78 个、记忆 77 个、通知 71 个。视觉、安全、主题、模型、浏览器、语音、远程控制和插件市场也都有独立项目。
这组分布说明，社区并不满足于给 Harness 多接几个 API。第一批需求集中在三个方向。
第一类是让 Agent 看得见、做得动。比如 DSH Vision Toolkit 提供视觉问答、OCR、目标定位、裁剪和像素差异等十类工具。它补的是原生文字 Agent 与图像任务之间的能力缺口。
第二类是让任务可以拆给更多 Agent。AgentTeams 提供十个协调工具、持久团队状态和任务依赖，把单个会话扩展为有成员、有分工、有前置条件的协作结构。
第三类是把运行过程变得可管理。会话、工作流、用量、通知、记忆和安全插件加起来已经超过 400 个。它们处理的是任务怎么恢复、成本怎么看、状态怎样提醒、长期信息放在哪里，以及工具边界如何约束。
能力层因此已经很丰富。DeepSeek Harness 已经形成能力层与分发层的生态雏形，但当前最准确的阶段判断仍是：爆发式生长、质量高度分散、治理基础正在形成。
插件市场，是社区自己补出来的
官方 README 目前给出的发现方式很原始：给插件仓库添加 dsh-plugin Topic，再通过 GitHub Discussions 或 Discord 交流。官方 CLI 负责安装，官方设置页能展示一部分 Host 侧插件，但完整的搜索、分类、更新和诊断体验并不是开箱即用的官方市场。
社区项目 dsh-market 正在补这块空白。它把精选目录接入 Harness 设置页，提供搜索、分类、一键安装、更新、主题切换、备份恢复、冲突诊断和加载顺序调整。用户不必在几千个 Topic 仓库里逐个找地址，插件也开始有了统一入口。
证据来源：https://raw.githubusercontent.com/dsh-market/dsh-market/main/assets/demo-en.png
这不是一个独立的新目录。dsh-market 的数据来自 Awesome DSH Plugin 精选列表，并把安装来源限制在这份列表中。目录负责收集和核对，市场负责把它变成产品界面，两者构成了当前社区分发层的主体。
但它们的审核边界很明确：收录确认的是「能安装、描述基本相符、分类正确」，不是质量排名，也不是安全审计。列表维护者会移除失效、停止维护或功能不符的项目，却不会替用户证明插件没有恶意代码。
GitHub Topic 数量只代表仓库主动打标，精选目录的收录也只确认可安装和描述基本相符，两者都不能证明插件安全、稳定或会长期维护。
这也是为什么 6918 和 1305 两个数字不能混用。前者测到的是生态扩张意愿，后者是社区整理后的可安装集合；都不是「经过验证、可以放心生产使用」的插件数。
装插件，本质上是在扩大信任边界
Harness 的工具审批，通常用来约束 Agent 发起的某一次动作。但插件代码本身运行在更外层。
Awesome DSH Plugin 的安全警告写得很直接：第三方插件以用户自己的权限运行，可以读取文件、使用凭据并访问网络；工具审批不会把插件代码放进沙箱。官方 CLI 文档也提醒，外部 MCP 服务器命令属于 Agent 沙箱之外的可信可执行代码。
证据来源：https://github.com/awesome-dsh-plugin/awesome-dsh-plugin
这意味着安装一个插件，不只是给模型多开放一个函数。插件可能参与 Host 启动、读取环境变量、注册网络服务、修改会话流程，或者把自己的补丁加入 Profile 层栈。它获得的信任范围，可能大于对话里一次「允许执行」按钮覆盖的范围。
构建环节还有第二道边界。通过 Git 安装且需要执行 prepare 脚本的插件，在 pnpm 10 之后默认会被阻止，用户必须显式加入 allowBuilds 再重试。这能拦住未经确认的安装脚本，却不能替代源码审查；允许构建之后，代码依然会以本机用户权限执行。
兼容问题则更日常。Harness 官方已经明确提示开发者预览阶段会有破坏兼容性的变化。第三方插件需要同时跟进 Profile 结构、依赖版本、构建脚本和前后端 bundle。生态越早期，安装成功、界面出现、功能可用和升级不坏，越是四个不同的检查项。
生态成熟，要看数字之外的三件事
现在判断 DeepSeek Harness 插件生态，数量仍然有价值，但只能回答「有没有人来」。接下来更重要的是三类基础设施。
第一是兼容信息。插件需要明确支持哪个 Harness 版本，市场也需要把版本约束展示在安装按钮之前。只写「支持 DeepSeek Harness」，在 rc 快速迭代阶段不够用。
第二是可信来源。仓库、npm 包、构建产物和市场条目之间需要可追溯关系。签名、依赖检查、权限说明和可复现构建，才会把「能装」推进到「知道自己装了什么」。
第三是维护信号。最近更新、问题响应、失败安装率、兼容测试和移除记录，比星标更接近真实可用性。935 个不足 5 星并不表示它们都差，只说明这个生态里大量项目还没有形成足够长的公开使用记录。
DeepSeek Harness 的插件路线已经证明了一件事：当模型、工具、会话、沙箱和界面都能被拆装，社区扩展 Agent 的速度会非常快。视觉、多智能体、记忆、浏览器和专业工具在几天内聚集起来，就是这个架构的直接结果。
接下来的难题也已经出现。能力扩张解决的是「还可以做什么」，分发与治理要解决的是「从哪里装、是否兼容、能否信任、出了问题怎样退出」。后一组问题不够热闹，却决定插件生态能不能从开发者试验场走进长期项目。
/ 作者，黄Sir