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.

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

Quand du travail démarre dans un espace, Control Center provisionne un checkout en copie sur écriture par dépôt enregistré, sous la racine propre de cet espace, sur une branche dérivée du modèle de branche de l’espace de travail. Chaque agent de l’espace dispose alors de son propre répertoire de travail en superposition — mais ces superpositions partagent le répertoire repos/ de l’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 de superposition diffèrent, si bien que le verrou de chemin du 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 au même moment.

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 sont lancés immédiatement, chacun dans le checkout de son espace, sur sa propre branche.

C’est la méthode à employer dès que les agents vont modifier des fichiers.

Travailler ensemble dans un même espace — plusieurs mentions

Dans un seul espace, mentionnez plusieurs agents avec @ :

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

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

Répartir depuis un pipeline

Le modèle pr_review intégré est l’exemple livré d’une répartition en éventail : plusieurs nœuds relecteurs s’exécutent simultanément à partir d’un même déclencheur et un nœud Consolidate (join) replie 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 ; les branches que vous dessinez vous-même s’exécutent donc bien.

Surveiller leur exécution

Observabilité → En direct (pied de la barre latérale → Observabilité, puis l’onglet En direct) affiche l’effectif d’agents de cet espace de travail, rafraîchi chaque seconde : le statut (en cours / inactif / en veille / interrompu), ce que fait chacun, les jetons et le coût de sa dernière exécution, ainsi qu’une commande d’arrêt pour un processus en cours. Sélectionner une ligne ancre un volet de transcription en direct.

Paramètres → Espace de travail → Agents affiche le même effectif avec un vocabulaire de statut différent, axé sur ce qui demande attention et dérivé de l’historique d’exécution de chaque agent — en cours, bloqué, échoué, inactif, jamais exécuté — trié de sorte 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

Entre espaces, chacun est sur sa propre branche : une collision se manifeste donc comme un conflit de fusion Git ordinaire au moment où vous fusionnez la seconde pull request. 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 simplement écrasé. Si vous êtes tenté de faire modifier un même espace par deux agents, 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’une modification touche avant de lancer le travail. Voir Rechercher du code avec le graphe de code.
Examinez et fusionnez sans tarder la pull request 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 de faire un reflink fait échouer le provisionnement au lieu de copier.
Un processus sur l’hôte du serveur
Des jetons de modèle, qui s’accumulent par agent

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