Canaux : aperçu

Un channel est une surface de messagerie par laquelle l’agent communique. Une seule instance ZeroClaw peut lier plusieurs channels simultanément : le même agent peut répondre dans Discord, Telegram, par e-mail et via la passerelle REST sans que vous ayez à exécuter des processus séparés.

Un agent liste les canaux sur lesquels il répond ; consultez Agents pour savoir comment les canaux sont rattachés à un agent (et comment un groupe de pairs permet aux agents d’un canal partagé de s’adresser les uns aux autres).

Les canaux sont des implémentations du trait Channel dans zeroclaw-api. Chaque canal est conditionné par une fonctionnalité au moment de la compilation, de sorte qu’une compilation minimale n’inclut que les canaux que vous souhaitez.

La compilation ZeroClaw par défaut inclut un ensemble de canaux allégé : ACP, webhook, email, Telegram, Discord et filesystem. Ceux-ci couvrent les sessions locales ou dans l’éditeur, l’entrée via passerelle et la messagerie externe courante lors de la première utilisation, sans compiler chaque intégration de plateforme incluse. Les artefacts de distribution standard ajoutent Git, Matrix, Lark et WhatsApp Web ; l’artefact Android omet WhatsApp Web pour assurer la compatibilité avec la cible. Pour les installations depuis les sources qui nécessitent l’ensemble historique étendu de canaux, exécutez install.sh --source --preset full, compilez avec --features channels-full ou utilisez des fonctionnalités channel-* individuelles pour des compilations sélectives :

./install.sh --source --preset full
cargo build --features channels-full
cargo build --no-default-features --features agent-runtime,gateway,channel-slack

Catégories

Plateformes de chat

Messagerie en temps réel où l’agent peut maintenir une conversation, recevoir des notifications de nouveaux messages via push ou long-poll, et répondre en tant qu’utilisateur bot.

Social et diffusion

Intégrations de type un-à-plusieurs ou de flux public.

Voir les réseaux sociaux.

Plateformes pour les développeurs

Voir Git.

E-mail

Voir Email.

Voix et téléphonie

Voir Voix et téléphonie.

Webhooks et programmation

Voir Webhooks et ACP.

Sources d’événements

Transports uniquement en entrée qui injectent des événements dans la boucle d’agent ou le moteur SOP. Ils ne génèrent aucune réponse sortante ; chacun est également un SOP fan-in.

Voir MQTT, AMQP, et Filesystem.

Configuration

Les instances de canal modernes sont configurées sous [channels.<type>.<alias>], avec default comme premier alias courant. Définissez-les via n’importe quelle surface de configuration :

Les secrets (jetons de bot, clés API, mots de passe) sont stockés chiffrés ; définissez-les via la gateway, zerocode ou zeroclaw config set (masqué), jamais en texte clair. L’entrée channels d’un agent lie un alias de canal à cet agent. Les noms de champs diffèrent selon le canal ; zeroclaw config schema constitue la liste de référence. Champs récurrents dans de nombreux canaux :

Les expéditeurs entrants sont contrôlés via les groupes de pairs, et non par un champ par canal.

Notifications de repli de modèle

channels.model_fallback_notice contrôle les notifications pour les replis ordinaires vers un autre modèle au sein de la même famille de fournisseurs. La valeur par défaut est off. Les notifications de repli entre familles et les notifications de garde-fou conservent leur comportement existant dans tous les modes.

Le paramètre s’applique globalement à tous les canaux qui utilisent l’orchestrateur de canaux partagés. Choisissez le mode pour chaque audience susceptible de recevoir une réponse, y compris les salons partagés et les canaux publics. detailed expose les identifiants de routage à ces audiences ; redacted signale la récupération sans ces identifiants. Il n’existe aucune dérogation par canal.

Ce paramètre ne contrôle pas les notifications de repli dans le chat web de la passerelle, dans ZeroCode ou dans les sessions RPC ; celles-ci utilisent le chemin de tour d’agent et conservent leurs notifications détaillées existantes avec les identifiants du fournisseur et du modèle.

Définissez le mode via ZeroCode Config ou un autre éditeur de configuration pris en charge, ou utilisez :

zeroclaw config set channels.model_fallback_notice redacted

L’orchestrateur lit la configuration active en cours au moment de remettre la réponse, de sorte qu’un changement de mode publié peut affecter un tour déjà en cours. Le simple enregistrement d’un fichier ne met pas à jour la configuration active d’un daemon en cours d’exécution. Utilisez les chemins existants de publication et de rechargement de la configuration décrits dans Cycle de vie de la configuration ; les écritures CLI autonomes prennent effet au prochain chargement ou rechargement.

Ces notifications ne sont ajoutées qu’à la livraison sortante. L’historique stocké de l’assistant conserve la réponse du modèle sans la notification, de sorte que les tours suivants ne reçoivent pas ces métadonnées de livraison comme contenu de la conversation. L’attribution doit identifier un repli réussi vers un modèle différent avant qu’une notification ne soit ajoutée ; les changements de profil de même famille ou du même modèle restent indiscernables dans l’enregistrement d’attribution actuel.

Capacité de streaming

Les canaux déclarent le type de streaming qu’ils prennent en charge : consultez Providers → Streaming pour la matrice des capacités et la signification de supports_draft_updates / supports_multi_message_streaming.

Ajout d’un canal

Implémenter un nouveau canal consiste à ajouter un fichier dans crates/zeroclaw-channels/src/ qui implémente le trait Channel. La référence canonique est n’importe quel canal existant de forme similaire : discord.rs pour le mode push, email_channel.rs pour l’interrogation (polling), webhook.rs pour le mode piloté par HTTP.