今天花了一上午在插件市场上挑插件，装了 4 个，真正能用的只有 2 个。 这篇把踩到的三个坑写下来——每个都附命令原文，你可以直接拿去对照自己的环境。
一、坑一：宿主升级了，插件没跟上，能力悄悄少了一块
我的宿主从 0.2.1-alpha.2 升到了 0.2.1-alpha.4，但两个子代理插件还停在 alpha.2。
后果不是报错，而是守卫把它们静默跳过：
dsh: skipping profile bundle "@deepseek-ai/dsh-subagent-claude-code":
incompatible with dsh 0.2.1-alpha.4: requirements {"@deepseek-ai/dsh-llm":"0.2.1-alpha.2", ...}
dsh: disabling profile plugin row "tool-subagent": ...
"跳过"两个字最坑：你不去看启动日志，就以为一切正常，实际上**"派子代理"这类能力已经被关掉了**。
- 怎么发现：升级宿主后，回头看一遍
dsh plugin list，把版本号跟宿主版本对一遍； 再跑一次dsh --profile <名字> --dump-config，grep 一下你想用的插件 id 在不在树里。 - 怎么修：注册表里通常已经有匹配版本 ⇒ 直接升到同版本，不用开任何"风险豁免"。
dsh plugin --profile web add "@scope/插件名@<与宿主同版本>"subagent系列。
二、坑二：装上了 ≠ 能用——它可能"没有挂载点"
第二个插件（一个提供 MCP 工具的包）装得干干净净，dsh plugin list 里也有它。
可我等了一上午，一个工具都没出现。原因是它根本挂不进这份 profile，两个证据：
# ① 写进「补丁层」
dsh: [cordis.patch.yml] patch: entry "mcp-graphflow" not found
# ——补丁层只能改**已存在**的条目，不能新建
# ② 写进「bundle 列表」
dsh: skipping profile bundle "@deepseek-ai/dsh-mcp-client":
Error: declares no dsh.bundle in its package.json
# ——它压根不是 bundle（package.json 里没有 dsh 字段）
- 教训："依赖里装了"和"它在跑"是两件事。判断标准应该是运行时痕迹： 进程在不在、工具表里有没有、产物有没有落盘——不是安装日志里的 "Done in 4m"。
- 收尾动作：我把两处无效改动撤回了，还留了一行注释写明"试过什么、为什么不行"。 半挂状态比失败更危险：下一个人会以为它已经能用。
三、坑三：守卫说"可以强行装"，你装不装？
工具链很克制，它给你留了后门，但同时把话说全：
dsh plugin --profile web allow-version <包>@<版本> --dsh-version 0.2.1-alpha.4 --accept-risk
# Running it may cause crashes or data loss.
这句话的翻译是："我可以放你过去，但崩了别怪我"。 我这里的取舍是不装——因为这是宿主：宿主崩了，整个工作台（包括正在跑的会话）一起没。 而这个插件给的只是"扩展生态"的可能性，不是现在缺的能力。
一个顺手的判据：先问"这个能力现在多缺"，再问"最坏情况我能不能接受"。 两个问题有一个答"不"就别装——留个候选，等它出匹配版本更划算。
四、附送一个小坑：BOM
改写配置文件时我用了一条 PowerShell：
Set-Content -Path package.json -Value $new -Encoding UTF8
结果它给 JSON 文件写进去了 BOM（备份头 4 字节是 7B 0A 20 20，改完变成 EF BB BF 7B），
严格解析器直接报 Unexpected UTF-8 BOM。
- 改 JSON/YAML 一律用 Python 读写（
pathlib+encoding="utf-8"），别用会自动加 BOM 的写法； - 改完回读字节确认，别只看"文件写成功了"。
五、四条可以抄走的检查法
- 升级宿主之后，回头对一遍插件版本（不然能力会静默消失）；
- 验证要看运行时痕迹，不是看安装成功日志；
- "能强行装"意味着"崩了算你的"——宿主上的东西，默认不冒险；
- 失败要撤回并留注释，别留半挂状态给下一个人。
