Otras plataformas de chat
Canales con integraciones funcionales pero que aún no se han extraído en guías dedicadas. Cada uno está controlado por una característica; habilita la característica correspondiente channel-<name> en el momento de la compilación.
Espaciado de respuestas salientes (reply_min_interval_secs)
Cada canal de salida acepta un campo opcional reply_min_interval_secs = N (rango 0..=REPLY_MIN_INTERVAL_MAX_SECS, valor predeterminado 0). Cuando se establece, el orquestador envuelve el canal en una capa de regulación por (canal, destinatario), de modo que las respuestas salientes consecutivas al mismo par esperan al menos N segundos entre sí. 0 (el valor predeterminado) es un paso directo: no se asigna ningún envoltorio y no hay sobrecarga.
Cuando el floor está activo, los envíos que llegan antes de que el floor expire entran en una cola FIFO acotada. Un worker en segundo plano drena la cola a la velocidad del floor para que las respuestas sigan llegando en orden con la cadencia configurada. La profundidad de la cola es por defecto 16 (adecuada para el caso de “el agente tuvo una ráfaga breve”) y está limitada por REPLY_QUEUE_DEPTH_CEILING (1024). Cuando la cola está llena, se descarta el envío más reciente y se emite un WARN con channel_alias, recipient redactado, queue_depth, queue_max y dropped_chars: el contenido del cuerpo queda fuera de los logs.
Las actualizaciones de borrador en streaming dentro de una misma respuesta no se regulan (congelarían la vista previa en vivo); solo el send final (y la escritura terminal de finalize_draft) entran en la cola. Los destinatarios distintos son independientes: la regulación de ritmo para un par no bloquea los mensajes hacia otro. El wrapper conserva el estado de hasta PACING_RECIPIENT_CAP (1024) pares distintos mediante desalojo LRU de estados inactivos: solo se reclaman las filas sin trabajo en cola y sin envíos en curso, por lo que el límite es un objetivo para el estado inactivo y no una cota dura incondicional ante una ráfaga con todos activos.
Caso de uso: canales de identidad emparejada donde las respuestas en menos de un segundo son un indicador de IA. La cobertura a nivel de protocolo existe de extremo a extremo en nueve canales (Telegram, Discord, Slack, Mattermost, Webhook, iMessage, Matrix, Signal, WhatsApp); las pruebas de integración fijan el contrato de valor mínimo + desbordamiento en Telegram y WhatsApp Web.
Advertencia sobre webhooks: en un canal de webhook síncrono, la respuesta saliente es la respuesta HTTP a la solicitud del llamador. Un valor mínimo de
reply_min_interval_secsdistinto de cero puede mantener esa respuesta abierta durante la duración del mínimo, lo que puede exceder el tiempo de espera de la solicitud del propio llamador. Establezca el mínimo solo cuando el llamador del webhook tolere una respuesta retrasada, o déjelo en0y controle el ritmo en el origen.
iMessage
iMessage puede usar la API de socios de Linq ([channels.linq.<alias>]) o el adaptador directo experimental ([channels.imessage.<alias>]).
El adaptador directo es solo para macOS. Envía mensajes mediante automatización de AppleScript y recibe leyendo ~/Library/Messages/chat.db; concede acceso de Automatización para controlar Mensajes y acceso total al disco para leer la base de datos.
WeChat personal iLink Bot (微信个人号 iLink)
El Bot iLink personal de WeChat utiliza inicio de sesión mediante código QR contra la API de iLink Bot para conversaciones personales de WeChat.
WeCom (企业微信 / WeChat Work)
Se implementan dos variantes de WeCom. Corresponden a productos de WeCom, funciones de compilación y claves de configuración diferentes, así que elija la que coincida con la forma en que se aprovisiona el bot:
| Webhook de bot (bot de grupo) | AI Bot WebSocket (bot inteligente) | |
|---|---|---|
| Construir función | channel-wecom | channel-wecom-ws |
| Clave de configuración | [channels.wecom.<alias>] | [channels.wecom_ws.<alias>] |
| Flujo de mensajes | Please send the English text you want translated to Spanish. | Bidireccional con borradores en streaming |
| Punto de conexión | https://qyapi.weixin.qq.com/cgi-bin/webhook/send | wss://openws.work.weixin.qq.com conexión persistente |
Webhook de bot (bot de grupo)
Un robot de grupo de WeCom (群机器人) envía mensajes de texto al grupo en el que se creó. Agregue un robot al grupo de destino desde el cliente de WeCom, copie el key de la URL del webhook y configure el canal con el alias default:
[channels.wecom.default]
enabled = true
webhook_key = "<GROUP-BOT-WEBHOOK-KEY>"
Luego vincúlalo a un agente con channels = ["wecom"].
Esta variante es solo de salida: los webhooks de robots de grupo de WeCom no exponen ningún callback al que ZeroClaw se suscriba, por lo que los mensajes del grupo nunca llegan al agente a través de ella. Úsala para enviar notificaciones del agente a un grupo. Para conversaciones que se inician a partir de mensajes entrantes de WeCom, usa la variante WebSocket de AI Bot que aparece más abajo.
AI Bot WebSocket (bot inteligente)
El API de conexión persistente del bot de IA (智能机器人) de WeCom ofrece un canal bidireccional: recibe mensajes de chats individuales y de grupos y responde por el mismo socket, incluidas las actualizaciones de borradores en streaming. Las credenciales del bot (bot_id y secret) se emiten al crear el bot de IA en la consola de administración de WeCom.
[channels.wecom_ws.primary]
enabled = true
bot_id = "<AI-BOT-ID>"
secret = "<AI-BOT-SECRET>"
# Autorización de entrada. Las listas vacías deniegan todo: sin al menos una entrada no se acepta ningún mensaje entrante. "*" permite a cualquier remitente y desactiva la lista de permitidos, así que es preferible usar IDs concretos.
allowed_users = ["<wecom-user-id>"]
allowed_groups = ["<group-chat-id>"]
# Opcional: cómo se dirige al bot en el texto de los grupos, p. ej. "danya" para "@danya say hi". Permite que la verificación previa genérica de intención de respuesta reconozca que un mensaje de grupo iba dirigido al bot.
bot_name = "<BOT-NAME>"
Luego vincúlalo a un agente con channels = ["wecom_ws.primary"] (usa el alias de la clave de configuración).
Valores predeterminados que conviene conocer:
- Los adjuntos multimedia descargados se descifran, se almacenan en caché dentro del espacio de trabajo del canal y se eliminan después de
file_retention_days(por defecto 7); las descargas que superenmax_file_size_mb(por defecto 20) son rechazadas. - Las respuestas se transmiten como actualizaciones de borrador de forma predeterminada (
stream_mode = "partial"); establecestream_mode = "off"para entregar la respuesta completa de una sola vez. Solopartialyoffson compatibles en este canal;multi_messagese rechaza al iniciar. - Los campos
proxy_urlyexcluded_toolspor canal se aplican como de costumbre.
Los IDs de remitente entrantes también pueden provenir de un grupo de pares cuyo channel sea wecom_ws o wecom_ws.<alias>, en lugar de las listas allowed_* mencionadas arriba.
DingTalk
Mensajero empresarial de Alibaba.
Lark / Feishu
Compila con channel-lark para Lark o Feishu. La característica raíz channel-feishu es un alias de channel-lark; la selección en tiempo de ejecución sigue realizándose mediante use_feishu = true.
Mensajero de consumo de Tencent. El acceso a la API de bots requiere registro de desarrollador; [channels.qq.<alias>] toma el app_id y el app_secret de la consola.
Los remitentes entrantes son los IDs opacos de la plataforma: user_openid en los mensajes de chat individual y member_openid en los mensajes de grupo con @-. Autorízalos mediante un grupo de pares (external_peers); un conjunto de pares vacío deniega el acceso a todos, por lo que un bot conectado que nunca responde normalmente no tiene una entrada en el grupo de pares para el remitente.
Las respuestas a un mensaje entrante son pasivas (se repite el msg_id del mensaje que las activa), por lo que no necesitan permisos adicionales. Los envíos que no son respuestas (entrega programada con cron, zeroclaw channel send) son mensajes activos y consumen la cuota de mensajes activos del bot. Especifique la instancia como qq.<alias> y el destino como user:<user_openid> para un chat individual o group:<group_openid> para un grupo, donde el ID del grupo proviene de group_openid del mensaje y no de member_openid del remitente. Un --channel-id qq sin más resuelve únicamente el alias default.
zeroclaw channel doctor sondea la identidad del propio bot (GET /users/@me) con las credenciales del canal, por lo que un resultado correcto significa que la API acepta el mismo token que usan las rutas de envío y de escucha, y no solo que el secreto de la aplicación todavía genera uno. La sonda no puede validar un destinatario: la plataforma no ofrece ninguna consulta para los ID de pares de chat individual, así que una dirección no utilizable solo se detecta cuando se intenta un envío.
IRC
IRC clásico. Admite SASL, autenticación con NickServ y múltiples canales.
Mochat
Notion
Trata una base de datos de Notion como una superficie de mensajes. Útil para flujos de trabajo asíncronos donde el “canal” es una bandeja de tareas.
Cuándo preferir una guía dedicada
Los canales con una configuración más compleja (flujos de OAuth, cifrado de extremo a extremo, consideraciones de múltiples dispositivos) se encuentran en sus propias páginas:
- Matrix: E2EE, verificación de dispositivos, particularidades de Synapse/Dendrite
- Telegram: creación de bots, alias, emparejamiento y autorización de pares
- Discord
- Slack
- Mattermost
- LINE
- Nextcloud Talk
- Signal
Si encuentras algún problema de configuración en cualquiera de los canales mencionados, abre un problema con el ejemplo reproducible y consideraremos convertirlo en una guía dedicada.