多渠道消息适配
Multi-Channel Messaging Adapter
统一抽象多个聊天平台（IM/Email/社交）的消息收发接口，通过适配器模式和消息总线解耦渠道实现与核心业务逻辑，支持动态注册和生命周期管理。
子问题
1.平台 API 差异抽象（WebSocket vs HTTP vs SDK）
2.消息格式统一（文本/图片/文件/富文本）
3.权限控制（allow_from 白名单）
4.消息路由与会话隔离
5.渠道生命周期管理（启动/停止/重连）
6.消息去重策略差异（OrderedDict vs deque vs set，各渠道独立实现）
7.WebSocket 到 HTTP 轮询的自动降级与恢复
8.跨线程事件桥接（飞书 SDK 回调在独立线程，需 run_coroutine_threadsafe）
9.出站消息进度过滤（区分最终回复与中间状态推送）
10.显式用户授权门控（Email 的 consent_granted 机制）
各项目的解法1 solutions
Signals
横向对比
| 维度 | Nanobot |
|---|---|
| 适配器基类 | ABC 定义 start/stop/send + _handle_message 模板方法 + is_allowed 权限检查 |
| 消息总线 | 双向 asyncio.Queue，零依赖，无持久化 |
| 渠道数量 | 9 个（Telegram/WhatsApp/Discord/Feishu/Slack/DingTalk/QQ/Email/Mochat） |
| 连接策略 | 混合：长轮询/WebSocket/Socket Mode/IMAP，各渠道独立实现 |
| 格式转换 | 每渠道独立转换（Markdown→HTML/mrkdwn/Card JSON），无统一中间格式 |
| 权限控制 | 基类 allow_from 白名单 + Slack 分层策略（DM/群组/mention） |
| 容错机制 | 各渠道自带重连循环(5s)，Mochat 有 WebSocket→HTTP 轮询降级 |
| 消息去重 | Feishu OrderedDict/QQ deque/Mochat set，各渠道独立实现 |
| 配置方式 | Pydantic BaseSettings + camelCase 别名，YAML/ENV 统一配置 |
最佳实践
1.使用 ABC 基类定义统一接口（start/stop/send），通过 MessageBus 异步队列解耦
2.每个渠道独立配置，支持 allow_from 白名单控制访问权限
3.延迟导入渠道 SDK，缺少依赖只 warning 不崩溃，保证其他渠道正常运行
4.模板方法统一权限检查，子类无需重复实现 ACL 逻辑
5.出站分发协程独立运行，按 msg.channel 路由，支持进度消息过滤配置