Certains travaux sont trop vastes pour une seule session d'agent : une fonctionnalité qui exige des exigences, une conception, une implémentation, une révision indépendante et une validation. D'autres, vous préférez les confier plutôt que les surveiller : une investigation qui devrait se terminer pendant que vous continuez à travailler. Un workflow confie les deux à une équipe d'agents munie d'un plan. Il s'adresse aux développeurs et aux chefs d'équipe qui veulent voir ce travail achevé sans surveiller chaque étape.
Le modèle définit quels agents effectuent le travail et dans quel ordre, et l'environnement d'exécution de Kiro exécute ce plan, de sorte que chaque étape s'exécute au bon moment, sans rappel. Les workflows sont des graphes composés d'étapes d'agent, de séquences, de boucles et de branches parallèles, dans un format que les personnes comme les agents peuvent lire et créer. Chaque étape s'exécute dans sa propre session avec un nouveau contexte : un réviseur, par exemple, évalue le travail sans hériter du raisonnement de celui qui a écrit le code.
Les workflows s'exécutent en arrière-plan. Vous continuez à travailler avec Kiro dans le clavardage principal pendant que le travail délégué progresse, et la session de chaque étape reste accessible pour la mettre en pause, la reprendre ou l'orienter pendant l'exécution, puis pour y revenir avec des questions de suivi par la suite. Déléguer même une petite investigation garde le résultat de ses outils et son raisonnement détaillé hors du clavardage principal, ce qui préserve votre contexte pour le travail en cours.
Kiro génère un workflow pour la tâche à accomplir. Enregistrez-en un comme recette pour le réutiliser, ou écrivez le vôtre.
Vous n'écrivez pas d'abord une recette. Décrivez le résultat dans le clavardage parent et précisez le degré de structure ou de révision souhaité. Dans une session V3, Kiro affiche le plan proposé pour que vous l'approuviez avant l'exécution de toute étape. Vous pouvez examiner ses étapes et ses agents avant de le lancer. Dans Kiro CLI 2.33.1 ou une version ultérieure, l'activation des Workflows ne lance plus de workflow à elle seule; un workflow ne s'exécute que lorsque vous le demandez explicitement.
Dans Kiro CLI V3, la sélection d'une recette dans le sélecteur /workflow run ouvre un formulaire de confirmation avec un aperçu du plan. La même étape d'approbation apparaît lorsque Kiro crée un workflow à partir de votre requête.
Voici trois requêtes qui démarrent une exécution :
Analyse le fonctionnement de l'authentification dans ce dépôt et présente les risques avant que nous changions quoi que ce soit. Effectue la tâche en arrière-plan et remets-moi un résumé avec des références.
Livre la fonctionnalité de limitation du débit dans un nouveau worktree : exigences, révision de la conception, plan, mise en œuvre avec deux réviseurs indépendants et validation finale par rapport aux exigences.
Rétablis la compilation sans modifier le comportement. Reproduis l'échec, corrige une cause à la fois et relance la même vérification. Interromps-toi et consulte-moi après dix tentatives.
Vous pouvez également spécifier des agents personnalisés, des modèles privilégiés et l'effort de raisonnement par étape, ou orienter la façon dont Kiro répartit le travail au moyen de votre requête ou d'un fichier de Steering. Kiro fournit trois recettes que sa propre équipe utilise : investigate pour les analyses en lecture seule, feature-pipeline pour la livraison progressive de fonctionnalités et publish-pr pour ouvrir une pull request et traiter les commentaires de révision. Nommez-en une et fournissez-lui les entrées. Kiro génère les recettes en JSON; YAML est également pris en charge.
Dans Kiro CLI 2.33 ou une version ultérieure, lorsqu'un workflow vous demande d'approuver son plan, l'approbation affiche une arborescence d'étapes compacte : chaque étape avec son agent, ainsi que le modèle et l'effort lorsque le plan les définit. Appuyez sur Tab pour entrer dans l'arborescence, sur Enter pour afficher ou masquer les détails d'une étape, puis de nouveau sur Tab pour revenir aux choix. Dans Kiro CLI 2.34 ou une version ultérieure, tapez des suggestions de modifications directement dans l'approbation pour réviser le plan avant son démarrage. Rien ne s'exécute tant que vous n'avez pas répondu. Lorsque /tools trust-all est activé, Kiro répond à un plan de workflow par son option ponctuelle Allow et n'enregistre aucune règle. Pour le confirmer, lancez un workflow depuis le clavardage et attendez l'approbation : elle énumère les étapes avant que quoi que ce soit s'exécute.
Dans Kiro CLI 2.33 ou une version ultérieure, un workflow démarre quand même lorsque votre organisation a désactivé le modèle Auto, au lieu d'échouer.
Un workflow coordonne plusieurs agents et répète les révisions, il utilise donc plus de jetons qu'une session unique. C'est le compromis : consacrez davantage de ressources à la structure et au jugement indépendant pour les travaux qui en bénéficient, et gardez les petites tâches dans le clavardage. Pour savoir comment l'utilisation des modèles est comptabilisée dans votre forfait, consultez la page Facturation.
Les workflows doivent être activés dans chaque client. Une recette est le même fichier dans Kiro IDE, Kiro CLI et Kiro Web; la façon d'activer les workflows, la provenance des recettes et les commandes disponibles varient selon le client.
- Ouvrez Workspace Configuration pour le projet.
- Choisissez Workflows.
- Activez les workflows.
- Démarrez une nouvelle session de clavardage.
Le paramètre sous-jacent est kiroAgent.workflows.enabled. C'est l'interrupteur global : lorsqu'il est désactivé, Kiro ne démarre pas de nouveaux workflows, mais les exécutions de workflow et les recettes existantes restent disponibles. Les changements s'appliquent aux nouvelles sessions. Si Workflows est absent, il n'est pas encore disponible pour votre compte.
Dans Kiro IDE 1.4.26 ou une version ultérieure, chaque clavardage de premier niveau admissible dispose également d'une commande Use workflows, au bas de la zone Workflows, au-dessus du clavardage parent, à côté de Share feedback for workflows. Le paramètre global détermine si les workflows sont disponibles ou non; Use workflows détermine dans quelle mesure Kiro en démarre un de sa propre initiative dans cette session. Les choix :
- Only when asked : traite les tâches dans votre session active et ne démarre un workflow que lorsque vous en demandez un. C'est le choix par défaut initial jusqu'à ce que vous en choisissiez un autre dans une session locale; par la suite, les nouveaux clavardages démarrent avec votre choix mémorisé.
- Only for large tasks : utilise les workflows de sa propre initiative pour les tâches en plusieurs étapes ou les tâches qui nécessitent plus de contexte.
- As much as possible : tente d'acheminer la plupart des tâches, comme la lecture de code, l'implémentation, les tests et la révision, vers les workflows.
Privilégiez Only when asked lorsque vous voulez décider vous-même de chaque délégation; privilégiez Only for large tasks lorsque le travail en plusieurs étapes doit s'exécuter en arrière-plan pendant que les petites tâches restent dans le clavardage; privilégiez As much as possible lorsque vous voulez que la majeure partie du travail d'une session s'exécute sous forme de workflows et que vous acceptez l'utilisation supplémentaire de jetons.
La commande change la façon dont Kiro décide, et non ce qu'il peut faire : aucun choix n'empêche le lancement d'un workflow, et vous pouvez toujours gérer les workflows en cours d'exécution. Votre choix le plus récent dans une session locale est mémorisé pour les nouvelles sessions de clavardage. Un choix fait dans une session infonuagique s'applique à cette session uniquement et ne modifie pas le choix local par défaut. La commande n'apparaît que dans un clavardage de premier niveau où les workflows sont activés; un onglet Workflow step ne l'affiche pas, pas plus qu'une session créée avant l'ajout de la commande.
Pour le confirmer, démarrez un nouveau clavardage, ouvrez Workflows au-dessus de celui-ci et vérifiez que Use workflows affiche Only when asked si vous n'avez pas choisi d'autre option, ou le dernier choix que vous avez fait dans une session locale.
Lorsque Kiro vous demande d'approuver des étapes de workflow proposées, l'IDE les affiche dans une carte d'autorisation où vous pouvez choisir Allow ou Deny, ou envoyer des commentaires. Une décision d'autorisation enregistrée peut traiter une proposition ultérieure sans afficher la carte. Consultez Examiner les étapes proposées dans Kiro IDE.
En coulisses, un workflow est un graphe : des étapes d'agents, des séquences, des boucles et des branches parallèles dans un format que Kiro et vous pouvez lire et écrire. Vous pouvez comprendre la plupart des recettes au moyen de cinq concepts :
| Concept | Signification |
|---|---|
| Étape | Un agent s'exécute dans sa propre session avec un contexte ciblé. Une étape ne peut pas lire la session d'une autre étape; elle reçoit les résultats antérieurs uniquement par des transferts explicites |
| Transfert | Un extrant capturé ou un artéfact déclaré transmet des éléments de preuve à une étape ultérieure |
| Branche et jonction | Des agents indépendants évaluent le même travail, puis une politique combine leurs résultats |
| Boucle | Un groupe d'étapes se répète jusqu'à ce que les éléments de preuve correspondent à une condition ou qu'un plafond de sécurité soit atteint |
| Attente | L'exécution surveille un système externe, une pull request ou tout ce qu'un de vos scripts peut vérifier, sans consacrer de tours de modèle lorsqu'aucun changement ne survient |
Le clavardage parent et chaque étape restent connectés dans les deux sens. Une étape fait un compte rendu vers l'extérieur avec un signal send_message qui transmet la progression, une question ou son résultat. Vous pouvez orienter une étape en cours d'exécution ou en pause à tout moment; consultez Répondre quand une étape a besoin d'une entrée.
Grâce à ces cinq concepts, la figure ci-dessous retrace une exécution à partir du clavardage parent : lancement, étapes dans leurs propres sessions, boucle de révision, retour des artéfacts et synthèse du résultat par l'agent principal. Les deux canaux restent ouverts pendant tout le processus; vous pouvez donc continuer à communiquer dans le clavardage parent et orienter une étape sélectionnée pendant son exécution.
Parent chat
availableYou
Investigate this repository, plan the change, and verify the result.
Kiro
Workflow launched. I will bring the verified result back here.
Background Workflow
delivery‑run
The gate either exits the repeat or follows the loopback.
01Ask and launch. You describe one outcome; the main agent starts a background run.
Simulation. Nothing you type here reaches a real run.
two conversations, one run: evidence flows back to the main agent, and your guidance flows in, typed to a step or relayed from the parent chat
La recette stocke cette structure sous forme d'arborescence JSON ou YAML lisible. Le produit en cours d'exécution présente la même structure sous forme de nœuds imbriqués, avec les métadonnées d'état, d'itération, d'agent, de modèle, d'effort et de durée lorsque celles-ci sont prises en charge.
Un workflow peut réviser le travail restant entre les limites des étapes à mesure que ses agents découvrent de nouvelles informations. Le travail terminé reste intact et l'étape active n'est pas réécrite pendant son exécution.
Kiro crée un point de contrôle de l'exécution aux limites des nœuds. Si une exécution se met en pause ou si le client se reconnecte, le travail terminé n'a pas à être repris depuis le début.
Ces exemples présentent des structures utiles, et non des règles. Modifiez les étapes, les agents, les modèles, les limites et les éléments de preuve d'achèvement en fonction de votre travail.
Analyser et expliquer
Analysez un dépôt inconnu en arrière-plan, rédigez un rapport avec des références et renvoyez les principaux risques et points à modifier au clavardage principal.
Éléments de preuve : artéfact de rapport et synthèse finale
Livrer une fonctionnalité
Passez par les exigences, la révision de la conception, la planification de la mise en œuvre, la programmation, la révision indépendante et la validation finale.
Éléments de preuve : conception approuvée, plan et vérifications
Dépanner jusqu'à la vérification
Reproduisez un échec, diagnostiquez-le, appliquez un correctif et exécutez les tests en boucle jusqu'à ce que la vérification configurée réussisse ou que l'exécution atteigne son plafond.
Éléments de preuve : test reproductible ou résultat lisible par machine
Publier et répondre
Ouvrez une pull request, attendez sans utiliser de tours de modèle, traitez les commentaires sans risque et recevez une pull request approuvée dont les vérifications réussissent, prête à être fusionnée.
Éléments de preuve : état de la révision, vérifications et préparation à la fusion
Consultez les exemples de workflows pour obtenir des squelettes de recettes complets et adaptables.
Les Workflows ajoutent run_workflow pour les recettes réutilisables et la délégation en arrière-plan à un seul agent. Pour exécuter un agent personnalisé en arrière-plan, l'agent principal peut lancer run_workflow(agent://<name>).
Un workflow à agent unique se comporte comme une délégation isolée ordinaire, mais il s'exécute en arrière-plan : le clavardage parent reste disponible, l'exécution peut être inspectée et les mises à jour sur la progression peuvent être transmises pendant le travail. Dans Kiro CLI 2.34 ou une version ultérieure, Workflow use détermine quand le clavardage principal démarre des Workflows.
| Situation | Comportement de délégation |
|---|---|
| Session principale avec les Workflows désactivés | Kiro traite le travail dans la session active et peut utiliser directement des sous-agents |
| Only when asked (par défaut) | Kiro ne démarre un Workflow que lorsque vous en demandez un |
| Only for large tasks | Kiro peut démarrer un Workflow pour un travail en plusieurs étapes ou nécessitant davantage de contexte |
| As much as possible | Kiro tente d'acheminer la majeure partie de la lecture du code, de l'implémentation, des tests et de la révision par les Workflows |
| Agent s'exécutant dans un Workflow | Cet agent peut toujours utiliser des sous-agents lorsque sa configuration le permet |
| Processus réutilisable en plusieurs étapes | L'environnement d'exécution gère les étapes, les transferts, les boucles, les attentes et la récupération explicites |
Les sous-agents imbriqués aident une étape de workflow à diviser sa propre tâche. Ils ne sont pas des nœuds dans le workflow parent et ne peuvent pas signaler, mettre en pause, terminer ou réviser cette étape en son nom.
Les workflows sont disponibles dans Kiro IDE, Kiro CLI et les sessions infonuagiques de Kiro Web. L'activation, l'accès aux recettes, les points d'entrée de lancement et les commandes diffèrent selon le client.
| Surface | Démarrage | Inspection et interaction | Commandes actuelles |
|---|---|---|---|
| IDE | Demandez à Kiro dans le clavardage parent, ou utilisez /workflow-run pour choisir une recette enregistrée et remplir ses entrées | Workflows au-dessus du clavardage parent; sélectionnez une étape pour ouvrir son onglet dédié Workflow step | Pause, Resume, Stop |
| CLI | /workflow run | Historique des workflows et moniteur plein écran | Pause, Resume, Stop, Réessayer les travaux ayant échoué ou ayant été abandonnés |
| Web | Demandez à Kiro dans une session infonuagique | Workflows, Summary, Files et Artifacts; sélectionnez une étape pour lui envoyer un message | Pause, Resume, Stop; Réessayer lorsqu'une exécution dans un état final comporte des nœuds en échec pouvant être réessayés |
Dans l'IDE, Kiro indique à un workflow qui modifie des fichiers du dépôt d'utiliser la branche extraite au démarrage de l'exécution. Si le workflow utilise un worktree, Kiro lui indique de créer le worktree à partir de cette branche et d'effectuer un rebasage sur la même branche à la fin.
L'exemple investigate lit un projet sans modifier les fichiers sources et rédige un rapport avec des références. Commencez dans le clavardage principal avec un résultat concret :
Utilise un workflow pour déterminer où sont configurés les délais d'expiration des requêtes API. Explique les règles de priorité, cite les fichiers et les symboles pertinents, ne modifie pas le projet et enregistre le rapport sous .kiro/reports/.
Kiro peut lancer l'exécution en arrière-plan et garder le clavardage parent disponible. Suivez l'exécution dans l'interface du client :
Ouvrez Workflows au-dessus du clavardage parent, développez l'exécution et sélectionnez investigate. Kiro ouvre un onglet dédié Workflow step qui présente la session, l'agent, le modèle, l'effort et l'activité de l'étape, ainsi que le champ Message this step's agent. Gardez-le à côté du clavardage parent pour suivre les deux contextes pendant l'exécution.
Les recettes peuvent provenir de votre espace de travail (.kiro/workflows/), de votre configuration utilisateur, de recettes synchronisées pour votre compte ou de l'ensemble fourni avec Kiro; lorsqu'il y a conflit entre les noms, une recette valide d'un niveau supérieur l'emporte. Consultez Créer des workflows pour connaître les fichiers pris en charge, les règles de priorité et l'importation Web.
Les recettes fournies illustrent des structures utiles; ce sont des exemples exécutables, et non une méthodologie obligatoire ou un inventaire garanti pour chaque version du client. Examinez une recette avant de l'exécuter. Les effets secondaires dépendent à la fois de ses requêtes et des outils et autorisations des agents sélectionnés.
Vous n'avez pas à rédiger d'abord une recette à la main. Décrivez le résultat et le degré de structure ou de révision dont vous avez besoin. Kiro peut créer un workflow pour la tâche en question; enregistrez une définition révisée sous .kiro/workflows/ lorsqu'elle mérite d'être réutilisée.
Un workflow exécute des agents en votre nom dans des sessions en arrière-plan qui se poursuivent pendant que vous travaillez à autre chose; la session de chaque étape reste accessible pour l'inspecter, la mettre en pause, la reprendre ou l'orienter. Selon les agents qu'une recette nomme, ses étapes peuvent modifier des fichiers, exécuter des commandes shell et des tests, effectuer des commits et ouvrir une pull request ou y répondre, et une veille command exécute un programme que vous fournissez une fois par interrogation. La définition de l'agent sélectionne les outils qu'une étape peut voir, au moyen de ses paramètres tools et excludedTools; examinez donc une recette et les agents qu'elle nomme avant de la lancer. Un workflow ne rend pas, à lui seul, un agent en lecture seule.
La visibilité des outils est distincte de l'autorisation. Chaque session d'étape passe par les mêmes vérifications d'autorisation et les mêmes invites d'approbation que toute autre session : les règles de portée utilisateur, administration, espace de travail, préréglage et session de la session qui a lancé l'exécution s'appliquent à chaque étape, en plus des propres règles de l'agent, et la règle applicable la plus restrictive l'emporte. Les propres règles allow de l'agent n'accordent rien que la session qui a lancé l'exécution n'autorise pas. Consultez Autorisations des sous-agents. Une veille command exécute son programme selon la politique d'autorisation de la session qui a lancé l'exécution : une règle qui demande une approbation envoie l'invite à cette session, et un refus fait échouer le nœud de veille. Les actions distantes, comme pousser une branche ou commenter une pull request, utilisent vos propres identifiants de dépôt, et la protection des branches, les vérifications requises et la politique d'approbation de votre dépôt continuent de les régir, en plus des invites d'autorisation de Kiro. L'exemple intégré de publication et de réponse vous remet une pull request verte et approuvée et ne la fusionne pas; consultez Publier et répondre. Lorsqu'un workflow vous demande d'approuver son plan, Kiro affiche le plan et rien ne s'exécute tant que vous n'avez pas répondu; lorsque /tools trust-all est activé, Kiro répond uniquement par l'option ponctuelle Allow et n'enregistre aucune règle. Dans un espace de travail non approuvé, Kiro ne charge pas les fichiers Workflow du répertoire .kiro/workflows/ de l'espace de travail; vos Workflows personnels, dans le nuage, intégrés et générés restent disponibles. Consultez Confiance de l'espace de travail.
Pour restreindre un workflow, définissez tools et excludedTools sur les agents personnalisés qu'utilisent ses étapes, fixez un maxIterations fini à chaque répétition et donnez un idleTimeoutSec aux veilles. Pour arrêter une exécution, utilisez Stop dans votre client. Retirer un fichier de recette de .kiro/workflows/ ou de ~/.kiro/workflows/ cesse de proposer cette recette locale, mais une recette de priorité inférieure portant le même nom peut prendre sa place; pour arrêter tous les workflows, désactivez le paramètre décrit sous Activer les workflows. Pour confirmer la portée d'une recette avant de vous y fier, lisez les définitions des agents qu'elle nomme et exécutez-la d'abord sur une petite entrée.
- Les exemples de workflows fournissent des points de départ complets pour l'analyse, la livraison de fonctionnalités, le dépannage et la livraison de pull requests.
- Créer des workflows traite des fichiers de recettes, des types de nœuds, des modèles, des conditions d'arrêt, des agents, des modèles d'IA et de la validation.
- Exécuter et gérer les workflows explique la progression, l'interaction avec les étapes, les commandes et la récupération dans les différents clients.
- Agents personnalisés explique comment définir les agents utilisés par les étapes de workflow.
Workflows