前言¶

把 DSH、橋接（surfcore）、SnowLuma 或 OneBot、QQ 串起來之後，最常見的外顯故障是同一句話：它不回話。橋接進程沒起來、DSH 重啓後 preset 未註冊、橋接仍指向舊端口、讀錯 OneBot 令牌文件——現象都像「對方不理你了」，修法卻完全不同。人工只能逐項猜端口、翻日誌、對配置。

下面介紹社區插件 dsh-chain-check（維護者 wuying1630，分類：客戶端）。它用一次只讀檢查把「猜」換成「看」：六項探針依次說明 DSH → 橋接 → OneBot → preset 與日誌側是否通，並在失敗項後給出可操作的修復提示。需要 Node 18+，零 npm 依賴；也可裝成 DSH 插件，在會話裏通過 chain_check 工具由 AI 調用，邏輯與 CLI 同源。

這是什麼¶

dsh-chain-check 是 DeepSeek Harness 生態裏的診斷插件，倉庫 wuying1630/dsh-chain-check，目錄頁見 SkillHub。當前 package 版本爲 0.1.0，MIT 授權，聲明與 DSH 0.2.x 兼容。

定位可以概括成 README 裏那句話：一條命令查清 DSH → 橋接 → SnowLuma/OneBot → QQ 鏈斷在哪一段。它不是常駐監控，默認只讀日誌、配置與端口，不殺進程、不寫配置；裝成插件時註冊的 chain_check 工具同樣只讀。唯一會改環境的入口是 CLI 的 node check.mjs --fix，且只處理兩種機器可自判安全的情況（見下文）。

核心功能：六項檢查¶

跑完腳本後，每項只給三樣：通沒通、一句人話說明現狀、不通時怎麼修。全通時彙總爲「全通」；有任一項失敗時進程退出碼爲 1，全通爲 0。也可 --json 輸出，便於接進其它腳本。

README 歸納過四種常見「真斷點」與表面現象：橋接未監聽、preset 未註冊導致橋接拒會話、DSH 換端口後 dsh.baseUrl 未對齊、讀錯令牌文件導致 unauthorized。工具針對這類棧設計；模型答非所問、羣禁言等平臺側問題不在判定範圍內。

安裝與啓用¶

方式一：裝成 DSH 插件¶

會話裏會多一個 chain_check 工具，AI 可在對話中發起檢查。安裝命令以 README 爲準：

dsh plugin --profile <你的 profile> add github:wuying1630/dsh-chain-check

裝上後只做一件事：註冊 chain_check。不常駐、不改現有 profile 內容、不寫額外文件。

方式二：不裝插件，直接跑腳本¶

鏈路已經懷疑損壞時，README 更推薦這條路——此時「裝插件」本身可能就是斷的一環。與插件走的是同一個 check.mjs，不會出現兩套邏輯。

node check.mjs

前置條件：本機 Node 18+（腳本使用內置 fetch 與 AbortSignal.timeout）。無需 npm install。

DeepSeek Harness 插件在運行時繼承當前 DSH 進程的權限與環境；安裝或啓用前，應自行閱讀倉庫源碼與 MIT 許可證，確認只讀探針與路徑訪問符合你的安全預期。SkillHub 爲社區目錄，與 DeepSeek / 幻方無官方從屬關係。

典型用法¶

日常排查¶

node --version
node check.mjs

看輸出裏 ✗ 後面那一行，腳本會直接指向修復方向。Windows 控制台中文亂碼時，可先 chcp 65001，或使用 Windows Terminal。

示例輸出（README 摘錄，六項全通）：

$ node check.mjs

  ✓  DSH 進程             8 個進程
  ✓  橋接（surfcore）      127.0.0.1:3100 在聽
  ✓  SnowLuma / OneBot    在線：阿硯（3574232603）
  ✓  preset「qq-chat-v2」  desktop（bundles 裏有 surfcore）
  ✓  最近的喚醒失敗        最近 400 行裏沒有喚醒失敗
  ✓  最後一條消息          發出：17:10:32 … 成功 1/1 條

  全通。

JSON 消費示例：

node check.mjs --json | jq '.results[] | select(.ok==false)'

查完順手修（僅 CLI --fix）¶

只有兩種情況會安全自動修：

node check.mjs --fix

1. DSH 換了端口，而 surfcore/config.json 的 dsh.baseUrl 仍指向舊端口 → 改爲當前探到的地址。
2. 橋接沒在跑 → 嘗試拉起來。

修完會打印做了什麼；應再跑一次不帶 --fix 的 node check.mjs 確認。preset 未註冊、配置語法錯誤等 deliberately 不自動改，避免 DSH 起不來或誤殺 SnowLuma 進程（README 在 lib/fix.js 註釋裏說明了勿按 node 進程數誤判重複實例）。

可選配置¶

全部可省略；省略時按「環境變量 → chain.config.json → 常見路徑猜測」解析，用猜的路徑會在輸出裏標明。

{
  "surfcoreDir": "D:/surfcore",
  "snowlumaDir": "D:/SnowLuma",
  "agentPreset": "qq-chat-v2",
  "processNames": ["DeepSeek", "dsh"],
  "onebotUrl": "http://127.0.0.1:3000",
  "onebotToken": "（可選）",
  "skipOneBot": false,
  "skipSurfcore": false
}

環境變量：DSH_HOME / SURFCORE_HOME / SNOWLUMA_HOME。

NapCat / AstrBot¶

工具第 3 項走標準 OneBot get_login_info，不限定 SnowLuma。NapCat 可在 WebUI 開 HTTP 後配置 onebotUrl、onebotToken，並設 skipSurfcore: true，避免無橋接時的誤報。AstrBot 若未開 HTTP，可 skipOneBot: true 與 skipSurfcore: true，此時仍可做第 1 項 DSH 檢查，其餘項會明確寫「已按配置跳過」。沒有 DSH 的純 NapCat 場景不適合作爲本工具主場景——第 1 項查的就是 DSH。

適用場景與注意¶

適合什麼時候用：

• 明明收到消息卻像沒看見 → 關注第 5、6 項。
• 改配置或裝插件後不說話 → 關注第 4 項。
• 機器重啓過 → 關注第 2 項與 DSH 換端口、dsh.baseUrl 對齊。

它 deliberately 不是：

• 7×24 心跳監控；出問題時當扳手用即可。
• 能判定羣權限、封號、模型內容質量問題的萬能儀。

已知限制（README 寫明）：

• 默認安全策略爲只讀；--fix 是 CLI 例外。
• 沙箱或非交互會話裏端口探測可能「看不見」，該項不判失敗並會在說明裏區分。
• 日誌僅讀 bridge.log 與 bridge.log.1。
• 主要在 Windows 上實測；Linux / macOS 分支（如 pgrep / ss）已寫但未驗證，勿當作生產保證。

插件以當前 DSH 進程權限運行；啓用前請覈對源碼。社區目錄 SkillHub 插件頁 便於檢索，事實細節以 GitHub README 爲準。

結尾¶

DSH 生態強調「一切皆插件」；dsh-chain-check 把 QQ 聊天鏈路上的常見斷點收成一次可復現的檢查，CLI 與 chain_check 工具共用同一腳本，鏈路已壞時仍可直接 node check.mjs 救急。需要安裝或二次開發時，從目錄頁與 GitHub 倉庫入手即可。