用途与实际影响
这项功能怎样使用
为什么需要它
渠道配置打开、连接探测正常和一次消息真正往返是三件事。只有把它们分开，才不会在关键任务时把“看起来在线”误判成“确实交付成功”。
举个实际例子
“先查 Telegram 和飞书能否接任务，别发测试消息。”AI 分别看渠道连接、网关响应和仍缺的消息证据；上次只确认 Telegram 连接，飞书还在启动，没有完整往返结果。
最后我会得到什么
成功时得到带明确渠道的入站、执行与回发闭环；发现问题时知道停在配置、连接、启动、入站还是出站；未发消息时就只得到运行态，不生成假的端到端结论。
正常时
目标渠道真实收到任务、执行并把回复送回原对话，才记为这条渠道通过。
发现问题时
上次 Telegram 已连接、飞书仍在启动；网关曾短暂超时又恢复，不能把连接和消息交付混成一个结论。
入口不可用或证据不足时
这条渠道停用、没收到任务或没送回回复时，只标记它未通过，不用另一渠道的成功代替。
从哪里开始
在已经配置并连接的 Telegram 或飞书会话直接发送明确任务；若渠道尚未接通，先让 AI 只读检查渠道状态，不能把发送按钮当作已可用。
需要准备什么
- 要发到 Telegram 还是飞书
- 明确任务与希望收到的结果
从开始到拿到结果
- 1
先看渠道有没有接通
AI 分别查看所选渠道的配置、运行和连接；飞书和 Telegram 的结果不能互相代替。
- 2
从原聊天发任务
本人在已接通的应用中发送明确任务，由 OpenClaw 接收并执行。
- 3
等回复回到原处
核对消息收到、任务执行和原渠道回信；缺哪一段就报告哪一段，不把“显示在线”当完成。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
Telegram已运行、就绪且连接；飞书仍启动中；最新网关RPC与健康检查通过，早先超时原因未证，真实消息收发未验关键规则与设计选择
9月9日Telegram running/ready/connected（运行/就绪/连接），飞书running/starting（运行/启动中）；RPC两次10秒超时后已自行恢复，仍不抹掉历史偏慢响应和消息未验的边界。
插件矩阵是 Telegram 2026.8.1 loaded（已加载）、Feishu 2026.6.8 loaded、Google Chat 2026.6.6 disabled（停用）、Qwen 2026.8.1 loaded、Z.AI 2026.7.1 loaded，compat issues（兼容问题）=0。
版本标签不同不等于故障；loaded 和 compat issues=0 也不等于消息或模型调用通过。
Google Chat disabled 是明确停用，不作为第三条可用入口。
Funnel（Tailscale 外部路由）active（活动）说明外部路线存在，但不公开地址，也不证明渠道消息成功。
本轮若要补证据，必须实际发送一条受控消息；这是外部动作，不能由只读状态检查代替。
本模块用到的名词
- channel lifecycle（渠道生命周期）
- 渠道插件报告的启动阶段，例如 ready（就绪）或 starting（启动中）；它不是消息回执。
- plugin matrix（插件矩阵）
- 每个插件自己的版本、loaded/disabled 和兼容问题数；标签不同不自动判故障。
- lastInbound / lastOutbound（最近入站/出站）
- 最近消息活动的脱敏状态；本轮两者都为空。
- Funnel（外部 Tailscale 路由）
- 外部访问路径存在的状态，不公开主机名或 URL（网址）。
专业定义
它保留用户已经在用的消息入口，不要求改用新的网页或聊天壳。
解决什么
避免把 enabled（已启用）、running（运行中）、connected（已连接）、ready（就绪）或外部路由中的任意一个状态，误写成完整消息交付。
当前怎样实现
- OpenClaw channels status（渠道状态）--json 提供各渠道的 configured（已配置）、running（运行中）、lifecycle（生命周期）、connected（已连接）与最近收发字段。
- tools/status.ps1 只读显示 Telegram、飞书、Google Chat，不保存账号或机器人标识。
- 脱敏插件清单分别保留 exact version（精确版本）、loaded/disabled（已加载/停用）和 compat issues（兼容问题）；不把版本差异压成一个总版本。
- 消息处理和回发仍由 OpenClaw 网关与渠道插件拥有；PUBLIC（公开） 仓库只解释脱敏状态。
执行流程
- 1
确认目标渠道的私人配置已经完成。
- 2
只读查看 configured（已配置）、running（运行中）、lifecycle（生命周期）和 connected（已连接）。
- 3
明确需要验收时，从目标应用发送一条受控测试消息。
- 4
确认入站、Agent（智能体）执行和同渠道回发。
- 5
分别记录 Telegram 与飞书结果，不互相代替。
边界
- 不公开账号、机器人身份、allowlist（允许列表）、token（令牌）、正文或原始日志。
- 不因本页建设发送真实消息。
- 不把一个渠道的 PASS（通过）推广到另一个渠道。
失败与恢复
- 渠道显示 enabled/running，但没有收发记录
- 保持“已配置运行、本轮 E2E（端到端验证） 未验”，不升级结论。
- 飞书停在 starting
- 保留 starting；检查插件与渠道状态，但不伪造 ready。
- 外部路由存在但消息失败
- 分别排查 Funnel、渠道连接与 Gateway，不把端口在线当回发成功。
真实入口
docs/USAGE.md从手机交办与消息 E2E（端到端验证） 解释
docs/DEPLOY.md渠道从 disabled 模板到私人配置的流程
tools/status.ps1渠道和 Funnel 脱敏状态入口
如何验证
- 9月9日官方channels status：Telegram configured/running/connected=true、ready；飞书configured/running=true、starting。未发测试消息，未重查入站/出站记录。
- 插件矩阵为 Telegram 2026.8.1 loaded、Feishu 2026.6.8 loaded、Google Chat 2026.6.6 disabled、Qwen 2026.8.1 loaded、Z.AI 2026.7.1 loaded，compat issues=0。
- 9月7日lastInbound/lastOutbound为空是原观察；9月9日没有读取消息记录，也没有发测试消息。
- Funnel 只确认 active；没有公开或核对 hostname/URL。
与其他模块的关系
渠道模块定义请求从哪里来、结果回哪里；模型模块决定执行路线，网关常驻模块负责中间运行。