Voici la deuxième note d’une série sur la conception d’Agents pour les tâches de longue durée, née d’une lecture approfondie de BEACON (université du Zhejiang, arXiv:2605.06078).
La première note expliquait que la détection de boucles ne repère pas un Agent qui stagne : la répétition est un signal d’entrée, le progrès un signal de sortie. Cet argument suppose un repère auquel mesurer le progrès. C’est le sujet de cette note.
Poser la bonne question
La question n’est pas « comment l’Agent sait-il qu’il a terminé une étape ? », mais « comment le système sait-il qu’il l’a réellement terminée, plutôt que simplement annoncé ? ».
Une couche de différence, et une crédibilité incomparable.
Nous avions déjà les deux moitiés sans les avoir reliées
C’est ce qui nous a surpris en relisant notre implémentation.
Première moitié. Les jalons existent déjà dans le produit. Un outil maintient un plan de tâche durable : décomposition d’une tâche longue et état de chaque étape — en attente, en cours, terminée, bloquée. Son objectif déclaré est d’offrir un repère de progression stable. Mais comment une étape devient-elle « terminée » ? Le modèle le déclare.
Deuxième moitié. Après chaque appel d’outil, l’hôte enregistre des faits déterministes : l’empreinte du contenu d’un fichier a-t-elle vraiment changé, quel est le code de sortie d’une commande, a-t-elle dépassé le délai ? Ces faits sont consignés côté hôte et n’entrent jamais dans le contexte du modèle ; c’est précisément pourquoi ils ne peuvent pas être fabriqués.
La lacune est là. Une ligne dit j’ai terminé. L’autre dit l’empreinte d’un fichier est passée de A à B. Rien ne les a jamais confrontées.
Ce qui manque n’est ni une structure de données ni l’observabilité. C’est le lien entre les deux.
Le plus utile dans l’article n’est pas la formule
BEACON est surtout connu pour son avantage à deux échelles, mais la partie à reprendre est la place donnée au détecteur Φ.
Φ ne nécessite ni modèle entraîné ni annotation humaine. Il lit uniquement les changements d’état observables dans les retours de l’environnement : transitions d’objets dans ALFWorld — objet ramassé, chauffage terminé —, transitions de pages dans WebShop et, dans ScienceWorld, le signal de sous-objectif déjà émis par l’environnement.
Aucun modèle ni coût d’échantillonnage supplémentaire. À titre de comparaison, un modèle de récompense de processus exige des annotations coûteuses et peut être détourné, tandis que l’estimation de valeur par Monte-Carlo exige des trajectoires supplémentaires à chaque décision. C’est ce coût que Φ évite.
Les créateurs de produits à base d’Agents disposent d’un avantage absent des environnements de l’article : les appels d’outils sont structurés dès le départ, avec des réussites et des échecs explicites. L’article devait extraire les signaux de l’environnement ; les nôtres existent déjà.
Trois couches pour le construire
Première couche : rassembler les preuves déterministes dans un flux unique. Aucun jugement sémantique, seulement une trace mécanique de changements irréversibles et vérifiables. L’empreinte d’un fichier a changé. Une commande est sortie avec le code zéro. Un appel API externe a réussi. Une ligne a été enregistrée. Tout cela existe aujourd’hui, mais reste dispersé, sans registre unique des faits établis.
Deuxième couche : relier les deux moitiés. C’est l’étape la plus utile. Quand le modèle déclare une étape terminée, cesser de le croire sur parole et chercher les preuves de première couche sur cette période. Si elles existent, marquer achèvement vérifié. Sinon, marquer achèvement déclaré. Cela n’empêche aucune déclaration du modèle ; cela distingue simplement ce qui est étayé de ce qui ne l’est pas.
Troisième couche : définir Φ par type de capacité. Les auteurs reconnaissent que Φ exige une connaissance du domaine et se généralise mal : n’attendez donc pas un détecteur universel. Les tâches de code observent les codes de sortie des tests ; les analyses de données, l’existence du fichier de sortie ; les tâches de messagerie, la réponse API. Cette couche se construit progressivement, capacité par capacité.
Un critère ajouté : l’irréversibilité, pas l’importance
Celui-ci ne figure pas dans l’article.
Les jalons de BEACON fonctionnent parce qu’ils marquent des transitions d’état sur lesquelles on ne revient pas. Une fois la clé obtenue, le monde a changé. Le critère devrait donc être cette action a-t-elle produit un effet externe irréversible ?, plutôt que cette étape était-elle importante ?.
Irréversible : écrire un fichier, créer un commit, envoyer un message, appeler une API payante, enregistrer en base de données. Réversible : lire un fichier, rechercher, récupérer une page, réfléchir.
Deux conséquences en découlent. La décision est mécanique, car le type d’action suffit : aucune compréhension sémantique, aucune subjectivité du type « le modèle jugeait cette étape importante ». Elle coïncide aussi avec les points de reprise : reprendre à une frontière irréversible est la seule reprise significative, puisque les actions réversibles peuvent simplement être refaites.
Deux chiffres : l’un pour oser, l’autre pour rester prudent
L’expérience de dégradation est rassurante. En supprimant aléatoirement la moitié des jalons, le score reste à 82.8 contre une référence de 72.8 : dix points d’avance. La dégradation est progressive, sans effondrement. Pour une mise en production, c’est essentiel : Φ n’a pas besoin d’être parfait avant d’être activé. Couvrir la moitié est déjà bénéfique.
Le chiffre qui invite à la prudence vient de la comparaison des partitionnements.
| Partitionnement | Score | par rapport à la référence (72.8) |
|---|---|---|
| Découpage aléatoire en 5 parties | 74.2 | +1.4 |
| Jalons réels | 91.4 | +17.2 |
La première note citait déjà ces chiffres, mais la conséquence est ici plus directe. Si vos jalons sont définis à l’intuition, ils ressemblent à un découpage aléatoire et le travail est gaspillé. Ils sont utiles précisément lorsqu’ils correspondent à la structure réelle de la tâche.
Où il faut relativiser
L’annexe de l’article cite elle-même la découverte automatique des jalons comme problème ouvert. Les trois benchmarks obtiennent leurs jalons par des règles : reconnaissance de motifs dans les réponses de l’environnement, transitions de pages ou signal fourni directement. Les situations véritablement ouvertes — pilotage du navigateur, refonte de code, recherche approfondie — n’offrent pas ces transitions vérifiables toutes faites.
Il s’agit donc d’un paradigme validé en environnement structuré, pas d’une solution à reprendre intégralement. Ce qui le rend applicable à un produit d’Agents est la frontière structurée de l’appel d’outil, pas une réponse déjà donnée par l’article.
L’autre piège est la granularité. Trop rare, le signal ne change rien ; trop dense, il devient du bruit au niveau segment. Côté produit, c’est la granularité de la décomposition des tâches. Nous avons ici un avantage absent des environnements de l’article : les étapes du plan sont conçues pour l’utilisateur, donc la granularité peut se fonder sur leur compréhension par une personne, plutôt que sur un réglage purement algorithmique.
Si vous ne faites qu’une chose
Réalisez la deuxième couche.
Elle coûte peu, car les données de la première existent déjà et la deuxième ne fait que les corréler aux déclarations du modèle. Elle se vérifie indépendamment, puisque le ratio entre achèvements vérifiés et déclarés est lui-même un indicateur utile. Et c’est la condition de tout le reste : sans notion de jalon vérifié, la détection de stagnation de la première note et la frontière de compaction de la suivante n’ont aucun fondement.
Elle a aussi une propriété rassurante : son déploiement ne change aucun comportement. Le modèle déclare les étapes comme avant ; seule une marque supplémentaire apparaît. Une fois les données accumulées, vous pouvez décider d’intervenir ou non sur les déclarations sans preuve.
La prochaine note porte sur la compaction du contexte : pourquoi couper à un seuil de tokens dit peu de ce qu’on peut oublier sans risque, et pourquoi il faut corriger l’extension la plus intuitive de cette note — supposer qu’une fois un jalon vérifié, tout ce qui précède peut être condensé.