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 d'équipe fiable : éléments de travail clairs, propriété explicite, état Kanban des agents, isolation des branches, visibilité du panneau de contrôle et barrières de fusion.
Quand activer
- La tâche implique plusieurs agents, outils, harnais, branches ou arbres de travail.
- L'utilisateur mentionne l'orchestration d'équipe, le Kanban d'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.
- Le déploiement d'agents existant produit des résultats mais pas un produit fusionnable.
Modèle opérationnel
Traitez 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 : en attente, prêt, en cours, en revue, bloqué, fusionné ou archivé.
- Preuves : tests, captures d'écran, logs, notes de revue ou rapports d'évaluation.
- Barrière de fusion : la condition exacte qui permet l'intégration.
Kanban d'agents
Utilisez le Kanban d'agents lorsque le travail doit être visible entre les sessions.
| Colonne | Signification | Critères de sortie |
|---|---|---|
| En attente | É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 |
| En revue | Le travail est terminé mais pas fusionné | Tests, révision de diff et vérification des risques réussis |
| Bloqué | Nécessite une entrée externe ou a échoué à la barrière | Le bloqueur a un propriétaire et une prochaine action |
| Fusionné | Intégré dans la ligne principale | PR fusionné ou main local mis à jour |
| Archivé | N'est plus pertinent | Raison enregistrée |
Chaque carte doit correspondre à ce schéma :
{
"id": "agent-card-001",
"title": "Développer une compétence de flux de travail 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 basé sur l'équipe
- Façonner le tableau : convertir l'ambition floue en éléments de travail avec propriétaires et barrières de fusion.
- Choisir le mode d'exécution : agent unique, mode flux de travail dynamique, dmux/tmux, déploiement d'arbre de travail, ou orchestrateur de bureau externe.
- Assigner les limites : un propriétaire par carte, périmètre de fichiers clair, et aucune écriture concurrente sans intégrateur.
- Exécuter les agents : chaque agent écrit des preuves et des notes de transfert, pas seulement du code.
- Réviser en séquence : tests d'abord, puis révision 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 d'état.
- Extraire une compétence réutilisable : si le modèle 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 d'agents.
- Propriétaire, harnais, branche, arbre de travail et dernière impulsion.
- Liens vers les artefacts de transfert, tests, captures d'écran et PRs.
- Bloqueurs regroupés par propriétaire et action de déblocage.
- Préparation à la fusion par barrière, pas par intuition.
- Candidats de flux de travail 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 barrière a échoué, et qu'est-ce qui peut être fusionné en toute sécurité ?
Compatibilité avec le flux de travail dynamique
Lorsqu'une carte nécessite un mode flux de travail dynamique :
- Mettez le harnais 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 à En revue.
- Promouvez le harnais 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, aucun propriétaire ni barrière 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 concurrentes : des agents parallèles modifient les mêmes fichiers sans arbres de travail.
- Aucun artefact produit : le processus produit des docs 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.
- Preuves de tests et d'évaluation.
- Bloqueurs avec propriétaire et prochaine action.
- Nouveaux candidats de compétences partagées.