Auto-amélioration

Description

Améliorez vos propres playbooks en fonction d'un score mesuré. Le benchmark (elophanto bench) rejoue les checkpoints que vous avez complétés et vérifiés auparavant : votre vrai prompt, l'étape de planification et l'exécution du modèle en direct, et chaque appel d'outil est répondu à partir de l'enregistrement, donc rien de réel ne s'exécute. Le score est la part des cas qui passent les mêmes portes que la production. Cette skill exécute la boucle d'expérience (experiment_setup / experiment_run) avec ce score comme métrique, donc un changement de playbook n'est conservé que s'il aide mesureablement.

Vous pouvez changer vos playbooks : les skills sous skills/, la connaissance sous knowledge/, et AGENT_PROGRAM.md. Vous ne pouvez pas changer le code ou les garde-fous de sécurité dans une expérience benchmark — experiment_setup refuse les autres fichiers cibles et experiment_run refuse un changement en dehors des cibles déclarées.

Déclencheurs

improve yourself
self-improvement
get better at
benchmark score
"why do checkpoints keep failing"
"the benchmark dropped"
"tune your playbooks"

Instructions

Vérifiez qu'il y a quelque chose à mesurer. Exécutez elophanto bench capture, puis elophanto bench history. Avec moins de 10 cas, le score est du bruit — arrêtez-vous et dites-le ; les cas s'accumulent au fur et à mesure que les objectifs se complètent.
Lisez les défaillances avant de changer quoi que ce soit. Exécutez elophanto bench run une fois (sans --metric) et lisez la colonne why : refus de receipt-gate, vérifications échouées, échecs de rejoue (le modèle a appelé un outil que l'exécution enregistrée n'avait pas besoin), arrêts. Lisez aussi les lignes de plan et de leçon du digest de santé quotidien (autonomy_health), et toute leçon retirée.
Formulez une hypothèse par expérience. « Les checkpoints qui collectent des listes échouent parce que le playbook ne dit jamais de lire chaque page » — lié aux cas défaillants, pas une réécriture générale.
Configurez avec experiment_setup :
- metric_command: .venv/bin/python -m cli.main bench run --metric > run.log 2>&1 (ou elophanto bench run --metric > run.log 2>&1 s'il est installé)
- metric_extract: grep '^bench_score:' run.log | tail -1 | awk '{print $2}'
- metric_direction: higher
- target_files: le un ou deux fichiers playbook sur lesquels porte votre hypothèse
- budget_seconds: environ max_cases × 300
Changez une chose, dans les fichiers cibles seulement, puis experiment_run avec une courte description. Il conserve le changement si le score augmente et l'annule sinon.
Traitez les petits gains comme du bruit. La sortie du modèle varie entre les exécutions ; un gain d'un cas sur vingt est dans la marge. Avant de signaler une amélioration, confirmez qu'elle persiste sur une deuxième elophanto bench run.
Rapportez la baseline, ce que vous avez essayé, ce qui a été conservé, et le score final — avec elophanto bench history comme preuve.

Vérifier

elophanto bench history montre une exécution après le changement avec un score plus élevé que la baseline, et l'empreinte a changé (le digest leçon/skill).
git diff sur la branche d'expérience touche uniquement skills/, knowledge/ ou AGENT_PROGRAM.md.

Notes

Chaque bench run consomme du quota modèle : cases × (étapes de plan + acting).
bench.enabled dans config.yaml exécute le benchmark chaque nuit ; le digest rapporte le score et sa variation.
Une leçon qui se prouve dans les vrais plans est promue en skill automatiquement (skills/learned-*) ; cette boucle est pour les changements délibérés.