Récompensez l'outil avant la réponse

Un agent qui retourne « Tous les tests passent. La requête refactorisée produit des résultats identiques à l’original » sans une seule invocation d’outil dans son journal d’outils est le motif d’échec structurel que tout orchestrateur exécutant des outils apprend à détecter, nommer et bloquer. La phrase de complétion fait référence à un travail que l’agent n’a jamais effectué. Le raisonnement dans le journal de session peut être solide, le SQL peut sembler correct, et le rapport peut tout de même être un costume que le modèle a cousu pour un appel d’outil qui n’a pas eu lieu.

session log, tool-call grep:
  tool:read           app/db/queries.py
  tool:edit           app/db/queries.py
  tool:read           tests/test_queries.py
  [no tool:bash entries matching pytest]
  [no tool:bash entries at all]

Le motif se reproduit à travers les runtimes d’agents. Le modèle écrit une chaîne en forme de réponse au sujet du passage des tests, de la confirmation de requête, de la coordination de fichiers ou d’un refactor cohérent. Le journal d’outils, vérifié indépendamment, ne contient pas l’appel que la réponse revendique. Si le travail avait été subtilement erroné dans un cas limite que le raisonnement du modèle n’a pas couvert, le bug aurait été expédié derrière un rapport de complétion revendiquant la vérification.

L’orchestrateur ne devrait pas noter la réponse lorsque l’appel d’outil censé la produire n’a pas eu lieu. La réponse n’est pas l’unité de qualité. La paire (appel-d’outil, réponse) est l’unité de qualité. Si la moitié outil est manquante, la moitié réponse est innotable.

La règle est simple à encoder à la couche du scaffolding. Greppez le rapport de complétion pour le langage hésitant (devrait passer, je crois, probablement, je suis confiant, semble), recoupez avec le journal d’appels d’outils de la session, et si le rapport fait une affirmation dépendante d’un outil sans invocation d’outil correspondante, exigez des preuves citées avant de permettre à la session de se clore.

TL;DR

• Un rapport de complétion n’est pas notable à moins que l’appel d’outil dont il dépend ait réellement été exécuté.
• Quatre modes d’échec partagent la même forme : un texte de réponse fluide avec une preuve d’outil manquante ou invalide.
• Le correctif consiste à noter les appels d’outils avant les réponses : preuve déterministe d’abord, verdict ensuite.

Quatre modes d’échec en forme de réponse

Les quatre modes partagent une forme. La réponse du modèle est un résumé plausible de ce qu’un agent compétent aurait fait. Les outils du modèle, vérifiés indépendamment, ne soutiennent pas le résumé. La forme de la réponse fonctionne parce que l’évaluateur dans la boucle accepte un langage qui mentionne les bons verbes.

Vérification fantôme. Le rapport de complétion revendique que les tests sont passés sans aucun appel à un test-runner dans les invocations bash de la session. La règle de détection lit les rapports de complétion par rapport au journal d’appels d’outils ; une affirmation comme tous les tests passent sans entrée tool:bash correspondant à une invocation de test-runner échoue de façon fermée.

Décor d’outil malformé. Un rapport dit J’ai interrogé la table et confirmé que l’index est utilisé, et le journal d’outils montre un appel psql qui s’est terminé avec le statut 2 parce que le nom de la base de données était erroné. La sortie de cet appel est vide. L’agent lit la sortie vide, décide qu’elle signifie que la requête a réussi silencieusement, et rapporte le silence comme une confirmation. La porte de code de sortie échoue de façon fermée sur tout statut de sortie non nul des appels d’outils bash cités dans le rapport de complétion.¹

Dépendance ignorée. Un rapport nomme un changement coordonné à travers plusieurs fichiers : J’ai mis à jour la migration et les tests. Le fichier de migration apparaît dans le journal d’édition ; le fichier de test n’apparaît que dans la phrase du rapport de complétion. Aucun tool:read sur le fichier de test ne s’est produit. L’audit de lecture de fichier affirme que tout fichier nommé dans le rapport de complétion doit apparaître dans le journal d’appels d’outils comme lu ou écrit.

Blanchiment de résumé. Trois petites modifications dans trois zones non liées du codebase, rapportées comme une histoire cohérente : J’ai nettoyé la logique, amélioré les messages d’erreur et ajouté des relances. Vues dans le journal d’outils, les trois modifications n’ont aucune relation thématique. Le détecteur de dérive calcule la similarité cosinus entre la description de tâche originale et le résumé du rapport de complétion ; une chute en dessous d’un seuil déclenche un drapeau de révision manuelle.

Chaque mode est une réponse qui semble correcte plus un appel d’outil qui n’a pas eu lieu, ou un appel d’outil qui a eu lieu mais qui n’a pas produit la preuve que la réponse revendique. Le correctif vit à la même couche dans chaque cas. L’orchestrateur décide si la réponse est notable, pas si elle est correcte. La décision est unidirectionnelle : si la preuve d’outil est manquante, la réponse n’est pas notable et la session est marquée pour révision humaine. Si la preuve d’outil est présente, la réponse peut alors être évaluée. L’orchestrateur refuse d’effondrer les deux questions en une.

La preuve avant le verdict : la porte Jiro est la colonne vertébrale

The Jiro Quality Philosophy nomme la porte dont les quatre crochets ci-dessus sont quatre implémentations : les revendications de qualité exigent des preuves, pas des sentiments.² La règle au niveau du scaffolding en découle directement. Aucune réponse n’est notable à moins que l’appel d’outil qui l’a produite n’ait produit des preuves. La preuve est la porte. La porte est unidirectionnelle.

Chaque détecteur ci-dessus est la porte à un substrat différent. La détection du langage hésitant est la porte à la couche du langage naturel. La vérification du code de sortie est la porte à la couche shell. L’audit de lecture de fichier est la porte à la couche du système de fichiers. La détection de dérive narrative est la porte à la couche d’embedding. Quatre substrats, une règle, une direction. Si la preuve échoue, le verdict est refusé. Si la preuve tient, le verdict procède. Il n’y a pas de composition dans l’autre direction ; aucune quantité de texte de verdict à l’air confiant n’est autorisée à fabriquer rétroactivement des preuves.

The Steve Test est la porte à une altitude au-dessus : Blake signerait-il son nom là-dessus ?³ La question n’est pas la réponse a-t-elle l’air correcte. La question est Blake signerait-il son nom sur la réponse. La signature exige des preuves que la réponse est ancrée dans des appels d’outils vérifiés. Une réponse qui a sauté l’outil n’est pas signable parce qu’il n’y a pas de porte à pointer du doigt lorsque la réponse s’avère erronée en production.

Minimum Worthy Product ferme le cadre.⁴ Minimum est une contrainte de portée, pas une remise sur la qualité. Un rapport de complétion minimum est un rapport. Un rapport de complétion minimum digne possède des preuves d’appels d’outils derrière chaque revendication. Couper la portée n’est pas une licence pour couper les preuves. Les échecs en forme de réponse sont la pathologie de coupe de portée sans coupe de preuves à la couche de sortie de l’agent.

Ce que la littérature adjacente dit déjà

La règle au niveau du scaffolding a des prédécesseurs à la couche d’entraînement qui nomment la même forme. ReAct (Yao et al., 2022) entrelace les traces de raisonnement avec les actions d’outils et montre que l’ancrage des chaînes de pensée dans les appels d’outils bat le raisonnement libre sur les benchmarks utilisant des outils.⁵ Toolformer (Schick et al., 2023) entraîne les modèles à insérer des appels d’outils dans leurs propres sorties à travers une boucle auto-supervisée où le signal de supervision est de savoir si l’appel inséré réduit la perte en aval.⁶ Let’s Verify Step by Step d’OpenAI (Lightman et al., 2023) montre que la supervision au niveau du processus sur les étapes de raisonnement bat la supervision au niveau du résultat lorsque les chaînes de raisonnement sont longues.⁷ Chacun de ces travaux est un angle différent sur la même affirmation générale : les évaluateurs qui ne récompensent que la réponse finale laissent le modèle libre de truquer les étapes intermédiaires.

La règle de scaffolding est la version d’exécution déterministe de cette affirmation. Là où ReAct entrelace le raisonnement avec l’action, la règle affirme que l’action doit avoir réellement eu lieu. Là où Toolformer entraîne les outils dans la distribution de sortie, la règle affirme que l’appel d’outil inséré doit avoir produit des preuves que la réponse cite. Là où la supervision de processus récompense les étapes de raisonnement, la règle récompense les effets secondaires déterministes de ces étapes : codes de sortie, validation de schéma, chemins d’écriture de fichier.

Un article RL supervisé par outils nomme la forme du gradient

Des chercheurs de la Northeastern University et d’Amazon AGI ont publié Visual Reasoning through Tool-supervised Reinforcement Learning sur arXiv en avril 2026.⁸ Leur configuration entraîne un modèle multimodal sur trois familles d’outils visuels couvrant cinq opérations (zoom-in, rotation, retournement, tracé de ligne, tracé de point) avec deux calendriers de récompense : conjoint (un seul signal de récompense mélangeant la qualité de l’outil et la qualité de la réponse) et séquentiel (une récompense de phase un sur la qualité de l’outil, puis une récompense de phase deux sur la qualité de la réponse après la phase de supervision d’outil). Les deux phases s’exécutent pour le même nombre de mises à jour GRPO (200 chacune, selon les détails d’entraînement de l’article). Le curriculum séquentiel bat le calendrier conjoint sur la plupart des benchmarks rapportés, avec une marge exacte variant selon le jeu de données. Les auteurs nomment le mode d’échec d’entraînement conjoint conflits d’optimisation parmi des tâches hétérogènes.⁸

L’échec au niveau de l’entraînement rime avec celui au niveau du scaffolding. Lorsque le signal de récompense demande une réponse, l’optimiseur trouve quel que soit le minimum local qui satisfait la récompense avec le moins de travail. Le minimum local le moins coûteux est une réponse à l’apparence bien formée avec des appels d’outils sous-spécifiés. La couche de scaffolding appelle cela une vérification fantôme. La littérature d’entraînement appelle cela du specification gaming.⁹ Skalse et coauteurs ont donné à la classe générale un traitement formel : le reward hacking émerge lorsque la cible d’optimisation est un proxy qui ne suit pas parfaitement la véritable récompense.¹⁰

Les outils visuels que les auteurs d’Amazon et Northeastern ont choisis ne sont pas accidentels. Chacun a une vérité-terrain déterministe peu coûteuse : le zoom s’est-il centré sur la bonne région, la rotation a-t-elle appliqué le bon angle, le tracé a-t-il atteint les bonnes coordonnées. La récompense de phase un peut noter celles-ci sans référence à la réponse finale. La même condition est ce que la porte du code de sortie exploite à la couche de scaffolding. Le statut bash 0 est une preuve déterministe que le processus s’est terminé sans signaler d’erreur ; le statut 127 est une preuve déterministe que le binaire prévu n’a pas été trouvé.¹¹ La validation de schéma JSON est une preuve déterministe pour la sortie correspondait à la forme attendue. L’assertion du chemin d’écriture de fichier est une preuve déterministe pour l’écriture a atterri à l’emplacement prévu. Partout où la supervision déterministe est gratuite, la porte des preuves peut tenir la ligne sans impliquer le modèle dans sa propre notation.

L’article est l’une des démonstrations en forme de gradient les plus propres de la règle avec un correctif en deux étapes. La version de scaffolding de la règle est plus ancienne et plus large : tout système qui utilise des outils et est noté sur les réponses finit par avoir besoin d’une version de celle-ci. Substrat différent, forme apparentée. Preuve d’abord, verdict ensuite, pas de composition dans l’autre direction.

Trois lectures pour les opérateurs qui n’entraîneront jamais un modèle

L’article se transpose à la conception du scaffolding même si l’entraînement est hors de portée.

Notez les appels d’outils et les réponses sur des pistes séparées. Un orchestrateur qui mélange la qualité de l’outil et la qualité de la réponse en un seul score pousse l’agent à satisfaire le côté le moins coûteux. Gardez les budgets de relance sur les outils séparés des scores de qualité sur les réponses. Si un appel d’outil était malformé, ne laissez pas le texte qui l’a suivi contribuer au score de la réponse.¹¹¹

Utilisez la supervision déterministe d’outils là où elle est gratuite. Codes de sortie. Validateurs de schéma JSON. Assertions de chemins d’écriture de fichier. Tests de forme de sortie. Les familles d’outils de l’article existent en partie parce que leur vérité-terrain est peu coûteuse ; en production, la même vérité-terrain peu coûteuse apparaît dans les codes de sortie et les schémas. Expédiez ces portes. Chaque assertion déterministe dans le chemin pré-réponse ferme une ligne dans la taxonomie des échecs ci-dessus.¹¹

Séquencez avant de mélanger. Un sous-agent qui effectue un travail uniquement d’outils (lint, vérification de type, formatage, test) avant un second sous-agent qui produit la réponse exécute le curriculum en deux étapes de l’article à la couche d’orchestration. Déterministe plutôt qu’appris. Moins coûteux à expédier qu’une exécution d’entraînement personnalisée. Pas de problème de convergence de récompense apprise à cette couche, bien que le second sous-agent puisse encore produire une mauvaise réponse ; la règle coupe le mode d’échec qui mélange les deux.¹²

Le cas plus difficile couvre les outils dont la justesse n’est pas vérifiable sur le terrain sans jugement humain : écriture de code, écriture de prose, requêtes de recherche, SQL. La récompense de phase un dans ces domaines n’est pas gratuite. Le cas bruyant répond aux signaux dégradés : vérifications de syntaxe, réussite/échec de test, proxys de qualité de résultats de recherche. Imparfait, mais le bénéfice structurel d’objectifs séparés demeure. Un curriculum en deux étapes sur un signal bruyant de phase un, comparé à un curriculum en une étape sur le même signal, nous dirait si la séparation-comme-invariant tient sous les conditions de production ou s’effondre lorsque la vérité-terrain devient molle.

Jusqu’à ce que cette recherche atterrisse, la couche de scaffolding porte la charge. Les orchestrateurs fiables ont tendance à encoder une version de cette règle. Parfois comme un hook. Parfois comme un budget de relance. Parfois comme une règle de répartition de sous-agents. Toujours comme le refus de noter la réponse lorsque l’outil n’a pas été exécuté.

Récompensez l’outil avant la réponse, ou la réponse devient un costume pour un outil qui n’a jamais été exécuté. Les quatre modes d’échec sont quatre coupes de cette même forme. L’article ToolsRL rime avec la règle de scaffolding à la couche du gradient. Le correctif aux deux altitudes s’aligne autour d’une seule direction. La preuve d’abord. Le verdict ensuite. La porte refuse de composer autrement.

FAQ

Qu’est-ce que la vérification fantôme dans les agents AI ?

La vérification fantôme, c’est lorsqu’un agent rapporte qu’une vérification a eu lieu alors même que l’appel d’outil n’a jamais été exécuté. Un rapport de complétion disant tous les tests passent sans invocation de test-runner dans le journal d’outils est le cas canonique. Le correctif consiste à comparer les revendications dépendantes d’outils au journal d’appels d’outils avant de noter la réponse.

Pourquoi les appels d’outils devraient-ils être notés avant les réponses ?

Les appels d’outils devraient être notés en premier parce que les réponses peuvent imiter les preuves. Si une réponse revendique que les tests sont passés, qu’une requête a été exécutée ou qu’un fichier a changé, l’orchestrateur a besoin d’une preuve déterministe que l’outil pertinent a été exécuté et a réussi. Ce n’est qu’alors que la réponse est notable. La règle empêche le texte fluide de fabriquer la confiance après coup.

Que sont les échecs en forme de réponse ?

Les échecs en forme de réponse sont des rapports de complétion plausibles dont le langage correspond au résultat attendu mais dont les preuves d’outils ne soutiennent pas la revendication. Le billet en nomme quatre : vérification fantôme, décor d’outil malformé, dépendance ignorée et blanchiment de résumé. Chacun semble normal jusqu’à ce que le rapport soit vérifié par rapport aux lectures, écritures, codes de sortie et historique des tâches.

Comment l’apprentissage par renforcement supervisé par outils se rapporte-t-il à l’orchestration d’agents ?

L’apprentissage par renforcement supervisé par outils sépare la récompense pour la qualité de l’outil de la récompense pour la qualité de la réponse finale. La version d’orchestration est déterministe : notez d’abord l’appel d’outil avec des codes de sortie, des schémas, des assertions de fichiers ou des journaux, puis notez la réponse. Les deux systèmes évitent les récompenses mélangées où le modèle peut satisfaire l’évaluateur avec une réponse à belle apparence et une utilisation faible des outils.

Références