dsh bot 怎么接飞书、微信与 QQ：DeepSeek Harness 消息桥 DSH plugin 选型与配置

一条飞书消息从被按下发送到变成回复，会依次经过平台、桥、改写与回送四个位置，每个位置都能用一条 DeepSeek Harness 的 DSH plugin 日志对上号。 跟着它走一遍，比对着配置清单逐项检查更容易发现断点。

第 0 跳：消息还在平台里，DSH plugin 还没有看见它

这一跳唯一的任务是拿到三个 ID 和一种可用的投递方式，其余都是后话。

用户在飞书群里敲下一句话，平台先把它变成一条事件，事件里带着发送者、会话和消息编号。 此时消息还躺在平台自己的队列里，DeepSeek Harness 的进程完全不知道它存在。 要做的第一件事不是装插件，而是确认机器人身份能不能收到这类事件。

记下 message_id、chat_id 与 sender_id，各平台叫法不同，作用却一致。 它们是去重、映射和排查时唯一能对上的凭据，缺一个就会在后面反复猜。 再确认平台允许哪种投递方式，是公网回调、长连接，还是只能自己拉取。

最后在开发者后台发一条测试消息，看平台事件记录里有没有它。 这一步没有记录，桥日志空白就是必然，不是 bug。 跳过这层直接安装消息桥，很容易把平台的问题误判成插件问题。

桥把事件接住：投递方式在这一跳被 DSH plugin 定型

能回调就回调，不能回调就让桥连出去，两样都不给才轮询；选择由平台能力决定，不由偏好决定。

桥是一个独立的 DSH plugin，任务只有三件：收事件、换格式、送回复。 它不负责推理，也不是 bot 本体，所以桥活着不等于 bot 会回答。 把桥当成翻译层，很多配置项该放在哪里就清楚了。

飞书通常允许填公网回调地址，桥开一个 HTTPS 端点就能收到推送。 微信与 QQ 的开放程度不同，常见做法是由桥主动连出去，维持一条长连接。 没有公网入口又没有长连接协议时，才用轮询或内网中转，用延迟换可用性。

接住事件之后，桥至少要保留原始事件体、接收时间和来源标识。 签名校验与重放防护要在这里完成，范围也要收窄到需要的群和消息类型。 安装入口可以在 DSH Plugin Hub 找到，中文检索写 DSH插件 或 DeepSeek插件 也能命中。

消息被改写：DeepSeek Harness 决定它属于哪个会话

改写不是换一种措辞，而是给消息补上会话、身份、权限和去重键。

进入 DeepSeek Harness 之后，消息不再是一条平台事件，而是一段带来源的输入。 会话映射先把群或私聊对应到一个 dsh 会话，并且要能双向反查。 映射做不到双向，回复就很容易发到另一个会话里。

发送者身份要写进上下文，群聊里 bot 必须知道是谁在说话。 权限检查放在改写阶段，白名单外的消息直接丢弃并留下拒绝记录。 静默忽略会让排查失去线索，至少要让日志说清楚拒绝了谁。

去重键通常由平台标识加 message_id 组成。 平台在超时后会重投同一条事件，没有去重就会得到两轮回答。 改写完成后把最终输入和原始事件各留一份，才能分清是重投还是映射重复。

回复回送：DSH plugin 的桥要过权限、长度与限流三关

能收不等于能发，回程失败通常没有明显报错，只会表现为用户没收到。

优先使用「回复这条消息」，而不是主动向会话发消息。 前者通常只需要会话内权限，后者往往要额外申请，还容易发错会话。 平台的单条消息有长度上限，长回答要分段并保证顺序。

流式输出也要收住，多数平台不支持增量更新。 桥一般会合并完整回答后一次发出，别拿网页里的打字机效果去要求平台消息。 高频回复会触发限流，退避重试要写进桥的逻辑，不能形成死循环。

发送失败必须留下日志，并在会话里留一个可见标记，方便事后追。 回送用的 chat_id 要与入站时记录的一致，不要重新推导，推导本身就是错误来源。 多平台共用一个桥时，发送通道要按来源隔离，否则消息会串台。

断在哪一跳：DeepSeek Harness 消息链留下的证据

五种现象都叫「没反应」，证据位置却完全不同，先定位再改配置。

平台显示已发送而桥日志空白，说明事件没到，查回调地址、签名与防火墙。 桥日志有事件而 bot 没有输出，问题在会话映射、任务队列或审批闸门。 bot 有输出而平台没收到，则回到发送权限、chat_id、限流与长度。

1. 平台已发送、桥日志空白：事件没到，先查回调可达性与签名校验。
2. 桥有事件、bot 无输出：查会话映射与审批闸门，消息通常卡在放行之前。
3. bot 有输出、平台未收到：查发送权限、目标会话与限流退避。
4. 同一句话回了两遍：查去重键，平台重投没有被识别。
5. 多个群互相串台：查桥实例与会话映射是否共用，必要时按平台拆实例。

回复重复多半是去重键失效，平台重投没有被识别。 多个群串台则要检查桥实例与会话映射是否共用，必要时按平台拆实例。 还有一个更底层的证据是端到端耗时，每一跳都能打点，哪段变长问题就在哪段。

日志里保留同一个 message_id，比在三个平台后台来回翻记录可靠得多。 验收时挑一条真消息走完全程，把耗时、失败位置和版本写进运维笔记。 下次故障发生时，这份基线就是判断断点的第一份证据。 来源：dsh-bot 插件条目、dsh-feishu-bridge 插件条目、DeepSeek Harness 快速开始。