DeepSeek Harness（DSH）插件生态观察：热度怎么读、哪些插件值得盯（2026-08）

aimright · 2026 年8 月 20 日 03:58

DeepSeek Harness（DSH）是眼下增长很猛的一个本地 AI agent 运行时：主仓 [deepseek-ai/deepseek-harness] 星标 16.9 万（MIT，2026-08-19/20 实测；08-23 复核已到 18.87 万——四天涨了近两万），口号是「万物皆插件」——模型、工具、技能、会话、沙箱、存储、界面全部可替换。它仍处 developer preview，官方明确核心插件与 API 会继续变。

主仓星标四天涨约 12%，这个量级说明热度正在上升。下面从星标、插件生态结构和安装风险看 DSH 的使用边界。

下面依次看插件生态的热度、星标榜的读法和插件观察清单，清单包含 GitHub API 核到的许可证警示。装不装之前，官方还写过一套安全建议，第六条就是只装经过审阅的插件；这一层和星标榜是两件不同的事。产品本体、数据默认落在哪，见[DeepSeek Harness 能读文件跑命令，装之前先看它把你的数据放在哪]；权限两个旋钮怎么拧，见[把 DeepSeek Harness 接进真实目录之前：官方自己写了六条建议，和一个沙箱管不到的地方]。

DSH 的定位与产品边界

它是一个可组装、可审计的本地 agent 运行时：给它一个工作区，agent 能读写文件、执行命令、委派子任务，高影响动作前请求人工批准，全程留追加式执行轨迹。产品团队可以把 DSH 放在可替换的运行时适配层后面，外层用成熟的桌面/Web 技术做产品壳；直接把它的 Web UI 包成消费级产品，会把用户体验绑在 preview 项目的升级节奏上。

插件生态的真实规模

GitHub 上带 dsh-plugin 标签的仓库约 7,700 个（2026-08-19 取数；08-23 复核已到 11,072 个，两周不到涨四成），但混有大量非插件项目。精选目录 [awesome-dsh-plugin]（10.2k，2026-08-19/20 实测；08-23 复核 11.9k，许可证 CC0-1.0）要求每个条目带 dsh.bundle manifest、可通过 dsh plugin add 安装，收录约 1,487 个条目。目录的自我定位是只确认能装，不排质量，不做安全审查。

这两个数你可以自己复现，零 AI：

# 带 dsh-plugin 标签的仓库总数
gh api "search/repositories?q=topic:dsh-plugin&per_page=1" --jq '.total_count'
# 任一仓库的星标/许可证/最后提交/归档状态
gh api "repos/<owner>/<repo>" --jq \
  '"\(.full_name) ⭐\(.stargazers_count) \(.license.spdx_id) push \(.pushed_at[:10]) archived=\(.archived)"'

标签数与目录收录数差了近一个数量级。dsh-plugin 是开放的自述标签，目录条目则至少过了「能装」这一关。

按目录 2026-08-18 的星标快照统计前 100 名，热度集中在五类基础缺口（分簇按插件自述功能归类，目录没有提供这些分类字段；同一个插件可能横跨两簇，按主要卖点归一次）：

需求簇	前100中的数量	在解决什么
界面与控制感	19 个	任务板、侧边栏、TUI、文件引用——用户要看见 agent 在干什么、是否能回退
工作流编排	9 个	需求→执行→评估的可重复流程、多 agent 分工、定时任务
长期记忆	8 个	跨会话不失忆：项目知识、偏好、失败教训的可控沉淀
通知与人工接管	8 个	长任务何时叫人回来批准——agent 正在变成异步系统
插件市场与发现	8 个	1,500 个插件里选哪个、怎么升级、冲不冲突

一个反直觉信号：安全类在目录里有 57 个条目，进前 100 的只有 2 个。安全插件难演示、难传播，策略执行、审计、凭证隔离这一层的供给仍然不足。对做企业级产品的人，这是空白信号；对普通用户，这是风险信号：生态的注意力还在功能和界面上。

星标榜怎么读才不上当

前 100 的星标分布是极端幂律：第 1 名占前 100 星标总和的 29.2%，前 10 名占 85.6%，第 50 名只有 75 星，第 100 名 24 星。

这四个百分比的算法：取目录 2026-08-18 快照里按星标降序的前 100 条，每条的星标取 gh api repos/<owner>/<repo> 返回的 stargazers_count，直接求和与占比，不剔除任何项目。29.2% 和 85.6% 是「含上游继承」的口径。

榜首基本是「上游大项目的 DSH 适配器」——比如排第一的记忆插件是火山引擎 OpenViking 主仓下的一个子目录，目录统计时继承了主仓约 3 万星标（08-23 复核为 32,550）。这里把插件位于体量远大于自身的主仓子目录视为「上游继承」。按这个规则扣掉之后，DSH 原生插件的真实星标池要小得多；3 万星代表主仓热度，插件自身的用户规模需要另行核实。

判读口径：前 20 名反映的是上游品牌势能和对核心缺口的补齐程度；20 名之后星标差距很小，适合作为「值得看」的候选清单，不能当使用率排序。

值得观察的插件清单（2026-08-19/20 逐仓实测）

以下每行的星标、许可证、最后提交都是 GitHub API 直接核验的，取数时点 2026-08-19/20；2026-08-23 对这 11 个仓库全量重跑，owner/repo、许可证、活跃状态全部对得上，无一归档，星标普遍上浮（例如 Archify 14.5k→15.2k、dsh-market 1.3k→2.0k），表里仍保留首轮快照值。

插件/项目	星标	许可证	最后提交	为什么盯
[OpenViking 记忆适配]	30.4k	AGPL-3.0	08-20	记忆是 agent 第一缺口；AGPL 的网络分发条款影响面大，把它的代码并进宽松许可项目很可能出问题，集成前必须过法务
[Hindsight]	20.3k	MIT	08-20	会学习的项目记忆、每仓库记忆库，许可证干净
[Archify]	14.5k	MIT	08-19	把 agent 输出落成架构图/时序图——「可交付工件」思路
[Ouroboros]	5.6k	MIT	08-19	需求访谈→执行→评估的完整工作流方法论
[DSH Web UI 合集]	4.9k	Apache-2.0	08-20	任务板/Git 图/Token 统计，DSH 原生生态里最完善的界面插件
[Mirage]	3.5k	Apache-2.0	08-20	虚拟工作区：按挂载点控制 agent 能碰什么资源
[Modlens]	3.3k	MIT	08-19	给文本模型补 OCR/版面/图像证据
[better-sidebar]	2.4k	MIT	08-19	文件/终端/Git/子代理一个操作面
[dsh-market]	1.3k	MIT	08-19	设置内浏览/安装/更新/备份——生态的发现与治理层
[Aegis]	1.1k	MIT	08-19	规划/调试/验证的技能包——卖方法论而非工具
[API relay audit]	795	AGPL-3.0	08-15	前 100 里罕见的安全审计插件（注入/改写/泄漏检测）；同样是 AGPL，集成取舍是只借思路不并代码，具体取决于分发方式，需问法务

许可证之外还要看使用政策。Harness 源码是 MIT，但官方[《安全使用政策》]另列了九类禁止用途，其中包括任何形式的军事用途，任何形式的网络攻击或化学、生物攻击，对个人或群体进行有害操纵，未经适当授权或出于不合理目的生成与传播可识别个人信息，以及任何违反适用法律法规或侵害第三方合法权益的使用。拿它做对外产品的团队，需要先过这一层法务审查。

装插件前的三层筛选（按顺序执行）

精选目录自己写明：插件以你的权限在你机器上运行，能读文件、用凭据、访问网络；对工具调用的审批无法把插件代码本身沙箱化。官方政策把同一件事写成可照做的第六条：只安装和运行来自可信来源、经过审阅的插件、MCP 服务器、Skills、Hooks 及其依赖。[Safe Use Policy] 所以顺序必须是：

热度层：先确认它解决明确的工作流问题，再看星标属于 DSH 专属还是上游仓库继承；排名只用于筛选候选。
适配层：支持你的 DSH 版本吗？与现有插件冲突吗？能固定版本、能回退吗？——先在隔离 profile 里试。
安全层：它读文件吗、开 shell 吗、联网吗、碰 API key 吗？维护者和依赖可信吗？——存有客户资料、私钥或生产凭据的机器，默认不装社区插件。

官方六条里，跟装插件最相关的几句

《安全使用政策》开头就承认了风险来源：Harness 能访问各种系统，并代表你在本地电脑上执行操作；因为它能跑代码、能执行动作，所以引入了独特的安全风险。官方还写明，尽管多数基础模型内置了针对提示词注入的基本防护，通过 Harness 与互联网交互、或者经由其他不可信数据源工作时，固有风险仍然存在。[Safe Use Policy]

同一页给出的六条建议可以直接照做。

第一条是用一台专用的虚拟机或权限受限的容器，官方给的理由是降低本地系统被攻击、或意外接触到关键系统资源的风险。第二条是始终仔细审阅 Agent 生成的代码与测试内容。第三条是避免向 Agent 提供敏感或机密信息。第四条是本节最硬的一条：任何可能导致重大变更的系统或操作，都应始终要求人工批准。第五条是尽可能把复杂指令拆成更小的、彼此隔离的操作。第六条就是上面说的那句——只装可信且经审阅的插件、MCP 服务器、Skills、Hooks 及其依赖。[Safe Use Policy]

政策里还有一句话值得单独摘出来，因为它是官方对提示词注入最直白的承认：在某些情况下，Agent 可能会执行嵌在内容里的命令，即使这些命令与它被分配的任务相冲突。[Safe Use Policy]

这句话对装插件的人特别具体。你让它读的每一份外部文档、每一个网页、每一个插件拉回来的结果，都是一条可能的指令通道。第三条和第六条之所以重要，原因都在这一句里。工具具备执行能力时，付款、签约、删除生产数据这类动作仍应逐项审批；一旦出错，后果由真实账户和真实业务承担，界面上的审批按钮也不能替代业务风控。官方第四条本身就是分界线——把「重大变更」在自己的场景里写成一份具体清单（哪些目录、哪些命令、哪些外部调用），比在配置文件里选一个预设更有用。

三条使用取舍

DSH 当 agent 引擎用：它解决「agent 怎么运行、怎么被限制和追踪」，产品体验交给可替换的适配层。
记忆类插件是最大的价值点，也是最大的误用点：把客户材料混进统一记忆池是灾难。正确形态是按项目/案件隔离、可导出、可删除。现有系统把「记忆」按数据敏感级分层，最敏感一层连本地模型的上下文都不进。
安全供给不足同时带来机会和警告：在权限声明、最小化外发、可验证审计上补位，比再做一个 UI 皮肤更有长期价值。

安全层具体查什么（装之前逐条过）

上面第 3 层说「读文件吗、开 shell 吗」太笼统，落到可执行的检查点是这六条：

dsh.bundle manifest 在不在、里面声明了哪些权限，声明与实际代码对不对得上。
有没有网络出站——尤其是往作者自己的域名发东西。
有没有 shell 执行、eval 这类动态执行。
碰不碰凭据：读环境变量、读 ~/.ssh、读浏览器 cookie 都算。
依赖链有多深，有没有从非官方源装包。
维护者是谁、这个仓库还有没有别的活人在提交。

前四条 grep 一遍就能过；后两条要人看。六条里任何一条答不上来，就先放在没有客户资料的隔离环境里。

第二条要和官方沙箱文档对着读。开发者文档把权限拆成两个互相独立的旋钮：沙箱模式和批准策略。权限预设这一层只是把这两个旋钮打包成客户端上的一个选择器，它自己不做任何执法，只记录意图并写回两个旋钮各自的设定入口。[Permission Presets]

官方默认的预设表里有两个条目。workspace-write 等于沙箱模式 workspace-write 加批准策略 ask；danger-full-access 等于沙箱模式 danger-full-access 加批准策略 never。[Permission Presets]

这两个旋钮各自的定义要分开读。沙箱模式有三档：read-only 只允许必需的写出口（POSIX 运行器会额外放行 shell 需要的 /dev/null）；workspace-write 额外允许写入工作区根目录和后端约定的临时区；danger-full-access 绕过约束。批准策略有两档：ask 是默认值，把请求交给已组合的应答者链；never 则不派发给任何应答者，确定性地返回拒绝。[Process Sandbox] [User Approval]

所以名字里带 danger 的那个预设，改的不只是沙箱，它同时把批准策略换掉了。具体到某个工具上会发生什么，取决于该工具怎么消费这两个值——文档写明 dsh-tools 与 dsh-tool-bash 消费的是封闭结果，除 allowed-once 之外一律失败关闭。换预设之前在空目录里实测一遍它在你机器上的实际行为，比读文档更靠得住。[User Approval]

官方文档对沙箱模式的定义里有一句限定，它比三档模式本身更重要：沙箱模式只管文件效果，网络和进程可见性不在这套词汇的范围内。[Process Sandbox]

这一句把「关进沙箱再装插件」的直觉推翻了。把 Agent 关进 workspace-write，限制的是它能往哪里写文件；它仍然可以联网，也仍然能看见系统上的进程。社区插件如果往作者域名发东西，文件沙箱拦不住。对做跨境业务、需要考虑客户资料出境的人，这条限定的实际含义是：文件沙箱不构成数据不出境的保证，那是另一套要单独设的东西。

还有第二层要注意：执法程度本身是一个被报告出来的事实，实际边界取决于后端。文档写明，full 表示后端管住了该模式承诺的每一项文件效果，partial 表示当前后端或较旧的内核 ABI 只管住了其中一部分，需要绝对保证的调用方必须拒绝或把这个差别显式地暴露出来。当前已知的 partial 情形包括较旧的 Landlock ABI，以及 Windows ACL 运行器在 Everyone 与硬链接上的边界。后端本身按平台不同：Linux 用 bwrap 与 Landlock，macOS 用 Seatbelt，Windows 用 ACL 受限令牌。同一个 workspace-write 设定，在三个平台上的实际约束强度并不相同。[Process Sandbox]

批准机制这一层有一个值得肯定的细节。文档写明结果集合是封闭的：allowed-once 只授予被问到的那一个动作；调用方在 rejected、cancelled 和 unavailable 三种情况下都要拒绝执行。缺失的、不归属的、抛异常的或者不符合约定的应答者，一律变成 unavailable，执行路径保持关闭。[User Approval]

用人话说：出了岔子的时候，它默认往「不做」的方向倒。评估任何一个会替你装插件、跑命令的 Agent 工具时，都值得先问这一句——它坏掉的时候，是拦住还是放行。

主仓与插件仓为 2026-08-19/20 GitHub API 实测，2026-08-23 全量复核一次；前 100 榜单统计基于精选目录 2026-08-18 星标快照，口径含上游继承、未做剔除。官方安全使用政策、权限预设、沙箱、用户批准四页按 2026-08-26 文档状态写入。

拓展阅读

美国 MacStadium CIO 调研复核…：同版块的站内帖，同样围绕复核，往深里读接这一篇。
苹果AI硬件2026观察：能确认的是Mac增长，不是“AI基建股”：还是观察，同版块的另一篇站内帖。
8 月 28 日 AI 三条：OpenAI 补亚太执行层…：同版块的站内帖，同样围绕工作流，往深里读接这一篇。
2026 AI视频生态全图：Runway / Luma / Wan…：AI实战·办公与学习的长青帖，另一条线上和态全挨着的一篇。
Copilot Cowork的安全边界：权限、审计、合规全解析：换个版块看权限：AI实战·办公与学习的长青帖。

参考资料

飞出国编辑部修订 · 2026-09-07。本文为本次修订内容。