消息网关
消息通道把外部聊天平台（Telegram、Slack、Email、Feishu 等）接入常驻的 Anyy。通道配置完成后，你就可以在自己已经在用的应用里与 Anyy 对话，它会在同一个会话中回复。
通道（channel） 是某一个平台的适配器。它负责该平台特定的工作——鉴权、接收消息（通过轮询、Webhook 或长连接 socket）、下载媒体、应用访问策略、格式化回复——并把这一切翻译成一种中立、与平台无关的消息形态，供运行时其余部分使用。正因为这种拆分，智能体循环、会话、记忆、工具与审批都无需知道一条消息来自哪个平台。
通道由 常驻网关（长期运行的 Anyy 进程）负责投递，它在一次性的 CLI 调用中不可用。请先启动网关（参见作为常驻服务运行），再配置通道。
平台对比
下面的平台列表是权威的配置目录。Implemented（已实现） 的通道拥有可用的运行时适配器和专属配置页。Planned（计划中） 的通道会出现在配置目录里（因此你能在向导和 doctor 输出中看到它们），但尚未注册运行时适配器。
分组只是为了便于阅读；所有已实现的通道共享同一套路由、策略与会话模型。
主流平台
| 平台 | 通道名 | 状态 | 配置指南 |
|---|---|---|---|
| Telegram | telegram | Implemented | Telegram |
| Discord | discord | Implemented | Discord |
| Slack | slack | Implemented | Slack |
whatsapp | Implemented | ||
| Facebook Messenger | facebook | Implemented |
中国平台
| 平台 | 通道名 | 状态 | 配置指南 |
|---|---|---|---|
| DingTalk | dingtalk | Implemented | DingTalk |
| Feishu / Lark | feishu | Implemented | Feishu |
| Weixin / WeChat | weixin | Implemented | Weixin |
| QQ Bot | qqbot | Implemented | QQ Bot |
其他传输
| 平台 | 通道名 | 状态 | 配置指南 |
|---|---|---|---|
| Email（IMAP/SMTP） | email | Implemented | |
| SMS（Twilio） | sms | Implemented | SMS |
| IRC | irc | Implemented | IRC |
| LINE | line | Implemented | LINE |
计划中
下列条目列在配置目录中，但尚无运行时适配器。在其适配器发布之前，它们没有配置页。
| 平台 | 通道名 | 状态 |
|---|---|---|
| Yuanbao | yuanbao | Planned |
| Google Chat | google_chat | Planned |
每个通道可接受的完整配置字段——凭据、访问策略、线程与媒体——参见通道参考。
架构
每个通道都位于外部平台与常驻运行时之间。入站消息流入运行时；出站回复则流回它来自的那个平台会话。
平台事件或轮询结果
-> 通道适配器解析平台载荷
-> 通道适配器应用访问策略并去重
-> 通道适配器暂存任何媒体
-> 中立的入站消息（ChannelInbound）
-> 通道运行时解析身份 + 通道绑定
-> 网关会话轮次（或命令分发）
-> 网关发出结果事件
-> 通道管理器解析投递路由
-> 中立的出站消息（ChannelOutbound）
-> 通道适配器格式化并发送平台回复
入站。 每个适配器把平台事件规范化为一条中立的入站消息，携带与平台无关的路由键：通道名、账号 id、外部对端 id、可选的线程 id、发送者 id，以及对端类型（dm、group、channel 或 thread）。运行时依据这些键解析出发送者的身份与通道绑定，随后驱动一次网关会话轮次——若该消息是命令，则改为分发命令。网关、会话与工具保持平台中立：它们绝不会针对 Telegram 话题、Slack 线程或 Discord 频道做分支判断。
出站。 当网关产生回复（或审批提示、澄清请求、后台任务通知）时，通道管理器解析出一条 投递路由（delivery route），并把一条中立的出站消息交给适配器。适配器为该平台格式化并发送。投递解析决定回复去往何处：
origin——回复到消息来自的那个会话（受信任通道消息的默认值）。gateway——投递到本地网关界面而非某个通道。current_user_default——某个具名通道的已配置默认绑定（需要delivery.channel）。none——抑制通道投递。
路由以存储的 通道绑定 为键，因此回复总能返回到来源通道、账号、对端与线程——即便是后台任务完成这类异步投递也是如此。指向已被移除或停用绑定的路由会被报告为陈旧（stale），而不会被错投。
快速配置
用交互式向导配置通道，然后验证它们：
# 交互式：选择平台并填写凭据
anyy setup channels
# 或直接配置某一个平台
anyy setup channels telegram --secret token=... --account-id personal-bot --write-config
# 在不联系平台的情况下验证已配置的通道
anyy channels doctor telegram
anyy setup channels 走的正是上面展示的目录。端到端的引导流程参见配置向导；逐平台的凭据步骤，请从矩阵中打开对应平台的配置指南。
机密（令牌、应用密钥、Webhook 密钥）以引用形式存放在机密系统中，绝不会内联写入配置、日志或诊断信息。
Gateway 命令
anyy channels 命令组在运行中的网关上操作已配置的通道：
# 对单个通道做静态诊断（配置、机密引用、Webhook 状态、live-smoke 就绪情况）
anyy channels doctor CHANNEL
# 在不完全重启的情况下，让常驻网关重新读取通道配置
anyy channels reload
channels doctor 离线运行：它检查已配置的通道块、必填字段与机密引用的可解析性，而不会启动适配器、注册 Webhook 或调用平台 API。channels reload 把配置变更应用到运行中的网关。
聊天命令
在通道会话内，以已注册命令开头的消息（例如 /help）会被作为命令分发，而不是开启一次普通的会话轮次。可用命令集取决于为该通道启用的界面（surfaces）。普通消息则作为会话轮次路由给智能体。某个平台暴露哪些命令，记录在该平台的配置页上。
会话管理
会话持久化
每个通道会话都通过其 通道绑定（通道 + 账号 + 对端 + 线程）绑定到一个 Anyy 会话。同一会话中的后续消息延续同一个 session，因此上下文与历史会跨轮次保留。正是这个绑定，让异步回复在之后能够找回正确的会话。
重置策略
会话可以被重置回干净状态，使下一条消息从头开始而不延续此前的上下文。重置如何触发、清除什么内容，取决于通道的配置；确切字段参见各平台的配置页与通道参考。
安全
配对
在未知发送者能够触达智能体之前，通道可以要求 配对（pairing）——一个为该发送者身份授权该通道的明确步骤。在完成配对之前，来自未识别发送者的消息会被策略拒绝，而不是被悄悄处理，并且该丢弃会被（以脱敏形式）记录下来，便于你看清某个通道为何显得安静。
管理员与普通用户
访问由逐通道的策略治理，所有平台共享一套通用词汇：
- 私信策略：
open、allowlist、pairing或disabled。 - 群组策略：
disabled、mention、allowlist、open或pairing。 - 面向发送者和群组/频道的 白名单，以及面向群组界面的要求提及（require-mention）选项。
通道策略控制谁可以与智能体对话；它并不授予对高风险操作的权限。改变状态、具备 root 能力或其他敏感的操作，无论请求从哪个通道到达，始终由 Anyy 的审批、ChangePlan、回滚与审计语义治理。
工具进度通知
在智能体处理一个轮次期间，通道可以把中间状态——例如工具进度或一条“仍在处理”的确认——回送到会话中，具体取决于各平台的能力（部分平台支持输入指示器，另一些仅支持文本）。审批提示与澄清请求通过与普通回复相同的出站路径投递。
后台会话
超出单个轮次的工作——后台任务与定时（cron）投递——会异步产生结果。当此类结果就绪时，通道管理器解析存储的投递路由，并把结果回送到来源会话，因此即便原轮次早已结束，你仍会在同一个通道里收到答案。
服务管理
通道只在常驻网关进程内运行。操作通道即操作该服务：启动它以让通道上线，保持它运行以让通道接收与投递消息，并用 anyy channels reload 应用配置变更。安装与守护网关的方式参见作为常驻服务运行。
运营多平台网关
你可以同时启用多个通道。它们共享同一个运行时、同一套会话模型与同一套策略词汇，而每个适配器各自封装其平台特定的传输方式（轮询、Webhook 或 socket）。例如，一个 Anyy 可以同时接收 Telegram 私信、监视一个 IMAP 邮箱，并在 Slack 线程中回复——全部经由同一个网关、同一套身份/绑定模型路由。