Agent 接入多渠道（Telegram/飞书/钉钉/Web）时，Channel 抽象层如何设计？

问题本质：把"平台差异"挡在核心之外

接入 Telegram、飞书、钉钉、Web 这些渠道时，每家的消息格式、富文本能力、文件传输、事件模型和鉴权方式都不同。如果让 Agent 核心逻辑直接处理这些差异，代码会迅速腐化。Channel 抽象层的目标，就是把差异收敛在边界，核心只面向一套统一接口。

统一的入站 / 出站接口

定义两个方向的标准动作：

• receive：各渠道的原始事件（webhook 推送、长轮询等）经适配器解析成统一的 Message——抽取出文本、附件、发送者、会话标识、平台元数据；
• send：上层产出与平台无关的标准回复，适配器再把它翻译成该渠道的具体格式（Telegram 的 sendMessage、飞书的卡片、钉钉的 markdown 等）。

核心 Agent 只读写标准 Message，完全不感知底层是哪家平台。

适配器模式：每渠道一个 Adapter

为每个渠道实现一个 Adapter，遵循同一套 Channel 接口（如 parseIncoming、send、verify、capabilities）。Adapter 内部封装该平台的鉴权/验签、消息体解析、富文本与文件处理、回调机制。新增一个渠道，就等于新增一个 Adapter 并注册，核心零改动——这正是开闭原则的落地。

统一领域模型：Message / User / Session

抽象出与平台无关的领域对象：Message（文本、富文本块、附件、引用关系）、User（跨渠道唯一标识 + 渠道内 id）、Session（由渠道 + 会话/群组标识构成，承载上下文）。这套模型是上层逻辑复用的基础，也是后续做会话隔离、记忆、统计的统一口径。

处理能力差异：降级与特性开关

各渠道能力参差：有的支持富交互卡片，有的只支持纯文本；有的能流式，有的不行。每个 Adapter 通过 capabilities 声明自身能力，上层据此选择渲染策略——不支持卡片就降级为 markdown 或纯文本，不支持流式就整段返回。用特性开关而不是 if 平台名硬编码，扩展性更好。

统一入口：webhook 与回调收口

所有平台的 webhook / 回调先进入一个统一网关，集中做验签、幂等去重（防平台重试导致重复处理）、限流与路由，再按渠道分发到对应 Adapter。这样安全与可靠性逻辑只写一份，避免每个渠道各自为政。