AREX Feed Article
DeepSeek 官方 API 统计：约 60% 的 DSH 用户使用至少一个第三方插件，团队承诺减少破坏性更新
DeepSeek Harness（DSH）团队成员 Tianyi Cui（，Member of Technical Staff）于 9 月 25 日 17:17（UTC，恰逢中秋节）称，从 DeepSeek 官方 API 统计的数据来看，约有 60% 的 DSH 用户使用了至少一个第三方插件。帖中写道，DSH 团队将持续支持第三方插件生态的繁荣发展，并推动插件 API 趋于稳定。
同一条帖子还写明了上报机制的细节：在用户使用官方 API 及模型时，DSH 会向官方 API 上报实际使用的插件包名和版本，此类上报不额外消耗 tokens。不过，这一数字与承诺均出自团队成员的个人账号，其简介标注「Opinions are my own」（观点仅代表本人）；60% 的使用率属公司口径，截至发稿无法独立验证。
出处明确，口径未明
发帖给出的数据出处是「从 DeepSeek 官方 API 处统计的数据来看」，但没有说明统计窗口、样本范围与计算方式，也未说明该比例是否直接由那条插件上报通道算出。Tianyi Cui 在帖中把第三方插件称作 DSH 用户体验中「最具特色且不可缺少的一部分」。
被统计的产品发布一个多月：8 月 13 日，DeepSeek 以 MIT 协议开源了 DeepSeek Harness，0.1.0 版本定位为面向开发者的预览版（）；介绍它构建于「everything-is-a-plugin」（一切皆插件）架构之上，由 Cordis 驱动。更早的 8 月 4 日，Tianyi Cui 曾公开征集 plugin、skill、MCP、orchestrator、aggregator、UI 等方向的 Agent Harness 开源项目参与 DSH 内测，并赠送部分 API 额度（）。第三方插件生态在产品公开发布之前就已开始组织。
截至发稿（北京时间 9 月 28 日）经 API 查询，这条帖子获得约 201,800 次浏览和 959 个点赞；本文引用的互动数据均为同一时点口径。
上报了什么：包名、版本与零 token 的通道
这套上报可以在开源仓库中得到印证：packages/llm/ 下的 plugin-package-inventory-deepseek 包文档说明，它为发往 DeepSeek 官方 LLM API 的请求补全当前活跃的插件包清单，供官方 API 做请求诊断，并维护请求中的 dsh_plugin_packages 字段；该字段的 version-1 格式只包含 { name, version } 键值对，位于模型消息、系统提示词和工具 schema 之外，不消耗任何模型输入 token，整份清单只增加 HTTP 请求字节（）。
文档同样写明了开关：enabled 配置默认为 true，设为 false 即可在请求中省略包元数据；随仓库发行的配置档案（shipped profiles）沿用默认值，也就是说只要准备成功，每一个发往官方 API 的请求都会带上这份清单。
这份文档正好对上了回复区的一个提问。主帖发出约一个半小时后，身在柏林的用户 Greg Glazewski（）问：「插件名的上报能不能关掉，还是它始终开启？」用户 c.1（）随即指出 DSH 是开源软件，其回复附上的链接正指向上述文档。用户 G 师傅（）则从隐私角度建议：上报插件包名和版本做使用统计，最好还是给用户一个开关。
README 里仍写着「将出现破坏性变更」
DSH 的仓库 README 至今保留着一行大写警告：「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」（将出现破坏兼容性的变更），并说明项目处于开发者预览（developer preview）阶段、正在快速迭代。帖子发出约四十分钟后，用户 Aurora（）在回复里描述了这个现状的体感：「dsh 一更新有些插件就不能用确实有点头疼。」
Tianyi Cui 在帖中给出的承诺是：「DeepSeek Harness 团队将持续支持第三方插件生态的繁荣发展，并推动插件 API 趋于稳定，在将来减少和尽量避免破坏性更新。」回复区里，用户 DeDi（）把这句话与作者投入直接挂钩：「推动插件 API 趋于稳定，第三方作者才敢持续投入。」
README 里的「快速迭代」有版本号可查：8 月 13 日开源时 DSH 是 0.1.0，9 月 10 日 Tianyi Cui 已发帖邀请用户试用 v0.1.5，称新版本与 DeepSeek V4.1 Flash 模型的训练深度结合（）。
自荐墙与连发两期的插件推荐
Tianyi Cui 在帖中宣布，接下来几天他个人将每天推荐一个优质的 DSH 第三方插件，欢迎插件作者在该帖回复区自荐，他会「结合插件质量及后台实际统计到的插件使用量择优推荐」。142 条回复很快聚集起作者们的自荐：开发者 Totoro（）介绍了已发布到 npm 的 dsh-plugin-bridge，在 DSH 的「插件 → 添加插件」中输入包名即可安装；用户 UnclK（）自荐的思考链翻译插件 dsh-think-translate 是他写的第一个 DSH 插件。
推荐按计划兑现。9 月 26 日，他推荐了从 DSH 内测期间就持续开发的 dsh-TUI，称其「补齐了 DSH 缺失的 TUI 界面，并持续随 DSH 版本更新及打磨功能」（）；9 月 27 日，第二期推荐了 dsh-better-sidebar，一个为其它插件提供侧边栏、底边栏、分栏、可浮动栏等基础 UI 能力的「底座类」插件。他解释说，这类插件体现了 Cordis 插件系统的可组合性，而且在 DSH 官方添加基础侧边栏能力之后，该插件复用了官方的组件接口，继续拓展官方没有的定制化能力（）。两期推荐帖分别获得约 123,230 次和 38,964 次浏览。
用量驱动推荐的隐忧
把「后台使用量」写进推荐标准，也引来了对机制本身的质疑。用户 Gregor（）在回复中提醒这个数字的另一面（译文）：「60% 这个统计反过来读也成立：40% 的用户从未安装插件，而且看起来没有插件也用得挺好。」用户 John Rood（）则把质疑指向推荐机制（译文）：使用量统计存在反馈问题，一旦「每日推荐」位成为现实，推荐本身会制造出下一轮排名所依据的使用量，最终收敛到同样的一小批插件；使用量适合当 tiebreaker（平局时的裁决依据），不适合当挑选标准。