8月13日上线的DeepSeek Harness，到11月4日日活已达154万，每天消耗约92万亿token，用时不到三个月。数字看起来很猛，但同一份GitHub README用全大写写着将会有兼容性破坏性变更，项目明确处于开发者预览、正在快速迭代，跑之前得先看安全声明。一个工具可以同时被几十万人每天使用，又还不适合当团队生产环境的默认选择，这两件事并不矛盾。真正该看的是这个154万量到了什么、又没量到什么，看完你就能更清楚判断它现在能不能放心用在生产里。

一、154 万是怎么数出来的

先把出处说清楚，因为这一层经常在第一轮传播里丢掉。

我核到的原始来源不是二手转述，是 @DeepSeekHarness官方账号 11 月 8 日发布的一篇文章，标题是《Growing Together with Our Plugin Community》。原文那句是：截至 11 月 4 日，counting users on the official API，dsh 达到 154 万日活，每天消耗约 92 万亿 token。

前半句是关键，也是最容易被跳过的一句：它数的是走官方 API 的用户。

这意味着自建本地模型、跑在离线环境里的人，不在这 154 万里。也就是说，它排除了安装量、GitHub 星标和活跃仓库数，量的是「向官方接口付费用量的人」。它量到的是一种采用，量不到另外几种。用这两个数除一下，大约每人每天 6000 万 token(这是我按 92 万亿和 154 万自己除的，原文没给这个数)。

数的是闸机这一侧的人。绕后面那条小路的，一个也没算进去。

同一篇里还有两个数：第三方插件约 3.5 万个，约 60% 的活跃用户自己造过或装过至少一个。这两个数说的是生态有多热闹。3.5 万个里有多少还能正常用、多少人认真读过源码，这篇没回答，也不会有人替你回答。

原文紧接着写了一句，比上面所有数字都值得抄下来：社区插件还在演进，成熟度和适用场景参差不齐。

这是团队自己说的。

所以真正决定这 154 万能证明什么的，是几个原文没答的问题。怎么去重，一个人多台设备算几次。留存曲线什么样，第二周还回来的人还剩多少。统计窗口内有没有突发拉高。官方只交代了「按官方 API 上的用户数」，没交代去重方法。

还有一层要说清：这是项目方自己发的数字。它比二手转述可靠得多，但它仍然是自报，不是审计过的账。自报数字最常见的两个缺口正好在这儿显形：没有独立的统计窗口说明，也没有留存的公开数据。一个工具可以让很多人当天装上打开，这不等于他们下周还在用。

读者据此怎么判：看到「日活 X 万」，先问三句：谁发的、数的哪批人、怎么去重。三句答不全，就把它记成「被报规模」，别记成「迁移依据」。

二、几十万人挤进去，是为什么

数字解释不了吸引力，架构能。

MIT 协议，官方页面上就一句话概括全部设计：Everything is a plugin. dsh 建立在 Cordis 之上，官方文档的说法更狠：There is no privileged core to patch.

翻成平常话：模型适配、工具注册表、技能、会话、沙箱、存储，连 agent 循环和调度、界面本身，全都是插件。没有一个权限更高的内核等着你去改，扩功能等于在旁边再挂一个插件。

最实际的一条是模型。dsh 里模型挂在 ctx.llm 上，是个可替换的插件。可选目录覆盖 Anthropic、OpenAI、AWS Bedrock、Azure、Gemini Enterprise 和 DeepSeek 自己的接口，也能接任何 OpenAI 兼容网关，包括你自己机器上的 Ollama。The New Stack 当时的说法很直接：这套东西没有任何一处把它绑死在 DeepSeek 的模型上。

第二条是能瘦身。预设从一个完整的编码 agent，到只剩 bash 加一个字符串替换编辑器的 Minimal 模式。用不上子代理和规划，就别背着它们跑。

第三条是能干净拆掉。有人把 VS Code 的扩展比作砌进去的砖，能加，拆一面墙才行。Cordis 的插件像乐高，掰下来不留渣。技术上对应的是可组合性。卸掉一个组件，它的副作用会回滚。声明了依赖，运行时替你管。

吸引力也确实能兑现成人话。有个用户让 agent 干一件事：帮我找个读论文的插件。他去倒了杯咖啡。回来发现装了 11 个。他问装了几个，答 11。问谁写的，答「GitHub 上的人」。问哪些人，答「查一下」。

有意思的是，官方那篇文章里正好在推荐一个读论文的插件。同一件事，官方叫它生态，用户经历的是一场意外。

他最后只留了两个：那个读论文的，和一个他真读过源码的。

有一处设计是加分项，值得单独讲，因为它正好对应生产环境最在意的东西。

dsh 的文档里有一条不变式，叫 model-visible means logged。意思是，任何进入模型请求的内容，都必须能从一份只追加的日志里重建出来，而且这是由运行时断言强制的。恢复、检索、回放，全都跑在同一条事件流上。

翻成人话：模型看见了什么，你事后都能查。对要做审计、要对一次判断追责的团队来说，这比能换模型更值钱。

读者据此怎么判：先问自己有没有「换模型、自托管、自己装配」这几个需求。没有的话，这些灵活性抵不过学习成本、维护成本和权限管理的麻烦。

三、日活和插件数，都不是生产就绪的证明

把两件事放在同一屏上看。

说句公道话，我逐个核了 README 和官方页，都没有「不推荐用于生产」这样的原句。真正写在那儿的是 developer preview、快速迭代，以及那句加粗大写的破坏性变更警告。你要跑，先读安全声明。

这三样加起来的份量，比任何日活数字都重。它意味着你今天配好的插件组合、写好的脚本、调好的钩子，可能在某个版本后集体失效，而且这是被事先声明的正常节奏，不是你踩到了 bug。

插件这一侧的风险更具体。官方文章自己写了：社区包成熟度参差，团队会加强插件安全，也会做官方市场。言下之意是现在还没有官方市场，你装的是社区包。

而「一切都是插件」这条设计，意味着一个第三方插件可以替换掉内置功能。上面那位用户问「谁写的」，agent 答「GitHub 上的人」，再问就变成「查一下」。这段对话本身就是供应链问题的演示，不需要任何额外论证。

四个锁着。中间那个锁开了，抽出来的是原本你以为锁着的部分。

作为旁证，不是 dsh 的事：上个月一个假的 Claude Code 扩展在 Cursor 市场里待了大约 11 小时才被下架。插件不是文档，是跑在你 agent 旁边的代码。

一句话收：日活衡量的是被使用，插件数衡量的是可选项。生产就绪还要另外三样：稳定性、可控性、可追责的验证。

读者据此怎么判：如果你的任务要稳定交付、要严格权限、受不了一年几次破坏性变更，就先按预览版产品管风险，别拿活跃用户数替代版本号、实测和权限审查。

四、想试，怎么试

不是「别用」，是别一步跨到全员迁移。

• 第一步，核需求。列出现在这套方案干不了的具体任务。要自托管、要频繁换模型、要自己拼插件，才算需求成立。「别家都在用」不是需求。
• 第二步，定小样本。挑几件真实的、能一句话判定过没过的活，现有工具留一组做对照。记的是任务有没有真完成，不是 agent 回复的「已完成」。
• 第三步，控边界。在非关键环境里跑。装插件前看来源和它要的权限，敏感数据别让它碰，卸载和回滚的路先想好。

左边是砌死的砖，拆要砸墙。右边是能掰下来的块。

第四步，设退出条件。破坏性变更太频繁、输出没真正落地、维护成本吃掉收益，任何一条成立就停在试验阶段。只有自己的证据够了，再谈扩大。

圈一小块水先试。缆绳还在岸上，随时能拉回来。

harness 这一层确实会影响最终结果，但它怎么影响，得在你自己那几件活上量。别人榜单上的分差搬不过来。

读者据此怎么判：需求明确、能隔离风险的团队，可以小范围试。没有验证人力、又扛不住 breaking changes 的团队，继续观察比现在迁移更划算。