前言¶

在 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