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 (uniquement sur macOS)

iMessage est relayé via la Linq Partner API ([channels.linq.<alias>]) :

macOS uniquement et nécessite soit Linq comme relais tiers, soit une automatisation directe via AppleScript (expérimental, nécessite les autorisations d’accès complet au disque et d’accessibilité).

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

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

Messager grand public de Tencent. L’accès à l’API Bot nécessite un enregistrement en tant que développeur.

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é.