Blog · 分析
dsh-plugin topic 被蹭标签污染了
2026-08-16 · dshbase
当我们审计自己的插件目录时，发现了一件尴尬的事：按 Star 排名第一的「插件」根本不是 DeepSeek Harness 插件。
openhanako —— 6047 星，霸占我们「热门」榜首 —— 是一个带记忆和人格的独立 AI agent。它没有 dsh-plugin topic、没有 bundle 清单、跟 DeepSeek Harness 毫无关系。它之所以出现在目录里，是因为它（或它的某个快照）曾经打过 dsh-plugin 标签，而那些不校验的目录直接把它照搬了过来。
问题根源：蹭标签
官方的 GitHub dsh-plugin topic 是发现插件的天然入口——但 GitHub topic 是作者自己打的、无人审核的。任何仓库都能为了曝光加这个标签，很多人也确实这么干。我们排查时发现：
- 独立 AI agent——
openhanako（6k★）、exo（646★）、synergy（542★） - 跨工具桥接——
EchoBird（3k★，「跨 20+ 编码 agent 的模型切换」）、ccteam（Claude Code/Codex/Grok/Kimi 编排器） - Claude 生态工具——
open-managed-agents（Claude Managed Agents API）、MateBot（「claudeclaw 克隆」） - 通用开发套件——Python devkit、Go 多 agent 框架、PPTX 生成器
这些没有一个能在 DeepSeek Harness 里加载。真正的 DSH 插件是一个 bundle——它带 cordis.patch.yml / cordis.yml 清单，用 dsh plugin add 安装。蹭标签的仓库没有这个。
我们如何鉴别
从那以后，dshbase 里的每个插件在收录前都要过三道关：
- Bundle 清单——仓库是否真的带了
cordis.patch.yml/cordis.yml/dsh.bundle.patch？这是插件能在 dsh 里加载的机械信号。 - Topic——当前是否打了
dsh-plugin标签？ - LLM 读 README——DeepSeek 读每个仓库的 README，判断它是真 DSH 插件还是蹭标签，并生成双语描述。
这套组合帮我们揪出了 19 个从上游快照继承来的非 DSH 项目——包括按 Star 排名的前三名。我们已全部删除。
这对生态为什么重要
DeepSeek Harness 在飞速增长，dsh-plugin topic 是事实上的注册中心。如果它被污染，那么每个信任它的目录——包括审计前的我们——都会把「不是插件的插件」展示给用户，这会侵蚀整个生态的信任。
我们的目录现在把校验做进了流水线，列表会保持干净。如果你也在维护 DSH 插件目录或 topic 本身，我们建议同样做：收录前先查 bundle 清单。Star 数不是信号——topic 里最火的仓库甚至根本不是插件。
点这里浏览清理后的目录。