Certains travaux sont trop structurés pour un seul tour d'agent et trop ramifiés pour une seule spec du Task Runner. Un flux de travail est un script Python rédigé qui orchestre de nombreux agents à travers des étapes explicites : il les exécute en parallèle, enchaîne leur sortie et vérifie les résultats avant de poursuivre.
Vous en écrivez rarement un à la main : décrivez l'objectif en langage courant et l'agent rédige habituellement le script pour vous.
Optez pour un flux de travail lorsque la forme du travail compte autant que le travail lui-même :
| Modèle | Ce qu'il fait | Exemple |
|---|---|---|
| Déploiement en éventail | Exécuter la même étape sur de nombreuses entrées en parallèle | Réviser tous les fichiers modifiés d'une pull request d'un coup |
| Pipeline | Alimenter l'étape suivante avec la sortie d'une étape | Rédiger → critiquer → réécrire → mettre en forme |
| Évaluation et vérification | Produire un résultat, puis le faire vérifier par un agent distinct | Générer un correctif, puis le valider par rapport à la spec |
Pour une seule exécution autonome à partir d'une spec, utilisez le Task Runner. Pour du parallélisme ponctuel au sein d'une conversation, utilisez les Sous-agents. Les flux de travail servent lorsque vous avez besoin d'une structure reproductible sur de nombreux agents.
Le chemin le plus rapide vers un flux de travail est de décrire le résultat souhaité et de laisser l'agent écrire le script :
« Écris un flux de travail qui prend chaque fichier markdown dans
docs/, fait résumer chacun par un agent en parallèle, puis fait fusionner les résumés par un second agent en un seul index. »
L'agent produit un script Python qui compose les étapes. Lisez-le, ajustez-le et exécutez-le. Comme c'est du Python ordinaire, vous pouvez le versionner, le partager et le réexécuter dès que les entrées changent.
session_send transmet un message à une autre session pour son prochain tour. Un agent coordonnateur peut diriger des sessions homologues au lieu de seulement les ouvrir, les lire ou les arrêter. Il s'agit de la primitive qui sous-tend le chef d'orchestre et tout modèle d'orchestration entre sessions que vous créez vous-même.
L'agent chef d'orchestre gère les objectifs trop vastes pour une seule session :
Le chef d'orchestre s'exécute dans une boucle de surveillance qui survit à la fermeture des onglets et aux plafonds de tours, de sorte qu'un long plan couvrant plusieurs sessions continue pendant votre absence.
Appelez le chef d'orchestre depuis n'importe quelle session en décrivant un objectif qui se divise naturellement en flux de travail parallèles.
Promouvez la définition d'un flux de travail d'une session dans la bibliothèque globale afin de la réutiliser entre les sessions :
/workflow <name> dans n'importe quelle sessionLes flux de travail de la bibliothèque sont versionnés. Vous pouvez consulter l'historique des révisions et revenir à une version antérieure.
Un tour de clavardage peut durer jusqu'à quatre heures. Pour un travail plus long, utilisez une boucle de surveillance ou le Task Runner afin que Crew puisse continuer entre les tours. Consultez Configuration pour les paramètres de délai d'expiration.
Un agent peut démarrer, réviser, inspecter et arrêter une boucle de surveillance liée à sa propre session. Les boucles à minuterie simple (monitor_start) fonctionnent depuis le clavardage du tableau de bord, Slack, Discord et Webex. La pastille d'objectif affiche la cadence active et le budget afin qu'une boucle en attente ne ressemble pas à un tour d'exécution ordinaire.
Utilisez monitor_watch lorsque l'objectif est d'atteindre une pull request prête à réviser. Les sondes du fournisseur s'exécutent sans tour d'agent tant que rien d'actionnable ne change, puis réveillent la session propriétaire avec un résumé délimité. Cela évite de consacrer un tour de modèle à chaque intervalle lorsque la pull request est calme.
| Hôte de pull request | Prérequis |
|---|---|
| GitHub | gh authentifié |
| GitLab.com ou un hôte GitLab autogéré dans la liste autorisée | glab authentifié |
| Azure DevOps Services | az avec l'extension azure-devops, plus az login ou AZURE_DEVOPS_EXT_PAT |
| Bitbucket Cloud | Accès public, ou BITBUCKET_EMAIL et BITBUCKET_API_TOKEN pour une pull request privée |
Collez l'URL canonique de la pull request dans Watch a pull request. Azure DevOps Server et Bitbucket Data Center ne sont pas pris en charge. Les surveillances Azure DevOps et Bitbucket privé doivent être démarrées depuis une conversation du tableau de bord car elles dépendent de justificatifs d'identité délimités au propriétaire.
monitor_watch est disponible depuis les sessions du tableau de bord, Slack et Discord. Les sessions Webex peuvent armer une boucle à minuterie simple avec monitor_start mais pas une surveillance structurée de pull request, car la livraison de réveil structuré n'a pas de route Webex.
Utilisez monitor_stop pour terminer une surveillance structurée; monitor_inspect lit son état actuel. monitor_stop et monitor_inspect fonctionnent tous deux avec les surveillances de pull requests, les surveillances de flux de travail et les boucles à minuterie simple de monitor_start.
Une surveillance structurée se retire lorsque son sujet atteint un état terminal ou que son budget est épuisé. Le contrôleur d'interruptions peut aussi transformer une tâche cron de sondage éligible en interruption de réveil sur changement, afin que les intervalles calmes ne consomment pas de tours d'agent.
Une exécution du Task Runner conserve son arbre de travail, sa branche et les leçons apprises après un redémarrage de la passerelle. Consultez Task Runner pour le flux de travail de bout en bout.
En coulisses, un flux de travail coordonne les mêmes agents d'arrière-plan que vous pouvez lancer vous-même. Chaque étape peut se déployer en éventail vers des sous-agents, attendre leurs résultats et transmettre une sortie synthétisée à l'étape suivante. Le script du flux de travail définit la structure : quelles étapes s'exécutent, dans quel ordre et ce que signifie « terminé ». Chaque agent accomplit le travail.
L'application Workflows fournie offre une surface de tableau de bord pour rédiger, valider et surveiller les exécutions de flux de travail. Elle est fournie désactivée et cachée du catalogue principal des applications par défaut.
Activez-la depuis la CLI :
kirocrew app enable workflows
Une fois activée, l'application apparaît dans la barre latérale à /workflows. Elle vous permet de valider un script de flux de travail par rapport à l'API isolée avant toute exécution, puis de surveiller chaque phase et chaque événement d'agent au fil de l'exécution. Des exemples exécutables sont inclus pour vous aider à commencer.
Flux de travail