Que fait Orchestration d'équipe d'agents ?
Utilisez cette compétence lorsque les agents sont gérés comme une équipe plutôt que comme un assistant unique. L'objectif est de rendre l'orchestration basée sur une équipe fiable : éléments de travail clairs, propriété explicite, état Kanban pour agents, isolation des branches, visibilité du panneau de contrôle et portes de fusion.
Quand activer
- La tâche implique plusieurs agents, outils, environnements d'exécution, branches ou arbres de travail.
- L'utilisateur mentionne l'orchestration d'équipe, le Kanban pour agents, l'escouade, le chef d'orchestre, le panneau de contrôle, le gestionnaire, l'application de bureau, Zellij, tmux, Hermes, Devin, Codex, Claude Code, ou le travail multi-agents.
- Un projet nécessite un état de flux de travail partagé entre personnes et agents.
- La répartition existante des agents produit des résultats mais pas un produit fusionnable.
Modèle opérationnel
Considérez chaque agent comme un coéquipier avec un contrat restreint :
- Propriétaire : la personne ou l'agent responsable de l'élément de travail.
- Périmètre : fichiers, branche, surface d'outil et zones interdites.
- État : backlog, prêt, en cours, revue, bloqué, fusionné ou archivé.
- Preuve : tests, captures d'écran, journaux, notes de revue ou rapports d'évaluation.
- Porte de fusion : la condition exacte qui autorise l'intégration.
Kanban pour agents
Utilisez le Kanban pour agents lorsque le travail doit être visible entre sessions.
| Colonne | Signification | Critère de sortie |
|---|---|---|
| Backlog | Élément de travail candidat, pas encore façonné | Critères d'acceptation rédigés |
| Prêt | Façonné et assignable | Propriétaire et branche/arbre de travail assignés |
| En cours | L'agent travaille activement | Artefact de transfert et fichiers modifiés existent |
| Revue | Travail terminé mais non fusionné | Tests, revue de diff et vérification des risques réussis |
| Bloqué | Nécessite une contribution externe ou a échoué à la porte | Le bloqueur a un propriétaire et une prochaine action |
| Fusionné | Intégré à la branche principale | PR fusionnée ou branche principale locale mise à jour |
| Archivé | N'est plus pertinent | Raison enregistrée |
Chaque carte doit correspondre à ce schéma :
{
"id": "agent-card-001",
"title": "Construire une compétence de workflow dynamique",
"owner": "codex",
"state": "running",
"branch": "product/dynamic-workflow-team-orchestration",
"worktree": ".",
"acceptance": [
"La compétence existe",
"Les tests couvrent les concepts requis",
"L'artefact de contenu contient des angles vidéo et article"
],
"merge_gate": "lint, tests ciblés et vérification du catalogue réussis",
"handoff": "path/to/handoff.md"
}
Flux d'orchestration d'équipe
- Façonner le tableau : convertir une ambition floue en éléments de travail avec propriétaires et portes de fusion.
- Choisir le mode d'exécution : agent unique, mode workflow dynamique, dmux/tmux, déploiement arborescent, ou orchestrateur de bureau externe.
- Assigner les limites : un propriétaire par carte, périmètre de fichier clair, et pas d'écritures qui se chevauchent sans intégrateur.
- Exécuter les agents : chaque agent écrit des preuves et des notes de transfert, pas seulement du code.
- Revoir séquentiellement : tests d'abord, puis revue de diff, puis vérifications de sécurité/risques, puis polissage contenu/produit.
- Fusionner délibérément : un intégrateur résout les conflits et met à jour le panneau de contrôle ou l'artefact de statut.
- Extraire une compétence réutilisable : si le motif de carte se répète, promouvez-le dans
skills/.
Exigences du panneau de contrôle
Un panneau de contrôle utile pour l'orchestration d'équipe doit afficher :
- Les éléments de travail actifs et leur état Kanban pour agents.
- Propriétaire, environnement d'exécution, branche, arbre de travail et dernier battement de cœur.
- Liens vers les artefacts de transfert, tests, captures d'écran et PR.
- Bloqueurs regroupés par propriétaire et action de déblocage.
- État de préparation à la fusion par porte, pas par intuition.
- Candidats de workflow réutilisables qui devraient devenir des compétences partagées.
N'ajoutez pas plus d'automatisation tant que l'opérateur ne peut pas répondre : qui possède ceci, qu'est-ce qui a changé, quelle porte a échoué, et qu'est-ce qui peut être fusionné en toute sécurité ?
Compatibilité du workflow dynamique
Lorsqu'une carte nécessite le mode workflow dynamique :
- Placez l'environnement d'exécution local à la tâche sous le propriétaire de la carte.
- Stockez les entrées et sorties sur la carte.
- Exigez une évaluation avant de passer de En cours à Revue.
- Promouvez l'environnement d'exécution en compétence partagée seulement après une utilisation répétée.
Modes d'échec à surveiller
- Soupe d'agents : de nombreux agents en cours d'exécution, sans propriétaire ni porte de fusion.
- Travail invisible : une sortie utile existe uniquement dans une transcription de chat.
- Théâtre de tableau : un tableau Kanban existe mais les cartes n'ont pas de critères d'acceptation.
- Écritures qui se chevauchent : des agents en parallèle modifient les mêmes fichiers sans arbres de travail.
- Aucun artefact produit : le processus produit des documents mais aucune surface exécutable ou publiable.
Standard de sortie
Terminez chaque passe d'orchestration avec :
- Modifications du tableau/des cartes.
- Branches fusionnées ou en attente.
- Tests et preuves d'évaluation.
- Bloqueurs avec propriétaire et prochaine action.
- Nouveaux candidats de compétences partagées.