Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

Autres plateformes de chat

Canaux disposant d’intégrations fonctionnelles mais qui n’ont pas encore été extraits dans des guides dédiés. Chaque canal est activé par une fonctionnalité ; activez la fonctionnalité correspondante channel-<name> lors de la compilation.

Espacement des réponses sortantes (reply_min_interval_secs)

Chaque canal sortant accepte un champ optionnel reply_min_interval_secs = N (plage 0..=REPLY_MIN_INTERVAL_MAX_SECS, valeur par défaut 0). Lorsqu’il est défini, l’orchestrateur enveloppe le canal dans une couche de régulation par (canal, destinataire), de sorte que les réponses sortantes consécutives vers le même pair soient espacées d’au moins N secondes. 0 (la valeur par défaut) correspond à un passage direct : aucune enveloppe allouée, aucune surcharge.

Lorsque le plancher est actif, les envois qui arrivent avant l’expiration du plancher entrent dans une file FIFO bornée. Un worker en arrière-plan vide la file au rythme du plancher afin que les réponses arrivent toujours dans l’ordre, à la cadence configurée. La profondeur de la file est par défaut de 16 (adaptée au cas « l’agent a connu une brève rafale ») et est plafonnée à REPLY_QUEUE_DEPTH_CEILING (1024). Lorsque la file est pleine, l’envoi le plus récent est abandonné et un WARN est émis avec channel_alias, le recipient masqué, queue_depth, queue_max et dropped_chars : le contenu du corps du message reste hors des journaux.

Les mises à jour de brouillon en streaming au sein d’une même réponse ne sont pas régulées (elles figeraient l’aperçu en direct) ; seul le send final (et l’écriture terminale finalize_draft) entrent dans la file d’attente. Les destinataires différents sont indépendants : la régulation pour un pair ne bloque pas les messages vers un autre. Le wrapper conserve l’état pour un maximum de PACING_RECIPIENT_CAP (1024) pairs distincts via une éviction LRU des états inactifs : seules les lignes sans travail en file d’attente et sans envoi en cours sont récupérées, de sorte que le plafond est une cible pour l’état inactif plutôt qu’une limite stricte inconditionnelle lors d’une rafale où tous sont actifs.

Cas d’utilisation : canaux à identité jumelée où les réponses en moins d’une seconde sont un indicateur d’IA. La couverture au niveau du protocole existe de bout en bout sur neuf canaux (Telegram, Discord, Slack, Mattermost, Webhook, iMessage, Matrix, Signal, WhatsApp) ; les tests d’intégration verrouillent le contrat de plancher + débordement sur Telegram et WhatsApp Web.

Mise en garde concernant les webhooks : sur un canal webhook synchrone, la réponse sortante est la réponse HTTP à la requête de l’appelant. Un seuil reply_min_interval_secs non nul peut maintenir cette réponse ouverte pendant toute la durée du seuil, ce qui peut dépasser le délai d’expiration de la requête de l’appelant lui-même. Ne définissez le seuil que lorsque l’appelant du webhook tolère une réponse différée, ou laissez-le à 0 et régulez le rythme en amont.

iMessage

iMessage peut utiliser l’API partenaire Linq ([channels.linq.<alias>]) ou l’adaptateur direct expérimental ([channels.imessage.<alias>]).

L’adaptateur direct est macOS uniquement. Il envoie via l’automatisation AppleScript et reçoit en lisant ~/Library/Messages/chat.db ; accordez l’accès à l’Automatisation pour contrôler Messages et l’Accès complet au disque pour lire la base de données.

Le bot personnel WeChat iLink Bot utilise la connexion par code QR auprès de l’API iLink Bot pour les conversations WeChat personnelles.

WeCom (企业微信 / WeChat Work)

Deux variantes de WeCom sont implémentées. Elles correspondent à des produits WeCom, des fonctionnalités de build et des clés de configuration différents ; choisissez celle qui correspond à la manière dont le bot est provisionné :

Bot Webhook (bot de groupe)AI Bot WebSocket (bot intelligent)
Développer la fonctionnalitéchannel-wecomchannel-wecom-ws
Clé de configuration[channels.wecom.<alias>][channels.wecom_ws.<alias>]
Flux de messagesPlease send the English string you want translated into French.Bidirectionnel avec brouillons en streaming
Point de terminaisonhttps://qyapi.weixin.qq.com/cgi-bin/webhook/sendwss://openws.work.weixin.qq.com connexion persistante

Bot Webhook (bot de groupe)

Un robot de groupe WeCom (群机器人) envoie des messages texte au groupe dans lequel il a été créé. Ajoutez un robot au groupe cible depuis le client WeCom, copiez la key de l’URL du webhook, puis configurez le canal sous l’alias default :

[channels.wecom.default]
enabled = true
webhook_key = "<GROUP-BOT-WEBHOOK-KEY>"

Ensuite, liez-le à un agent avec channels = ["wecom"].

Cette variante est sortante uniquement : les webhooks de robot de groupe WeCom n’exposent aucun callback auquel ZeroClaw puisse s’abonner, de sorte que les messages de groupe n’atteignent jamais l’agent par son intermédiaire. Utilisez-la pour envoyer des notifications de l’agent dans un groupe. Pour les conversations initiées par des messages WeCom entrants, utilisez la variante AI Bot WebSocket ci-dessous.

AI Bot WebSocket (bot intelligent)

L’API AI Bot (智能机器人) de WeCom, à connexion persistante, offre un canal bidirectionnel : elle reçoit les messages des discussions privées et de groupe, et répond sur la même socket, y compris pour les mises à jour en streaming des brouillons. Les identifiants du bot (bot_id et secret) sont délivrés lors de la création de l’AI Bot dans la console d’administration de WeCom.

[channels.wecom_ws.primary]
enabled = true
bot_id = "<AI-BOT-ID>"
secret = "<AI-BOT-SECRET>"

# Autorisation des entrées. Des listes vides refusent tout : sans au moins une entrée, aucun message entrant n'est accepté. "*" autorise n'importe quel expéditeur et désactive la liste d'autorisation, donc privilégiez des identifiants précis.
allowed_users = ["<wecom-user-id>"]
allowed_groups = ["<group-chat-id>"]

# Facultatif : la manière dont le bot est interpellé dans le texte d'un groupe, par exemple "danya" pour "@danya say hi". Permet à la pré-vérification générique d'intention de réponse de reconnaître qu'un message de groupe était adressé au bot.
bot_name = "<BOT-NAME>"

Puis liez-le à un agent avec channels = ["wecom_ws.primary"] (utilisez l’alias de la clé de configuration).

Valeurs par défaut à connaître :

  • Les pièces jointes multimédias téléchargées sont déchiffrées, mises en cache dans l’espace de travail du canal, puis supprimées après file_retention_days (7 par défaut) ; les téléchargements dépassant max_file_size_mb (20 par défaut) sont rejetés.
  • Les réponses sont diffusées sous forme de mises à jour provisoires par défaut (stream_mode = "partial") ; définissez stream_mode = "off" pour une livraison unique de la réponse complète. Seuls partial et off sont pris en charge sur ce canal ; multi_message est rejeté au démarrage.
  • Les champs proxy_url et excluded_tools propres à chaque canal s’appliquent comme d’habitude.

Les identifiants d’expéditeur entrants peuvent également provenir d’un groupe de pairs dont channel est wecom_ws ou wecom_ws.<alias>, à la place des listes allowed_* ci-dessus.

DingTalk

La messagerie d’entreprise d’Alibaba.

Lark / Feishu

Compilez avec channel-lark pour Lark ou Feishu. La fonctionnalité racine channel-feishu est un alias de channel-lark ; la sélection à l’exécution se fait toujours via use_feishu = true.

QQ

Messagerie grand public de Tencent. L’accès à l’API Bot nécessite une inscription de développeur ; [channels.qq.<alias>] prend l’app_id et l’app_secret fournis par la console.

Les expéditeurs entrants sont les identifiants opaques de la plateforme : user_openid pour les messages de discussion privée, member_openid pour les messages @ de groupe. Autorisez-les via un groupe de pairs (external_peers) ; un ensemble de pairs vide refuse tout le monde, donc un bot connecté qui ne répond jamais n’a généralement pas d’entrée de groupe de pairs pour l’expéditeur.

Les réponses à un message entrant sont passives (le msg_id déclencheur est repris), elles ne nécessitent donc aucune permission supplémentaire. Les envois qui ne sont pas une réponse (livraison cron, zeroclaw channel send) sont des messages actifs et consomment le quota de messages actifs du bot. Adressez l’instance avec qq.<alias> et la destination avec user:<user_openid> pour une conversation privée, ou group:<group_openid> pour un groupe, où l’identifiant de groupe provient de group_openid du message et non de member_openid de l’expéditeur. Un --channel-id qq seul ne résout que l’alias default.

zeroclaw channel doctor interroge l’identité du bot elle-même (GET /users/@me) avec les identifiants du canal ; un verdict positif signifie donc que l’API accepte le même jeton que celui utilisé par les chemins d’envoi et d’écoute, et pas seulement que le secret de l’application permet encore d’en générer un. La sonde ne peut pas valider un destinataire : la plateforme n’expose aucune recherche d’identifiants de pairs pour les conversations privées, si bien qu’une adresse inutilisable n’apparaît qu’au moment où un envoi est tenté.

IRC

IRC classique. Prend en charge SASL, l’authentification NickServ et plusieurs canaux.

Mochat

Notion

Traite une base de données Notion comme une surface de message. Utile pour les flux de travail asynchrones où le « canal » est une boîte de réception de tâches.


Quand privilégier un guide dédié

Les canaux nécessitant une configuration plus complexe (flux OAuth, chiffrement de bout en bout, considérations multi-appareils) sont détaillés dans leurs propres pages :

Si vous rencontrez des problèmes de configuration sur l’un des canaux mentionnés ci-dessus, ouvrez un ticket avec le cas de reproduction et nous envisagerons d’en faire un guide dédié.