Surveiller un agent avec un modèle de décision
Les agents de code sont là où ces modèles sont le plus densément utilisés, et les usages se regroupent en trois endroits. Les trois partagent une même structure : sortir le jugement du modèle génératif, le confier à quelque chose de moins cher et de plus rapide, et laisser le code agir sur une réponse typée.
1. Avant un appel d’outil : autoriser ou non
L’endroit le plus direct. Un hook PreToolUse de Claude Code fait ceci :
Demande à un
Noul: cette commande shell est-elle strictement en lecture seule ? Approuve automatiquement à 0.95, sinon retombe sur l’invite de permission habituelle — et ne refuse jamais.
Trois décisions de conception méritent d’être nommées :
- 0.95 est élevé. La barre pour approuver automatiquement se situe bien au-dessus de la barre pour « cela semble risqué ». Une fausse autorisation coûte une machine ; un faux blocage coûte une confirmation de plus. Des coûts asymétriques appellent des seuils asymétriques.
- Il ne refuse jamais. Il ne fait qu’ajouter une approbation ; tout le reste retourne au système d’origine. Une barrière qui ne fait qu’ajouter de la capacité est bien plus facile à tester — son pire cas est de n’avoir servi à rien.
- Les commandes dangereuses n’atteignent jamais le modèle. Une liste locale de refus catégoriques et un filtre d’injection les interceptent d’abord. Cela compte plus que le seuil — voir Ce qui doit vivre dans le code.
Résultat mesuré : 0 sur 8 commandes modifiant l’état ont été approuvées automatiquement.
2. Quand l’agent veut s’arrêter : a-t-il fini ?
Un autre endroit fréquent. Un hook Stop demande au modèle de décision si l’agent est en train de finir trop tôt, en lui soumettant ses règles d’achèvement en langage clair.
La version la plus retenue fonctionne ainsi :
Dépense un appel à quatre questions seulement quand des fichiers ont changé et qu’aucune vérification passante n’a tourné depuis. Échoue ouvert en cas d’erreur.
« Ne demander que quand cela vaut la peine de demander » est le nœud de cette classe — ces hooks s’exécutent à chaque tour, et appeler sans condition multiplie le coût par le nombre de tours. La condition ci-dessus est « changements non vérifiés », qui est exactement le moment où un agent est le plus susceptible de déclarer victoire sans avoir vérifié.
Un hook apparenté empêche un agent de finir trop tôt en jugeant des règles d’achèvement en langage clair plutôt qu’en faisant confiance à la déclaration de l’agent lui-même.
3. Quand le contexte se remplit : qu’est-ce qui est encore nécessaire ?
Le troisième endroit est la compaction du contexte, où les approches divergent le plus.
La compaction traditionnelle résume : on confie un pan de conversation à un modèle et on récupère de la prose. L’original a disparu, et le résumé est irréversible.
L’approche par modèle de décision ne réécrit pas — elle ne fait que noter :
| Approche | Ce qui est préservé |
|---|---|
| Noter chaque appel d’outil et chaque résultat pour « encore nécessaire » | Les lignes jugées à garder restent mot pour mot |
Déplacer les scores bas dans un magasin, laisser un pointeur expand() en place |
Rien n’est supprimé, seulement plié |
| Un préfixe figé en ajout seul | Le cache de prompt n’est jamais cassé |
| Élaguer la longue sortie Bash avant que le modèle ne la voie | Le bruit du terminal n’entre jamais dans la fenêtre |
La phrase commune : le travail du modèle de décision ici est un jugement binaire garder/écarter, pas une réécriture. C’est précisément ce pour quoi il est bon et ce pour quoi les modèles génératifs sont mauvais — et « plier au lieu de supprimer » transforme un mauvais jugement de « information perdue à jamais » en « un expand de plus ».
Le contrepoint : les barrières de sûreté et d’efficacité échouent en sens opposés
Le contraste le plus instructif de cette partie de l’écosystème : à la même question « que se passe-t-il en cas d’erreur », des projets ont choisi des réponses opposées, et les deux ont raison.
- Un juge de permissions : refuse en cas d’erreur ou de délai dépassé.
- Un hook Stop : autorise en cas d’erreur.
Le critère n’est pas « lequel est plus sûr » mais si cette barrière garde un risque ou un débit. Les barrières qui gardent un risque (permissions, secrets, commandes dangereuses) devraient plutôt bloquer une bonne chose que laisser passer une mauvaise ; les barrières qui gardent un débit (vérifications d’achèvement, vérifications de format) devraient plutôt laisser passer quelque chose que bloquer tout le flux.
En une phrase
Les agents sont le foyer le plus naturel pour ces modèles parce qu’ils ont besoin d’un grand nombre de jugements bon marché dont les résultats sont consommés immédiatement par du code. Mais à chacun de ces points, décide d’abord : de quel côté cette barrière doit-elle tomber quand elle casse ?