它是什么
这个 GitHub 仓库同时装着三样东西，而它们的安装方式各不相同。最常见的误读，是把它当成“一个插件”——它其实是一个分发容器。根 package.json 把这一点写得很直白：name 是 @dsh-external/dsh-super-injector，指向的只是其中一个组件，而 description 自称是“dsh-routing-suite 分发入口”。
injector/—— 插件那一半。走官方装配路径装好后，它向运行的 DSH 发布一整套dev_*工具，用于把其它本地插件包注入、热重载、卸载与自检。preset/—— 两个 agent 预设（router-standard、router-spec），替换某个会话的推理 persona 与工具清单。graded/—— 会话级任务协议：六个工具、脑暴出题、规格门控、打卡制与红队门。
一条命令只会装配注入器。它既不安装预设，也不安装 graded。
三条组件，三条安装路径
上游 README 的头条命令是：
dsh plugin --profile web add github:yjh051108/dsh-routing-suite它只装配注入器。仓库自己的三步安装链写清了另外两个需要什么：
git clone https://github.com/yjh051108/dsh-routing-suite.git
cd dsh-routing-suite
dsh plugin --profile web add .\injector # 注入器
$target = Join-Path $env:USERPROFILE '.dsh\.agent-presets\router-standard'
Copy-Item -Recurse .\preset\router-standard $target # 每个预设平铺复制README 明确警告不要复制整个 preset/ 目录，因为多出来的一层嵌套会让 DSH 发现不了预设。这与 DSH 的实际行为一致：@deepseek-ai/dsh-agent-presets 只扫描预设根目录的一级子目录，并要求每个预设目录直接含有自己的组装文件。
graded/ 又是第三条路径。仓库里带着构建好的 tarball graded/dsh-external-dsh-graded-mode-0.0.1-rc1.tgz，但 graded/README.md 把 <NPM_GLOBAL>、<DSH_HOME>、<PLUGIN_DIR> 留成占位符要你自己替换——这是一处成文的缺口，不是可以直接粘贴的命令。
注入器到底做了什么
injector/ 的 README 自称是 DSH 的“BepInEx 式模组注入入口”。来源里描述的东西比这个比喻更窄也更具体：它把本地插件包软链（Windows 上是 junction）到 ~/.dsh/profiles/web/node_modules，然后调用 ctx.loader.create({ name, config }) 把它挂载进正在运行的进程。根 cordis.patch.yml 只插入一行——注入器自己——所以它是唯一需要官方装配的条目。它在 ~/.dsh/super-injector/registry.json 维护清单并在重启后重新恢复已注入的包，监听插件产物目录并在改动后热重载，卸载时销毁 fiber 并移除链接。
关于“它会不会改 DSH 自己的文件”：它不修改 harness 源码，但确实会往你的 DSH profile 里写东西——profile 的 node_modules 下一个链接，以及 ~/.dsh/profiles/<profile>/cordis.patch.yml 里的条目，其中卸载时追加的 disabled: true 是为了阻止被移除插件的 bundle patch 重新装配自己。README 还记录了一条 dev_fix_patch 修复路径，用于 profile 里已经存在重复 loader entry id 的情况。
注入器自己的 package.json 把 peerDependencies 写成范围声明（@deepseek-ai/dsh-tools: >=0.0.1-rc <2、cordis: >=4.0.0-rc <5），并用一个 dsh.client 块在 web 平台上注入两个客户端包。
预设替换掉的到底是什么
preset/router-standard/agent.cordis.yml 不是一处小补丁，而是一份完整的 agent 平面组装文件：persona、agent-instructions、路由 bootstrap，接着是文件系统、搜索、编辑器、后台任务、skill、goal、plan 模式、压缩、委派、workflow、ralph、ask-user、todo 与 web 等行，另有一个仅 Windows 生效的分组，用 ./gitbash-executor.mjs 替换出一个私有的 shell 服务。
因此挂载它意味着交给 agent 一套与部署默认值不同的 persona 和工具清单，其中还包括一份写明 thresholdRatio、retainRatio、thresholdChars、headChars、tailChars 的压缩配置。预设还会从自己的 bootstrap 模块注册 dev_router_status、dev_router_mode、dev_mode_subagent 三个工具——它并不依赖注入器，尽管预设 README 把两者描述为配套使用。
安装期会执行代码
根 package.json 声明了 "prepare": "node injector/scripts/prepare.mjs"，而 npm 与 pnpm 对 github: 依赖会自动运行 prepare——头条命令抓取本仓库走的正是这条路。安装这个包会执行代码。
injector/scripts/prepare.mjs 很短，其行为可以直接从文件读出。它先检查 injector/lib/index.js 与 injector/lib/client.js 是否已存在；两者都在时打印 [prepare] lib/ already built — skipping tsdown run 并以 0 退出。否则它用本地 tsdown 构建这两个产物，找不到本地副本时回退到 npx --yes tsdown@^0.22.14 --config tsdown.config.ts，首次会联网下载。构建失败或产物缺失时它会故意以非零码退出，其错误文本自己说明没有 lib/ 插件就无法加载。此外 install.sh 还可能从 GitHub 下载一个 Release tarball 来装配。
运行要求
- DSH 目标版本：README 声明
>=0.1.0-rc.6 <0.2.0，并称已跟进rc.8、0.1.1-rc.2与0.1.2-alpha.1。同一份 README 提示 DSH 仍处于 developer preview，破坏性变更是预期之内的事。 - Node：根
package.json没有声明engines字段。注入器与预设各自的清单声明>=22。 - 客户端平台：
web，来自dsh.client块。没有描述 headless 或纯 CLI 模式。 - 权限、网络与遥测：注入器说明
DSH_HOME会覆盖由homedir()推导出的路径，install.sh在源码构建失败时从 GitHub Releases 拉取。除此之外，来源没有描述权限模型、审批流程或遥测。请按「未说明」理解，而不是按「安全」理解。
已知限制
- 没有一条命令能装完整个套装。 头条命令只给你注入器；预设要手动平铺复制；graded 是另一套装配，其说明里还留着占位符路径。
- 仓库对自己内容的表述前后不一致。 中文 README 一处把 graded 产物写成
graded/dsh-external-dsh-graded-mode-0.0.1-rc1.tgz，紧邻的表格单元里却写成graded/dsh-graded-mode-3.2.0.tgz——后者并不在文件树里。英文 README 只写了后者。 - 注入器的安装手册部分过时。
injector/INSTALL.md在手动 patch 与卸载两节里仍称包名为@yjh051108/dsh-super-injector，而随包发布的清单用的是@dsh-external/dsh-super-injector。不要把这两个名字混用。 - 预设的版本号在多个文件里互相矛盾。 根 README 写
v0.3.0 … 主线 v1.19.1/v34，预设 README 的状态标题写v1.19.1，bootstrap 里的常量报v1.20.0，而preset/CHANGELOG.md已经写到v1.27.0。 - 那些研究数据是作者自报的。 仓库公开了 P1–P23 探针结果、一份“模型注意力懈怠”研究，以及路由 96%、收敛 100%、开放任务完成率「0% → 100%」这类数字。它自己的
graded/docs/DATA.md说明方法是从几个具名会话 ID 聚合事件计数，不含任何会话原文。我无法独立核实这些探针、样本与方法，这些数字也不构成“这个插件在你机器上会怎样”的测量结果。 - 有两个仓库名字相近。 npm 上有一个
dsh-routing-suite@0.1.2，其repository字段指向github.com/dragonbaba/dsh-routing-suite，属于另一位作者。那个包不是本项目，这也是本条目写install命令而不是包名的原因。
什么时候用它、什么时候不要用
如果你在开发 DSH 插件，想要一套不必重启 web 进程的挂载/卸载循环，或者想在不把某个本地插件包永久加进 profile 的前提下跑它，可以看注入器。如果你关心提示词层面的路由与阶段性工具披露，想连同这个仓库发布的 persona 与工具清单一起用，可以看预设。
不要抱着“一条命令装齐三件套”的预期去装它，也请先读一遍安装期执行代码那条路径。如果你想要的是一个只碰官方发布包的插件管理器，这个仓库不是那个形状：它刻意工作在官方装配层之下，维护自己的注册表，并会写入你的 profile patch 文件。在复现之前，请对性能数字保持怀疑；复现脚本就在仓库里，那才是核对它们的正确方式。
FAQ
一条命令能把仓库里所有东西都装上吗？
不能。dsh plugin --profile web add github:yjh051108/dsh-routing-suite 装配的是根包里的注入器。路由预设要按平铺方式逐个复制到 ~/.dsh/.agent-presets/，README 把这列为单独一步，并警告不能靠复制整个 preset/ 目录完成。graded/ 以 tarball 形式随仓库分发，需要另行装配，其说明里还留着占位符路径。
安装的时候会有代码被执行吗？
会。根 package.json 声明了 prepare 脚本，npm 与 pnpm 对 github: 依赖会自动运行它——这正是头条命令采用的机制。脚本是 injector/scripts/prepare.mjs：若 injector/lib/index.js 与 injector/lib/client.js 已存在就跳过，否则用 tsdown 构建，本地没有副本时通过 npx 拉取 tsdown@^0.22.14。install.sh 还可能从 GitHub 下载一个 Release tarball。
注入器会修改 DSH 本身吗？
它不修改 harness 源码。它把插件包链接进 profile 的 node_modules，用 ctx.loader.create 挂载，并在 ~/.dsh/super-injector/registry.json 维护清单。但它确实会写你的 DSH profile：~/.dsh/profiles/<profile>/node_modules 下一个链接，以及追加到 ~/.dsh/profiles/<profile>/cordis.patch.yml 的条目，其中就包括卸载插件时写入的 disabled: true。
注入器和预设有什么区别？
注入器是走官方插件路径装配的 DSH 插件，它提供 dev_* 工具和一套运行时挂载/卸载循环。预设是从 ~/.dsh/.agent-presets/ 加载的 agent 平面组装文件，它们替换会话的 persona 与工具清单，并注册自己的路由工具。装了其中一个，不等于装了另一个。
它针对哪个 DSH 版本？
README 声明 >=0.1.0-rc.6 <0.2.0，并注明已跟进 rc.8、0.1.1-rc.2 与 0.1.2-alpha.1。同一份 README 说 DSH 处于 developer preview、破坏性变更属预期，所以请把上界当成真实约束，而不是套话。
为什么许可证字段写 MIT，而包里写的是 BSD-3-Clause？
因为来源之间本身就矛盾。GitHub API 报告 MIT，根目录的 LICENSE 文件是 MIT 正文，README 也写 MIT。但根 package.json 与 injector/package.json 都声明 "license": "BSD-3-Clause"，而 graded/package.json 声明 Apache-2.0。本条目记录 GitHub API 的取值（MIT），并指出这处分歧，而不是替它下定论。