dsh plugin list 怎么用？DeepSeek Harness 查看已安装插件与 profile 归属

dsh plugin list 的完整形态是 dsh plugin --profile <名字> list，它把参数转发给 profile 目录里的 pnpm，等价于在那个目录跑 pnpm list；但你要找的「已安装插件」其实有两个口径——list 看的是 pnpm 依赖，真正决定加载哪些插件层的是 profile 的 dsh.profile.bundles，两者经常对不上（来源）。

DSH plugin 概览：两个口径，先分清再看数字

在 DSH 里问「装了哪些插件」有两种答案：一种来自 pnpm 依赖（dsh plugin list），一种来自 profile 的组合包清单（dsh.profile.bundles），它们回答的不是同一个问题。 DSH插件 与 DeepSeek插件 的已装清单都靠这条命令查，先记住结论：

1. dsh plugin list：列的是 $DSH_HOME/profiles/<名字> 目录里的 npm 依赖，管「包里在不在机器上」；
2. dsh.profile.bundles：列的是启动该 profile 时按顺序叠加哪些插件层，管「运行时会加载什么」；
3. 两者不等价：内置组合包只在前者缺席，没声明 dsh.bundle 的库包只在后者缺席。

把这个区别记住，后面所有「为什么数量对不上」的疑问都会自己解开。

dsh plugin list 怎么用：转发给 pnpm，参数照旧

dsh plugin --profile <name> <args...> 会把 --profile 之后的参数原样转发给该 profile 目录里的 pnpm，所以 list 就是 pnpm list（别名 ls），pnpm 的全部参数都成立（来源）。 上手三步：

1. 先拿到 profile 名字。 启动 dsh web 用的是内置的 web profile；web 与 headless 首次使用会从随包模板自动初始化，其他名字的 profile 必须由 dsh plugin 通道创建。

2. 执行默认查询，只看直接依赖：

# 默认 --depth 0，只列直接依赖
dsh plugin --profile web list

pnpm list 的默认深度就是 --depth 0，所以不加参数时输出的已是直接依赖，而不是整棵依赖树（来源）。

3. 按需要换输出形态：

# 完整依赖树
dsh plugin --profile web list --depth Infinity

# 只列 dependencies，不列 devDependencies
dsh plugin --profile web list --prod

# JSON 输出，适合写检查脚本
dsh plugin --profile web list --json

# 按包名模式过滤（位置参数）
dsh plugin --profile web list "dsh-*"

装插件本身走的是同一条通道，《dsh plugin add 怎么用？》里有 add 的完整语法与目标写法。

DeepSeek Harness 已安装插件列表怎么读：pnpm 依赖 vs dsh.profile.bundles

dsh plugin list 的数字与 profile 的 dsh.profile.bundles 长度经常不一致，原因有两条：内置组合包从 dsh 安装本体解析、不进 profile 的 node_modules（所以 list 里看不到），而没声明 dsh.bundle 的包会装上却不激活任何层（所以 list 里看得到）（来源）。 按下面的顺序对着看，就不会读错：

1. 看 pnpm 侧装了哪些依赖：

dsh plugin --profile web list

2. 看 profile 的依赖与组合包清单——同一个文件里，dependencies 是 pnpm 管的依赖，dsh.profile.bundles 是 dsh 维护的加载顺序：

cat ~/.dsh/profiles/web/package.json

结构形如：

{
  "dependencies": { "<第三方插件包>": "…" },
  "dsh": {
    "profile": {
      "bundles": ["@deepseek-ai/dsh-base", "<第三方插件包>"]
    }
  }
}

3. 对齐两个数字：@deepseek-ai/dsh-base、@deepseek-ai/dsh-web-app、@deepseek-ai/dsh-headless 这类内置组合包总是从 dsh 安装本体解析，pnpm 只负责 out-of-tree 的包（来源）——所以 bundles 比 list 多出内置项是正常的。

4. 反向确认「装了但没生效」：如果某个包在 list 里、却不在 bundles 里，那它就是没声明 dsh.bundle 的普通依赖。dsh plugin 在安装时会为此打一条警告，并且不激活任何配置层（来源）。

5. 不启动，直接用组合树复核：

dsh --profile web --dump-config

每个生效的组合包都会打印出一个 # == <包名> 层，这份输出才是「运行时到底加载了什么」的最终答案（来源）。

按 profile 查 DeepSeek Harness 插件：换名字就看另一份清单

插件是装在 profile 上的，不是装在全局的——dsh plugin --profile <名字> list 会进到 $DSH_HOME/profiles/<名字> 目录执行 pnpm list，换一个名字看到的完全是另一份清单。 多 profile 环境的排查顺序：

1. 先列出本机有哪些 profile：

ls ~/.dsh/profiles

2. 对候选 profile 逐个查，确认目标插件装在哪一个：

dsh plugin --profile web list
dsh plugin --profile headless list

3. 判断某个插件「为什么没生效」的方向：先确认它在你实际启动的那个 profile 里（dsh web 用的是 web），否则你只是在另一个 profile 里装了它。

4. 注意应用参数不在这里：dsh plugin 只解析 --profile 并转发其余参数，而 dsh --profile web --port 8080 里的 --port 属于 web 应用——启动器只解析自己的参数，第一个它不认识的词开始就是应用的参数（来源）。

DSH plugin list 注意事项

一句话总结：list 看依赖、bundles 看加载，数字对不上很正常，用 --dump-config 定案。 四条提醒：

1. 别用 list 的数量当「生效插件数」：它既不包含内置组合包，又会带上没有 dsh.bundle 的库包；
2. 脚本里用 --json 而不是解析文本：树状输出的缩进和符号会随版本变，--json 稳定得多；
3. --depth 别乱调大：profile 的依赖树可能很深，--depth Infinity 在插件多时输出会很长，排查用 --depth 0 通常够；
4. list 是只读的：它不会改 package.json 或 pnpm-lock.yaml，放心跑。

懒得对口径？让 DSH Plugin Hub 直接给你一份准数

上面这套「pnpm 依赖 ↔ bundles 清单 ↔ dump-config」的三角对账，图形界面里一步就完成了。 装好 DSH Plugin Hub 后打开设置 → 已安装插件：界面直接给出当前环境的插件列表，带来源标签（目录插件 / 手动安装）、版本号与更新时间，行尾提供「可更新」与「卸载」；搜索、来源筛选、按名称或 Star 排序都现成。与其在命令行里对两份清单，不如让市场直接把「装了什么、能不能更新」摆在一屏里。

来源：dsh CLI README、DeepSeek Harness 官方文档 - 打包与安装插件、pnpm list（pnpm ls）命令文档