Mrzqd
2026 年8 月 28 日 06:45
1
昨天给我的记账小程序做一个微信clawBot通道记账，我的账户好好的但是对象的账户就是收不到消息.不会不维护了吧，唯一个正常的微信Bot通道
已打开 02:13PM - 25 Aug 26 UTC
## 环境
- OpenClaw：2026.7.1-2
- @tencent-weixin/openclaw-weixin：2.4.6
- Nod… e.js：22.22.3
- 系统：Linux
- Gateway：systemd user service
- 模型：DeepSeek V4 Pro
<img width="1179" height="2556" alt="Image" src="https://github.com/user-attachments/assets/2de111ff-f3dd-4a44-9e15-4b7b998c67f4" />
## 问题现象
受影响微信可以正常向 OpenClaw 发送消息：
1. Gateway 能立即收到微信消息
2. 微信端每次都会显示“对方正在输入”
3. Agent 和模型能够正常生成回复
4. Gateway 日志显示 `outbound: text sent OK`
5. 但微信客户端完全收不到最终文本
包括只有十几个字符的即时回复，也无法送达。
## 插件直发测试
在微信中发送：
`/echo 测试`
日志显示：
- 插件成功识别 `/echo`
- `Slash command handled, skipping AI pipeline`
- 没有出现发送异常
按照插件实现，应该直接返回：
1. `测试`
2. 通道耗时信息
但微信端两条消息都没有收到。
因此问题与 AI 模型、Agent、工具调用和回复长度无关，发生在微信插件或腾讯 iLink 的下行投递阶段。
## 已执行的排查
- Gateway 和微信监控均为 running
- DeepSeek 请求正常返回 HTTP 200
- 普通短文本回复无法送达
- 插件原生 `/echo` 回复也无法送达
- 清除并重新生成该账号的：
- `context-tokens.json`
- `sync.json`
- 重启 Gateway
- 收到一条新的微信消息后，使用最新 context token 立即回复
- 问题仍然存在
- 使用同一微信重新扫码时提示：
`已连接过此 OpenClaw，无需重复连接`
- 当前插件没有可用的 logout/服务端解绑能力
- 微信仍使用首次绑定时的原手机和原设备，并非更换设备导致
## 日志特征
```text
inbound message: ... types=1
inbound: ... hasMedia=false
outbound: ... contextToken=present textLen=13 mediaUrl=none
outbound: text sent OK
debug-check: ... hasContextToken=true
插件原生命令：
[weixin] Slash command: /echo, args: 测试
[weixin] Slash command handled, skipping AI pipeline
日志和账号标识可根据需要脱敏后提供。
## 预期行为
sendMessage 成功后，微信客户端应能显示对应消息。
如果腾讯服务端没有实际投递，插件不应记录为发送成功，而应返回明确错误。
## 实际行为
- sendTyping 正常，微信能显示“正在输入”
- sendMessage 未报错
- 微信端没有任何最终消息
- 同一账号无法通过重新扫码刷新授权
- 本地删除凭据可能造成服务端仍绑定、但本地无法恢复的状态
## 希望协助确认
1. 腾讯 iLink 是否对该 Bot/微信账号的下行消息进行了静默丢弃
2. sendMessage 返回成功是否仅代表请求被接受，而不代表用户可见
3. 是否可以提供服务端解绑或强制重新签发 Bot Token 的接口
4. 插件能否增加用户可见的送达确认或失败检测
5. 能否在“已连接过此 OpenClaw”时提供强制重新授权能力
7 个赞
sanbu
2026 年8 月 28 日 06:48
2
用的正常着呐。那就是协议出问题了吧，token错了？
1 个赞
Zeus1
2026 年8 月 28 日 06:54
4
是针对账号限流了 官方的插件有相关的 issue 应该说被风控了 我们也遇到这个问题
已打开 04:30AM - 25 Aug 26 UTC
## 问题概述
同一套 iLink Bot API 调用程序、同一台主机和同一网络出口下，原微信账号绑定的 iLink bot 出现以下状态：
- 微信客户… 端向 bot 发送私信正常；`getupdates` 能收到消息。
- 每条入站消息均带来新的 `context_token`。
- `getconfig`、`sendtyping` 正常，微信客户端能看到“正在输入”。
- 短文本回复调用 `ilink/bot/sendmessage` 返回 HTTP 200，业务结果为成功（`ret: 0`）。
- 微信客户端始终看不到 bot 发送的文本消息。
随后改用另一个微信账号重新扫码绑定。在服务端主机、网络出口、调用代码和运行方式保持不变的情况下，新绑定立即恢复正常双向收发。
该对照结果表明，异常状态可能与原微信账号、原 iLink bot/token、对应会话命名空间或服务端风险控制状态有关，而非通用网络或请求格式问题。
## 时间线与背景
1. 原绑定此前能够正常双向收发。
2. 首次发现 bot 回复未显示后，为排查偶发故障，进行了多次短消息发送、重新扫码绑定和客户端重启测试。
3. 这些操作均发生在故障出现之后，目的是确认消息是否延迟、会话是否过期以及新 `context_token` 是否有效；没有主动进行营销、群发、骚扰或其他批量自动化行为。
4. 随着测试继续，原微信账号下的多个新绑定仍表现为：入站和 typing 正常，文本下行不可见。
5. 换用另一个微信账号扫码绑定后，同一环境立即恢复正常。
考虑到故障后的重复测试频率较高，不排除排查操作进一步触发或延长了账号/bot 维度的风险限制。但当前 API 和客户端均没有返回任何“限制中”“需冷却”或“需要申诉”的状态，因此调用方无法判断应当停止重试。
## 稳定复现的状态链
```text
WeChat -> getupdates OK
fresh context_token OK
getconfig OK
sendtyping ret=0 OK
客户端显示“正在输入” OK
sendmessage HTTP 200 / ret=0 OK
客户端显示文本 FAILED
```
回复均为即时短文本，通常在收到入站消息后数十毫秒进入 `sendmessage`，可以排除长任务导致的 `context_token` 过期。单次测试也未达到长文本或连续多段发送场景。
本地同时确认：
- 只有一个进程使用该 bot token 进行长轮询和发送。
- `to_user_id` 与最新入站消息发送方一致。
- `context_token` 来自同一条最新入站消息。
- 未出现 `errcode=-14`、`ret=-2`、HTTP 4xx/5xx 或 token 冲突错误。
## 与 #261 的关系
现象与 #261 相似：`sendmessage` 已被服务端接受，typing 可见，文本消息在微信客户端不可见。
本案例的新信息是：原绑定持续失败期间，换绑另一个微信账号后，在完全相同的主机、网络和调用实现上立即恢复正常。原账号的缺失消息目前也没有像 #261 那样批量补发。
## 当前状态判断困难
`ret: 0` 当前只能说明请求被接口接受，无法确认以下状态：
1. 消息是否进入微信客户端下行队列；
2. 消息是否在接受后被账号、bot、token、会话或风险策略过滤；
3. 当前绑定是否处于临时限制或冷却状态；
4. 限制维度是扫码微信账号、`ilink_bot_id`、bot token，还是目标会话；
5. 用户应等待、重新登录，还是通过某个官方入口申诉。
这种状态下，调用方看到成功返回后通常会继续测试，反而可能提高请求频率并加重风险状态。
## 希望提供的能力
希望 iLink 侧协助确认并完善以下能力：
1. 提供服务端投递状态查询，至少区分 `accepted`、`queued`、`filtered`、`delivered` 和 `failed`。
2. 当消息因风险控制、账号限制或冷却状态无法下发时，`sendmessage` 返回明确的非零错误码、原因类别和建议重试时间。
3. 提供当前 bot/token/账号状态的只读查询接口，便于调用方及时停止重试。
4. 文档补充限制触发后的推荐恢复步骤、冷却窗口及官方申诉入口。
5. 协助核查“原绑定持续不可见、换绑微信后立即恢复”的服务端状态是否属于账号/bot 维度限制。
出于安全考虑，公开 issue 中未附完整微信用户 ID、bot ID、token、`context_token` 和 `message_id`。如维护者需要定位具体请求，可以通过安全渠道提供脱敏时间点和必要标识。
1 个赞
LanCube
2026 年8 月 28 日 06:54
5
微信限流了吧，经常碰到，能不用就不用微信吧，转qq，飞书、钉钉什么的
Mrzqd
2026 年8 月 28 日 07:07
7
是的，我的大号小号都是正常的，但是我的对象的和我同事的都是收不到Bot发送的消息。不知道风控如何解除
reallyasd
2026 年8 月 28 日 07:13
9
微信bot经常miss消息,我已经放弃了;用邮件都比他这强
Mrzqd
2026 年8 月 28 日 07:14
10
另外有一个issue说是部分账户消息挤压，必要形式是过了一段时间后回一股脑的发过来
已打开 02:35PM - 19 Aug 26 UTC
已关闭 03:59PM - 19 Aug 26 UTC
# [Bug] sendMessage returns message_id successfully, but text is not delivered t… o WeChat client
## Environment
* OpenClaw: `2026.7.1`
* `@tencent-weixin/openclaw-weixin`
* Issue initially occurred on `2.4.3`
* Upgraded to `2.4.6`, issue still reproducible
* Weixin iLink endpoint:
* `https://ilinkai.weixin.qq.com`
* Bot type: `3`
* Platform: Docker / Linux
* Timezone: UTC+8
## Problem
Weixin inbound messages are received normally, OpenClaw successfully invokes the LLM and generates a reply, and `/ilink/bot/sendmessage` returns HTTP 200 with a server-side `message_id`.
However, the text reply never appears in the WeChat client.
Interestingly, `sendTyping` works normally and the WeChat client can actually display **“正在输入…” / “typing…”**.
So the Bot → WeChat connection itself appears to be working, while text message delivery fails silently.
## Timeline
The integration was working normally around:
`2026-08-18 22:00 UTC+8`
On the morning of:
`2026-08-19`
I found that the Bot could still receive WeChat messages and invoke the LLM, but WeChat no longer displayed any text replies.
There was no intentional configuration change before the issue started.
The problem originally occurred with plugin version `2.4.3`.
I then upgraded to `2.4.6`, but the issue remained.
## What works
The following parts are all working:
* WeChat → Bot inbound messages
* `getUpdates`
* `getConfig`
* fresh `context_token`
* `typing_ticket`
* `sendTyping`
* WeChat client visibly shows “正在输入…”
* OpenClaw agent routing
* LLM invocation
* LLM reply generation
* `/ilink/bot/sendmessage` HTTP request
* iLink returns a server-side `message_id`
Only the final text message is missing from the WeChat client.
## Clean re-login test
To rule out stale Bot tokens / session state / context tokens, I completely removed the previous local Weixin account state and performed a fresh QR login.
The login request confirmed that no previous local token was reused:
```text
newfetchQRCode: local_token_list count=0
```
A completely new Bot ID was issued:
```text
ilink_bot_id=c3e7214fb597@im.bot
status=confirmed
```
The new account started without an old sync cursor:
```text
No previous get_updates_buf found, starting fresh
```
So this was not a reuse of the previous Bot session.
## Reproduction
After the fresh login:
1. Send `测试` from WeChat to the Bot.
2. Bot receives the message successfully:
```text
getUpdates status=200 raw={"msgs":[...]}
inbound message: from=o9cq...@im.wechat types=1
```
3. A new context is obtained:
```text
POST /ilink/bot/getconfig
getConfig status=200 raw={"ret":0,"typing_ticket":"..."}
```
4. Plugin saves the fresh context token:
```text
setContextToken: key=c3e7214fb597-im-bot:o9cq...@im.wechat
```
5. Typing notification works:
```text
POST /ilink/bot/sendtyping
sendTyping status=200 raw={"ret":0}
```
The WeChat client actually shows:
```text
正在输入…
```
6. OpenClaw agent completes normally and generates:
```text
收到 ✅ 通道正常。
```
7. Plugin sends the text using the fresh context token:
```text
outbound:
to=o9cq...@im.wechat
contextToken=...(len=136)
textLen=10
POST https://ilinkai.weixin.qq.com/ilink/bot/sendmessage
```
8. iLink returns HTTP 200 and a server-side message ID:
```text
sendMessage status=200 raw={"message_id":7495842118583015944}
```
9. Plugin reports:
```text
outbound: text sent OK
```
But the WeChat client receives **no text message**.
## Important observation
`sendTyping` and `sendMessage` are using the same freshly established conversation.
The behavior is:
```text
WeChat → getUpdates OK
getConfig OK
fresh context_token OK
sendTyping ret=0 OK
typing visible in WeChat OK
LLM reply generation OK
sendMessage HTTP 200 OK
sendMessage returns message_id OK
text visible in WeChat FAILED
```
This suggests that authentication, Bot binding, user routing, and the Bot → WeChat communication path are generally working.
The failure appears to occur after the iLink `sendmessage` endpoint accepts the message.
## Server-side message IDs
A message generated after the completely fresh QR login:
```text
7495842118583015944
```
Before the clean login, the same symptom also occurred with:
```text
7495838842399575304
7495838843884374536
```
For all of these, iLink returned HTTP 200 and a `message_id`, while the WeChat client did not display the corresponding text.
## Additional exclusions
I have already ruled out:
* stale `context_token`
* expired context token
* missing context token
* old sync state
* old Bot token
* reused QR login session
* OpenClaw agent failure
* LLM failure
* reply routing failure
* long-message limitation
The reproduced reply is only about 10 characters long.
The issue also started before upgrading the plugin from `2.4.3` to `2.4.6`.
## Expected behavior
When `/ilink/bot/sendmessage` returns a valid server-side `message_id`, the text message should appear in the target user's WeChat conversation.
## Actual behavior
The API returns:
```json
{
"message_id": 7495842118583015944
}
```
and the plugin reports:
```text
text sent OK
```
but no text is displayed in the WeChat client.
At the same time, `sendTyping` succeeds and the typing indicator is visible in the same WeChat conversation.
## Request
Could the Tencent/iLink side please check the server-side delivery status for:
```text
message_id = 7495842118583015944
```
In particular, I would like to know whether the message:
1. was accepted by `sendmessage`,
2. entered the downstream WeChat delivery pipeline,
3. was filtered/dropped after acceptance,
4. or failed during final delivery to the personal WeChat client.
The fact that `sendTyping` is visible while `sendMessage` returns a valid `message_id` but is not visible may help narrow down the issue.
Thanks.
Zeus1
2026 年8 月 28 日 07:15
11
Zeus1
2026 年8 月 28 日 07:27
13
不赚钱的项目够呛能修我感觉
qting
2026 年8 月 28 日 07:46
15
发几条就限流了，麻花都东西还是一如既往的扣扣搜搜，果断删了
我的不回消息几天了 周一晚上开始了 我已经转战telegram了
昨天正常了一下 然后又死了 彻底死心了我 还是用telegram把 哎
moni
2026 年8 月 28 日 08:22
19
佬，用飞书吧，我也是弄了个记账，接的飞书，飞书的消息卡片体验很好
2 个赞
我的情况不一样 假如积压他是会补发的 我们是有的号两三天完全收不到
