SeedRealtime, Seeduplex et agent téléphonique full duplex : ce qu’il faut pour agir sur Android

Ce que SeedRealtime et Seeduplex changent pour les agents téléphoniques

Le 9 avril 2026, ByteDance Seed a présenté Seed Full-Duplex Speech LLM, avec Seeduplex comme cadre natif d’écoute pendant la parole. L’idée centrale est simple à formuler et profonde pour l’usage mobile : l’agent vocal peut parler tout en continuant à écouter. Il gère donc mieux les interruptions, les hésitations, les reprises et les bruits qui arrivent pendant sa propre réponse.

La page officielle de SeedRealtime situe aussi ce modèle dans la famille Seed actuelle. Pour les constructeurs d’agents téléphoniques, ce type de modèle change le confort d’interaction. L’utilisateur n’a plus besoin d’attendre une fin de phrase parfaite pour corriger : il peut dire « attends », « plutôt demain », « non, à Claire bureau », ou interrompre une réponse trop longue. Cette fluidité se rapproche davantage d’une conversation humaine.

Ce progrès compte pour FoneClaw parce que nous construisons vers un téléphone où la voix devient l’entrée naturelle de l’intention. Une conversation plus réactive aide l’utilisateur à expliquer ce qu’il veut faire. Elle ne suffit pourtant pas à produire une action Android fiable. Entre la voix et le téléphone, il faut une couche d’exécution gouvernée : état de tâche, permission, approbation, résultat visible et récupération. Pour la thèse plus large sur le mobile centré sur la voix, Téléphone IA centré sur la voix : pourquoi la prochaine interface du mobile ne sera pas seulement un écran plus intelligent donne le contexte produit.

Comment une IA vocale full duplex gère pauses, bruit et interruptions

Dans une interaction half-duplex, l’assistant écoute, s’arrête, réfléchit, puis parle. Pendant qu’il parle, l’utilisateur attend ou coupe brutalement la sortie. Ce format marche pour une commande courte, mais il devient lourd dans les scénarios de téléphone : corriger un destinataire, ajouter une contrainte, dire que le contexte a changé, ou interrompre parce que l’agent a mal compris. Le full duplex rapproche l’échange d’une conversation vivante : le système garde une oreille active pendant sa réponse.

ByteDance Seed attribue à Seeduplex des progrès sur l’écoute attentive, la suppression d’interférences, la détection des fins de parole et la gestion des interruptions. Ces résultats sont présentés par Seed comme des mesures de performance du système, notamment dans des situations où l’utilisateur parle par-dessus l’agent ou où du bruit accompagne l’échange. Pour un agent vocal temps réel, ces points sont essentiels : une interruption peut être une correction, une urgence ou un arrêt.

La recherche pose aussi une question d’architecture. L’article How Should LLMs Listen While Speaking? explique que les systèmes full duplex doivent router l’audio utilisateur qui arrive pendant la génération. Les approches comme la fusion de canaux ou l’attention croisée exposent des compromis entre ancrage dans le signal immédiat et robustesse du contexte. En termes simples : écouter en parlant crée plus de possibilités, mais aussi plus de décisions sur ce qui mérite d’interrompre la réponse en cours.

Sur téléphone, la latence devient tout aussi importante. Un modèle qui comprend vite mais répond trop tard casse la sensation de dialogue. Un modèle qui répond vite mais interprète mal une correction crée de la frustration. Pour la dimension vitesse d’inférence et agents mobiles, LLM à 1000 TPS : ce que cela change pour les agents téléphone approfondit ce sujet sans le confondre avec l’exécution Android.

Pourquoi conversation et exécution Android sont deux plans distincts

Nous séparons toujours deux plans dans notre conception. Le premier est le plan d’interaction : entendre l’utilisateur, comprendre le tour de parole, accepter une interruption, reformuler l’intention, poser une question courte. SeedRealtime et Seeduplex rendent ce plan beaucoup plus naturel. Une IA vocale full duplex peut suivre un échange rapide et réagir à une correction au bon moment.

Le second est le plan d’exécution : changer un réglage Android, préparer un SMS, lancer un appel, ouvrir une navigation, lire un état d’écran, demander une permission, afficher une approbation, vérifier le résultat. Ce plan demande des contrats explicites. Une phrase fluide ne vaut pas autorisation d’envoyer un message. Une correction vocale ne choisit pas automatiquement la bonne SIM. Une conversation naturelle ne remplace pas l’état de l’application ni les permissions Android.

Lorsque ces deux plans sont mélangés, l’expérience devient fragile. L’agent peut donner l’impression d’avoir compris, puis agir sur le mauvais écran. Il peut interrompre correctement sa réponse, puis perdre l’état de la tâche. Il peut confirmer oralement une intention, puis rencontrer une permission manquante. C’est la raison pour laquelle nous construisons FoneClaw comme un agent téléphonique avec exécution gouvernée, au-delà de la conversation.

Pour poser cette distinction dans le contexte complet des actions Android, Contrôle du téléphone par agent IA : ce qu’un agent Android doit vraiment faire explique pourquoi le téléphone a besoin d’un modèle d’action, d’état, de permission et de reprise.

Un contrat en sept étapes de l’intention parlée au résultat vérifié

Pour transformer une conversation full duplex en action fiable, nous utilisons un contrat en sept étapes. Il commence par la capture : l’utilisateur parle, l’agent reçoit l’intention et identifie le contexte utile. Dans un futur système full duplex, cette capture pourra inclure interruptions et corrections pendant la réponse de l’agent. La deuxième étape est la clarification : si le destinataire, l’application, l’horaire ou l’action reste ambigu, l’agent pose une question courte au lieu d’avancer sur une hypothèse fragile.

La troisième étape est la planification. L’agent choisit le chemin Android pris en charge : brouillon de message, réglage Ne pas déranger, appel préparé, navigation confiée à l’application de cartes, ou autre workflow compatible. La quatrième étape est l’approbation. Quand l’action a un effet externe ou sensible, l’utilisateur doit voir la cible, l’effet et le contexte. C’est là que l’interface compte autant que le modèle vocal. Le guide Interface d’approbation des agents IA sur téléphone : confiance, contexte et reprise détaille ce moment de décision.

La cinquième étape est l’exécution par les outils gouvernés. L’agent agit dans le périmètre pris en charge, via les permissions Android et les contrôles disponibles. La sixième étape est la vérification : le résultat doit être visible, confirmé ou expliqué. Un réglage activé, un brouillon prêt, un appel préparé ou une navigation ouverte doivent laisser un état compréhensible. La septième étape est la récupération. Si le réseau change, si l’écran devient ambigu, si une permission manque ou si l’utilisateur interrompt, la tâche doit rester reprenable.

Ce contrat est plus important encore avec le full duplex. Une conversation plus rapide augmente le nombre de corrections et de micro-décisions. L’architecture doit donc conserver l’état et les approbations à travers les tours de parole. Dans FoneClaw, cette discipline guide notre travail actuel : l’agent ne se contente pas d’entendre mieux ; il doit agir mieux.

Comment nous construisons la couche d’exécution FoneClaw actuelle

La base actuelle de FoneClaw porte cette couche d’exécution Android avec l’assistant flottant, la continuité de tâche sur le même téléphone, la récupération de permissions et les actions rapides. La page Télécharger FoneClaw permet de tester cette surface utilisateur. SeedRealtime sert ici de signal sur l’avenir de l’interaction vocale ; FoneClaw utilise notre couche Android actuelle pour transformer une intention en action prise en charge.

Notre voix actuelle est déclenchée par l’utilisateur. Le contexte d’écran actuel est également attaché à la demande par l’utilisateur, plutôt que capté en continu. Cette décision produit rend le contexte plus lisible : l’utilisateur sait quand il apporte l’écran courant à la tâche. L’assistant flottant rapproche l’agent de l’application active, tandis que Home garde un point de reprise stable. Pour comprendre ce fonctionnement visuel, Assistant IA flottant Android : comprendre et agir depuis l’écran actuel explique le chemin de contexte d’écran actuel.

Nos workflows actuels couvrent des actions Android gouvernées : réglages comme Ne pas déranger, messages visibles, composeur téléphonique, navigation vers une application de cartes sélectionnée et certains réglages pris en charge. Les capacités utilisateur sont présentées sur Fonctionnalités FoneClaw. Le point commun n’est pas une liste d’actions isolées ; c’est le contrat : demande, contexte, permission, approbation, exécution, résultat, récupération.

En tant que constructeur, nous regardons les modèles full duplex comme une future entrée d’interaction plus riche. Pour les intégrer proprement dans un agent Android, il faudra les brancher sur une couche d’exécution qui sait distinguer correction vocale, arrêt, approbation, changement de contexte et permission système. C’est précisément la couche que nous renforçons dans FoneClaw.

Scénarios d’agent vocal temps réel qui demandent des garde-fous

Premier scénario : le mode réunion. L’utilisateur dit « active Ne pas déranger jusqu’à midi », puis interrompt : « attends, plutôt jusqu’à 11 h 30 ». Un modèle full duplex peut capter cette correction pendant qu’il répond. La couche Android doit ensuite préparer le bon réglage, demander l’approbation utile, appliquer l’action prise en charge et confirmer l’état final. La fluidité vocale améliore la saisie ; la vérification protège le résultat.

Deuxième scénario : le message dicté. L’utilisateur commence : « prépare un SMS à Camille : j’arrive dans dix minutes », puis corrige immédiatement : « non, à Camille bureau, et dis quinze minutes ». Le full duplex rend cette correction naturelle. FoneClaw, côté exécution, doit afficher le destinataire, le texte complet et les conditions d’envoi. Si une double SIM ou une interface ambiguë apparaît, la tâche reste visible pour reprise.

Troisième scénario : appel ou navigation. L’utilisateur demande « appelle le cabinet », puis ajoute pendant la réponse : « en fait ouvre l’itinéraire ». L’agent vocal temps réel doit comprendre le changement d’intention. La couche d’exécution doit choisir entre le composeur et l’application de cartes, montrer la cible et laisser l’utilisateur confirmer si l’action engage un appel ou une navigation. Cette transition illustre le cœur de FoneClaw : une conversation peut changer vite, mais l’action doit rester vérifiable.

Quatrième scénario : une tâche interrompue. L’utilisateur prépare un réglage, reçoit une notification, revient plus tard et dit « reprends ce qu’on faisait ». La continuité de tâche sur le même téléphone devient décisive. La couche vocale peut reconnaître la demande de reprise ; l’agent Android doit retrouver l’état, expliquer l’étape restante et proposer le prochain geste fiable.

Confidentialité, batterie, limites audio-visuelles et prochaines briques

Une IA vocale full duplex soulève des choix pratiques sur téléphone. Le micro, la latence et la batterie deviennent des contraintes de produit. Écouter pendant que l’agent parle augmente la qualité d’interruption, mais demande une gestion fine des ressources. Sur Android, nous privilégions les déclenchements explicites et les contextes apportés par l’utilisateur, afin que l’expérience reste compréhensible et contrôlable.

La vision audio-visuelle demande aussi de la précision. Dans le billet Seed, l’entrée visuelle et l’interaction proactive figurent dans les travaux à venir. Le benchmark VideoFDB sur le full duplex audio-visuel montre que l’ancrage vidéo en streaming reste un défi distinct : certains systèmes utilisent encore peu le flux visuel hors questions explicitement visuelles. Pour un agent téléphonique, voir, écouter et agir doivent donc être évalués séparément.

Notre checklist de constructeur est directe : l’utilisateur sait-il quand l’agent écoute ? La correction vocale modifie-t-elle l’état de tâche ou seulement la réponse ? Une action sensible affiche-t-elle une approbation ? La permission Android est-elle demandée au bon moment ? Le résultat est-il vérifié ? La batterie reste-t-elle acceptable ? Le contexte d’écran est-il attaché volontairement ? La récupération est-elle possible après interruption ?

SeedRealtime et Seeduplex montrent une avancée importante pour l’interaction. FoneClaw se concentre sur la suite : transformer une intention fluide en action Android gouvernée. C’est là que le téléphone agentique devient utile pour le lecteur : moins de friction dans la conversation, plus de rigueur dans l’exécution.