其他聊天平台

具有可用集成但尚未提取为独立指南的通道。每个通道都通过功能门控进行控制；在构建时启用相应的 channel-<name> 功能。

限制出站回复的速率（reply_min_interval_secs）

每个出站通道都接受一个可选的 reply_min_interval_secs = N 字段（范围为 0..=REPLY_MIN_INTERVAL_MAX_SECS，默认值为 0）。设置后，编排器会将该通道包装在一个按 (channel, recipient) 划分的节流层中，使得发往同一对端的连续出站回复之间至少间隔 N 秒。0（默认值）为直通模式，不会分配包装器，也不会产生额外开销。

当下限处于活动状态时，在下限耗尽前到达的发送请求会进入一个有界 FIFO 队列。后台工作进程会按下限速率排空队列，以便回复仍能按配置的节奏有序送达。队列深度默认为 16（适用于“智能体短暂突发“的情况），并以 REPLY_QUEUE_DEPTH_CEILING（1024）为上限。当队列已满时，会丢弃最新的发送请求，并发出一条带有 channel_alias、脱敏后的 recipient、queue_depth、queue_max 和 dropped_chars 的 WARN：消息正文内容不会写入日志。

单条回复中的流式草稿更新不会进行节奏控制（否则会冻结实时预览）；只有最终的 send（以及末尾的 finalize_draft 写入）才会进入队列。不同收件人之间相互独立：对某个对端的节奏控制不会阻塞发往另一个对端的消息。该包装器通过空闲状态 LRU 淘汰机制，为最多 PACING_RECIPIENT_CAP（1024）个不同对端保留状态：只有没有排队任务且没有进行中发送的条目才会被回收，因此该上限是针对空闲状态的目标值，而非在全部活跃的突发场景下的无条件硬性边界。

用例：成对身份的通道，其中亚秒级回复是 AI 的破绽。在九个通道（Telegram、Discord、Slack、Mattermost、Webhook、iMessage、Matrix、Signal、WhatsApp）上存在端到端的线级覆盖；集成测试在 Telegram 和 WhatsApp Web 上锁定了下限 + 溢出契约。

Webhook 注意事项： 在同步 webhook 通道上，出站回复就是对调用方请求的 HTTP 响应。非零的 reply_min_interval_secs 下限会使该响应保持打开状态，持续时间为下限时长，这可能超过调用方自己的请求超时时间。仅当 webhook 调用方能够容忍延迟响应时才设置该下限，否则将其保持为 0 并在上游进行节流。

iMessage（仅限 macOS）

iMessage 通过 Linq Partner API（[channels.linq.<alias>]）进行桥接：

仅限 macOS，需要 Linq 作为第三方中继，或直接使用 AppleScript 自动化（实验性功能，需要完全磁盘访问权限和辅助功能权限）。

WeChat personal iLink Bot (微信个人号 iLink)

WeChat personal iLink Bot 使用二维码登录方式接入 iLink Bot API，用于处理个人 WeChat 对话。

DingTalk

阿里巴巴的企业级即时通讯工具。

Lark / 飞书

使用 channel-lark 为 Lark 或飞书进行构建。根 channel-feishu 特性是 channel-lark 的别名；运行时选择仍通过 use_feishu = true 进行。

QQ

腾讯的消费级即时通讯工具。机器人 API 访问需要开发者注册。

IRC

经典 IRC。支持 SASL、NickServ 认证以及多频道。

Mochat

Notion

将 Notion 数据库视为消息表面。适用于“通道”为任务收件箱的异步工作流。

何时选择专用指南

具有更复杂设置（OAuth 流程、端到端加密、多设备考虑）的频道位于其各自的页面中：

• Matrix：端到端加密、设备验证、Synapse/Dendrite 相关细节
• Telegram：机器人创建、别名、配对与对等授权
• Discord
• Slack
• Mattermost
• LINE
• Nextcloud Talk
• Signal
• WhatsApp

如果您在上述任何渠道中遇到配置问题，请提交包含复现步骤的 Issue，我们将考虑将其提升为专门的指南。