前言¶

在 DeepSeek Harness（DSH）上写插件时，常见两类现场很难自证：插件已挂载却「没有任何动静」，以及文档里写了 ctx.get('sessionController')，在真实进程里到底能不能取到。宿主侧日志主要走 ctx.logger，默认只落在 cordis 内存环形缓冲里；装机版后端子进程的 stdout 还会被 GUI 管道收走，单靠控制台往往看不到完整轨迹。类型声明能说明接口形状，却不能替代运行中的可达性结论。

下面介绍社区插件 dsh-backroom（维护组织 LEEKINBUN-dsh-tools，当前版本 0.3.0，MIT 许可证）。它在宿主进程内注册六条 127.0.0.1 循环 HTTP 路由：四条只读诊断，两条带密钥的会话相关能力且默认关闭。插件自身不写盘；分类为 admin-security。可在 SkillHub 目录页 查看条目，源码与说明见 GitHub 仓库。DSH 生态强调「一切皆插件」；SkillHub 为独立社区目录，与 DeepSeek / 幻方无官方从属关系。

这是什么¶

dsh-backroom 是一间给 DSH 插件作者用的「后台间」：把宿主 ctx.logger 缓冲与插件 console.error/warn 收成可读日志尾；用活体矩阵报告各官方服务面在当前进程里 ctx.get 的真实结果；并可读取桌面端崩溃日志做崩溃归因。另提供密钥门控的会话窄口与会话创建路由，未配置密钥时等同于不存在。

兼容声明（来自 package.json）：dsh >= 0.2.0，并在 0.2.0-rc.2、0.2.1-rc.2 上标注为 compatible。需要 Node >= 20 的 profile（如 desktop / web）加载 bundle。

核心功能：六条 loopback 路由¶

六条路由均通过插件的 webServer.register() 挂在 /dsh-backroom/* 前缀下，无需应用 session cookie 即可访问（与 /dsh-chamber/* 类似），响应头为 Cache-Control: no-store。

前四条为只读；session 与 sessions 需环境变量 DSH_BACKROOM_SESSION_KEY，且 sessions 还须满足 README 中列出的五把闸（如 DSH_BACKROOM_WORKSPACE_ROOTS 未设则建会话整格 disabled）。

如何发现 baseUrl 与端口¶

自 0.2.1-rc.2 起后端端口为系统分配，不要再假设 0.2.0 时代的固定端口。可靠做法之一：在 DeepSeek Harness.exe 相关进程的监听口中，对候选端口请求 GET /dsh-backroom/probe，返回 200 者即为后端；或使用仓库提供的启动器，其会打印 backend port = …。

在 DSH 会话内，模型每轮可见工具 backroom_entry（只读），会返回 baseUrl、六条路由调用格式、各闸状态与硬限制。本机任意进程也可先调免 key 的 GET /dsh-backroom/presets 确认插件已挂载。

安装与启用¶

官方 README 采用 profile 本地 file: 依赖 + bundle 注册，而非单一 CLI 插件名安装。步骤如下。

1. 将插件目录放在稳定路径，例如 C:\plugins\dsh-backroom。
2. 编辑 ~/.dsh/profiles/<profile>/package.json，同时增加 dependency 与 bundle：

{
  "dependencies": { "dsh-backroom": "file:C:/plugins/dsh-backroom" },
  "dsh": { "profile": { "bundles": [ /* …已有 bundle…, */ "dsh-backroom" ] } }
}

3. 用 dsh 自带的 pnpm 安装并重启 dsh（bundle 仅在启动时解析，刷新页面不够）：

Remove-Item -Recurse -Force "$env:USERPROFILE\.dsh\profiles\<profile>\node_modules\dsh-backroom"
pnpm install --dir "$env:USERPROFILE\.dsh\profiles\<profile>"

file: 安装为拷贝而非符号链接；改源码后需重新安装或按 README 比对 lib/** 校验是否同步。卸载时删除 manifest 中上述两行、移除 node_modules\dsh-backroom、再次 pnpm install --dir … 并重启；若仅想屏蔽，可只从 bundles 数组去掉 "dsh-backroom"。

安装前请自行审阅源码与 MIT 许可证；插件以当前 dsh 进程权限运行，动手端点在未设 key 时关闭，但仍会暴露只读诊断与 loopback 面。

典型用法：最小 curl 序列¶

设 $P 为后端端口，$K 为启动器或 DSH_BACKROOM_SESSION_KEY 提供的密钥（推荐请求头 x-backroom-key，避免 query 进日志）。下列示例来自 README 最小调用序列。

先看本机当前 agent 预设名册（免 key）：

curl -s "http://127.0.0.1:$P/dsh-backroom/presets"

只读排查常用 probe 与 logs：

curl -s "http://127.0.0.1:$P/dsh-backroom/probe"
curl -s "http://127.0.0.1:$P/dsh-backroom/logs?limit=200&level=error"

需要动手能力时，须先通过环境变量打开闸（例如启动器 tools/start-desktop-with-mouth.ps1 设置 key、DSH_BACKROOM_WORKSPACE_ROOTS 等）。建会话示例：

curl -s -X POST "http://127.0.0.1:$P/dsh-backroom/sessions?key=$K" -H 'content-type: application/json' \
  -d '{"cwd":"D:/Temp/backroom-ws","agentPreset":"minimal","caller":"some-agent"}'

向该会话发一条并等待回合结束：

curl -s -X POST "http://127.0.0.1:$P/dsh-backroom/session?key=$K&session=<sid>&wait=turn-end&timeoutMs=90000" \
  -H 'content-type: application/json' -d '{"text":"只回一个字：好"}'

session / sessions 不是给会话内模型直接调用的工具面；外部 agent、脚本或 CI 需自行带 key 访问 HTTP。崩溃日志目录在非默认位置时，只读 faults 可通过 DSH_BACKROOM_CRASH_LOGS 指向允许根下的目录。

适用场景与注意¶

适合谁： 正在开发或调试 DSH 插件、需要宿主日志与 ctx.get 活体矩阵、需要区分「插件逻辑错误」与「进程被外部终止」（kill-shaped）的维护者；需要在外部自动化里有限度创建会话并发 prompt 的集成场景（须接受五把闸与进程级账本，重启后 owned 清空）。

日常建议： 平时只依赖四条只读路由即可；打开「会话窄口」时使用 README 推荐的 -Sid 靶会话与一次性启动器，避免把 key 长期写入用户环境变量。

安全与边界： 动手路由默认 403 disabled；key 文件默认可被本机任意进程读取，防的是误操作而非恶意本机进程。faults 虽免 key，但路径受白名单约束，避免成为任意文件读取入口。权限档不能通过本插件放宽；不能切换模型、不能删除会话（仅归档隐藏）。

结尾¶

dsh-backroom 把插件作者最缺的三样能力收在一组 loopback 端点里：可读日志尾、运行中服务面探针、崩溃归因，并在显式配置后才开放会话相关的窄口。若你在 DSH 上排查「装了但没证据」或「类型说有、进程里没有」，可先安装 bundle、确认 probe 与 logs，再按需查阅 faults 与 presets。

• 目录页：https://www.skillhub.cn/plugins/LEEKINBUN-dsh-tools/dsh-backroom
• 源码与中文 README：https://github.com/LEEKINBUN-dsh-tools/dsh-backroom