Exécuter des agents en parallèle

Ce guide vous montre comment exécuter plusieurs agents en même temps sans qu’ils s’écrasent mutuellement le travail.

L’unité d’isolation est l’espace, pas l’agent

Quand du travail démarre dans un espace, Control Center provisionne un checkout avec copie sur écriture par dépôt enregistré, sous la racine propre à cet espace, sur une branche dérivée du modèle de nom de branche de l’espace de travail. Chaque agent de l’espace obtient ensuite son propre répertoire de travail superposé — mais les répertoires superposés partagent le répertoire repos/ de cet espace.

Donc :

Deux agents dans des espaces différents travaillent dans des checkouts différents, sur des branches différentes. C’est une véritable isolation.
Deux agents dans le même espace travaillent dans le même checkout, sur la même branche. Leurs chemins superposés diffèrent, de sorte que le verrou de chemin de lancement (qui ne sérialise les exécutions que lorsqu’elles demandent le répertoire de travail identique) ne les sérialise pas non plus. Ils peuvent écrire les mêmes fichiers en même temps.

La règle qui en découle : un espace par tâche parallèle.

Exécuter des tâches en parallèle — des espaces distincts

Ouvrez un espace avec l’agent A et envoyez-lui une tâche.
Ouvrez un second espace avec l’agent B et envoyez-lui une tâche différente.
Les deux se lancent immédiatement, chacun dans le checkout de son propre espace, sur sa propre branche.

C’est la recette à utiliser chaque fois que les agents modifieront des fichiers.

Travailler ensemble dans un seul espace — plusieurs mentions

Dans un même espace, mentionnez avec @ plus d’un agent :

@alice refactor the auth module. @bob review what alice lands.

Les deux agents se lancent en parallèle et diffusent en continu dans le même espace, étiquetés par expéditeur. Comme ils partagent le checkout de l’espace, réservez ce mode à la collaboration — un agent qui écrit, un qui lit, ou deux agents qui raisonnent sur le même arbre — et non à deux modifications indépendantes.

Se déployer en éventail depuis un pipeline

Le modèle pr_review intégré est l’exemple livré d’un déploiement en éventail : plusieurs nœuds de révision s’exécutent en parallèle à partir d’un seul déclencheur, et un nœud Consolidate (join) réunit leurs constats dans un seul rapport. Lancez-le depuis l’écran des pipelines et chaque relecteur est lancé en parallèle.

L’éditeur de pipeline masque la sentinelle terminale et la recâble pour qu’elle attende chaque puits actif lorsque vous ajoutez ou connectez une étape, de sorte que les branches que vous dessinez vous-même s’exécutent bel et bien.

Regarder les agents s’exécuter

Observabilité → En direct (pied de la barre latérale → Observabilité, puis l’onglet En direct) affiche la liste des agents de cet espace de travail, rafraîchie chaque seconde : l’état (En cours / Inactif / En veille / Interrompu), ce que fait chacun, les jetons et le coût de sa dernière exécution, et une commande d’arrêt pour un processus en cours. Sélectionner une ligne ouvre un tiroir de transcription en direct.

Paramètres → Espace de travail → Agents affiche la même liste avec un vocabulaire d’état différent, qui privilégie ce qui demande attention et qui est dérivé de l’historique d’exécution de chaque agent — En cours, Bloqué, Échoué, Inactif, Aucune exécution — triés de manière à ce que tout ce qui demande attention remonte en tête. L’onglet Journaux de chaque agent contient son propre historique d’exécution.

Les deux surfaces sont limitées à l’espace de travail actif.

Gérer les conflits

D’un espace à l’autre, chaque espace se trouve sur sa propre branche, de sorte qu’une collision se manifeste comme un conflit de fusion Git ordinaire au moment de fusionner la deuxième demande de tirage. Résolvez-le comme n’importe quel conflit de fusion.

À l’intérieur d’un même espace, il n’y a ni frontière de branche ni verrou : les agents écrivent les mêmes fichiers en direct et le perdant est tout simplement écrasé. Si vous en venez à vouloir que deux agents modifient des fichiers dans un même espace, répartissez plutôt le travail entre deux espaces.

Pour réduire les collisions dans un cas comme dans l’autre :

Donnez à chaque agent un périmètre distinct — des fichiers différents, des modules différents.
Utilisez le graphe de code pour vérifier ce qu’un changement touche avant de lancer l’agent. Voir Rechercher du code avec le graphe de code.
Examinez et fusionnez rapidement la demande de tirage de chaque agent.

Considérations sur les ressources

Chaque agent en cours d’exécution coûte :

Un checkout d’espace — négligeable sur le disque tant que la copie sur écriture est disponible ; sous Windows, un git worktree. Un système de fichiers incapable d’effectuer un reflink fait échouer le provisionnement plutôt que de copier.
Un processus sur l’hôte du serveur
Des jetons de modèle, qui s’accumulent par agent

Les coûts aboutissent dans Observabilité → Aperçu. Notez qu’un tour interactif normal n’a aucun plafond de dépenses ; voir Gérer les coûts pour les deux commandes qui en ont un.