Le mode Talk

La voix paraît simple de l’extérieur : vous parlez, l’assistant répond. En dessous, le mode Talk regroupe plusieurs formes d’exécution qui diffèrent par qui détient l’audio, qui détient les outils et la transcription, et qui détient les identifiants du fournisseur. Le Talk natif est une boucle continue qui écoute la parole, envoie la transcription au modèle par la session active, attend la réponse, puis la prononce avec le fournisseur configuré. Les chemins temps réel remplacent une partie de cette boucle par une connexion vivante au fournisseur, et c’est le catalogue de la passerelle, et non la supposition du client, qui décide lesquels sont utilisables.

Les formes d’exécution

• Le Talk natif sur macOS, iOS et Android utilise la reconnaissance vocale de la plateforme, le chat de la passerelle et une commande de parole, la reconnaissance Apple pouvant recourir à des services réseau sur macOS et iOS et le comportement Android dépendant du service vocal installé, tandis que les nœuds annoncent une capacité de parole et déclarent les commandes qu’ils prennent en charge.
• Sur iOS, le WebRTC détenu par le client sert aux configurations temps réel OpenAI qui choisissent le transport WebRTC ou omettent le transport, tandis que les configurations à relais explicite, à websocket de fournisseur et les configurations temps réel non OpenAI restent sur le relais détenu par la passerelle et que les configurations non temps réel utilisent la boucle vocale native.
• Le Talk autonome sur Apple Watch utilise le WebRTC natif et Opus sur UDP avec un contrôle d’appel détenu par la passerelle, reprend le fournisseur temps réel configuré sur la passerelle, garde les outils et la transcription du côté de la passerelle, et échoue de façon visible quand une configuration n’est pas prise en charge.
• Android n’utilise le temps réel relayé par la passerelle que si le catalogue annonce le groupe temps réel prêt et si le modèle configuré franchit aussi le contrôle client Android, n’ouvre jamais de session WebRTC détenue par le client, et garde délibérément les nouveaux modèles vocaux sur la reconnaissance native tant que le chemin relayé n’est pas prouvé en direct depuis un appareil Android.

Les configurations non prises en charge échouent de façon visible, sans repli par relais.

Identifiants, routes et voix

La route WebRTC détenue par la passerelle tient les identifiants OAuth et de plateforme à l’écart des clients du relais, et les chemins en websocket de service gardent la clé de plateforme sur la passerelle. Pour les modèles temps réel en disponibilité générale, les sessions navigateur préfèrent les identifiants de plateforme dans un ordre fixe : la clé d’API temps réel configurée, puis un profil de clé OpenAI, puis la variable d’environnement. Sans aucun des trois, le Talk navigateur se rabat sur un profil OAuth ChatGPT d’OpenClaw et échange les descriptions de session par le courtier d’offres à usage unique de la passerelle, si bien que le jeton OAuth n’atteint jamais le navigateur. Un identifiant de plateforme configuré mais impossible à résoudre échoue franchement au lieu de glisser en silence vers OAuth. Les deux routes vocales diffèrent également : la route de l’API publique exige une clé de plateforme, tandis que la route Codex préfère un profil OAuth ChatGPT d’OpenClaw et se rabat sur une authentification par clé d’API de plateforme. Leurs familles de voix diffèrent aussi, si bien que choisir le même modèle et une voix prise en charge dans Talk et dans Discord est ce qui les fait sonner pareil, et qu’une voix de la route Codex choisie avec le modèle public retombe sur la voix par défaut de cette route. Des routes non publiées et délivrées par compte peuvent être posées dans la configuration mais ne passent ni par les catalogues ni par les diagnostics, n’utilisent jamais OAuth et exigent une clé de plateforme. Des bornes d’exécution s’appliquent partout : huit sessions simultanées par passerelle, une durée de session de trente minutes, et des jetons d’offre à usage unique de soixante secondes pour les sessions navigateur. Une session refusée n’indique pas d’elle-même la cause, alors vérifiez le compte, le modèle et la voix retenus.

Directives de voix et limites

• Une réponse peut porter une seule ligne JSON en première ligne non vide pour piloter la voix, et cette ligne est retirée avant la lecture, les clés inconnues sont ignorées, et un indicateur ponctuel ne vaut que pour la réponse en cours alors que, sans lui, la voix choisie devient la nouvelle voix par défaut du mode Talk.
• Les clés de directive prises en charge couvrent les identifiants de voix et de modèle, la vitesse, le débit en mots par minute, la stabilité, la similarité, le style, le renfort de voix, la graine, la normalisation, la langue, le format de sortie, le niveau de latence et l’indicateur ponctuel, ElevenLabs acceptant la stabilité, la similarité et le style de zéro à un, la vitesse de 0,5 à 2, et le niveau de latence de zéro à quatre.
• Pour les réponses dominées par des blocs de code, la commande de parole utilise un court message parlé qui renvoie l’auditeur vers l’écran, tandis que le code en ligne et la prose ordinaire restent dans la réponse prononcée.

Talk est une capacité de nœud avant d’être une fonctionnalité, si bien que la page des Les nœuds est l’endroit où cette capacité et son modèle de commandes sont définis. Discord passe par les mêmes ponts de passerelle que Talk lorsqu’il est configuré avec le modèle vocal correspondant, et c’est là que Talk rencontre les Les canaux. Discord préserve aussi l’identité de chaque locuteur à travers le travail délégué à OpenClaw, en gardant les connexions au modèle vocal séparées par locuteur tandis que le contexte partagé de la salle appartient à la conversation de l’agent.

Pourquoi le catalogue décide

Il est demandé aux clients Talk de première partie de lire le catalogue plutôt que de tenir des alias de fournisseurs en local, et la raison en est que les identifiants de fournisseurs, les modes, les transports, les stratégies de cerveau, les formats audio temps réel et les indicateurs de capacité changent tous plus vite qu’un client déjà livré. Le catalogue expose aussi le résultat de disponibilité retenu à l’exécution, et une passerelle plus ancienne qui omet la disponibilité du groupe doit être tenue pour non vérifiée plutôt que résolument non configurée, ce qui est un refus délibéré de deviner. Le même réflexe se voit dans le comportement en cas d’échec, où les configurations non prises en charge échouent de façon visible au lieu de relayer en silence et où un identifiant configuré mais impossible à résoudre échoue franchement. Le routage suit la propriété plutôt que la commodité, et c’est pourquoi la stratégie de consultation de l’agent fait passer les appels d’outils temps réel par la politique de la passerelle, tandis que le réglage à outils directs n’existe que pour la compatibilité héritée et que le réglage neutre sert à la transcription ou à une orchestration externe. C’est ce routage qui maintient un tour parlé dans la même exécution d’agent qu’un tour écrit, là où vit aussi sa La mémoire. C’est aussi la raison pour laquelle une conversation vocale hérite du reste des limites de l’agent au lieu de les contourner, y compris du Le bac à sable dans lequel il tourne déjà.

Sur Diali

Sur Diali, les canaux se connectent depuis le tableau de bord et la configuration d’exécution d’OpenClaw hébergé sur Diali en est générée puis remplacée à chaque version. Chaque client exécute son propre assistant, avec un état sur un volume persistant ; des instantanés quotidiens et une restauration en un clic sont disponibles grâce à l’option Sauvegardes (incluse avec Max). Vous en saurez plus sur La sécurité Diali.

• Talk regroupe plusieurs formes, qui diffèrent par ce que chacun détient.
• Lisez le catalogue ; ne gardez pas d’alias de fournisseurs dans le client.
• Les configurations non prises en charge échouent au lieu de relayer.