Exécution TAO Token-Efficient

Exécutez un workflow TAO par étapes en tant qu'une série de sessions d'agent headless fraîches — une carte de stage par session — au lieu d'une longue conversation. L'état vit sur disque, jamais dans l'historique de chat, donc aucune session ne relit le passé de la run.

Mesuré sur des workflows réels (mêmes tâches, mêmes résultats, tokens facturés) :

Le mécanisme : une API d'agent est sans état, donc une longue conversation renvoie son historique complet à chaque message — à mi-parcours, cela représente ~100k+ tokens de texte de skill, d'édits de spec, et de logs d'entraînement relus à chaque tool call, dont l'étape actuelle n'a besoin que de ~3k. Les cartes rendent explicites les 3k de chaque étape et abandonnent le reste.

Les trois couches

1. Core (agnostique du harness) — cartes de stage (markdown, contrat de var d'env), un driver bash (routage de stage + attente de job), et des contrats d'état sur disque (references/CONTRACTS.md).
2. Adaptateurs harness (adapters/) — guard + recorder implémentés par harness : hooks pour Claude Code, extensions pour Pi. Même logique, ~150 lignes chacun. Les guards bloquent les impasses connues avant que les tokens ne soient consumés ; le recorder ajoute les commandes exécutées à commands.log pour que les sessions ultérieures les réutilisent au lieu de les re-dériver.
3. Packs de cartes (par skill d'application) — cartes compilées vivant à côté du skill dont elles ont été créées, par ex. skills/applications/tao-run-deft-aoi/cards/ et skills/applications/tao-run-automl/cards/. Chaque pack livre son propre driver.sh et README.md (version pin, env requis, comment exécuter).

Les cartes réduisent le travail du modèle ; elles ne l'éliminent pas. Le driver possède le routage et l'attente (déterministe), les scripts d'aide possèdent les commits d'état (déterministe), et le modèle exécute un stage pré-planifié : exécute les commandes verbatim, lit une table de gate, décide réussite/échec à partir de la sortie réelle, remplit la seule valeur dynamique. Si un stage devient jamais 100 % déterministe, promouvoir-le hors de la carte dans le driver ou un script d'aide.

Démarrage rapide — exécuter un pack de cartes livré

# plugin installs export TAO_SKILL_BANK_PATH automatiquement ; les utilisateurs standalone le définissent en premier :
export TAO_SKILL_BANK_PATH=/path/to/tao-skill-bank

# une seule fois : scaffold ~/.tao-kit/kit.env et vérifier les prérequis harness
bash "$TAO_SKILL_BANK_PATH/skills/core/tao-token-efficient-execution/scripts/install.sh"

# éditez ~/.tao-kit/kit.env : définir WS (et VENV pour le pack AutoML) et MODEL ;
# exportez la clé API de votre fournisseur dans votre shell — ne la mettez jamais dans kit.env.
# puis lancez un driver pack détaché (laissez stderr attaché : les erreurs de config s'impriment immédiatement) :
nohup bash "$TAO_SKILL_BANK_PATH/skills/applications/tao-run-automl/cards/driver.sh" > /dev/null &

# monitorer
tail -f ~/.tao-kit/automl/driver.log

Le driver attend que les jobs s'exécutent (basé sur l'activité, pas sur le processus), déclenche une session fraîche par stage, s'arrête sur les erreurs validées (pas de retry automatique — un opérateur décide), et quitte 0 seulement après vérification de l'achèvement. DEFT prépare son handoff d'inférence et passe l'audit de complétion ; AutoML nécessite son marqueur DONE sans échec traînant. L'épuisement du round-cap quitte avec un code non-zéro.

Lancer un driver pack est un travail avec effets secondaires : complétez la gate tao-launch-workflow (plateforme, credentials, image, datasets, revue de lancement) avant de le lancer, exactement comme pour une exécution in-conversation. Les guards Pi ne sont pas un sandbox OS : utilisez un worker isolé de confiance, pas une station de travail contenant des credentials non liées (voir adapters/pi/README.md).

Démarrage rapide — créer un pack pour un autre workflow

Une session d'authoring avec un modèle fort compile le skill en cartes (mesuré : ~10 minutes, coût unique ; chaque exécution ultérieure les exécute) :

1. Lisez references/authoring_prompt.md (le contrat round-0) et references/authoring_prompt_v2.md (règles distillées des mesures de défaillances de petit modèle : une commande par étape, gates d'état mécaniques, chemins d'artefacts exacts, terminaison explicite, auto-réparation bornée).
2. Remplissez les paramètres de run — tout ce qui est concret pour la machine cible. Tout ce que vous omettez, les sessions d'exécution brûleront des tokens en le redécouvrant.
3. La session d'authoring lit le skill + inspecte l'espace de travail + écrit les cartes dans skills/applications/<skill>/cards/. Elle ne DOIT PAS exécuter le workflow.
4. Copiez le driver.sh d'un pack livré et éditez ses trois points de config : la table de routage stage→card, le prédicat working(), et le bloc paths. (templates/driver.template.sh est le squelette portable pour harness.)

references/CARD_AUTHORING.md reconstruit une vraie session d'authoring étape par étape.

Plancher du modèle (mesuré, côté exécution)

L'authoring nécessite toujours un modèle fort. L'exécution a été mesurée sur différentes tailles :

L'exécution de skill brut (pas de cartes) ne s'est pas complétée honnêtement sur AUCUN des petits modèles mesurés — abandons, violations de protocol, ou succès faussement déclaré. Les cartes sont ce qui rend possible l'exécution de petit modèle, pas une optimisation mineure.

Signalez, ne patchotiez pas : quand un modèle d'exécution échoue une carte, signalez-le et arrêtez (l'arrêt no-auto-retry du driver l'impose). Ne modifiez jamais les cartes ou l'état pour couvrir les erreurs d'un modèle ; seuls les défauts authentiques d'authoring de carte sont corrigés, explicitement.

Fichiers