dsh 插件的真相:往插件图里 insert 一行

我对 dsh 的插件机制一直没什么概念。知道能装，知道有 dsh plugin add，也就到此为止。

这次认真动手，是因为我顺手在 dsh 的聊天框里问了一句： profile 到底是什么，插件为什么不能跨 profile 用。

dsh 的界面就是一间聊天室：左边挂会话、插件、便签墙，中间是对话框，问它什么就答什么。所以「问软件自己的设计」这件事，在这里只需要打一行字。

它的回答比我预期扎实： profile 就是 $DSH_HOME/profiles/<name> 下那一整套独立的运行时配置，package.json、node_modules、cordis.patch.yml 全在里面。装插件只写进该 profile 自己的 node_modules，别的 profile 连包都找不到，自然加载不到。

这个回答让我意识到，我一直把插件当「往软件里加个功能」，其实它是「往某个 profile 的插件图里加一行」。

顺着这条线，我装了 awesome-dsh-plugin 列表里的两个社区插件：一个便签墙，一个火山方舟生图。

这两个插件是什么

便签墙 dsh-plugin-sticky-wall， npm 上 1.8.0 。给侧栏加一块便签区：彩色纸、勾选框、可折叠、能拖能改大小，删掉的进回收站还能捞回来。

方舟生图 dsh-plugin-ark-image-gen， 0.1.1 ，走的是 Doubao Seedream 那条线。两个模型工具，ark_generate_image 出图，ark_image_gen_status 自检密钥、模型和输出目录。

两个都出自同一个作者 zmengle ，同一天合进 awesome 列表。列表里分了类，一个算 ui ，一个算 vision 。

装的过程只有一条命令

dsh plugin --profile web add dsh-plugin-sticky-wall@1.8.0 dsh-plugin-ark-image-gen@0.1.1

一条命令，两个包一起装。我记了时间， 1.24 秒。--profile web 的意思是装进 web 这个 profile ，不是全局。

输出里有五行不显眼但信息量很大的提示。

第一行是 Lockfile passes supply-chain policies (verified 1d ago)，锁文件得过供应链检查。

第二行更少见，它把 sticky-wall 加进了 minimumReleaseAgeExclude 名单，意思是这个包的「发布年龄」不够，得单独放行。

第三行是 Agent skills awaiting approval: dsh-plugin-ark-image-gen，生图插件自带一个技能，装完还得你批准一次。

收尾那句是 Packages: +2 -8，加了两个，顺手清了八个。

一个插件长什么样

我进 node_modules 看了一眼，便签墙这个包一共八个文件。

client.js 115,734 字节，index.js 37,302 字节，cordis.patch.yml 287 字节，剩下是 package.json 、 README 、 CHANGELOG 、 LICENSE 、 screenshots.json 。

也就是说，一块能拖能折叠、带回收站、还接五个模型工具的便签墙，代码全在那两个 js 里。 client.js 是浏览器端那半， index.js 是主机端那半。算一下，界面那半占了整个插件 76% 的代码量。

package.json 里关键是两个字段：dsh.bundle.patch 指向 cordis.patch.yml ，dsh.client.platform 写 web 。

还有一条版本限制，engines.dsh 写着 >=0.2.1-rc.4 <0.3.0-0，我机器上的 0.2.2-rc.1 正好落在里面。

五行 YAML 就是插件的全部

把 cordis.patch.yml 打开，只有五行，两行注释加一条 insert ：

- insert:     - id: sticky-wall       name: dsh-plugin-sticky-wall       config: {} 

原文件上面还有两行注释，一句说这行 id 必须和 cordis 里的条目 id 对齐，一句说 name 必须能解析到这个包。

id 是这行插件在插件图里的名字， name 是能解析到的包名， config 留空就走默认值。

再对比我自己的 ~/.dsh/cordis.patch.yml，挂的是 memorix 那个 MCP 客户端，结构一模一样，只是 name 换成了 @deepseek-ai/dsh-mcp-client， config 里写了启动命令和参数。

所以 dsh 插件的本质是：往 cordis 的插件图里 insert 一行。装包和挂载是两件事， pnpm 负责前一半，这五行负责后一半。

便签墙：装完立刻有界面

启动日志那句 就绪：/Users/trevorwang/.dsh/sticky-wall.json （ 2 条便签） 说明状态落在文件里，不在内存里。

那 16 个字段里有 x 、 y 、 z 、 pinned 、 collapsed 、 color ，等于便签的位置、层叠、钉住、折叠、纸色全都存下来了。换个 profile 拷过去，墙还是原样。

让模型自己记事

便签墙给模型五个工具：sticky_wall_add、sticky_wall_list、sticky_wall_update、sticky_wall_remove、sticky_wall_restore。

我在网页会话里说了一句「把这两件事记到便签墙」，它真的调了工具，把内容写成 - [ ] 开头的待办，还自己挑了纸色和位置：一条天蓝放右上，一条蜜桃放右下。

回看文件，墙上正好四条，原来那两张欢迎便签没被动。

生图插件：装上了，但没密钥

生图那个在界面上看不见任何东西，它是纯工具插件。我在 web 会话里让它调一次自检，返回是这样：

"ready": false,   "hasKey": false,   "keyHint": "" "model": "doubao-seedream-5-0-flash-260915" "baseUrl": "https://ark.cn-beijing.volces.com/api/v3" "outDir": "/Users/trevorwang/ark-output" "hint": "设置环境变量 ARK_API_KEY 或在插件配置里填 apiKey" 

两个 false ，外加默认模型、接口地址、输出目录，连该设哪个环境变量都写清楚了。

这个设计我挺认：工具不假装能用，缺什么就说缺什么。我没去配密钥，因为这篇要验的是插件机制，不是出图质量。

顺带发现：市场索引是本地服务

插件页右上角有个 Discover ，背后查的是本地一个索引服务。

我按旧记录去敲那份 index.json ，返回 502 ，服务没起。

也就是说，这时候的「插件市场」在我看来还是一次本地预览：索引靠一个临时服务撑着，挂了就是空的。装插件也得知道包名，直接写命令。

这不影响这篇要验的机制，但能解释为什么官方下一步才叫「建插件市场」。

真正的坑：工具跟着 profile 走

这个坑我踩到了。先用命令行 dsh headless 让它记事，它回复说写好了，但翻它自己的推理才发现，它没调 sticky_wall_add，而是直接打了正在运行的便签墙服务的 HTTP 接口。

原因很干脆：插件装进了 web profile ， headless 是另一个 profile ，那个 profile 的 node_modules 里根本没有这两个包，工具自然不在它的工具表里。

我换个说法再试，让它调 ark_image_gen_status，它直接答「我的工具列表里没有这个工具」，顺手把四个 profile 的目录都查了一遍，确认只有 web 有。

我让 dsh 审了这两个插件的代码

装完我懒得自己逐行读，直接在同一个聊天框里问它：这两个社区插件代码质量怎么样，别客套，也别替我美化。它居然真的去翻了源码，还如实告诉我哪一条我记错了。

然后是它标成 Critical 的问题，各两条，都挺实。

便签墙的 /import 根本不写盘。导入只改内存， handler 等的还是上一次那根旧的 writeChain ，却照常回 ok:true。导入备份后界面一切正常，重启进程全没了。

它的写盘失败也被吞掉。persist() 的 .catch() 只打日志， Promise 依然 fulfilled ，所以 HTTP 层永远成功。磁盘满、权限错，客户端照样显示已保存。

生图那边，内置技能永远加载不了。skillProvider.get() 少返回三个必需字段，我当场调 skill ark-image-gen 就复现了报错。另一个是不传 seed 的常规出图会被判失败：返回 seed: null， schema 却声明 integer ，图生成了盘也落了，模型收到的是工具失败，重试就重复计费。

它还顺手戳穿了我前面的一个说法。我以为插件里写的 config 会生效，实际 apply(ctx) 把第二个参数丢了，运行时只认环境变量。这条我去核了源码，它说得对。

我的判断

写到这里，我原来的判断变了。

我本来想说的是：五行 YAML 门槛这么低，插件生态必然起来，剩下只差一个安装引导。听完 dsh 自己审代码，这话我说不出口了。

门槛低是双刃的。 2026 年 11 月这个时间点上，低门槛带来的不只是热闹。低到 2025 年一个人用两个 js 文件做出便签墙，也低到两个 Critical 级 bug 能一路发布、进列表、被我这种不看代码的人装进机器。作者不是不会写，是只验了顺路径。

第二件事是， dsh 审自家生态这件事本身比 bug 更有意思。它没有护短，把两个插件的行号、调用链、该补的测试一条条列了出来，还顺手纠正了我记混的插件名。这在以前的工具里是做不到的：它读的是同一台机器上的源码。

第三件事才是那道 profile 边界。我这种天天折腾的人都差点以为「装完到处都能用」，何况只是想要一块便签的人。装完第一次找不到，第二次就不装了。

所以插件市场真要成，缺的不是数量，也不是引导。缺的是一层能替用户验一遍的关卡，和一句说明白「这东西装在哪个 profile 」的话。

你的工作流里，有什么东西值得写成一块便签墙？