dsh-preset-bridge — 模式目录桥接
把 0.1.x 惯例的预设目录(~/.dsh/.agent-presets/<id>/)重新接入 DSH 桌面版 0.2.x 的模式列表。
DSH 桌面版 0.2.0 移除了预设目录扫描:官方文档明确「注册表不扫描目录,也不接受 preset 路径」。于是升级桌面版后,
router-standard、router-spec之类以目录形式安装的模式会全部从模式选择器消失(网页版 0.1.x 运行时仍自带扫描,不受影响)。本插件把这条发现通道补回来。
⚠️ 先读限制与不保证 —— 本插件不保证对你的预设生效,且属于过渡期补丁。
本项目由GLM-5.3Flash、DeepSeek V4.1Flash自主开发
安装
推荐方式:把网址发给 AI,由其自行安装
把本仓库地址直接发给 DSH 会话里的 AI(例如桌面端或网页版里说一句):
帮我安装 https://github.com/Lyrissonare/dsh-preset-bridge 这个插件到桌面版 profile,装好后重启验证模式列表。
AI 会自行完成装配、登记 bundles、重启并检查 ~/.dsh/preset-bridge.log 与模式菜单——这比手动执行命令更能发现环境差异(不同机器上预设引用的包不同,可能需要补兼容映射,AI 可以当场处理)。
手动方式
D:\DSH\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop add https://github.com/Lyrissonare/dsh-preset-bridge
然后重启桌面端。验证:新建会话 → 模式选择器应出现 .agent-presets 下的各预设;或打开 设置 → Agent 预设 → 自定义。
每次修改
~/.dsh/.agent-presets/里的预设后,需要重启桌面端才会重新注册。
⚠️ 限制与不保证生效
使用本插件前请务必理解以下各条。它是一个过渡期补丁,不是官方功能。
- 只适用于 0.2.x 桌面版 profile,不要装到 0.1.x 环境。 网页版 / 0.1.x 运行时自带目录扫描(
dsh-agent-presets组件提供同名agentPresets服务),再注入一个提供方会冲突。本插件声明了engines.dsh: >=0.2.0-rc <0.3.0-0,超出版本应被安装预检干净拒绝。 - 能被"发现"≠能"健康挂载"。 本插件把预设注册进注册表,但预设内容自身的 0.2.x 兼容性它管不了。健康的预设出现在模式菜单;挂载失败的预设会显示在 设置 → Agent 预设 → 自定义 里并带「加载失败」徽标及原因(菜单只列健康预设)。
- 兼容映射是逐个积累的,当前只覆盖已知的坑。 已处理的唯一一条:
@deepseek-ai/dsh-workflow-worker-thread(0.1.x 的 workflowEngine 提供方,0.2.0 已删除)→ 原位替换为官方的@deepseek-ai/dsh-workflow-ptc。如果你的预设还引用了其他被 0.2.0 移除的包,仍会挂载失败——需要往lib/index.js里补对应映射。引用越"纯官方包"的预设,生效概率越高。 - 引擎行为差异。 worker-thread 与 workflow-ptc 是两种不同的引擎实现(线程池 vs spawn 子进程),工作流类预设的运行细节可能有微妙差异。替换是对齐官方 0.2.x 的推荐做法,但若你的预设依赖 worker-thread 的特定行为,属于已知差异,不承诺一致。
- DSH 大版本更新可能使其失效。 桥接依赖 0.2.0 的内部约定(
agentPresets.register的定义形状、挂载审计规则、isolate 语义、!!js方言、ctx.effect语义)。0.3.0+ 这些随时可能变化——声明了版本上界,届时应被预检拒绝而不是静默失效。失效的后果是良性的:预设从菜单消失,应用本身照常工作,~/.dsh/preset-bridge.log会记录原因。 - 过渡期补丁,随时可能退役。 上游修复后(routing-suite 发布 0.2.x 适配,或 DSH 官方恢复/官方化目录发现),请直接卸载本插件、卸载方式:桌面端 设置 → 插件 → dsh-preset-bridge → 卸载。预设目录本身始终是唯一事实来源,不受任何影响。
- 本插件按"现状"提供,不作任何保证。 见 LICENSE(MIT)。作者不对因使用本插件造成的任何问题负责。
与其他预设的兼容性实测
| 预设 | 结果 |
|---|---|
| router-standard / router-spec / router-react(dsh-routing-suite) | ✅ 需 worker-thread → workflow-ptc 映射(插件已内置) |
| liangshen | ✅ 同上 |
| anchored-standard | ✅ 同上 |
| codex-document-mode | ✅ 零修改直接通过(不引用工作流) |
排障
- 日志:
~/.dsh/preset-bridge.log(桌面端 host 的 ctx.logger 不落盘,插件自己写文件)。 - 预设没出现在菜单:先看 设置 → Agent 预设 → 自定义 里是否带「加载失败」徽标及原因;再看 bridge.log。
- 新增/修改预设后必须重启桌面端(预设目录变化不触发热加载)。
配置
在 profile 的 cordis.patch.yml 里按 id 覆盖:
- id: dsh-preset-bridge
config:
roots: # 额外扫描目录;缺省只扫 ${DSH_HOME:-~/.dsh}/.agent-presets
- D:/somewhere/else/presets
实现细节(血泪坑,贡献者/魔改前必读)
- 相对行名必须改写为绝对
file:URL:0.2.0 注册表挂载预设时按「声明处 baseUrl」解析./xxx.mjs相对名,而所有声明都落在注册表自己的包地址上,预设目录里的本地脚本(router-core-v34.mjs 等)会解析失败。挂载前把./开头的行名(含?v=缓存戳)重写为pathToFileURL绝对地址。 @deepseek-ai/dsh-workflow-worker-thread已被 0.2.0 移除:0.1.x 时代预设的 delegation 组普遍自带这一行当 workflowEngine 提供方;0.2.0 只剩接缝包dsh-workflow和官方提供方dsh-workflow-ptc(provider: spawn,同组 isolate 语义一致)。提供方行导入失败会让同组 tool-workflow / tool-ralph 永远 "waiting for workflowEngine" → 预设被判 broken、模式菜单不显示。插件在注册前原位替换行名(组、isolate、config 形状均不变)。- 提供方行不能裸插在预设顶层:预设审计要求服务发布必须落在带
isolate: { workflowEngine: true }的cordis:group组里,裸行会报 "Preset services require isolate realms"。所以只做「同组原位替换」,不做顶层注入。 !!js节点要构造成{ __jsExpr: ... }惰性表达式节点(与 cordis-plugin-include 的 entryListSchema 同构),由 Loader 在条目激活时求值;不能在解析期 eval。- 本 cordis 的
ctx.effect(setup)语义:setup 立即执行、其返回值才是清理函数(React useEffect 式)。直接把 async 清理函数当 setup 传会导致注册完立刻反注册。 - 预设重名(与内置或彼此撞 id)时注册表会抛错:捕获后告警跳过,不让单个坏预设拖垮其余注册。
No comments yet. Be the first to write one.