Accueil / Plusieurs agents et vérification adverse

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

Un workflow est un script qui orchestre des sous-agents de façon déterministe, avec une sortie structurée par un schéma JSON et un checkpoint après chaque étape, mais le modèle qui s'applique à un agent relancé suit un ordre de priorité à quatre étages, et sans que les trois premiers soient renseignés, cet agent hérite en dernier recours du modèle de la session qui l'exécute, pas de celle qui a écrit le script.

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. La documentation officielle des workflows Claude Code montre un exemple qui passe directement un objet schéma à la fonction qui appelle un agent, ce qui retire toute marge d'interprétation sur la forme du résultat attendu.

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é.

é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

Ce dernier champ, aucun modèle posé dans le script pour cette étape, est le point le plus facile à manquer en relisant un script écrit plusieurs mois plus tôt.

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. 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. Ne pas le faire produit un résultat rendu par un modèle que personne n'a choisi pour cette étape précise, sans qu'aucune alerte ne prévienne du changement.