Pourquoi un serveur d’agents devrait demander la progression aux outils

Le cache attend pendant l’outil

Un agent de code peut passer une grande partie de son temps à attendre une installation, une compilation, une suite de tests ou un script généré. Pendant cette attente, le cache KV du contexte reste associé à la requête et occupe de la mémoire GPU. Le serveur doit décider s’il le conserve, le déplace vers la mémoire CPU ou le reconstruit plus tard. L’article de Yipeng Liu et ses coauteurs soutient que cette décision ne devrait pas reposer principalement sur une estimation faite avant le début de l’appel.

Le nom d’un outil, ses arguments ou sa durée habituelle ne disent pas combien de temps prendra cette invocation précise. La contention de la machine, les index de paquets, les object stores, les API et les quotas externes changent avec l’environnement. L’outil en cours d’exécution détient souvent une information meilleure, mais la pile agentique la masque ou la détruit.

Les appels longs dominent le temps

Dans les exécutions de mini-SWE-agent étudiées, moins de 3 % des appels d’outils concentrent près des deux tiers du temps d’outil. Il s’agit typiquement des installations, compilations, tests et scripts générés. Pour les appels très courts, presque toute politique de cache donne un résultat acceptable. Pour les appels longs, la décision de rétention est au contraire coûteuse et mérite un signal propre.

Les auteurs rejouent des commandes issues de runs de benchmark sur un sandbox inactif. Une même commande peut finir un ordre de grandeur plus vite qu’en production. Limiter le quota CPU change parfois peu la situation, tandis que l’ajout de voisins occupés ralentit beaucoup d’appels. Le rang des durées observées sous charge n’est pas conservé sur une machine au repos. Une moyenne historique ne suffit donc pas à ordonner les appels futurs.

Ce que les outils cachent déjà

Le système d’exécution retire souvent les barres de progression pour simplifier la sortie. L’agent peut ensuite ajouter une seconde couche de silence en utilisant tail, une redirection vers un fichier ou une option silencieuse. Les totaux disparaissent, les compteurs s’arrêtent, les sorties sont tamponnées et certains appels ne parlent qu’après une option verbose.

Le papier distingue des signaux forts et faibles. Un signal fort indique une fraction ou un compte restant : une suite de tests donne une progression, une installation nomme les paquets, ou un build énumère les fichiers. Un signal faible indique surtout que la fin approche : dernière phase d’une compilation, dernière étape d’un téléchargement ou limite d’un timeout. Les deux peuvent être utiles au scheduler, même si le second ne permet pas d’estimer tout le temps restant.

Dans trois corpus publics d’appels d’outils, les instruments des auteurs récupèrent un signal fort sur 38 %, 51 % et 48 % du temps d’outil selon le corpus. En ajoutant les signaux faibles, la couverture monte à 66 %, 59 % et 72 %. Ces proportions décrivent le temps d’outil, pas le nombre d’appels ; quelques appels longs pèsent donc beaucoup dans le résultat.

Une voie latérale sans changer ce que voit l’agent

La proposition architecturale repose sur deux chemins. Le chemin de résultat continue à transmettre à l’agent exactement la sortie et le code de retour qu’il aurait reçus. Un chemin d’état séparé envoie au serveur des événements horodatés, des compteurs, des totaux et des marqueurs de phase.

Avant l’appel, le harnais enregistre un identifiant et prépare éventuellement une option verbose, un dry-run pour connaître un total ou une instrumentation du script. Pendant l’exécution, un tap lit la sortie ou sa copie latérale ainsi que les fichiers produits. Quand l’outil termine, la sortie originale revient à l’agent dans son format initial. L’objectif est de donner au serveur une information de planification sans modifier l’observation qui guide le modèle.

Pour un script généré par l’agent, le papier propose d’ajouter une ligne de progression dans la voie latérale, puis de vérifier l’équivalence de son comportement. Pour un build qui n’annonce qu’un compteur sans total, un dry-run peut fournir le dénominateur. Pour une installation qui annonce sa dernière phase, un signal de fin proche peut suffire à commencer la restauration du cache.

Le gain sur la reprise

Le système est évalué sur quatre corpus publics et dans un moteur de production. Le résumé rapporte que le harnais récupère les signaux sans modifier le score de benchmark de l’agent et que, aux moments où une décision de cache est prise, le signal de progression est plusieurs fois à un ordre de grandeur plus précis que les meilleurs prédicteurs publiés. Il reste aussi précis lorsque l’environnement change.

Branché au moteur avec quelques indications, le système réduit le temps p90 jusqu’au premier token après un appel d’outil de 20,7 % avec une politique HBM seule et de 20,8 % avec HBM plus DRAM, par rapport à LRU. Le résultat est proche d’un oracle. Il ne signifie pas que toute commande devient plus rapide : le gain concerne la reprise du contexte et l’ordonnancement de la mémoire après l’attente.

Ce que le serveur doit vérifier

Un signal de progression peut être faux ou incomplet. Le papier inclut donc un cas où le rapporteur ment. Une plateforme ne devrait pas déplacer aveuglément un cache sur la base d’un compteur fourni par un outil non fiable. Elle peut comparer le signal à l’horloge, aux fichiers produits, au code de retour et aux phases déjà observées. Un signal faible est parfois meilleur qu’une fausse fraction précise.

La voie latérale doit aussi respecter les frontières de confidentialité. Les événements de progression peuvent contenir des noms de fichiers, des commandes, des chemins ou des informations sur les fournisseurs externes. Il faut choisir un schéma minimal, associer les événements à un call ID stable et contrôler leur durée de conservation. Le papier étudie l’efficacité du signal ; l’intégration produit doit ajouter ses propres garanties d’isolation et d’audit.

Implications pour un SaaS d’agents

Pour un SaaS d’agents, le point intéressant est le découplage entre résultat et état. Le modèle n’a pas besoin de voir toutes les métriques de l’ordonnanceur. Le serveur, lui, n’a pas besoin de deviner le travail restant à partir du nom de l’outil. Cette séparation peut réduire la pression qui pousse à injecter des messages de monitoring dans le contexte du modèle.

Elle impose en revanche une interface de progression commune. Les outils devraient pouvoir signaler une fraction, une phase, une échéance ou l’absence de signal. Les appels non parsables, les API distantes et les attentes humaines restent une frontière explicite. Les classer comme inconnus est préférable à inventer une durée et à présenter cette estimation comme un fait.

Limites et statut de la source

Les proportions dépendent des corpus d’agents, des outils et des instruments choisis. Une meilleure observabilité ne résout pas la latence du fournisseur, ne garantit pas que l’outil expose une progression fiable et n’élimine pas les appels non parsables. Le gain de 20,7–20,8 % concerne le moteur et les conditions expérimentales rapportées, pas une promesse pour chaque infrastructure.

Le texte est un preprint ArXiv, donc pas nécessairement évalué par les pairs. Il constitue une proposition d’architecture et une évaluation de système, non une norme d’API ou une garantie de performance universelle.

Sources

Yipeng Liu, Yingqiang Zhang, Feifei Li et Huanchen Zhang, « Ask the Tool, Don't Guess: Agent Tool Calls Hold Their Progress, and the Serving System Should Read It », ArXiv 2609.18849v1 : preprint, PDF.