DSH 装完，第一件事不是用，是装插件。
因为它是空的。模型、工具、会话、界面，连 agent loop 都是插件。你不装，它就是个能对话的框。
于是所有人都在搜「必装清单」。我搜了，看了十几篇，然后发现一件事：这些清单本身对不上账。
dsh --version 打出来的为准。这篇写于 2026 年 10 月底，那时最新的候选版是 0.2.1-rc.2。版本对不上，先看第四节那张配对表，别照抄。1. 清单不可信，但你可以信自己的核对
同一个 dsh-market，我在三个站看到三个星数：3,428、8,235、9,425。安装命令也有两个版本，一个写 dshmarket，一个写 github:dsh-market/dsh-market。billion-context 的月下载，一处 175 万，一处 180 万。
不是谁造假。抓取时间不同、口径不同（npm 下载量还是站内点击），加上大量站点互相抄，数字就在传抄里长歪了。
所以星数只能用来「发现」，不能用来「决策」。我现在的判断顺序是这样，三条，缺一条就跳过。
- 最后提交在三个月内吗？ 一个半年没动的插件，在 DSH 这种还在预览期、版本天天破兼容的宿主上，基本等于废了。
- 它声明了支持的宿主版本吗？ 看
package.json里的engines.dsh，或者@deepseek-ai/dsh-*的 peer 范围。没声明的不是不能用，是没人替你对过账。 - 它要的权限你给不给？ 插件跑起来就是你的用户身份，能读文件、能用凭据、能连网。这条比前两条重要，但只有前两条过了才轮得到它。
2. 插件装在 profile 里，不是装在系统里
这是理解 DSH 插件的唯一关键，也是最多人翻车的地方。
dsh web 启动的是 web profile。桌面版启动的是 desktop profile。headless 是另一套。每个 profile 在 ~/.dsh/profiles/<名字>/ 下有自己的 package.json 和 node_modules。
所以「我装了但没有标签页」，九成是装错了 profile——你在 web 里翻界面，插件躺在 desktop 里。
命令统一是这个形状：
dsh plugin --profile web add dsh-better-sidebar@latestdsh plugin 本身不做安装，它把参数原样转发给 profile 目录里的 pnpm。所以你给的必须是 pnpm 认的源：npm 包名、github:owner/repo#ref、link:/本地路径。
三条安装路径，各有各的场合：
| 路径 | 适合谁 | 代价 |
|---|---|---|
| 设置 → 插件 / 插件市场 | 刚上手，只装一两个 | 桌面版和 web 版界面不一样，别照着别人的截图找 |
dsh plugin add |
长期用，要固定版本 | 桌面版必须先完全退出（托盘右键退出），否则进程锁冲突 |
cordis.patch.yml |
自己写插件，或者做可复现环境 | 手改 dsh.profile.bundles 会让后面的更新没法诊断 |
第三种我只在一种情况下用：需要把整套环境钉死、能进 Git 的那种。
3. 我会装的顺序
原则一句话：一次装一个，重启一次，拿一个真活儿试一遍，再装下一个。
第 0 个：入口
dsh-market。装完，设置里多一个「插件市场」。
它最大的价值不是「能搜插件」——目录站也能搜。是它能管你已经装了的东西：看运行状态、逐插件检查更新、给每个插件写一句备注。装到第十五个的时候，你会需要那句备注来想起「这个到底是干嘛的」。
安装命令以插件页面上写的那条为准，我看到过两种写法：
dsh plugin --profile web add dshmarket
# 或者
dsh plugin --profile web add github:dsh-market/dsh-market装完重启 dsh web，再去设置里看。如果「插件市场」这个入口压根没出现，先查宿主版本——它要求 dsh web 0.1.0-rc.6 以上，更老的宿主上它会自己禁用，只在浏览器 console 里说一句。
第 1 个：上下文
billion-context。作用是压缩会话，把 100K 的窗口当更长的用，官方口径是省五倍 token。
这东西在下载榜上是断层的——我看到的几个榜单里它都排第一，月下载一百七十多万。原因很朴素：长会话是所有人的痛，而它是唯一一个直接消除这个痛的。
一个提醒：它的许可是 MIT 加署名条款。自己用无所谓，如果你做的东西要交付给客户，这条会落到你头上，装之前把 LICENSE 读一遍。
第 2 个：界面
dsh-better-sidebar。把右边那一列从「只读预览」扩成能干活的：文件树可编辑、真终端、Git diff 和历史、子代理的执行状态。
我用它的理由很具体：让 AI 改完六个文件之后，我需要一个地方看「这一轮到底动了哪几行」。Git 面板是全量的，它有一个视角只列本轮改动。这个差别，用过就回不去。
它有版本配对问题，单独放在第四节讲，因为这是最容易踩死的一个坑。
第 3 个：眼睛
ModLens（@liustack/modlens）。给纯文本模型补视觉：截图丢进去，出来的是结构化 JSON——OCR 文本、版面结构、实体和关系，不是一句「图中是一个报错窗口」。
什么时候需要它：你的模型路由不接受图片输入，而你的日常里有一半问题是靠截图描述的。什么时候不需要：你的模型本来就能看图，那这个插件只是多一层。
之后按痛点补，不按榜单补
- 账单：
Balance Whale Widget或dsh-api-balance。角落显示余额、当日花费、单次成本，支持三十多家厂商模板。它的价值不是好看，是让你在烧穿之前知道。 - 搜索：
ModSearch/dsh-free-search。给不能联网的模型补搜索，免费、免 key、多引擎回退。官方搜索现在便宜了，但免费的仍然不亏。 - 看清上下文里装了什么：
dsh-context。构成饼图、/context命令、压缩和注入事件留痕。 - @ 文件：
dsh-at-file。@文件名直接引内容，多个文件对比。 - 接微信：
dsh-wechat。人不在电脑前也能批权限、接着聊。 - 接管浏览器：腾讯的
BrowserSkill。用它你已经登录的 Chrome / Edge，能读页面、填表、截长图。
这些我一个都没装。不是不好，是我现在没有那个活儿。
4. 四个坑，按踩到的概率排
第一个：版本范围。
这是最阴的一个，因为它不报错。
dsh-better-sidebar 有一个明确的配对表，社区实测出来的：
| 你的宿主 | 装哪个版本 |
|---|---|
0.2.0-rc.1 及以上 |
@latest（当时是 0.24.x） |
0.1.7-rc.1 / rc.2 |
必须钉死 @0.22.1 |
0.1.6 及更早 |
@0.19.1 |
关键在于：写成 ^0.1.7-rc.1 这种 caret 范围跨 minor 不成立。在 0.2.0 的宿主上，它会被启动预检直接禁用整行——不弹窗，不写日志，你只会以为插件没装上。
所以：先 dsh --version，再决定装哪个版本号。别用 @latest 图省事。
第二个：一次装五个。
装完白屏，你有五个嫌疑人，而且你不知道是哪一个。
一次一个。装完重启，跑一个真的任务——不是「看一眼有没有新按钮」，是让它干一件你本来就要干的事。能用，再装下一个。
第三个：GitHub 源被 pnpm 拦。
从 GitHub 装的插件，如果带 prepare 构建脚本，pnpm 10 以上默认阻止。CLI 会打印出需要加的那个 key，在 profile 的 pnpm-workspace.yaml 里 allowBuilds 下面加上，重跑。
同时把 commit 钉住：github:owner/repo#<sha>。不然上游明天 push 一次，你装的东西就变了，而你不知道变了什么。
第四个：桌面版的进程锁和 profile 归属。
用 CLI 操作桌面版插件，必须完全退出应用——macOS 是退出进程，Windows 是从托盘右键退出，关窗口不算。不然就是锁冲突。
还有一条更硬的：desktop profile 由 Electron 独占管理。dsh --profile desktop --dump-config 会被直接拒绝，提示 managed exclusively by the Electron application。CLI 既不能 dump 也不能启动它。桌面版的插件，就在桌面版界面里管。
5. 怎么证明它真的装上了
这一段是这篇里我最想让你记住的。
装完看到新按钮，不等于装上了。看到 list 里有这个包，也不等于生效了。
判据只有一个：组合树里有没有它那一层。
dsh plugin --profile web list # 装了什么依赖
dsh --profile web --dump-config # 运行时到底加载了什么第二条输出里，每个生效的组合包会打印出一个 # == 开头的层。有那一层，才算挂上了。
两个命令对不上，是很常见的情况：包在 list 里、不在 dump-config 里，说明它是个没声明 dsh.bundle 的普通依赖——装是装上了，但不激活任何配置层。安装时 CLI 其实会为这种情况打一条警告，只是没人看。
如果连 dump-config 都对上了，但界面还是没反应，按这个顺序往下走：
- 运行时：
node -v、dsh --version、pnpm 版本。版本错位产生的问题，长得跟插件 bug 一模一样。 - profile：你装的和你在跑的是不是同一个。
ls ~/.dsh/profiles看一眼有几个。 - bundle：
package.json里声明的 patch 文件，包里到底有没有。 - 重复的 Cordis：依赖树里出现两份 Cordis，服务身份就崩了，插件互相看不见。
npm ls cordis查。
最后，界面类插件改完先硬刷新（Cmd/Ctrl+Shift+R）。客户端那半边是半热加载的，不刷新你看的还是旧的。
6. 退路
DSH 这点做得好：插件是声明式的。装 = 往配置栈里插一行，卸 = 把那行删掉，重启，所有注册的工具、面板、中间件一起注销，不留残渣。
dsh plugin --profile web remove dsh-better-sidebar
dsh web前提是你没手改过 dsh.profile.bundles。手改过的，顺序和层级就可能对不上，删不干净。
所以装之前做一件三十秒的事：
cp ~/.dsh/profiles/web/cordis.patch.yml ~/dsh-web-profile-backup.yml还有一个时间点的坑值得单独说。0.2.0 那一波升级，社区当天报了三类问题：插件批量失效、工作区被清空、Windows 上 0xC0000142 沙箱启动失败。同一批 issue 里还有个更细的：0.2.0 把「自动化任务」改成了一个可选插件包，升级之后原来的定时任务可能就没了，直到你补装那个包。
结论不是「别升级」，是：RC 版本永远别用 @latest，钉死版本号。 升之前备份 profile，升完先跑一遍你最常用的那个活儿，再干别的。
7. 那条线
插件跑起来，用的是你的权限。这一句要展开说：市场安装不执行 package script、会做产物完整性校验——但这只保护「安装」这一秒。装完之后它读文件、用凭据、连网，全都跟你自己敲命令一个权限。
工具审批管的是模型调工具，不覆盖插件自己的代码。
所以我的规矩是两条：
- 敏感项目单独开一个 profile，里面不装任何来路不明的东西。
- 装之前花两分钟翻一眼仓库：谁的、什么许可、有没有 lifecycle script、要不要网。
许可这件事比想象中容易漏。我看到的例子里，有一个下载量排第一的插件是 MIT 加署名条款，还有一个代码审查插件用的是「非商业」许可——源码公开，能用能改，但不能商用。自己玩没人管你，交付给客户就是另一回事。
还有一类我直接划掉：反代别家产品来「薅额度」的。这类插件不是技术风险，是账号风险——我看到的那个已经因为上游风控被处置、仓库归档停止维护了。
8. 最后
我在同一个下午搜了十几篇「必装清单」，把它们对了一遍账，星数、下载量、安装命令、版本号，几乎没有两篇完全一致的。
这不是说别看了。是说看完之后，能信的只有你自己 --dump-config 打出来的那一屏。
所以建议很短：装三个，用一周，然后删掉一个。
删掉的那个，一定是你一周里一次都没打开的。它存在的理由，只是它在某个榜单上排得靠前。
写于 2026 年 10 月
发表回复