Pourquoi la mémoire de travail de votre agent d'IA échoue dans les tâches longues

Lorsqu'on demande à un agent d'IA d'ouvrir un tableur, d'extraire des données, de mettre à jour un graphique et d'envoyer le résultat par e-mail, l'approche typique consiste à lui fournir un journal croissant de captures d'écran, de clics de souris et de réponses système. À mesure que la tâche s'étend sur des dizaines d'étapes, cet historique brut se transforme en marécage. Les informations critiques, un chemin de fichier, une modification vérifiée, une URL, se retrouvent enterrées sous des tentatives échouées et des observations obsolètes.

C'est le problème que des chercheurs de l'UC San Diego et de l'Aether AI Lab ont entrepris de résoudre avec StructAgent, un cadre dont l'idée centrale semble presque paradoxale : pour rendre les agents plus fiables sur les tâches longues, donnez-leur moins de contexte. Mais le contexte qu'ils conservent doit être structuré, vérifié et lié de manière causale à ce qui fait réellement avancer la tâche.

Dans des expériences rapportées dans un nouvel article, StructAgent a amélioré le taux de réussite d'un modèle de 9 milliards de paramètres de 27,0 % à 46,9 % sur OSWorld-Verified, un benchmark pour l'utilisation d'ordinateurs à long horizon. Avec un modèle plus puissant de 27 milliards de paramètres, il est passé de 31,6 % à 62,2 %. En utilisant le modèle MiniMax-M3, il a atteint 78,9 %, un nouvel état de l'art pour les méthodes open-source sur ce benchmark.

Les auteurs citent Edsger Dijkstra : « Le but de l'abstraction n'est pas d'être vague, mais de créer un nouveau niveau sémantique où l'on peut être absolument précis. » L'article se lit comme un long argument en faveur de ce principe appliqué à la conception d'agents.

Le problème de l'historique brut

Les agents numériques actuels, qu'ils soient alimentés par des LLM ou des VLM, consomment généralement l'historique des interactions sous forme de séquence plate : captures d'écran, arbres d'accessibilité, sorties d'actions. Au fil de nombreuses étapes, ce contexte s'élargit pour inclure des modifications intermédiaires, des tentatives échouées et des achèvements partiels. L'agent n'a aucun moyen structuré de séparer ce qui compte de ce qui ne compte pas.

StructAgent remplace cela par un état unifié contenant trois composants typés : les exigences actuelles, les valeurs utiles (chemins de fichiers, URL, données extraites) et les preuves vérifiées. Plutôt que d'inférer la progression à partir d'un journal croissant, chaque module, planificateur, acteur, vérificateur, lit et écrit dans cet état partagé. La règle critique est qu'aucune progression ne peut être validée sans une décision étayée par le vérificateur.

Comment ça fonctionne

Le cadre exécute une boucle. Le planificateur lit l'état actuel et sélectionne un sous-objectif. L'acteur tente d'atteindre ce sous-objectif dans l'environnement. Le vérificateur vérifie si une progression valide a été réalisée. Ce n'est que si le vérificateur trouve des preuves que l'état est mis à jour. C'est plus strict que les approches où l'acteur déclare lui-même l'achèvement, ou où un juge final ne vérifie que la capture d'écran finale.

Le vérificateur utilise un sondage structuré : il peut vérifier les fichiers sur le disque, les sorties de commandes, les URL, les arbres d'accessibilité, pas seulement l'écran. Dans une tâche multi-applications, par exemple, l'acteur peut sembler exporter une image d'un document, mais le vérificateur peut vérifier le système de fichiers pour le fichier réellement exporté. Si le fichier est manquant, le sous-objectif reste en attente, bloquant un achèvement erroné.

Cette discipline permet plusieurs capacités : le point de contrôle de la progression (l'état lui-même est un point de reprise), la récupération ciblée des échecs (le vérificateur diagnostique si un échec est dû à un manque de preuves, à une exigence conflictuelle ou à un bloqueur environnemental), et l'exécution assistée par des outils (des procédures réutilisables qui nécessitent toujours des validations par le vérificateur).

Les chiffres

Les expériences contrôlées sur OSWorld-Verified utilisent un budget de 100 étapes et un pipeline de notation commun. Les résultats montrent que StructAgent améliore chaque backbone testé, avec les plus grands gains sur les modèles les plus faibles. L'implication est que le cadre compense la capacité limitée d'un modèle à extraire des signaux de l'historique brut.

Les applications bureautiques (tableurs, documents) connaissent les améliorations les plus nettes, probablement parce que ces environnements exposent des états intermédiaires durables comme les valeurs de cellules et les contenus de fichiers. Les tâches inter-applications restent le paramètre le plus difficile. Même avec le backbone le plus puissant, les performances sur les scénarios multi-applications sont en retard par rapport aux domaines plus simples. La surface de preuve du vérificateur est moins fiable à travers les frontières applicatives.

Le cadre se généralise au-delà des environnements de bureau. Dans Minecraft, StructAgent a remplacé les sources de preuves de bureau par des vérifications basées sur l'inventaire. Il a atteint un taux de réussite moyen pondéré par les tâches de 76 % sur cinq niveaux d'outils, contre 59 % pour la référence publiée Optimus-1. Les plus grands gains sont sur les niveaux Fer et Or, où les longues chaînes de dépendances rendent le suivi vérifié des sous-objectifs particulièrement utile.

Pourquoi c'est important

StructAgent arrive à un moment où l'industrie de l'IA pousse fortement vers les systèmes agentiques, des modèles capables d'agir de manière autonome sur de longues périodes. Mais des benchmarks comme OSWorld-Verified montrent que même les meilleurs modèles échouent sur des tâches longues. L'article présente le problème comme un problème de conception d'agent, pas seulement un problème de mise à l'échelle du modèle. Son approche repense la vérification, passant d'une porte finale à un mécanisme d'engagement continu.

L'analyse des échecs des trajectoires de score zéro est révélatrice, même pour StructAgent lui-même. Les échecs de l'acteur représentaient 33 % des cas, mais les échecs du planificateur et du vérificateur représentaient chacun 30 %. Aucun module n'explique tous les échecs, ce que les auteurs soutiennent comme une vision systémique : la fiabilité à long horizon nécessite une meilleure conception des preuves, un meilleur entraînement du vérificateur et un support d'exécution adapté au domaine.

L'article montre également que la vérification structurée bat la vérification uniquement visuelle. Lorsque les vérificateurs structuré et visuel étaient en désaccord, dans 100 cas intermédiaires examinés manuellement, le vérificateur structuré était correct 63 % du temps, contre 31 % pour le vérificateur uniquement visuel. L'avantage venait des preuves latentes : fichiers, sorties de commandes, URL qui ne sont pas visibles de manière fiable dans les captures d'écran.

Les questions ouvertes

Les gains de StructAgent sont les plus importants lorsque les environnements exposent un état vérifiable : fichiers, URL, structures de données accessibles. Dans les domaines purement visuels, certaines tâches de navigateur et applications riches en images, l'avantage diminue. L'article suggère des vérifications plus riches spécifiques aux applications et l'entraînement du vérificateur comme prochains goulots d'étranglement.

Une autre question ouverte est de savoir comment cette approche s'adapte à des tâches encore plus longues ou à des configurations multi-agents. L'abstraction d'état est conçue pour être partagée entre les modules, mais l'article ne teste pas de scénarios multi-agents. Les auteurs notent dans leur conclusion que le paradigme pourrait s'étendre aux agents web, aux agents incarnés et à la collaboration multi-agents, mais laissent la mise en œuvre comme un travail futur.

StructAgent n'échappe pas non plus au coût de la vérification. Chaque appel de vérificateur ajoute de la latence et de la puissance de calcul. Pour le budget de 100 étapes utilisé dans les expériences, ce surcoût est gérable, mais pour des tâches de plusieurs milliers d'étapes, le vérificateur lui-même devient un goulot d'étranglement.

Néanmoins, les résultats sont difficiles à ignorer. Un cadre qui élève un modèle de 9 milliards de paramètres de 27 % à 47 % sur un benchmark difficile, sans augmenter la taille du modèle, suggère que la manière dont un agent suit sa propre progression peut être aussi importante que la capacité brute du modèle. L'argument central de l'article, que l'exécution à long horizon a besoin d'une structure causale pour la progression, et pas seulement d'une fenêtre de contexte plus grande, est une question avec laquelle l'industrie devra probablement composer à mesure que les tâches agentiques s'allongent.

Le code et la page de projet de StructAgent sont disponibles publiquement. Les auteurs ont signalé que la conception centrée sur l'état ne se limite pas aux tâches de bureau, mais constitue un paradigme général pour créer des agents capables de suivre honnêtement ce qu'ils ont accompli et ce qu'ils n'ont pas accompli.