OpenClaw 在用户看来应是一个连贯的智能体，但网关背后要协调 多套聊天 API，各自重试语义不同。2026 年，许多看似「模型发疯」的事故实为 Webhook 双重投递 或主通道中断却未演练备路径。本矩阵为 Slack、Telegram、Discord 排序故障转移，定义幂等键，并给出八条可在 NodeMac 专用 Mac mini M4 上复现的步骤（SSH 自动化、一次性权限用 VNC，节点覆盖 HK、JP、KR、SG、US）。
基线集成：Slack 与 Discord Webhook、多模型故障转移与超时、状态目录与无头网关清单。健康：就绪探针；诊断：doctor。定价：定价；帮助：帮助。
你真正在排查的故障模式
当网关 HTTP 响应慢时，聊天提供商会积极重试。若工具副作用（工单、发布、退款）非幂等，重试会变成重复事故。另方面，Socket Mode 或长轮询在笔记本睡眠、Wi‑Fi 切换或企业 TLS 中间盒时会断开——在固定云 Mac 与稳定出口上往往消失。
- 至少一次投递 是默认假设——请按此设计。
- 人工升级 应在去重存储不可用时绕过自动化。
- 跨发 同一智能体回复到两个主通道会混淆审计轨迹。
通道层级矩阵
| 通道 | 2026 最佳角色 | 故障转移注意 |
|---|---|---|
| Slack | 企业团队主通道；丰富线程 | Socket Mode 令牌需按文档日历轮换 |
| Telegram | 个人机器人快；良好备播 | 群组隐私模式会改变提及语义——用真实群测试 |
| Discord | 面向社区的智能体；Webhook 扇入 | 每公会速率限制不同；分片告警 |
幂等与重放矩阵
| 入站模式 | 去重键配方 | TTL 提示 |
|---|---|---|
| Slack Events API | 哈希 event_id + team_id |
至少 24 小时 |
| Telegram updates | 每机器人 update_id |
若可能长时间离线维护则 48 小时 |
| Discord interactions | 交互负载 id + 公会 id |
除非代理更长重试，否则 12 小时 |
存储提示：将去重状态放在与 OpenClaw 状态目录相同的非同步卷上，以便 launchd 下 SQLite 或文件锁行为一致。
八步上线路径
- 声明层级：一页架构说明含负责人。
- 实现去重存储，带命中率与逐出指标。
- 重放测试：每通道在预发保存负载重放两次。
- 增加断路器：备通道也出错时——对人类 fail closed。
- 记录关联 ID：贯穿网关、工具调用与出站聊天回复。
- 自动化令牌轮换：Slack Socket Mode 每季演练。
- DNS 阻断演练：针对主提供商 API。
- 记录冻结开关：停止工具执行而不删配置。
常见问题
Slack 与 Discord 是否都应为主？
否——自动工具执行只选一个主通道；另一个用于通知或降级模式。
好的去重键是什么？
稳定提供商 ID 加工区或公会范围，哈希后以超出重试窗口的 TTL 存储。
为何用专用 NodeMac Mac？
长连接在线时间、可预测路径、与用户及 API 邻近的区域放置。