3.5 万个插件之后:谁来给 Agent 生态补规矩

导语：最该看的不是 154 万，是 3.5 万

11 月 8 日，DeepSeek 在官方 X 账号发了《Growing Together with Our Plugin Community》，Bloomberg 几小时后跟进（官方帖、MLQ.ai、Clauday 均为 11-08；中文日报有记为「11 月 5 日晚公布」的，两者不一致，学姐按一手 X 帖与 Bloomberg 口径处理）。

最抓眼的数字很亮：截至 11 月 4 日，仅统计使用官方 API 的用户，日活 154 万，日消耗约 92 万亿 token。但学姐第一眼停住的是另外两个：第三方插件约 3.5 万个，约 60% 的活跃用户至少制作或安装过一款。 官方自己还写了一句很诚实的话——社区插件「成熟度不一」。

这不是一个「生态繁荣」的故事。这是一个分发规模已经跑在治理前面的故事。学姐在大厂做产品时最怕的排期，就是「先上线、后补审核」：补的时候面对的不是一张白纸，是几万个已经跑在用户机器上的第三方代码，以及它们已经替用户存下来的东西。

今天这篇不聊插件怎么写，聊的是：如果你负责一个 Agent 平台、或者要给团队选一个，这 3.5 万个插件意味着什么，以及从今天起该按什么顺序补。

一、先把事实和口径摆平

做产品判断第一步是不被数字带跑。学姐把官方口径逐条拆开（全部为 DeepSeek 公司自述、未经独立审计）：

时间线也一并记下：v0.1 于 8 月 13 日上线，桌面端 9 月 29 日发布。官方给出的目标是把 Harness 做成「Agent 时代的操作系统」，设计原则是「一切皆插件」——MLQ.ai 转述官方表述时特别点出，第三方插件可以替换内置功能。

学姐的解读：这句「可以替换内置功能」是全文最重的一句，也是大部分报道跳过的。它意味着平台把「哪些能力由谁提供」的决定权交了出去。到了这一步，插件就不只是功能扩展，而是信任边界的重画。

另外要提一处媒体争议：36氪 11-08 日报转述时提出，插件越多，说明与工具规则越挤占上下文、抬高执行成本，Agent 未必更强。这条质疑成立，但它属于上下文预算那一层，学姐今天的 A 篇已经用三份材料拆过，这里不重复展开，只留一句指向——别把插件数量当成能力指标。

二、真正被转手的不是能力，是「状态持有权」

官方帖里点了四个社区插件，学姐逐个拆给你看，它们各自从用户那里拿走了什么：

dsh-media-desk（@woniuniuniuCN）：从记录想法、写脚本、做封面到分镜，把一整套日常创作流程打包成一个工作台。它持有的是流程与习惯。

dsh-guizang-design（@op7418）：把常用的设计与文案润色技能合成一个插件，文章可转成网页、图片卡或封面；成品存进「My Work」，还能用「做一个类似的」继续往上叠。作者原话是插件「比技能包给你的多得多」，因为可以一直留住你过去的作品、内容系列和写作风格。它持有的是可复用资产与个人风格。

dsh-context（@bowenliang123）：展示上下文如何组成、如何演化，以及多智能体协作的细节，也就是把「Agent 此刻手上有什么信息」这件事可视化。它持有的是运行时的可见性——反过来说，它也能看见。

agentero-dsh（@Phil-Fan）：把文献管理、翻译、笔记接成一套文献工具，让人和 Agent 在同一个地方读论文。它持有的是知识库与标注。

学姐的解读：这四类里没有一类是「多一个功能」。它们共同做的事是替用户持久化状态。一旦状态在第三方插件里，三件事立刻变复杂：

这和昨天 B 篇讲的「Harness 按小时卖」是同一条规律的第二面：那次是平台持有状态、便宜的是时间贵的是状态；这次是第三方持有状态，多了一层「持有者不是你签合同的那一方」。学姐提醒一句，这不是说插件有恶意，官方明确说社区插件成熟度不一、很多是开发者按自己需求做的；这是说，状态一旦外置给第三方，产品契约里就必须多写三页。

顺带一个风险参照：量子位 11-08 在讲 Personal Agent 执行层时提到，OpenClaw 社区曾曝出约 4.2 万个 Gateway 暴露公网、技能市场混入 300 多个恶意技能（单一媒体转述、未见原始安全报告，仅作风险信号，不做数量级外推）。没有一个已跑起来的插件生态能跳过这一课，npm 和浏览器扩展都交过学费。

三、顺序倒置：这次治理的对象是存量，不是白纸

官方在同一篇帖里给出的承诺是「将要」：进一步提升插件 API 的稳定性与兼容性、加强插件安全、建官方插件市场、为插件作者准备 token 补助 / 技术交流 / 推广的扶持计划；目前只有一个收集意向的表单，参与规则与支持细则要等计划上线时公布。

把两句话放一起读：3.5 万个插件、60% 用户已经装了；市场、审核规则、安全机制、API 兼容承诺都还没落地。Clauday 的评论很直接——市场是对的动作，但顺序反了。

学姐的解读：产品上「先立标准」和「先跑规模」是两条真实存在的路线，各有代价。10 月 25 日我们写过 Agent Skills 捐给 Linux 基金会 AAIF，那是先把规范变成公共品再铺生态；这次是先把生态铺出去再补规范。前者慢、容易错过窗口，后者快、但补治理时要处理存量兼容——你不能把用户已经装了三个月的插件一夜下架，也不能要求几万作者同时改签名格式。

所以真正要设计的不是「一套完美的审核制度」，而是一套能对存量做分层、灰度、回溯的收编流程。这也是学姐下一节想给你的东西。

四、三种收编路线，怎么选

学姐的建议很明确：本次适合第二条。 理由不是它最严谨，而是它是唯一一条既不动用户已存状态、又能把最高风险那一小撮先框住的路线。分级依据不要用「下载量」或「作者知名度」，用上面第二节那四类——看它持有用户的什么，这比看热度可靠得多。

五、六步落地清单（按这个顺序做，别跳步）

第 1 步｜盘点，先拿到名单。 建一张插件台账，字段固定八个：包名、来源仓库、版本 / 哈希、安装人、安装时间、最近调用时间、持有状态类型、是否能读上下文或凭据。11-01 那篇讲 Agent 台账时学姐说过「最近调用时间」是性价比最高的字段，这里同样成立——长期沉默却仍带着凭据的插件，不是资产，是挂着的攻击面。

第 2 步｜按状态持有分四级。 L1 只读工具（查天气、格式化）；L2 读写本地文件；L3 持有用户资产（作品、文献、风格配置）；L4 能读 Agent 上下文、工具返回或凭据。L4 数量通常最少，但要先处理。

第 3 步｜签名与来源固定。 禁止「按包名裸装」——官方现在的方式就是在安装页输入包名，同名包、抢注包、改名的风险全在这一步。改成「包名 + 来源仓库 + 版本哈希」三元组，并把自动更新默认关掉，更新走显式确认。

第 4 步｜最小权限与沙箱。 至少回答四个问题：插件能否出站联网、能读写哪些目录、凭据怎么注入、能不能看到 Agent 的完整上下文。量子位 11-08 转述 Muse Secure VM 的做法可当参照：凭据由 authd 在网络边界注入，模型接触不到原始密码（媒体转述、非官方文档，仅作设计参照）。

第 5 步｜重设默认态。 新插件先进只读观察期；默认不允许自动安装、不允许静默升级；高风险能力首次调用要显式授权并留痕。多数用户永远不会打开配置面板，你评审的应该是默认态，不是可选项。

第 6 步｜定义退出与归档。 卸载时数据归谁、导出格式是什么、服务端副本多久删除、怎么给用户一份可核验的删除回执。昨天 B 篇写 Kimi 时那句「删除需先归档」在这里更严格——因为归档方可能是第三方。

六、五问判断清单、三种团队规模、三件不要做的事

选型或评审时，把这五问甩给供应商

三种团队规模的最小可行做法

三件不要做： 不要用下载量代替风险分级；不要在没有旧基线的情况下批量关插件（你会在同一天失去对照组和回滚能力）；不要把「加强插件安全」当成已交付功能写进对外承诺——官方目前给的是意向，不是机制。

七、口径说明

学姐把官方尚未给出的项列清楚，一律不推测：官方市场上线日期、审核规则与准入标准、插件权限模型与沙箱边界、插件 API 稳定性与兼容承诺的具体范围、扶持计划的参与规则与额度、用户数据的归属与删除路径、以及 3.5 万个插件的统计口径（是否含重复、失效、私有包）。中文日报与英文一手帖在发布日期上也存在 11-05 / 11-08 的差异，本文按官方 X 帖与 Bloomberg 口径处理。

六步清单、四级分类与五问表是学姐反推的产品工具，不是 DeepSeek 官方方案，也不构成对任何插件的安全评价；所有规模与性能数字均为公司自述、未经独立审计，仅作趋势信号。

一句话总结

插件数量是分发指标，状态持有才是治理单位——生态跑得比规则快的时候，产品该做的不是喊停，是先给存量分级。

作者说

学姐是 211 本、985 硕，工业设计加人机交互背景，现在做软硬件 AI 产品。我参与过一次插件市场上线，最贵的不是审核系统，是上线半年后才发现有一批插件早就在替用户存文件，而我们的卸载流程从没设计过导出。所以今天看到「3.5 个插件、60% 用户、市场和规则待建」，第一反应不是兴奋，是想起那次补作业的排期。