dsh bot 不回消息怎么排查：DeepSeek Harness 平台回调、桥进程与审批闸门

消息在平台上显示已送达，dsh bot 那边却没有任何回复，这是 DeepSeek Harness 排障里最常见的一种沉默。 它可能发生在桥、队列、审批或平台发送任何一段，单看聊天窗口无法判断。下面按消息实际走过的顺序追证据，每一步都留下可对照的记录。

DeepSeek Harness 里 dsh bot 不回消息时先拆链路

先确认消息走到哪一段，再决定改哪里，顺序反了只会白改配置。

平台显示发送成功，只说明消息离开了客户端，并不代表桥收到了它。真正送达要经过平台回调、桥进程、队列与回程发送，任何一段断开，聊天窗口看起来都只是「没人回」。把这几段分开看，才能知道下一步该翻哪份日志。

证据要从外到内收集，而不是从最熟悉的配置开始猜。平台的投递记录能证明事件有没有发出，桥日志能证明事件有没有进来，队列状态能证明任务有没有排上，桥的发送日志能证明回复有没有出去。四份记录指向同一段，才值得动手修改。

先固定一个最小的复现场景：同一个会话、同一条消息、同一个平台账号。每次测试只改变一个条件，否则即使恢复了，也说不清是哪次改动起的作用。记录下发送时间与消息标识，后面所有日志都靠它对齐。

1. 平台事件记录里找消息标识与投递结果。
2. 桥日志里找同标识的入站与签名结果。
3. 队列与任务状态里找处理开始与结束时间。
4. 桥发送日志里找回复内容和平台响应码。

如果两份记录之间出现空白，断点就在那里，不必继续往后翻。空白之前的最后一条记录，通常已经说明了问题属于哪个环节。接下来要做的，是确认这条记录为什么停住，而不是把整条链路重装一遍。

桥：dsh plugin 的入站事件停在哪一步

桥是第一个能留下完整入站证据的地方，先看它有没有收到事件。

回调地址不可达时，平台会不断重试，但桥这边始终安静。常见原因是本地服务只监听回环地址，或者隧道在重启后换了域名，而平台配置还指向旧地址。用平台自带的测试事件打一次，比在聊天窗口反复发消息更快。

签名校验失败也会让事件停在门口。密钥轮换之后，平台与桥各持一份不同的值，日志里通常显示校验不通过，而不是解密失败。核对密钥时要同时看环境变量和配置文件，避免只改了其中一处。

桥进程没启动、崩溃或与平台断连，表现同样是没有任何入站记录。此时平台侧可能仍显示发送成功，因为消息确实已经被平台接收。检查进程是否随客户端启动、长连接是否在线，比检查 bot 的提示词有用得多。

[bridge] listening on 127.0.0.1:8787
[bridge] callback verified msg=om_8f3c
[bridge] signature mismatch msg=om_91a2
[bridge] enqueue task=t_2041

日志里只有监听记录、没有事件行，问题在回调或网络；有事件行但没有入队行，问题在解析或权限。把这两类日志分开看，能少走很多弯路。重启桥之后先发一条测试消息，确认入站、解析、入队三段都留下记录，再回到真实会话。

队列：DeepSeek Harness 的消息为什么排着不动

队列里堆着任务，说明消息已经到了，只是还没轮到执行。

一个耗时很长的任务会把后面的消息全部堵住，尤其是涉及大量文件读取或外部命令的操作。聊天窗口不会显示「排队中」，使用者看到的就是 bot 沉默。检查任务列表里最早开始、尚未结束的那一条，往往就能解释后面所有消息为什么没动静。

失败重试也会制造类似现象。某条消息处理失败后被反复放回队列，新消息排在它后面，整体看起来像卡死。日志里同一个消息标识出现多次，基本可以确认是重试而不是新消息。先处理掉那条失败任务，队列才会继续往前走。

队列深度和任务状态要一起看。深度持续增长说明消费速度跟不上，深度不变但任务长期处于运行中，则更像单条任务挂住。两种情况的处理方式不同，前者要减少并发或拆分任务，后者要找到卡住的调用并终止。

不要为了清空队列直接删除任务记录。删除只能让界面恢复干净，真正的原因还在，下一条消息仍会卡在同一个位置。先把失败任务的输入、工具调用和错误信息保存下来，再决定是重试、跳过还是修改流程。

审批：DSH plugin 停在等待确认时该看什么

等待确认不是不回消息，而是 bot 在等一个明确的授权。

审批提示里通常会列出准备执行的工具、目标路径和关键参数。先看这些内容是否与当前任务相符，再看它为什么被判定为越界。提示信息不完整时，不要凭印象点确认，先让 bot 复述它打算做什么。

工作区边界是最常见的触发点。读取工作区之外的文件、写入未授权的目录、调用会启动子进程的命令，都会让任务暂停。把任务范围缩小到工作区内部，往往比每次都手工授权更省事，也能减少后续同类中断。

等待时间过长时，有些配置会自动取消任务，聊天窗口于是表现为「什么都没发生」。查看任务状态是已取消还是仍在等待，可以区分这两种情况。若日志里只有审批创建记录而没有结果记录，说明确认动作根本没有发生。

授权之后仍然没有回复，问题就不在审批。此时回到队列和回程发送，确认任务是否真的继续执行。把审批当成链路中的一站，而不是所有沉默的解释，排查方向才不会跑偏。

平台发送：DeepSeek Harness 的回复为什么没落到会话

bot 有输出不等于平台收到，回程同样会失败。

机器人被移出群聊、应用权限被回收，或者访问令牌过期，都会让发送接口返回错误。桥日志里能看到完整的回复内容，平台侧却没有任何消息，这种反差通常就是回程失败。先确认机器人仍在目标会话里，再检查令牌有效期。

平台的频率限制也会吞掉回复。短时间内连续发送多条消息时，部分请求会被拒绝，而 bot 侧只看到一次发送失败。日志里的响应码和重试记录能说明问题，必要时降低发送频率或合并消息。

回程日志要和入站日志使用同一个消息标识，否则很难判断哪条回复对应哪次请求。有些桥会把回复拆成多条发送，任何一条失败都可能导致内容不完整。把发送结果逐条记录下来，比只看最后一条「成功」可靠。

这套顺序对 DSH插件 和 DeepSeek插件 都适用，差别只在日志位置和字段名。插件条目可以在 DSH Plugin Hub 对照版本与配置说明。确认回程正常之后，再回头优化提示词或模型参数，才不会把链路问题误判成回答质量问题。

复盘 dsh plugin 排障时留下的证据链

能复现的断点，才算真正定位。

复盘时先固定消息、会话和环境，再让别人按同样的步骤走一遍。如果对方得到的断点与你不同，说明还有未记录的条件，例如账号权限、网络出口或插件版本。把这些条件写进记录，比只写「已修复」有价值。

四份记录要用同一时间基准对齐。平台、桥、队列和发送日志可能位于不同机器，时区或时钟偏差会让顺序看起来完全相反。先校正时间，再判断先后，否则很容易把结果当成原因。

不要用重装来掩盖链路问题。重装会顺带重置配置和进程状态，表面上恢复，实际断点仍然存在，下一次换一个条件又会复现。保留旧日志和旧配置，直到确认根因，再决定是否清理。

最后把结论写回记忆或值班记录，注明触发条件与验证方式。下次遇到相似症状时，先按记录复现，再决定是否需要重新取证。排障的经验只有落到可执行的步骤上，才会真正缩短下一次的沉默时间。

来源：dsh-bot 插件条目、dsh-feishu-bridge 插件条目、插件与生命周期。