# Bot 之间的消息与 Webhook

## 现象

在已验证的**官方 VoceChat 0.5.38、Linux amd64** 发行包和镜像中，另一只 Bot 发出的私聊或群聊消息可以出现在聊天记录中，但不会触发接收方的 Webhook。真人发送的相同类型消息可以正常触发。

| 消息来源 | 聊天历史 | 接收 Bot 的用户 SSE | Webhook |
| --- | --- | --- | --- |
| 普通用户 | 有 | 收到 | 收到 |
| 另一只 Bot | 有 | 收到 | 未收到 |

该现象经过本机隔离环境验证；不能直接推广到其他版本或架构。官方来源：[0.5.38 发布页](https://github.com/Privoce/vocechat-server-rust/releases/tag/v0.5.38)、[镜像仓库](https://hub.docker.com/r/privoce/vocechat-server)。

## 结论

该版本的 Webhook 转发路径会按**发送者的 Bot 身份**过滤消息。消息存储和用户 SSE 不受这一过滤影响，因此“历史中能查到”不代表“已向插件推送”。

给 Bot 设置密码、重新登录，或使用用户登录 Token 改走普通发送接口，都不会改变其 Bot 身份，因此没有解决这项 Webhook 限制。公开仓库的旧版源码与实际发布包存在版本差异，不能仅凭旧源码判断发布版本的行为。

插件会忽略自身 Bot UID，并检查白名单与消息类型；其他 Bot 消息只要实际到达 Webhook 且通过规则，就可以正常进入队列。排查时先看插件入站 POST 计数，再判断是上游没有推送，还是插件拒绝了已到达的消息。

## SSE 方案

用户事件流是可行的另一条入站路径。隔离测试确认，使用 Bot 的**用户登录 Token**订阅 `/api/user/events`，可以收到其他 Bot 的消息；直接使用 Bot API Key 订阅该用户端点返回 401。两种 Token 不能混用。

**当前插件只有 Webhook 入站，尚未实现 SSE 接收。** 若后续增加 SSE 适配，应接入现有持久化、防抖与去重流程，并处理重连补读和与 Webhook 的重复事件。凭据仍应放在 DSH credentials 中，自身消息过滤和目标白名单继续生效。