Accueil / Plusieurs agents et vérification adverse

Workflows déterministes : schémas, checkpoints, reprise

Un workflow est un script qui enchaîne des appels d'agent de façon déterministe : mêmes étapes et même schéma de sortie à chaque exécution. Un schéma JSON impose des champs nommés d'une étape à l'autre, et chaque étape terminée écrit un checkpoint, ce qui permet de reprendre un workflow interrompu sans tout refaire.

Un workflow, au sens de ce module, est un script qui enchaîne plusieurs appels d'agent de façon déterministe : la même séquence d'étapes et le même schéma de sortie à chaque exécution, contrairement à une conversation où l'agent décide seul de l'ordre de ses actions.

Le schéma qui remplace un rapport en langage libre

Quand un agent doit transmettre son résultat à l'étape suivante, un schéma JSON impose des champs nommés et des types précis, plutôt qu'un paragraphe que l'agent suivant devrait relire et interpréter. Deux agents qui échangent par un schéma commun ne se comprennent pas de travers sur la forme, ce qui déplace la vigilance là où elle compte vraiment, sur le contenu.

Le checkpoint qui évite de tout refaire

Chaque étape terminée écrit un checkpoint. Au moment de reprendre un workflow interrompu, une étape marquée terminée renvoie directement son résultat sauvegardé sans relancer l'agent qui l'a produit. Une étape dont le prompt a changé depuis la dernière exécution est relancée, et toute étape placée après elle dans la séquence l'est aussi, même si son propre prompt n'a pas bougé. Avant la version 2.1.305, les agents terminés pouvaient aussi repartir quand on relançait un script non modifié ; la reprise les sert désormais depuis le journal du run.

étape : rédaction_synthèse
statut : terminé
prompt identique à la dernière exécution : oui
modèle posé dans le script pour cette étape : aucun

Le modèle qu'un agent relancé hérite réellement

Depuis la version 2.1.251, le modèle qui s'applique à un agent relancé suit un ordre de priorité à quatre étages : le paramètre posé directement dans l'appel de cet agent, le champ modèle du sous-agent lui-même, une variable d'environnement propre au sous-agent, puis, en dernier recours, le modèle de la session qui exécute le script au moment où elle le relance. Avant cette version, l'ordre différait sur un point qui change tout pour un vieux script : la variable d'environnement passait en premier et l'emportait sur le paramètre d'appel comme sur le champ modèle du frontmatter, y compris sur la valeur model: inherit. Depuis octobre, la variable CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL fait tourner tous les agents d'un workflow sur un seul modèle sans toucher aux autres sous-agents ; la ligne du journal ne dit pas où elle se place dans cet ordre, la page des workflows ne mentionne pas la variable : seul le journal la documente. Quand aucun des étages prioritaires n'est renseigné, un agent écrit sous un modèle donné à une date bascule silencieusement sur le modèle de la session qui le relance des mois plus tard, sans qu'aucun message à l'écran ne le signale. Ce point rejoint le choix d'architecture posé dans fan-out, pipeline, barrière : un pipeline sauvegardé reste un pipeline, et chacune de ses étapes garde son propre risque d'héritage silencieux de modèle.

Rouvrir un script écrit plusieurs mois plus tôt et vérifier ligne par ligne quel modèle s'appliquera réellement à chaque agent prend quelques minutes, à condition de vérifier aussi la version de l'outil d'orchestration au moment de l'écriture du script face à celle installée aujourd'hui.

Quand arrêter une étape qui échoue

Dans une boucle d'étapes, « la même erreur deux fois » se juge sur l'ensemble des critères rejetés d'une tentative, pas sur un identifiant isolé. Un ensemble différent ouvre une tentative de plus, le même ensemble ferme l'étape, et deux étapes échouées de suite arrêtent la boucle. Une étape échouée n'arrête pas le chantier : son travail reste dans le dépôt et se reprend dans un petit chantier neuf. À chaque reprise, relisez le plan et ajoutez une précision avant la tentative suivante, et faites écrire les verdicts par un script qui vérifie que les clés égalent les critères.