作者丨Rhea
编辑丨李娜 岑峰
DeepSeek Harness 开源已有一段时间，「Everything is a Plugin」的理念催生了大量社区插件。十几天内，GitHub 上【dsh-plugin】标签下的仓库数量突破一万。然而，经过对这一万多个仓库的拆解、探针测试及高下载量插件的深度运行分析，我们发现该生态存在严重的安全隐患与管理缺失。
「一切皆插件」将内核控制权完全交予用户，但绝大多数人缺乏相应的技术能力，且整个生态目前处于无人管理、无人负责的状态。（注：本文数据截至 2026 年 8 月 25 日）
01 一万个插件，到底有多少是真的？
统计口径差异巨大
同一生态在不同平台的统计数据差异显著，根源在于「插件」一词尚无公认定义。若将 DeepSeek Harness 插件生态视为漏斗：
从第一层到第三层流失 81%，从第三层到第五层再流失 55%。这意味着「拥有 1.1 万个插件」与「仅可用不到一千个插件」两种说法均成立，取决于统计口径。
造成如此大落差的原因是官方指引极其宽松：仅需在 GitHub 仓库打上 dsh-plugin 标签。这导致生态缺乏必要的门槛与管理机制：
- 无官方插件目录与搜索功能
- 无版本兼容矩阵
- 无签名或校验机制
- 无安全上报通道
- 无官方推荐清单
由于 GitHub 标签零门槛，大量无关内容涌入。例如，官方 README 链接按「最佳匹配」排序（高度依赖 Star 数），排名第四的竟是一个 2020 年创建的简历生成器，仅因蹭热度标签而入选。
可用插件比例极低
经逐一筛查，约 93% 的被拒记录原因为「无法按 dsh 规范安装」，主要缺失 dsh.bundle 声明、依赖或技能布局。
对随机抽取的 50 个被拒仓库分析显示，其真实构成分为三类：
- 空壳仓库： 仅含 README，数量极少。
- 代码未规范打包： 具备完整代码但未添加声明或未发布至 npm，导致官方命令无法识别。
- 无关内容挂标： 包含 Windows 启动器、macOS 组件甚至恶意模仿门户广告的插件。
此外，命名冲突严重，多个团队使用相同名称开发桌面客户端，给新用户造成极大困扰。
02 DeepSeek 开放了内核，但大家只想装工具
卖铲子与娱乐类插件占据主流
在可安装的 2,143 个插件中，主要分为三类：
- 基础设施类（市场、计费、文档、开发辅助）
- 娱乐体验类（主题、桌宠、界面增强）
- 核心能力扩展类（工具、记忆、视觉、语音、工作流）
下载量前三名均为市场和界面类插件，直到第四名才出现具备核心扩展能力的视觉插件。这一现象与 Anthropic 的 Claude Code 插件生态高度一致：在新生态中，帮助用户「发现」和「管理」工具的插件往往是最快爆发的刚需。
例如，下载量第一的 dsh-market 插件周下载量达 15.9 万，约占官方入口包周下载量的 24%。它提供了搜索、筛选、一键安装等官方缺失的功能。
核心内核改造鲜有人问津
尽管官方主打「无特权内核」，允许替换 Agent 主循环，但真正实施此类深度改造的插件仅有两个：
- dsh-frostfin：替换主循环以直连 Kimi Code，周下载仅 438。
- dsh-session-pause：禁用官方 loop 以实现暂停功能，未发布至 npm。
相比之下，切换模型接口的插件被广泛使用，69 个相关插件将 Codex、Claude 等模型的订阅额度接入 DeepSeek Harness。这表明，绝大多数开发者对修改底层执行内核缺乏兴趣，更倾向于直接利用现有能力。
03 装一个插件的代价是什么？
安全机制失效：Read-only 管不了插件
DeepSeek Harness 设定了三档文件权限：read-only（只读）、workspace-write（工作区写入）、danger-full-access（完全访问）。然而实测发现，即便在最严格的 read-only 模式下，插件仍可读取 SSH 私钥、获取环境变量中的 API Key、写入临时文件并连接外网。
原因在于权限控制仅针对模型发起的请求，而插件本身被视为 dsh 的一部分（即「同事」而非「访客」），不受保安（沙箱）检查。安装插件即意味着授予该插件当前电脑账号的所有权限。
官方文档明确指出「沙箱不是安全边界」，但在缺乏监管和审核的生态中，用户需自行承担所有风险。部分热门插件甚至会强制提升权限等级或在安装时默认关闭复核机制，而这些行为普通用户难以察觉。
缓存成本：插件可能导致缓存失效
安装插件会向上下文注入大量工具说明书，导致前缀匹配失效，从而使 DeepSeek 精心优化的 KV 缓存策略归零。这不仅增加首轮响应延迟，还可能导致模型选错工具。
虽然官方提供了 profile 和 preset 机制来管理插件组合，以及 Code Mode 来压缩工具说明，但整个生态缺乏对用户的相关提示。用户往往在不知情的情况下承担了高昂的 token 成本。
兼容性危机：插件冲突频发
实测发现，下载量前十的插件若同时安装，极大概率因资源抢占（如侧边栏组件路径冲突）而无法启动。官方文档虽说明了配置覆盖规则，但缺乏自动检测与仲裁工具，导致用户在遇到冲突时只能手动排查。
04 它对行业的影响
Star 爆炸不等于生态成熟
对比 OpenClaw，DeepSeek Harness 在开发者圈内热度极高，但 Fork 比例较低，表明多数用户仅停留在围观阶段。深入分析作者群体发现：
- 近七成作者为 2024 年及之前注册的老账号。
- 四成作者零粉丝，组织账号占比极低。
- 新人作品多集中在低 Star 区间，头部流量仍由老牌 AI 开发者把持。
缺乏官方分发与管理机制，使得优质新项目难以获得曝光，生态面临被少数老玩家垄断的风险。
05 DeepSeek 为什么把插件分发留给了社区？
主动删减分发机制
查阅设计记录发现，DeepSeek 团队在开源前夕主动删除了专用的插件分发机制（包括专用格式、包装层及验收流水线）。理由是避免与 profile 组合包路径重复，且认为原有机制配置灵活性不足。
然而，这一决策仅解决了「安装」层面的冗余，却完全忽略了「发现」与「信任」机制的建设。团队将选择权完全交给用户，未提供任何官方背书或过滤手段。
历史经验表明官方介入迟早必要
对比 Figma、Claude Code 及 MCP 的发展路径，没有任何一个成功的开放生态长期缺失官方注册表或目录。MCP 作为开放协议，最终也由 Anthropic 补上了官方 Registry。DeepSeek Harness 目前连 npm 早期的基础映射都未建立，名称冲突与来源不明问题频发，官方介入构建信任体系势在必行。
06 往后会怎样
四个历史剧本的启示
参考 npm、VS Code 等生态的演进，DeepSeek Harness 目前处于比 npm 早期更混乱的阶段：发现靠 GitHub 标签，安装靠 npm，两者之间缺乏映射与对齐。同名不同源、同源自不同名的情况屡见不鲜。
生态的核心价值与局限
DeepSeek Harness 的独特价值在于允许通过配置替换主循环和后端的极致开放性，但这仅对极少数需要修改执行内核的开发者有用。对于 55% 以上致力于扩展应用能力的插件开发者而言，其他 Harness 或 MCP 同样能满足需求。
换言之，DeepSeek 提供的最独特能力，恰恰是生态中使用率最低的部分。
07 尾声
从 11,439 个仓库到 955 个活跃插件，巨大的落差揭示了社区自发组织的局限性。官方仅提供一个标签，将安全、责任与筛选机制完全抛回给用户。
更严峻的是，由于缺乏有效的发现与激励机制，新人的优秀作品难以出头，而老旧的蹭热度项目却占据高位。「Everything is a Plugin」解决了「什么可以被扩展」的问题，但尚未解决「谁来决定什么值得被安装」这一核心难题。当陌生人的代码进入陌生人的电脑时，建立发现、信任与责任机制已是迫在眉睫。
