154万日活,3.49万插件:DeepSeek离“Agent操作系统”还有多远?

154 万日活、日均约 92 万亿 Token、3.49 万个公开第三方插件。DeepSeek Harness 的社区公告，交出了一份颇有分量的增长成绩单。

但读完之后，我更在意公告里三个带着“将”字的安排：提升插件 API 的稳定性与兼容性，完善插件安全机制，建设官方插件市场。

用户已经来了，开发者也开始写插件。接下来，平台要给他们怎样的规则？这关系到 DeepSeek 提出的那个目标：成为“Agent 时代的操作系统”。

DeepSeek Harness，简称 dsh，是 DeepSeek 开源的 Agent harness。可以把它理解成让 AI 调用工具、执行任务的一套工作环境。它在 8 月 13 日上线 v0.1，9 月 29 日推出官方桌面端，也能以 Web UI 和命令行形态运行。本文讨论的数字，来自 11 月 5 日发布的社区公告，数据截至 11 月 4 日。

154 万日活，先看清统计的是谁

公告有一句不能跳过的限定：“以使用官方 API 的用户为统计范围”。

因此，154 万 DAU 指向 Harness 的调用用户。DAU 就是日活跃用户数；它与 DeepSeek App 的活跃人数、官网访问量是不同指标，不能直接比较。图底部还有 548 万 MAU，即月活跃用户数，但没有单独标注另一套统计口径，本文按同源理解。

两个增幅也有明确起点。DAU 增长 545%，Token 用量增长 306%，比较的都是 2026 年 9 月 29 日，也就是官方桌面端上线那天。时间窗口只有一个多月。

把数字放在一起算，会多看到一层变化。

92.1 万亿除以 154 万，约等于每个日活用户每天消耗 6000 万 Token。按增长率反推，桌面端发布时约有 23.9 万 DAU，日均约 22.7 万亿 Token，人均约 9500 万。这里的反推依赖公告增幅，结果都是近似值。

换句话说，日活涨到约 6.45 倍，用量涨到约 4.06 倍，按这组汇总数计算的人均消耗下降了。

再看图底部的另一个指标：人均每日请求 261 次。92.1 万亿 ÷ 154 万 ÷ 261，约为每次请求 23 万 Token。这个量级更接近 Agent 持续读文件、调用工具和执行任务的形态。

需要保留一条边界：这些是公告指标之间的粗略换算。公告没有进一步解释 Token 组成，也没有把各项聚合指标的统计窗口逐一展开，不能把它当作一次典型请求的实测账单。

插件数量同样值得算一遍。GitHub 有 2.94 万，npm 有 1.85 万，相加是 4.79 万，去重后的公开插件总数却是 3.49 万。图注明确写了“根据公开资料估算，并已去重”。如果来源只有这两处，差额 1.3 万可以理解为重叠项；是否还包含其他来源，公告没有交代。

还有一个容易混淆的地方：名字。PyPI 上另有同名 Python 客户端，社区桌面端和第三方插件市场也会使用 dsh 这个称呼。它们的功能、用户数和插件数，都不能直接并入官方 Harness 的成绩单。文末保留了对照清单。

增长很快，原因还不能只归给一个节点

官方 DAU 图给出了 9 月 30 日至 11 月 4 日的数据，并标出 10 月 17 日 V4.1-Flash-1017 模型发布。

图：官方社区公告。此前各点为自标注日起连续七天的日均值，11 月 4 日为单日值；月活为 548 万。

比较基线取在桌面端发布日，所以这张图无法单独呈现桌面端上线当天带来的跃升。它能展示的，是此后的持续变化。

跨过 10 月 17 日，曲线出现了更陡的一段。但模型发布、生态自然扩散、桌面端持续被采用，都挤在同一个时间窗口里。公告没有拆分各自的贡献。

图注也提醒我们，前面的点是七日日均，最后一个点是单日值。它们有助于看方向，不能直接用来判断某一天的增长脉冲。

图：官方社区公告。Token 曲线与日活曲线的统计点说明一致，底部列出人均每日请求 261 次。

Token 曲线后半段的增幅有所收窄。结合用户增速更快这件事，人均消耗下降就容易理解了。

但原因仍有几种可能：新增用户使用强度较低，用户构成发生变化，或者模型与框架执行任务更省 Token。汇总数据无法区分它们，拉新质量还要结合留存来看。

高频调用对插件作者还有一个很实际的要求：今天跑通的插件，下次升级后还得能用。原稿作者记录过一次 CLI 升级后插件出现 allowBuilds 校验失败，也提到看到过未经核实的类似社区反馈。这些只够作为个体观察，不能推成普遍故障，却能解释开发者为什么会关心兼容承诺。

“操作系统”的目标，靠什么落地

公告把产品设计概括为“一切皆插件”，并明确说，内置功能同样可以被第三方插件替换。

可替换性给开发者留出了空间。能否形成稳定的平台，还要看切换成本、插件可移植性，以及换了框架后原有插件能否继续运行。公告没有为这些问题给出完整答案。

官方下一步要补的三件事很具体：API 稳定性与兼容性、插件安全机制、官方插件市场。它们分别关系到能否持续维护、能否放心安装、能否找到用户。

面向作者的支持计划也在筹备。公告提到 Token 激励、技术交流和作品推荐，具体参与规则、支持安排要等计划正式推出时公布。

这里还有一组待明确的规则：插件是否有商业分成、谁能上架、出问题如何处理、违规作品怎么下架。公告没有展开这些细则。商业分成也只是值得询问的问题，不能据此认定平台已经承诺付费结算。

我的判断是，这份公告同时在做两件事：汇报增长，招募生态。154 万说明调用侧已有规模，3.49 万说明公开供给已有规模。下一步要检验的，是平台能否让这些投入持续下去。

3.49 万插件背后，先看四个具体的人

插件可以扩展或替换 Harness 的内置能力。装入一个插件，相当于给 Agent 添一项可用的工具或工作方式。

原稿梳理的安装机制是：插件由 dsh 的 profile 加载，Web UI 与桌面端共用；dsh plugin add 将安装参数交给 pnpm，支持 npm 包、Git 仓库或本地 tarball。具体权限边界，社区公告没有列细目，只承诺继续完善安全机制。

图：官方社区公告。公开数量根据资料估算并去重，58.94% 的用户创建或使用自定义插件。

这张图从 8 月 13 日开始，标出了四个发布节点。按曲线粗略估读，9 月 29 日桌面端发布时已经有约 2.2 万个插件，之后才增长到 3.49 万。图中没有提供该日精确标值，不能把估读数当成精确统计。

也就是说，3.49 万覆盖从 8 月中旬开始的整个累计过程。若把它全算进桌面端上线后的 37 天，日均增长就会被高估。

这个总数统计的是公开第三方插件，企业和个人私有插件不在其中。至于谁在维护、维护了多久、多少插件有人持续使用，单看数量还不知道。

公告挑了四位作者，可以先从他们做的东西理解需求。

蜗牛做的是自媒体工作台 dsh-media-desk，把灵感、脚本、封面和分镜放在一起。他把自己的日常形容为：“睡醒、打开 DSH、秒开工作台、开蹬。”

歸藏做的是 dsh-guizang-design。他把设计和文字润色 Skill 整合成插件，让文章能转成网页、图文卡片或封面，作品也可以保存和复用。他看重的是积累：“作品、专栏和语气都能积累下来，内容生成的质量会非常稳定。”这是作者的使用评价。

博文的 dsh-context 关注上下文，也就是 Agent 执行任务时拿到的那些信息。插件帮助用户查看信息由什么组成，以及它们如何随对话变化。

Phil Fan 的 agentero-dsh 则从科研日常出发，把文献管理、翻译、笔记和论文阅读连起来，希望做一款“人和 Agent 用着都舒服的文献工具”。

四个案例都从具体的不顺手出发，再把解法做成别人可以安装的产品。这也提示了一种观察角度：评估插件，先看它承接了什么日常需求，再看它调用了多少能力。

不过，四个案例只能证明有人在认真做。长尾有多长，头部有多集中，仍然没有答案。58.94% 的用户创建或使用自定义插件，也只能说明覆盖面，无法说明使用频率与深度。

发现插件的入口还不够完整。按原稿整理，官方可通过包名安装，也提供实验性的“自定义插件索引”，启用后可在“发现”页浏览索引内容；索引文件 URL 需要自行填写，产品不内置索引源。这些产品细节属于原稿背景补充，未在本次社区公告中展开。

原稿作者还记下了找插件时的麻烦：群里推荐以后要先问包名，去 npm 搜 dsh 又会遇到同名项目，需要核对仓库。第三方市场自报的插件数则有 1,117、11,000+、12,435 等不同数字。这些数字未经独立核实，也不属于官方统计，只能作为观察分发需求的线索。

平台和作者，算的是两本账

平台要持续投入 API 维护、兼容性、安全机制和市场运营。插件带来的回报，则可能是更多使用场景、更持续的调用。

154 万 DAU 除以 3.49 万公开插件，约为 44。这个比值只表示每 44 个日活用户对应一个公开插件，不能推出每个插件有 44 个用户，更不能说明需求已经得到满足。

一个插件进入日常工作后，调用可能从偶发变成持续。平台关心用量，作者还要关心维护时间，尤其是升级之后要不要重新适配。

因此，比插件总数更有解释力的，是使用分布。若少数插件承担大部分调用，平台就更依赖少数维护者；若长尾作品也有持续使用，才更能看出需求覆盖面。长尾分布本身仍不足以单独证明发现机制有效。

公告暂未给出这类数据。

作者的投入比较确定：时间、适配、持续维护。回报却要看曝光、分发和激励怎样落实。Token 激励能帮忙降低探索成本，能覆盖多少长期投入，还要等细则。

这就是招募期里值得算清的一笔账：先投入多少自己能承受的维护成本，再判断平台承诺是否足够具体。

五个问题，会影响你愿不愿意投入

第一，支持计划具体支持什么。Token 激励如何申请、门槛是什么、持续多久？若未来涉及商业分成，再看比例和结算安排。公告目前只给了方向。

第二，官方市场怎么上架。审核标准、审核周期、下架条件，都关系到开发者能否规划发布。

第三，API 兼容承诺有多长。破坏性变更会提前多久通知，旧接口保留多久？“提升稳定性与兼容性”还需要落成可执行的规则。

第四，安全责任怎么划。插件能访问哪些内容、执行哪些操作，出现问题后平台和作者如何处理？普通用户也该关注这一条，因为它关系到你敢装什么。

第五，留下来的人和插件有多少。留存率、插件下载与使用分布、头部集中度，能帮助判断增长有没有转化为日常使用。

这些空白不会否定已有的 154 万日活。它们影响的是后来的人是否继续使用，以及开发者是否愿意继续维护。

接下来，盯住能核对的承诺

支持计划细则是一个观察点。支持方式、准入门槛、申请流程有没有写清楚，可以直接看文件。

官方市场是另一个观察点。何时开放、能否搜索、上架与审核规则是否可查，都比笼统的生态愿景更容易检验。

兼容政策也值得等。平台愿意把弃用通知和兼容期写进文档，作者才更容易估算升级成本。

如果你在写插件，现在能做的事很具体：把支持版本和已知限制写进 README，把包名、仓库地址与安装方式说明白。政策尚未明确的部分，先留出维护余量。

如果你只想用插件，除了看数量，还可以留意是否持续更新、权限说明是否清楚、遇到问题能否找到维护者。

我会继续看那些公开规则，以及 3.49 万个插件里有多少真正进入了日常工作。开发者愿意持续维护，用户敢于长期使用，“操作系统”这个目标才有了更扎实的依据。

附：别把同名项目算进来

PyPI 的 deepseek-harness（HenryZ838978）：同名 Python 客户端。原稿列出的 V4-Pro、V4-Flash、Vision 协议适配，以及 dsh doctor 探针，属于该项目的背景信息，不能据此推定官方 Harness 的能力。

anywhere-labs/deepseek-harness-desktop、dataelement/dsh-desktop、Minke：社区桌面端。原稿提及的手机扫码远程、.dshpreset、内置第三方市场、Intel Mac/Linux 安装包等能力，需要分别核对具体项目，不归入官方桌面端的能力清单。

dsh-market、dsh-plugin.org、deepseek1024、Oh-My-DSH：第三方插件市场。其一键安装能力及自报数量属于各自项目，1,117、11,000+、12,435 等数字均未独立核实，不能与官方去重总数直接相加。

V4.1-Flash-1017：图中的模型发布节点。模型能力与 Harness 框架能力需分别判断。

以上是原稿提供的同名项目背景补充，并非社区公告的内容。