deepseek harness plugins 从哪装：DeepSeek Harness 三大插件来源与首装 5 个

deepseek harness plugins 的答案不是一份清单，而是三条来源加一套验证动作：官方内置与组合包、内置的 DSH Plugin Hub、GitHub 与 npm。先确认你要的能力属于哪一类，再决定从哪装、装完怎么验证。

概览：先把「插件」这个词拆开

搜索 deepseek harness plugins 的人，通常卡在同一个地方：知道有插件，但不知道从哪开始装。 这个问题可以拆成三步：先分清插件、插件包与 profile 三个对象，再认清三条来源，最后用两条命令验证装没装进去。三步走完，后面加插件就是重复同一套动作。

DSH plugin 是一个导出 apply 函数的 TypeScript 模块。 框架加载时调用 apply 并传入 ctx，插件在 ctx 上注册命令、工具、界面组件或服务（来源）。所以「装插件」不是装一个独立软件，而是把一段注册逻辑挂进某个运行环境。

profile 决定这段逻辑挂进哪里。 web、headless、desktop 各自维护独立的依赖树与配置，同一个插件装进两个 profile 就是两个实例，互不影响。搜索英文词的人常忽略这一点，结果在桌面端装完，去命令行里找不到。

插件包则是分发形态。 它可以是一个 npm 包，也可以是一个 GitHub 仓库引用；Hub 里的「插件」条目只是这两种来源的展示层。理解这层关系，看到同名插件时就不会慌——先看来源与包名，再看名字。

三大来源：官方内置、Hub、GitHub 与 npm

DeepSeek Harness 的插件来源只有三类，区别在「谁维护」和「怎么发现」。

官方内置与组合包解决「基础能力」问题。 这类包跟核心版本一起走，升级时同步升级，优点是不用自己判断兼容性。缺点也明显：它只覆盖官方认为通用的能力，长尾需求要靠社区。

DSH Plugin Hub 解决「发现」问题。 入口在「设置 → 插件市场」，可以按分类浏览、搜索、看卡片上的版本与验证状态，再一键安装（来源）。Hub 是社区项目，与 DeepSeek AI 没有隶属关系，但它把来源、兼容版本、验证状态放在同一张卡片上，省掉了来回查仓库的时间。

GitHub 与 npm 解决「来源」问题。 Hub 详情页里的安装命令，最终指向的就是这两者：写 github: 就装仓库，写包名就装 npm 包。想确认一个插件到底从哪里来，看详情页的来源标注，比看名字可靠。

三者不是互斥关系。 Hub 是发现层，GitHub 与 npm 是分发层，官方内置是稳定层。日常路径是「Hub 里找到 → 看来源 → 用详情页命令安装」；排查路径是「先看来源，再回对应仓库核对版本」。

首装 5 个：按使用频率挑，不按热度

第一次装插件，不要一次装十个。 先装一个能立刻感知效果的，验证链路通了，再按需加。下面五个方向覆盖了大多数人的日常：记忆、浏览器、工作台、上下文观测、花费统计。

1. dsh-memory：跨会话记忆。 装上之后，新会话能读到你之前留下的项目偏好与结论。选它的理由是效果可见：问一个上次聊过的项目，能答上来就说明插件生效了。
2. dsh-browser：共享真实浏览器。 它让 agent 驱动一个可见、可接管的浏览器，适合需要登录态或要看页面渲染的任务。装完先让它打开一个本地页面，确认能接管再继续。
3. dsh-better-sidebar：右侧工作台。 把右侧栏变成文件编辑、终端、Git 与子代理任务的集合。它对版本匹配有要求，装之前先看 Hub 卡片上的兼容版本。
4. dsh-context：上下文仪表盘。 显示统计、趋势、事件与文件活动，适合排查「上下文为什么突然变长」。它不是必需能力，但对长期使用很有帮助。
5. dsh-cost-meter：会话花费。 在统计行显示金额胶囊与分桶账单，适合对成本敏感的人。单价配置要按你的模型价格填，默认值不一定对得上。

排序原则是「先装能验证的」。 记忆和浏览器一眼能看出有没有生效；工作台与仪表盘要看界面；花费统计要跑一轮对话才有数。先装前者，链路通了再装后者。

不要用「必装清单」代替判断。 同一份清单在别人的 profile 里成立，在你的环境里可能因为版本、系统或权限不成立。Hub 卡片上的验证状态与兼容版本，比任何清单都更接近你的实际情况。

装之前：两条命令确认环境

装插件前先确认两件事：DSH 本体能跑，目标 profile 已初始化。 两条命令就能确认，不需要猜。

1. 执行 dsh --version，能输出版本号说明 CLI 可用；报 command not found 就先解决安装问题，不要继续装插件。
2. 执行 dsh plugin --profile web list，能列出当前 profile 的插件（哪怕是空列表），说明 profile 已经初始化、插件子系统可用。
3. 如果要装的是桌面端插件，把上面的 web 换成实际 profile 名；不确定时先看 dsh --dump-config 里的 profile 段。

命令能跑通，再谈安装。 插件装不上时，一半以上的问题其实出在「本体没跑通」或「profile 用错」，而不是插件本身。

装完验证：三个信号

判断插件装没装好，看三个信号：列表里有、配置树里有、界面上有入口。 三个信号从底向上，逐层确认。

1. 列表信号： 执行 dsh plugin --profile web list，目标包名出现在列表里。没有就是没装进这个 profile，先检查 --profile 参数。
2. 配置信号： 执行 dsh --dump-config，在组合后的配置树里能找到该插件注册的段。列表里有、配置里没有，通常是包坏了或加载失败。
3. 界面信号： 重启后目标入口出现。前两个信号都正常但界面没有，先重启一次；仍然没有，去「系统日志」看加载阶段报错。

三个信号都过，才算真的生效。 只看「安装成功」的提示不够，那只能说明包下载完了，不能说明注册成功。

装完不生效的五种情况

插件装完不生效，按出现频率排，五类原因占了大多数。 每一类都有对应的判断动作，不需要重装整个环境。

1. 装错 profile。 命令里写的是 --profile web，但你在桌面端找入口。判断方法：在两个 profile 下分别执行 list，看包在哪个里。
2. 版本不匹配。 插件声明的兼容版本与核心版本对不上，加载阶段被跳过。判断方法：看 Hub 卡片的兼容版本与 dsh --version 的输出。
3. 没重启或热重载失败。 新装的插件不会自动注入已经运行的界面。判断方法：完整退出再启动，不要只刷新页面。
4. 同名插件装错来源。 市场里有多个同名条目，你装的是另一个作者的包。判断方法：对比包名与 owner，而不是只看显示名。
5. 依赖或构建脚本被拦。 安装阶段的构建脚本没有执行，包虽然下载了但产物不完整。判断方法：看系统日志里的安装阶段，确认构建步骤是否被跳过。

排查顺序建议从下往上： 先看日志里的加载阶段，再看配置树，再看列表，最后才怀疑插件本身。反过来做，容易在错误的方向上反复重装。

三个来源怎么选：一张场景表

来源选择不需要纠结，按「你要的是稳定、发现还是源码」对号入座。

日常组合是「Hub 发现 + npm 安装」。 在 Hub 里看卡片与来源，复制安装命令；需要锁版本时，把命令里的包名补上版本号。这个组合兼顾发现效率与可复现性。

出问题时回到来源。 插件行为不对，先去它真正的仓库看 issue；Hub 只是索引，不负责实现。同理，来源标注为 GitHub 的插件，不要拿 npm 上的同名包去对照，它们可能不是同一个项目。

下一步

先装一个、验证一个，再扩展。 还没装本体就先看《DeepSeek Harness 怎么安装》；装完本体后到 DSH Plugin Hub 里挑第一个插件，按本文的三信号验证，通了再装第二个。

想继续深入，可以看《dsh plugins 和 dsh plugin 有什么区别》理清搜索词，或看《DeepSeek Harness 插件市场有多少插件》了解三个统计口径。

来源：DeepSeek Harness 官方文档 - 第一个插件、dshplugin/dsh-plugin-hub、dsh CLI README、DSH Plugin Hub 插件页