微信 iLink 会话被静默失效，恢复需两次人工干预（重登 + 入站消息）——希望增加掉线检测与无人值守自愈能力

**提交人**: 弈宣 沈
**客户端版本**: 0.1.57

---

## 结论（先行）

微信连接器的 iLink 会话会被微信侧**静默失效**：全程无任何 logout/kick 事件，所有发送只返回 `SEND_FAIL`，日志仅见 `iLink rejected the message`。恢复的唯一手段是人工重新登录；且重登后新绑定返回 `NO_PEER_CONTEXT`（"当前绑定尚未收到过微信消息，无法确定安全的发送目标"），**还必须先从微信侧发一条入站消息才能恢复发送**。对依赖无人值守 scheduled 发送的场景，每次掉线 = 两次人工干预 + 数小时推送中断。

## 三个关键事实

1. **静默性**：掉线无任何事件通知，只有发送失败时才能间接发现；连接器层面缺少会话健康探测
2. **高频性**：最近一周内 4 个掉线日（08-18/19/20/22 日志均有 iLink 拒绝记录），08-23 上午两个推送窗口仍被拒，中午重登后才恢复
3. **恢复摩擦**：重登 ≠ 恢复，还需入站消息解锁发送目标——对无人值守链路是双重人工依赖

## 背景

我们通过 `cindy_wechat` MCP（`send_message_to_user`）做定时内容摘要推送：一天三个推送窗口，全部由 scheduled agent 无人值守发起。生产侧自建了 outbox 状态机兜底（`pending → processing → sent`；通道故障 `release` 不消耗重试、恢复后 `requeue` 补发；两段式领取，首条真实卡片兼作通道探针）。这套机制保证掉线期间内容不丢，但兜不住"通道本身要人工多久才能修好"。

## 脱敏日志摘要

```
[2026-08-22T16:47:21+08:00] [WARN] [mcp/cindy_wechat] sendMessage failed target=...m.wechat detail=iLink rejected the message.
[2026-08-23T11:30:43+08:00] [WARN] [mcp/cindy_wechat] sendMessage failed target=...m.wechat detail=iLink rejected the message.
```

（同类记录分布于 08-18/19/20/22 各日；target 字段日志本身已脱敏）

## 我们的应对（供官方参考）

- 掉线识别：发送失败 + 日志 grep `iLink rejected`；条目 release 回 pending 保全，桌面通知提醒用户重登
- 恢复动作：Cindy 内重新登录微信（唯一有效）；重登后需人工发一条微信消息解锁发送目标，再触发补发

## 诉求建议

1. **会话健康检测 + 主动通知**：心跳探测 iLink 有效性，失效时桌面通知/状态栏标红，而不是等发送失败才暴露
2. 如技术可行：**延长会话寿命或自动重连**，降低静默失效频率
3. **重登后 peer context 保留或显式"验证发送目标"操作**，让无人值守 scheduled 发送可自愈
4. （可选）暴露**通道健康状态查询的 MCP 工具**，agent 发送前可先探测，避免盲发烧失败
---
**版本区域**: CN
**OS**: darwin arm64 (25.2.0)
**界面语言**: zh-CN

Start by tracing the cindy_wechat MCP entry point send_message_to_user and the handling of iLink rejected the message failures. Review how session state, peer context, notifications, and requeue behavior are represented; done should be a defined health-detection and recovery flow that addresses silent expiry and the post-login NO_PEER_CONTEXT requirement.

Written by the indexing model from the issue text.