Harness² — Mise sous harnais de tâches récurrentes
Adapté de Harness² : Mise sous harnais récursive d'agents pour un monde ouvert, réduit au cas où une exécution a déjà été acceptée et où l'objectif est de la répéter.
Aperçu
Réussir une fois n'est pas la même chose qu'être reproductible. L'exécution acceptée est votre seul point de référence fiable : elle contient un véritable livrable, une véritable trajectoire, et les endroits que l'utilisateur a personnellement modifiés.
L'objet de l'optimisation est le processus du prochain passage, pas le livrable de ce passage. Le résultat n'est donc pas un meilleur rapport — c'est un harnais, une procédure opérationnelle standardisée (SOP) et une checklist de régression.
Quand l'utiliser
- L'utilisateur dit « nous ferons cela chaque semaine à partir de maintenant » ou « verrouillons ce processus »
- Le même type de tâche a été effectué au moins une fois, et ce résultat a été accepté
- Le processus vit dans la tête de quelqu'un : qui exécute quel script en premier, quelle étape nécessite une vérification humaine, où se trouvent les pièges
- La même classe de tâche échoue toujours de la même manière : attributions de sources manquantes, définitions incohérentes, reprises constantes
Quand NE PAS l'utiliser
- Tâche unique → il suffit de la faire
- Il existe un véritable correcteur, test unitaire ou critère d'acceptation calculable → utilisez-le ; il bat le contraste comportemental de loin
- L'utilisateur souhaite uniquement modifier un format ou une définition, et l'a précisé → éditez le harnais directement, ignorez la boucle de contraste
- Le processus est déjà stable, et le coût ou la latence est serré
Ce qu'est un harnais
Tout ce qui entoure le modèle et qui peut être édité. Quatre suffisent pour fonctionner ; huit est l'ensemble complet :
| Composant | Rôle | Minimum |
|---|---|---|
| prompt système | rôle, contrat de sortie | ✅ |
| conseils sur les outils | quand utiliser chaque source de données, comment remplir les arguments | ✅ |
| compétences | jugement et procédures réutilisables | ✅ |
| garde-fous | contraintes strictes (ne jamais inventer de chiffres, toujours citer les sources) | ✅ |
| mémoire | notes de domaine transportées entre les instances | |
| scripts | travail déterministe (conversion, dédoublonnage, agrégation) | |
| sous-agents | vérification ou récupération parallèle séparée | |
| plugins | middleware (forcer une auto-vérification toutes les N étapes) |
Un harnais doit exister sous forme de fichiers pour pouvoir être différencié et réutilisé. « Nous faisons généralement comme ça », laissé dans un chat, ne peut être solidifié.
La boucle : Proposer → Sonder → Composer
0. Geler la base de référence
Archivez le dernier passage en entier : instantané du harnais, trajectoire complète (séquence d'appels d'outils + artefacts intermédiaires), livrable final, le diff des modifications de l'utilisateur, critères d'acceptation, instantané des données ou fenêtre temporelle.
Les endroits que l'utilisateur a personnellement modifiés sont des emplacements de défauts à haute confiance — plus fiables que toute conjecture.
1. Proposer
Lisez la base de référence, puis proposez deux candidats, chacun avec une phrase nommant le défaut qu'il cible :
- invariant : défauts de processus — pas de vérification croisée, résultats intermédiaires jamais persistés, échecs non relancés, sources non étiquetées, contexte explosé
- domaine : contraintes professionnelles de cette classe de tâche — définitions cohérentes, conversion de devise ou d'unité, fenêtres temporelles alignées
Vous avez besoin des deux pour séparer « maladie générale » de « maladie spécifique à cette classe de tâche ». Avec un seul candidat, vous ne pouvez pas attribuer le résultat.
2. Sonder
Rejouez avec la même entrée, en contrôlant les variables : même modèle, même ensemble d'outils, même instantané des données. Seul le harnais change.
Comparez deux choses :
- Delta comportemental par rapport à la base de référence : ensemble et ordre des outils, nombre d'étapes, appels répétés, erreurs et relances, disparition des points de correction manuelle, persistance des intermédiaires, attribution complète des sources
- Cohérence de la relecture : relancez-la — la structure est-elle la même ? La mesure centrale de la solidification est la stabilité, pas la meilleure exécution unique
Le contraste montre que « le comportement a changé ». Il ne montre pas que « le résultat est correct ». Ne confondez jamais les deux.
3. Composer
Ne conservez que les changements qui (a) satisfont toujours les critères d'acceptation après relecture et (b) réduisent le travail ou la correction manuelle. Conserver l'original est autorisé — un changement sans preuve est du bruit.
Enregistrez chaque décision sur une ligne : changement | défaut ciblé | preuve observée | adopté / révisé / abandonné.
4. Solidifier
Trois artefacts ; en manquer un signifie que ce n'est pas solidifié :
harness/— les fichiers modifiablesSOP.md— étapes, points de contrôle, quand demander à un humain, pièges connus (plus de dix éléments et personne ne le lit)REGRESSION.md— la checklist d'acceptation à parcourir après le prochain passage
Si un changement est adopté sur plusieurs tours, promouvez-le en script ou compétence autonome.
Hiérarchie des preuves
diff de l'utilisateur > comparaison avec le livrable accepté > cohérence de relecture > delta de trajectoire > intuition
N'est pas une preuve : un rapport plus long ou plus détaillé, « l'utilisateur ne s'est pas plaint cette fois », le modèle affirmant avoir mieux fait.
Budget
Par défaut k=1 plus une relecture. La solidification est rentable sur la durée, alors amortissez-la sur plusieurs passages : sondez un candidat lors de chaque exécution récurrente, au lieu de dépenser 3× en une fois pour exécuter toutes les branches en parallèle.
Drapeaux rouges — arrêtez-vous si vous en voyez un
- Hériter du harnais précédent en bloc sans lire le diff des modifications de l'utilisateur
- Rejouer avec une entrée, un modèle ou un instantané de données différent tout en prétendant que « c'est mieux »
- Conclure à partir d'une seule relecture sans écarter le hasard
- Modifier cinq composants à la fois, rendant toute attribution impossible
- Une SOP de 20 éléments que personne ne suivra la prochaine fois
- Écrire un coup de chance ponctuel dans une entrée invariante
Erreurs courantes
| Erreur | Conséquence | Correctif |
|---|---|---|
| Optimiser avant d'archiver | base perdue, changements non attribuables | gelez d'abord la base de référence |
| « Ça se lit mieux » comme preuve | vous solidifiez une préférence, pas un processus | liez-la à une observation concrète |
| Modifications uniquement du prompt, pas de points de contrôle | les humains corrigent encore à la main la prochaine fois | associez chaque défaut à un point de contrôle |
| SOP rédigée comme un carnet de voyage | personne ne la lit, donc rien n'est solidifié | n'écrivez que les points de décision et les pièges |