File de tâches d’agent IA sur Android : sessions et reprise

Pourquoi plusieurs conversations ont besoin d’une vraie file

Une file de tâches d’agent IA sur Android commence par un problème très concret. Vous demandez à l’agent de préparer un SMS à partir d’un message affiché, puis vous ouvrez une autre conversation pour régler Ne pas déranger avant une réunion. La première tâche attend une approbation d’envoi ; la seconde peut modifier un réglage système. Si l’agent traite seulement ces échanges comme deux fils de chat, il risque de mélanger contexte, cible, approbation et action finale.

Sur téléphone, une conversation n’est pas encore une tâche gouvernée. Une vraie file garde l’état de chaque demande : ce que l’utilisateur a demandé, quelle application ou fonction Android est concernée, quelles permissions existent, quelle action est prête, quelle confirmation reste à donner, et ce qui doit être vérifié après exécution. Elle transforme la discussion en cycle de vie de tâche, avec des pauses légitimes quand le système demande une permission, quand l’utilisateur doit confirmer, quand le réseau change ou quand l’app visible n’est plus celle attendue.

Nous avons appris cela en construisant FoneClaw : le téléphone n’est pas un document de travail où plusieurs brouillons peuvent rester ouverts sans conséquence. Un agent Android manipule parfois des états personnels, des contacts, des paramètres, des messages ou des itinéraires. L’ordre, l’identité et la reprise comptent autant que la qualité de la réponse du modèle. Pour les lecteurs qui veulent construire des enchaînements métier ou personnels, Automatiser les tâches Android avec une seule commande vocale garde le détail des workflows ; ici, nous traitons la couche qui empêche plusieurs tâches de se gêner.

La règle de base est simple : une file de tâches mobile n’est pas une boîte de réception. C’est un contrôleur de cycle de vie. Elle doit savoir ce qui tourne, ce qui attend, ce qui demande une approbation, ce qui a été arrêté, ce qui peut reprendre et ce qui est terminé.

États d’exécution, d’attente, d’approbation et de fin

Une file fiable expose des états lisibles. Sans eux, l’utilisateur voit seulement un agent qui répond ou se tait. Avec eux, il comprend pourquoi une tâche avance, pourquoi une autre attend et quelle action vient ensuite. Nous préférons un modèle d’état assez court pour être visible dans l’interface, mais assez précis pour éviter les transitions implicites.

Ce tableau n’est pas une norme universelle ; c’est un cadre pratique pour tester une interface d’agent IA à conversations multiples. Le point important est la transition. Une tâche en attente reste en attente. Une demande de permission reste une demande de permission. Une approbation donnée pour un brouillon précis ne devient pas une autorisation générale pour une autre conversation.

Cette séparation rend le téléphone utilisable pendant qu’une tâche patiente. Vous pouvez laisser un message en attente de confirmation, vérifier un réglage dans une autre conversation, puis revenir au brouillon initial. La file ne doit pas bloquer toute l’expérience parce qu’une seule tâche attend ; elle doit au contraire préserver l’identité de chaque demande pour que l’utilisateur sache quoi reprendre.

Identité de conversation et isolation des tâches

L’isolation des tâches commence par une identité durable. Une conversation peut contenir beaucoup de texte, mais la tâche doit conserver ses propres champs : demande initiale, cible prévue, contexte attaché, action proposée, état des permissions, approbation, résultat attendu, traces de reprise et raison d’arrêt. Cette identité de tâche vit au-delà de la fenêtre de contexte temporaire du modèle. Elle permet au runtime Android de dire : cette action appartient à cette session, avec cette cible, dans cet état.

Prenons deux conversations. Dans la première, l’utilisateur demande : prépare un SMS pour dire à Claire que j’arrive dans dix minutes. Dans la seconde, il demande : active Ne pas déranger jusqu’à la fin de ma réunion. Le modèle peut comprendre les deux. Le runtime doit les garder séparées. Le SMS porte un destinataire, un texte, une app de messagerie et une approbation d’envoi. Le réglage Ne pas déranger porte une durée, un état système, une permission et une vérification après modification. Mélanger ces champs crée une mauvaise action, même si chaque phrase semble correcte séparément.

Quand l’utilisateur change de conversation, l’interface doit donc changer de contexte visible. Elle peut montrer la tâche active, la tâche en attente, l’approbation requise ou l’état terminé. Ce changement n’a pas besoin d’être lourd ; il doit être explicite. Un badge de tâche, un résumé court, une cible et un prochain geste suffisent souvent. Pour les architectures où l’identité, les permissions et la piste d’audit doivent être détaillées, Identité des agents IA : permissions, approbation par outil et piste d’audit prolonge ce sujet.

L’isolation ne remplace pas la sécurité Android, les permissions ou les approbations. Elle donne à ces contrôles un endroit clair où s’attacher. C’est ce qui empêche un brouillon, une permission ou un arrêt de glisser vers la mauvaise conversation.

Approbations liées à la session

Une approbation liée à la session répond à une question simple : quand l’utilisateur appuie sur confirmer, quelle tâche reçoit cette autorisation ? Sur un téléphone avec plusieurs conversations d’agent, un bouton générique devient trop faible. L’approbation doit porter une identité : session d’origine, tâche, cible, outil ou action, contenu proposé, effet attendu et moment de validation.

Cette liaison évite un scénario classique. L’utilisateur prépare un message dans une conversation, passe à une autre tâche, puis voit une carte d’approbation sans contexte suffisant. S’il confirme, il doit savoir exactement quelle action part : quel destinataire, quel texte, quelle app et depuis quelle conversation. Une approbation refusée, ignorée ou laissée en attente garde le même périmètre ; elle ne donne aucune autorité à une autre tâche.

Nous évitons de dupliquer toute la conception de l’interface d’approbation dans cet article, car Interface d’approbation des agents IA sur téléphone : confiance, contexte et reprise traite les cartes, les raisons et les signaux de confiance en profondeur. Ici, le critère de file est plus étroit : l’approbation doit être rattachée à la bonne session et survivre aux changements de conversation.

Dans FoneClaw, cette logique guide notre produit. Une confirmation utile ne se contente pas de demander oui ou non ; elle rappelle ce qui va changer sur Android. Plus le téléphone peut porter plusieurs tâches, plus ce rappel devient essentiel.

Équipes d’agents parallèles ou file téléphone

La concurrence d’agents Android ne doit pas être confondue avec les équipes d’agents parallèles. Dans son annonce MiniMax Agent Team, MiniMax décrit des rôles de leader, worker et verifier pour des tâches longues. Cette logique convient bien aux livrables de connaissance : recherche, code, rapport, vérification, planification. Plusieurs agents peuvent travailler sur des sous-parties, garder un état intermédiaire, demander une intervention humaine et reprendre une session durable.

OPPO présente une autre direction avec son annonce sur l’interopérabilité Agent-to-Agent et l’AIOS, autour de la collaboration appareil-cloud, de la mémoire et de la confidentialité. Le laboratoire OPPO Mente documente aussi, dans le dépôt X-OmniClaw, des boucles d’agent par session, un runtime isolé et des chaînes d’arrêt précises. Ces signaux montrent que l’industrie prend au sérieux les sessions, l’isolation et l’arrêt.

Microsoft aborde le même problème côté entreprise avec ses modèles multi-agents orientés workflow. L’architecture sépare orchestration, agents, état et contrôle du processus. C’est une distinction utile pour Android : la coordination peut être parallèle dans la couche de raisonnement, tandis que les effets téléphone doivent souvent être ordonnés, relus et vérifiés.

Sur un téléphone personnel, l’effet final pèse plus lourd que le nombre d’agents. Envoyer un message, modifier un réglage, lancer un appel, partager une position ou déplacer un fichier demande une cible claire. Une file mobile peut laisser plusieurs tâches progresser séparément, mais elle doit sérialiser les actions qui se marcheraient dessus : deux réglages audio concurrents, deux messages vers des destinataires différents, deux demandes qui utilisent le même écran ou une action sensible pendant qu’une autre attend approbation.

Chez FoneClaw, nous voyons donc la file comme un contrôleur d’exécution téléphone. Elle profite du raisonnement du modèle, mais elle organise surtout l’ordre, les états et les reprises. Le téléphone peut devenir un centre de commande personnel ; Contrôle d’agent IA mobile : quand le téléphone devient le centre de commande développe cette vision plus large.

Arrêt, reprise et vérification d’état

La récupération rend la file utile quand la réalité Android change. Une tâche peut attendre parce que l’utilisateur doit accorder une permission. Une autre peut être stoppée parce que l’app cible n’est plus visible. Une troisième peut devenir périmée parce que le contact, le texte ou l’écran a changé depuis la demande initiale. La file doit reprendre à partir de la tâche d’origine, puis relire les conditions actuelles avant tout effet final.

Imaginons une tâche de message qui attend l’autorisation d’accéder au contexte visible. Pendant ce temps, l’utilisateur ouvre une autre conversation et demande de vérifier le volume. La file doit permettre au réglage volume d’avancer si son action est claire, tout en gardant le message en attente. Quand l’utilisateur revient au message, l’agent doit vérifier que le destinataire et le texte proposés correspondent toujours à la demande initiale. Si l’écran n’est plus le même, une clarification ou un nouveau brouillon vaut mieux qu’une exécution automatique.

L’arrêt a la même importance. Un utilisateur doit pouvoir stopper une tâche qui prend trop de temps, qui vise le mauvais contexte ou qui produit une proposition inattendue. L’état arrêté conserve la raison : arrêt utilisateur, permission manquante, cible introuvable, réseau indisponible ou contexte périmé. Cette raison nourrit la reprise. Reprendre ne signifie pas continuer aveuglément ; cela signifie reconnecter la demande initiale aux conditions présentes.

La récupération de permission suit ce principe. Après l’accord Android, l’agent relit l’état : permission réellement accordée, app correcte, cible toujours valable, action toujours souhaitée. Pour les tâches à effet externe, un aperçu frais et une approbation liée à la session restent le chemin le plus clair. Nous construisons FoneClaw avec cette logique parce qu’un téléphone change vite : notifications, écrans, comptes, réseau et gestes utilisateur peuvent modifier la vérité entre deux étapes.

Comment FoneClaw porte plusieurs tâches

La base actuelle de FoneClaw porte la fondation multi-conversation : gestion des sessions récentes, file stricte entre conversations, états indépendants d’exécution et d’attente, approbations liées à la session, isolation des tâches et récupération de permission. Les capacités actuellement disponibles ajoutent l’assistant flottant déplaçable, l’attachement volontaire de l’écran actuel et la continuité de tâche entre Home et l’assistant flottant. Les informations disponibles jusqu’ici sont accessibles depuis la page de téléchargement FoneClaw.

Ce modèle sert une expérience simple : plusieurs conversations peuvent exister sans fusionner leurs actions. Une tâche peut avancer dans Home. Une autre peut attendre une approbation. L’utilisateur peut ouvrir l’assistant flottant au-dessus d’une autre app, attacher l’écran actuel en un geste et continuer la tâche qui correspond à ce contexte. Les approbations, l’arrêt et la récupération restent partagés entre Home et l’assistant flottant, ce qui évite de traiter chaque surface comme un produit séparé.

Prenons un scénario complet. Le matin, vous demandez à FoneClaw de préparer un rappel pour une réunion. La tâche est terminée. Ensuite, vous demandez dans une autre conversation de préparer un message à un collègue à partir d’un écran actuellement affiché. Le brouillon attend votre approbation. Avant de confirmer, vous ouvrez une troisième conversation pour régler Ne pas déranger pendant trente minutes. La file doit conserver trois identités : rappel terminé, message en approbation, réglage système en cours ou terminé. L’assistant flottant rend le contexte atteignable, mais l’ordre d’exécution reste gouverné.

Les actions Android prises en charge par FoneClaw gardent leur comportement de permission, approbation, état visible et récupération. Les 100+ built-in tools donnent une surface large pour les tâches courantes, tandis que la file décide comment ces actions coexistent. Nous ne mesurons pas la qualité d’un agent Android au nombre de conversations ouvertes ; nous la mesurons à sa capacité à préserver la bonne tâche, au bon moment, avec le bon effet.

Checklist d’évaluation d’une file d’agent Android

Pour évaluer une file d’agent IA sur Android, commencez avec deux tâches à faible risque. Dans une première conversation, demandez un brouillon visible ou un rappel. Laissez la tâche attendre une clarification ou une approbation. Dans une seconde conversation, demandez une action réversible comme ouvrir une app ou vérifier un réglage pris en charge. Revenez ensuite à la première tâche et observez ce qui reste attaché : demande, cible, contenu, état et prochain geste.

Notez cinq critères. L’identité de tâche est-elle visible ? Les états en cours, en attente, approbation, permission, arrêt et terminé sont-ils compréhensibles ? Une approbation reste-t-elle liée à sa session d’origine ? Les actions téléphone sont-elles ordonnées quand elles touchent le même contexte Android ? La reprise relit-elle l’état actuel avant l’effet final ? Ces questions révèlent plus qu’un compteur de conversations ouvertes.

Ajoutez ensuite un test d’arrêt. Lancez une tâche, stoppez-la, changez d’écran, puis demandez une reprise. Un bon agent explique ce qu’il reprend, ce qui a changé et quelle confirmation reste nécessaire. Pour une tâche sensible, effectuez toujours ce test avec un scénario réversible avant d’étendre le workflow à des messages, fichiers, appels ou réglages plus conséquents.