前言¶
把 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 输出，便于接进其它脚本。
| # | 检查 | 抓什么 |
|---|---|---|
| 1 | DSH 进程 | 进程在不在，监听哪些端口 |
| 2 | 桥接 | 端口通不通 |
| 3 | SnowLuma / OneBot | 端口与 QQ 是否在线（可试多份 onebot_*.json） |
| 4 | preset 注册 | profile 的 dsh.profile.bundles 里是否包含 surfcore |
| 5 | 最近的唤醒失败 | 最近约 400 行日志里是否有硬故障 |
| 6 | 最后一条消息 | 最近一次发出 / 唤醒的时间与结果 |
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
- DSH 换了端口，而
surfcore/config.json的dsh.baseUrl仍指向旧端口 → 改为当前探到的地址。 - 桥接没在跑 → 尝试拉起来。
修完会打印做了什么；应再跑一次不带 --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 仓库入手即可。
