子智能体路由 Minhyuin/dsh-subagent-injection

dsh-subagent-injection（子智能体注入）

一个 DSH Web 插件：在设置 → 内置插件里增加一页「子智能体注入」，用来集中配置主代理委派子智能体时使用的 provider / model / 推理强度，并按优先级顺序自动注入到 subagent 调用上，失败自动顺位重试。

它解决什么

DSH 自带的 subagent 工具本身接受 provider / model / reasoning_effort 参数，但必须由主代理自己决定 要不要传、传什么。本插件把这件事从提示词里搬到界面上：

1. 设置页维护一张有序路由表（可拖动排序），每行是一个 provider + model + 推理强度。
2. 主代理每次调用 subagent，插件都会在工具真正执行前把参数改写为路由表中的候选，顺序即优先级。
主代理不需要被提示词提醒 —— 它自己传不传参数都一样。
3. 某个候选因为路由本身的问题失败（provider 不可达、密钥被拒、模型不存在、限流、5xx…），自动换下一个候选，主代理与用户都不需要干预；只有整张表都失败才会报错，并把每次失败的原因列出来。
4. subagent_fork 开关：取消勾选后该工具被禁用，调用会被自动改派为 subagent（而不是报错），因此仍然享受上面的路由顺序。

界面

设置 → 内置插件 → 子智能体注入：

| 控件 | 作用 |
| 启用调度 | 总开关。关闭后插件完全不介入任何工具调用。 |
| 允许 subagent_fork | 见上文第 4 条。 |
| 路由表 | 每行：⠿ 拖动柄、序号、provider、model、推理强度。 |
| 推理强度 | 仅当该模型声明了推理强度时才显示；未声明的模型没有这一列，也不会注入 reasoning_effort。 |
| 刷新 / 保存 | 保存直接写回 profile 的 cordis.patch.yml，无需重启即可生效。 |

候选模型与推理强度不读 cordis.yml 的原始配置，而是读运行中的模型目录 （session/modelCatalog，即 llm.resolveModelInfo 的结果），所以界面里出现的档位一定是适配器真正接受的那些；未声明的模型不会显示推理强度选择器。保存时还会丢弃"上一个模型残留的、当前模型并不支持的"推理强度。

安装

dsh plugin --profile <你的 profile> add dsh-subagent-injection

重启 dsh web（或桌面端），打开 设置 → 内置插件 → 子智能体注入。安装器也接受 Git 地址、tarball 与本地绝对路径。

需要 DSH 0.2.0-rc.2 或更新版本：plugin/package.json 的 engines.dsh（以及嵌套的 dsh.engines.dsh）声明为 >=0.2.0-rc.2 <0.3.0，宿主更旧时请先升级 DSH。宿主侧只依赖 @deepseek-ai/schemastery（DSH 运行时本来就会提供），浏览器侧只依赖 shell 基线模块表里的 react / react/jsx-runtime / @deepseek-ai/dsh-client-ui-primitives。

开发仓库本体（link: 到源码树，改代码立刻生效）：

// C:\Users\User\.dsh\profiles\desktop\package.json
{
"dependencies": { "dsh-subagent-injection": "link:<本仓库>/plugin" },
"dsh": { "profile": { "bundles": [ /* …, */ "dsh-subagent-injection" ] } }
}

<本仓库>/plugin 需要有一条同名 Junction/软链到 node_modules，或者用 plugin_manager 的 bundle 安装完成这两步。
装载后 profile 的 cordis.patch.yml 里会出现本插件的条目，设置页的保存也写在同一个条目上：

- id: subagent-injection
name: dsh-subagent-injection
config:
enabled: true
fork: false
routes:
- provider: pioneer
model: deepseek-v4.1-flash
- provider: deepseek
model: deepseek-flash
effort: max

分类与使用场景

分类：开发效率 / 模型与推理配置。使用场景：子智能体委派、多模型路由与失败降级、推理强度固定、关闭 subagent_fork。

隐私与权限

宿主端只注册一个 ctx.on("tools/execute", …) 监听器，只读 ctx.config 与运行中的模型目录：不发起网络请求、不读写文件、不访问环境变量、不执行动态代码，也没有安装脚本。浏览器端是自注册 bundle，只通过 remote.settings 的 describe / update 读写本插件自己的配置项。唯一被写入的位置是当前 profile 的 cordis.patch.yml 里本插件的条目。

提交合规（dsh.so）

npm run check:submission（tools/check-submission.mjs）对着 plugin/ 的 npm tarball 逐条核验 dsh.so 的接受标准：dsh 兼容信号、README 安装说明、SPDX 许可证与许可证文件、仓库名/包名的 id 规范、engines.dsh 版本声明、可扫描源码、以及"出厂内容只有 files 声明的那些"。
安全扫描本身由服务端 vet 判定，本地只检查它的结构性前提（dsh.bundle.patch 指向的文件必须存在、入口必须可解析、engines.node 不得低于 22）。

发布流程：master 上的推送由 .github/workflows/release.yml 推导版本并打 tag，打上 tag 后 .github/workflows/publish.yml 把同一个版本写进 plugin/package.json 并 npm publish（需要仓库 secret NPM_TOKEN）。

为什么改代码之后要分别重启

DSH 的 HMR 只监听 profile 的 cordis.patch.yml 与 package.json，插件源码不在监听范围内：

- 改配置（设置页保存、直接编辑 cordis.patch.yml）→ 立即热生效，不用重启。
- 改宿主端代码（plugin/lib/index.js）→ 必须彻底退出 DSH 再打开；只关窗口或刷新页面不够（宿主端是 Node 侧 require 进来的，模块缓存跟随进程生命周期）。
- 改浏览器端代码（plugin/lib/client.js）→ 刷新页面即可。宿主每次请求都现读磁盘，并用 {mtimeMs, ctimeMs, size} 算出 rev 做 URL 指纹。

目录

plugin/ 插件本体（profile 里 link: 的就是它，也是 npm 上发布的那个包） package.json dsh.bundle.patch + dsh.client(platform: web) + engines.dsh cordis.patch.yml bundle 补丁：插入 id=subagent-injection 的条目 lib/index.js 宿主端：tools/execute 监听器（注路由 + 失败顺位 + fork 改派） lib/client.js 浏览器端：自注册 factory bundle（无构建步骤，手写 jsx） README.md 随 tarball 发布的安装/配置说明（npm 页与市场条目显示这一份） LICENSE MIT 全文（根目录那份的副本，check:submission 会比对两者） LICENSE 仓库许可证（GitHub 识别的那一份） tools/ 开发期工具，不参与插件运行，也不进 tarball test-host.mjs 宿主端 18 项断言 test-client.mjs 浏览器端 bundle 形状 / slot 契约 / 渲染 / 保存断言 check-submission.mjs 对着 npm tarball 核验 dsh.so 的提交规范 asar-map.mjs asar 读取/解包/grep（读 DSH 上游源码用） asar-snip.mjs 在压缩过的 bundle 里打印正则命中附近的片段

本地验证：

npm install # 只为拿到宿主端 import 的 @deepseek-ai/schemastery（DSH 运行时本来就会提供）
node tools/test-host.mjs # host: 18 checks passed
node tools/test-client.mjs # client: bundle shape, slot contract, render and save checks passed
npm run check:submission # 26/26 checks passed（对着 tarball 核验提交规范）

仓库本身没有构建步骤：两半都是手写纯 JS，客户端半边是自注册 bundle。唯一的安装项是 schemastery（Config 的 schema 库），在 DSH 里它是 peer dependency。

CI（.github/workflows/ci.yml）在每次 push/PR 上跑这三条。

master 上的推送由 .github/workflows/release.yml 调用 .github/scripts/release.sh 推导版本并建 Release，规则与提交类型对应如下（对齐参考项目的 release 规则）：

| 提交 | 结果 |
| feat: | 次版本号 +1 |
| fix: perf: revert: docs: | 修订号 +1 |
| 类型后带 !，或正文含 BREAKING CHANGE: | 主版本号 +1 |
| ci: chore: refactor: style: build: test: | 不发布 |

版本算术没有交给 mathieudutour/github-tag-action：它用 API 把最新 tag 与 HEAD 做 compare，全新仓库第一次 push 时没有任何 tag，比较结果为空，会一直打印 “0 commits … no release”，首个 Release 永远发不出来。

打上 tag 之后，.github/workflows/publish.yml 把同一个版本写进 plugin/package.json（npm version <tag> --no-git-tag-version）并 npm publish，所以 git tag、registry 上的版本与 README 里的 dsh plugin --profile <profile> add dsh-subagent-injection@X.Y.Z 三者始终一致。发布需要仓库 secret NPM_TOKEN（npm automation / granular token，对 dsh-subagent-injection 有 publish 权限）。

实现要点

- 宿主端只注册一个 ctx.on("tools/execute", …) 监听器，这是 DSH 唯一允许在工具真正执行前观察并改写的扩展点。
监听器改写 exec.name / exec.schema，把 fork 改派成 subagent；改写 exec.arguments 注入路由，每次尝试结束后再还原。
- 路由优先级 = 数组顺序。如果主代理自己指定了 provider/model，这个选择会作为第一个候选先试，失败后再按配置顺序顺位。
- 只有「路由类」失败才顺位重试；取消、工具自身 bug 等一律原样上报，避免重复副作用。
- 浏览器端是手写的 window.__ModuleLoader__.load({ id, factory }) 自注册 bundle，只依赖 react / react/jsx-runtime / @deepseek-ai/dsh-client-ui-primitives（都在 shell 的基线模块表里），所以不需要打包器；设置页通过 settings.plugins.tab 插槽挂进「内置插件」分区，读写走 remote.settings 的 describe / update（远端一律返回 {ok, value} / {ok, error} 信封，客户端先拆信封再当数据用）。