dsh plugin 装到哪个 profile：web、desktop 与自定义 profile 的落点

dsh plugin 装到哪个 profile，取决于你从哪个入口打开 DeepSeek Harness，而不是包本身有什么限制。 浏览器入口对应 web profile，桌面客户端对应 desktop profile，实验和隔离验证则用自定义 profile。装错位置最常见的结果不是报错，而是「明明装好了却在另一端看不到」。

dsh plugin 的 profile 落点：入口决定安装位置

profile 是一套独立的插件组合，入口不同，落点就不同，跨端推断是最常见的错误来源。

DeepSeek Harness 把插件、配置和运行状态按 profile 分开存放。web profile 服务浏览器界面，desktop profile 服务桌面客户端，两者各有自己的已装列表。插件包可以相同，但装进哪个 profile 决定了它在哪个入口被加载。

因此安装前要先回答一个很具体的问题：你平时从哪里打开 Harness。如果是在浏览器里输入地址使用，就选 web；如果是双击桌面应用，就选 desktop。这个问题看起来简单，却能解释大多数「装了没反应」的情况。

自定义 profile 的存在是为了第三种场景：你不想让实验插件污染日常环境。它可以指定独立的启动方式，只加载你放进去的那几个插件。它不是一个更高级的 profile，也不适合直接复制日常配置。

还有一个容易忽略的事实：同一个插件可以同时装进多个 profile，但每个 profile 里的实例彼此独立。配置、缓存和授权状态都不会自动同步。想让两端行为一致，只能分别安装、分别验证。

DeepSeek Harness 的 web profile：浏览器端怎么装

浏览器入口的插件必须装进 web profile，装完还要刷新页面才能看到变化。

确认入口之后，安装动作本身并不复杂。关键是命令里要明确写出目标 profile，不要让 CLI 按当前上下文猜测。默认落点往往是最近使用的那个 profile，和你想装的位置未必一致。

安装完成后先用列表命令核对，再去浏览器里实际打开一次。列表里有、页面里没有，通常是前端缓存没有刷新；列表里也没有，才说明安装没有落到目标 profile。两种情况的处理方式不同，先分清再动手。

dsh plugin install dsh-plugin-hub --profile web
dsh plugin list --profile web

刷新页面之后，市场条目和已装列表都应该出现变化。如果条目出现了但功能不可用，问题通常不在安装位置，而在插件版本与本体版本的匹配。这时候去看插件条目的兼容说明，比反复重装更有效。相关条目可以在 DSH Plugin Hub 对照。

dsh plugin 装进 desktop profile 的正确姿势

桌面端是另一套组合，需要单独指定 desktop profile，并在安装后重启客户端。

桌面端的安装流程和 web 类似，但多了两个容易漏掉的步骤。一是安装时要显式指定 desktop profile，二是部分插件在安装后还需要执行一次应用或启用操作。少了后者，插件文件在，加载列表里却没有它。

桌面客户端的版本也会影响结果。较旧的客户端可能不认识新版本插件的清单格式，表现同样是「装了看不到」。遇到这种情况，先确认客户端版本，再确认插件要求的最低版本，顺序不要颠倒。

安装完重启客户端，是让加载器重新读取插件清单的最直接办法。重启后先看插件管理页，再实际调用一次功能。两步都通过，才算这次安装真正完成。

自定义 profile 与 DeepSeek Harness 的隔离验证

自定义 profile 适合放待验证的插件，不适合当成日常环境的备份或副本。

新建自定义 profile 时，只装这次要验证的插件，依赖能少则少。插件之间的相互影响是排查问题最麻烦的部分，环境越干净，结论越可靠。如果一次装五六个插件，出问题时你很难判断是谁引起的。

配置也不要整份复制。日常 profile 里的路径、密钥和授权状态，复制过去可能指向错误的位置，还会让两边互相干扰。需要哪些配置就手工补哪些，顺便确认每一项在新环境里仍然有效。

验证完成后要有清理动作。不再需要的 profile 应该删除，避免它长期占用磁盘、混淆后续判断。如果这个 profile 还要留着，就写清楚它的用途和最后验证时间，否则几个月后没人记得它是干什么的。

隔离验证的价值在于可重复。同样的插件组合、同样的本体版本，在干净 profile 里能复现问题，才有讨论的基础。如果只在日常环境里试一次，结论往往只能算个例。

DSH插件 装在另一个 profile 为什么看不到

看不到不等于没装上，先确认当前入口和 profile，再怀疑安装失败。

最常见的情形是装到了 web，却从桌面端找。两个入口读取的是不同的插件目录，桌面端当然不会显示 web profile 里的内容。这种时候重装多少次都没用，换对 profile 才有意义。

第二种情形是启动命令带了别的 profile。命令行工具可能记住上一次使用的配置，或者被环境变量覆盖。你以为在操作默认 profile，实际写进了另一个位置。用列表命令确认当前 profile，比凭印象判断可靠。

第三种情形是插件装了但没有启用。部分插件需要显式开启，或者依赖某个宿主能力才能出现在界面上。这类情况下，插件列表里能看到名字，功能入口却是灰的，和「完全看不到」是两种不同的症状。

把症状分开之后，排查路径就清楚了。列表里没有，查安装落点；列表里有但入口缺失，查启用状态；入口有但功能报错，查版本兼容。不要把所有「看不到」都归因于安装失败。

DeepSeek插件 的跨 profile 迁移与核对

迁移靠清单重装，不靠复制目录，配置要逐项核对而不是整包搬运。

迁移之前先导出清单，写清包名、版本和必要的配置项。清单不需要多复杂，能让你在目标 profile 里一条条装回去就够。有了清单，迁移过程可重复，出问题也能对照着回退。

在目标 profile 里按清单重新安装，然后逐项核对配置。路径、端口、授权信息是最容易出错的三类，复制目录时它们往往还指向旧环境。核对完再启动，比启动后发现异常再回头查省事得多。

旧 profile 不要立刻删除。先让新环境跑一段时间，确认插件列表、功能和配置都正常，再清理旧目录。迁移期间两个环境并存是正常的，关键是别让它们共用同一份配置。下面这份顺序可以固定下来，每次迁移照着走。

1. 导出目标 profile 的插件清单，记录包名与版本。
2. 在新 profile 中逐条安装，避免使用浮动版本号。
3. 核对配置中的路径与端口，确认没有指向旧环境。
4. 检查授权与登录状态，必要时重新授权。
5. 启动目标入口，确认插件列表与预期一致。
6. 实际调用一次核心功能，确认不只是「显示正常」。
7. 保留旧 profile 一段时间，确认稳定后再删除。

来源：deepseek-harness CLI README、DeepSeek Harness 快速开始、npm @deepseek-ai/dsh。