Routage des capacités d’un agent IA Android : AutoAttach, Suggest et Fallback

De la demande aux capacités candidates

Imaginons une demande simple : « retrouve le lieu de mon prochain rendez-vous et prépare l’itinéraire ». Le routage des capacités d’un agent IA commence avant l’action. L’agent doit comprendre l’intention, regarder le contexte disponible, puis classer plusieurs candidats : lire le calendrier, extraire le lieu, ouvrir une application de carte, proposer une navigation, ou demander une clarification si plusieurs événements correspondent.

Un agent Android ne peut pas charger chaque outil, chaque Skill, chaque Workflow et chaque Plugin dans chaque contexte. Ce serait lent, bruyant et risqué. Il doit réduire l’espace de décision. La demande, l’app active, l’écran joint par l’utilisateur, les permissions déjà accordées, les capacités activées et l’historique immédiat aident à former un ensemble de candidats raisonnable. Le modèle peut ensuite raisonner sur ces candidats, mais le routage ne vaut pas autorisation.

La première erreur à éviter consiste à prendre une bonne correspondance sémantique pour une action prête à partir. « Itinéraire » peut correspondre à une carte, à un calendrier, à un message ou à une recherche Web. Le routeur doit classer, puis vérifier : le calendrier est-il accessible ? Le lieu est-il unique ? Une app de navigation est-elle installée ? L’utilisateur veut-il seulement préparer l’itinéraire ou le lancer ?

Cette page se concentre sur cette mécanique de sélection. Pour le vocabulaire général des couches FoneClaw, notre guide Outils, Plugins, Skills et Workflows FoneClaw : choisir la bonne couche reste la meilleure entrée. Ici, nous suivons une demande jusqu’à la capacité choisie, l’approbation, l’exécution et la reprise.

Choisir AutoAttach, Suggest ou Fallback

Dans un agent Android, le routeur doit décider comment utiliser les candidats. Trois chemins reviennent souvent : AutoAttach, Suggest et Fallback. Ils ne sont pas des niveaux de permission. Ils décrivent la manière de rattacher ou de présenter une capacité avant une action éventuelle.

AutoAttach convient à notre exemple si l’écran montre déjà un événement de calendrier avec une adresse claire. L’agent peut rattacher ce contexte à la demande sans demander à l’utilisateur de redécrire le lieu. La capacité reste seulement mieux informée. Si l’étape suivante consiste à lancer une navigation, l’action doit encore passer par le chemin Android pris en charge et, selon le risque, par une confirmation.

Suggest devient préférable quand deux capacités ont du sens. Si l’utilisateur demande « organise cette demande en tâche », FoneClaw peut proposer de créer une note, une tâche ou un événement selon le contexte. La suggestion donne un choix lisible au lieu de décider trop tôt. C’est utile quand un faux positif ferait perdre du temps ou toucherait une mauvaise app.

Fallback protège les cas où le routeur n’a pas assez de confiance. Si le calendrier n’est pas autorisé, si l’adresse est absente, si aucune app de carte n’est disponible ou si plusieurs contacts portent le même nom, la bonne réponse n’est pas une boucle d’essais autonomes. L’agent doit expliquer le blocage, demander une précision ou proposer une route plus sûre. Pour relier confiance et décision utilisateur, notre guide Interface d’approbation des agents IA sur téléphone : confiance, contexte et reprise approfondit la présentation de ces choix.

Séparer découverte, activation et exécution

Le routage contextuel devient dangereux quand les états sont mélangés. Découvrir une capacité ne signifie pas l’installer. L’attacher au contexte ne signifie pas l’activer. L’activer ne signifie pas que chaque action future est approuvée. Approuver une action ne signifie pas que le résultat est déjà vérifié. Un routeur fiable garde ces transitions explicites.

Les signaux de l’écosystème vont dans cette direction. Google décrit Agent Plugins comme une spécification ouverte pour empaqueter des Skills et des serveurs MCP. Cette forme de packaging aide les agents à comprendre ce qui existe, mais elle ne rend pas une extension automatiquement fiable, installée ou exécutable. De même, Agent finder de GitHub classe des ressources pertinentes à la demande tout en respectant les registres et réglages configurés ; la découverte reste séparée de l’installation.

Cette distinction est encore plus importante sur téléphone. Une capacité peut toucher les contacts, les messages, les fichiers, la localisation, le calendrier ou les réglages système. Le routeur peut proposer la bonne capacité, mais Android et l’utilisateur gardent leur rôle au moment d’agir. Pour le volet registre, confiance et découverte de ressources, notre article Agentic Resource Discovery : ai-catalog.json, registres et confiance pour agents mobiles traite le sujet plus largement.

Utiliser les signaux de routage sans excès

Un routeur de capacités a besoin de signaux structurés. L’identité de la capacité dit ce qu’elle prétend faire. Le manifeste décrit son nom, ses entrées, ses sorties, son périmètre et parfois ses dépendances. Les métadonnées de contexte indiquent si la capacité est pertinente pour l’écran actuel, l’app ouverte, la langue de l’utilisateur ou le type de tâche. Le score de confiance aide à décider entre AutoAttach, Suggest et Fallback.

Ces signaux sont utiles, mais aucun ne suffit seul. Une dépendance doit être résolue avant activation. Une capacité dont le manifeste semble correct peut rester inadaptée si l’app cible n’est pas installée. Une Skill importée peut aider à formaliser un parcours, mais elle doit être présentée, prévisualisée et confirmée dans un cycle gouverné. Un Plugin découvert dans un registre n’est pas prêt à toucher le téléphone tant que son activation n’a pas été revue.

Nous concevons aussi le routeur pour éviter les états partiels. Si une actualisation de capacités échoue, l’agent doit garder le dernier état accepté plutôt que de travailler avec une moitié de catalogue. Cette logique d’instantané cohérent évite les situations où le modèle croit qu’une capacité existe alors que son outil, sa dépendance ou sa permission n’est plus disponible.

Le contexte ne doit pas devenir une excuse pour tout joindre. Si la demande concerne une adresse visible, il peut être pertinent d’attacher l’écran actuel. Si la demande concerne un message, le routeur doit éviter d’élargir inutilement aux contacts, au calendrier ou aux fichiers. La sélection contextuelle de capacités doit rester minimale, traçable et proportionnée à la tâche.

Pour les risques propres aux Skills et aux permissions mobiles, notre page Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action détaille pourquoi l’évaluation doit continuer jusqu’au moment exact de l’action.

Reprendre après un mauvais routage

Un bon routeur n’est pas celui qui prétend ne jamais échouer. C’est celui qui sait quoi faire quand une capacité manque, devient obsolète, est refusée ou reste ambiguë. Le Fallback n’est pas une sortie honteuse ; c’est une partie normale de la fiabilité.

Si la capacité manque, l’agent doit le dire clairement et proposer une alternative prise en charge : recherche Web, ouverture manuelle de l’app, création d’une note de préparation ou demande de précision. Si une dépendance est périmée, il doit éviter d’activer un chemin partiel et demander une mise à jour ou une revue. Si une permission Android est refusée, il doit expliquer quelle permission bloque l’action et continuer seulement après le choix de l’utilisateur.

Les ambiguïtés sont plus fréquentes qu’on ne le croit. « Envoie le fichier à Marie » peut désigner plusieurs fichiers ou plusieurs contacts. « Prépare l’itinéraire » peut vouloir dire afficher une carte, lancer la navigation ou simplement copier une adresse. Dans ces cas, un routeur sérieux préfère Suggest ou Fallback à une exécution précipitée.

La reprise se distingue aussi d’un simple retry du modèle. Relancer le même prompt peut aider si le modèle a mal compris. Cela ne résout pas une permission absente, une app fermée, une dépendance non activée ou une cible ambiguë. FoneClaw traite ces cas comme des états de téléphone et de produit, pas seulement comme des erreurs de texte. La tâche doit rester continue : l’utilisateur voit ce qui bloque, choisit la suite, puis l’agent reprend à partir d’un état connu.

Le routage gouverné dans FoneClaw

Dans FoneClaw, nous appliquons le routage d’outils Android à partir de la demande réelle. L’utilisateur peut écrire ou dicter une intention, joindre le contexte de l’écran quand c’est utile, puis laisser l’agent classer les capacités candidates. FoneClaw dispose de 100+ built-in tools pour les actions Android prises en charge, et peut aussi travailler avec des Skills, des Workflows et des Plugins dans des états gouvernés.

AutoAttach sert à enrichir le raisonnement quand le contexte est fortement pertinent. Par exemple, si l’utilisateur demande « résume cet écran et prépare une réponse », le contexte de l’écran peut être joint à la demande. Suggest intervient quand plusieurs chemins sont possibles : créer une note, préparer un message, ouvrir une app ou enregistrer un Workflow. Fallback prend le relais quand la capacité n’existe pas, manque de confiance, demande une activation ou rencontre une permission absente.

Le point produit important est simple : le routage n’exécute pas automatiquement une action sensible. Il ne contourne pas les approbations. Il ne transforme pas une proposition de Plugin en installation silencieuse. L’activation d’un Plugin passe par une revue, et l’apprentissage d’une Skill utilise une prévisualisation et une confirmation avant de sauvegarder un brouillon désactivé. Cette séparation permet d’explorer des capacités sans perdre le contrôle de ce qui agit réellement sur Android.

Quand une capacité est prête, FoneClaw passe à l’action gouvernée : vérifier l’état du téléphone, préparer les arguments, présenter l’approbation si nécessaire, exécuter l’outil pris en charge, puis montrer le résultat. Si l’action ne peut pas continuer, la récupération de permission et la continuité de tâche aident l’utilisateur à reprendre sans recommencer depuis zéro.

Nous construisons cette mécanique parce qu’un agent mobile utile ne doit pas seulement trouver une capacité. Il doit savoir quand la joindre, quand la proposer, quand s’arrêter, quand demander l’accord et quand récupérer. C’est la différence entre une sélection contextuelle de capacités et une automatisation opaque.

Sept tests pour un routeur fiable

Pour concevoir ou évaluer un routeur de capacités, testez autant les faux positifs que les bonnes correspondances. Un routeur qui trouve toujours quelque chose peut être plus dangereux qu’un routeur prudent.

• Candidat : la capacité classée répond-elle vraiment à la demande et à l’app cible ?
• Contexte : AutoAttach joint-il seulement les éléments nécessaires ?
• Suggestion : Suggest présente-t-il un choix compréhensible quand plusieurs routes sont plausibles ?
• No-match : Fallback apparaît-il quand aucune capacité n’est assez fiable ?
• Dépendance : l’activation vérifie-t-elle les dépendances avant de rendre la capacité utilisable ?
• Approbation : l’exécution sensible reste-t-elle visible et confirmée ?
• Reprise : le système explique-t-il les permissions, ambiguïtés et états manquants sans boucle infinie ?

Le meilleur essai est une paire de demandes. D’abord une demande claire, comme « crée une note de test avec ce texte ». Ensuite une demande volontairement ambiguë, comme « envoie ça à Marie ». La première vérifie le chemin nominal ; la seconde révèle les faux attachements, les suggestions utiles et la qualité du Fallback. Un routeur mature réussit les deux : il agit quand le chemin est clair et ralentit quand le téléphone a besoin d’une décision humaine.