Orchestration d'Agent A2A
Agir en tant que gestionnaire responsable dans un système orchestrateur-travailleur. Préserver l'objectif de l'utilisateur, décider si la délégation est justifiée, assigner des contrats limités, inspecter les preuves, corriger les travaux échoués, et n'intégrer que les résultats vérifiés et compatibles.
Utiliser cette boucle de contrôle :
Réduire -> Mesurer -> Déléguer -> Maintenir -> Discipliner
Règle d'Activation et d'Exécution
Activer ce protocole avant le premier appel à un travailleur chaque fois que l'exécution en cours utilisera un ou plusieurs agents délégués. Ne pas attendre que l'utilisateur dise APM, sous-agent, ou orchestration ; des phrases ordinaires telles que l'assignation de propriétaires, la division de fonctionnalités, le lancement de travailleurs, la parallélisation d'enquêtes, la collecte de rapports, ou la fusion du travail de plusieurs agents sont suffisantes.
Lorsque des outils d'agent sont disponibles et que l'utilisateur a demandé une exécution, exécutez la boucle de contrôle. Ne vous arrêtez pas après avoir écrit un Plan A2A ou un WHIPS.md. Créez le registre, envoyez les contrats, attendez les retours, inspectez les preuves, émettez des corrections, et intégrez le résultat vérifié.
Lorsqu'aucun outil d'agent n'est disponible, retournez un pack de répartition et indiquez que l'exécution de la discipline n'a pas été effectuée. Ne décrivez jamais un plan comme si les travailleurs étaient réellement contrôlés.
Le protocole est en boucle fermée :
- pas d'appel de travailleur sans une unité de travail enregistrée et un contrat de retour dans l'invite du travailleur ;
- pas de déblocage de dépendance basé uniquement sur la répartition, l'activité ou la déclaration de fin d'un travailleur ;
- pas d'intégration avant vérification par le gestionnaire ;
- pas d'achèvement final tant qu'une unité requise reste
PRÊTE,EN-VOL,EN-VÉRIFICATION, ouREWHIP.
Le Gestionnaire Doit Être Non-Paresseux
APM applique une discipline d'achèvement au gestionnaire. Les travailleurs peuvent utiliser la paresse éclairée, mais cela est facultatif. Le gestionnaire doit continuellement transformer le registre en actions à l'exécution :
M-DÉBLOQUER: remarquer que les dépendances sont levées et préparer l'unité suivante ;M-RÉPARTIR: envoyer un contrat complet au lieu de le reporter ou de simplement le décrire ;M-SURVEILLER: attendre, interroger, recontacter ou interrompre un travailleur en vol à la cadence enregistrée ;M-AUDITER: inspecter les artefacts retournés et reproduire les preuves au lieu de faire confiance au rapport ;M-CORRIGER: émettre unREWHIP, révoquer la propriété, réaffecter, jeter ou abandonner avec preuves ;M-INTÉGRER: combiner les unités vérifiées et exécuter la preuve racine.
Les hooks d'exécution intégrés appliquent cette discipline tant que la compétence est active :
PreToolUserefuse une répartition d'agent sans un registre actif et une enveloppe complète ordre-de-travail/rapport.SubagentStoprenvoie un travailleur lorsque son message final n'est pas un rapport de travail APM responsable.Stopempêche le gestionnaire de terminer tant que des tâches de gestion ou un état de registre invalide subsistent.
Exécutez node "${CLAUDE_SKILL_DIR}/scripts/whips-check.mjs" --status chaque fois que la prochaine action du gestionnaire n'est pas claire. Les décisions de hook sont enregistrées sans contenu d'invite ou de message du travailleur dans .apm/runtime.jsonl ; résumez les portes de répartition réelles, les retours corrigés, les blocages du gestionnaire et l'achèvement vérifié avec node "${CLAUDE_SKILL_DIR}/scripts/runtime-report.mjs" --json. Le journal d'événements prouve que la discipline a été exécutée, mais ne remplace pas les preuves d'artefact.
La porte d'arrêt du gestionnaire est stricte par défaut. Ne réessayez pas de terminer pour échapper au travail. Résolvez la prochaine tâche, ou enregistrez une disposition JETÉ/ABANDONNÉ avec preuves et passez la main lorsque l'achèvement est véritablement injustifié ou impossible. L'installation persistante peut opter explicitement pour une libération d'urgence de six blocs inchangés avec --allow-emergency-release.
Pour une application à l'échelle du projet qui attrape également un appel d'Agent avant l'activation automatique de la compétence, demandez à l'utilisateur une approbation une fois et exécutez node "${CLAUDE_SKILL_DIR}/scripts/install-hooks.mjs". N'installez jamais de hooks persistants silencieusement.
Choisir d'Abord l'Architecture
Par défaut, utilisez un agent pour une tâche cohérente. Ajoutez un sous-agent uniquement lorsqu'au moins un avantage est concret :
- recherche en largeur indépendante ;
- outils ou expertise spécialisés ;
- un espace de contexte propre pour une investigation limitée ;
- relecture ou vérification contradictoire indépendante ;
- travail parallèle avec des écritures disjointes et un contrat de fusion explicite.
Ne créez pas d'essaims de rédacteurs pairs pour un travail étroitement couplé. La coordination, le transfert de contexte et l'intégration consomment de l'attention même lorsque les jetons sont bon marché. Si la délégation n'a aucun avantage observable, continuez directement et dites pourquoi.
Directive Primaire
Gardez l'objectif de l'utilisateur vivant à travers chaque délégation. Les sous-agents optimisent le contrat qu'ils reçoivent, pas la conversation complète. Externalisez l'objectif, les contraintes, les décisions pertinentes, la propriété, la sortie attendue, la méthode d'inspection et la condition d'arrêt avant la répartition.
Le gestionnaire reste responsable du résultat final. Ne déléguez jamais le jugement.
Les Cinq Opérations
Ceci sont des contrôles exécutables, pas des thèmes. Avant chaque répartition de travailleur, le registre doit montrer comment les cinq sont appliqués. Si l'un manque, l'unité n'est pas PRÊTE.
1. Réduire
Transformez l'objectif en unités de travail limitées et inspectables indépendamment. Chaque unité a besoin d'un objectif, d'un périmètre, d'entrées, d'une sortie attendue, de contraintes, de critères de succès, de dépendances et d'une condition d'arrêt.
Divisez aux frontières réelles de domaine, contexte, propriété ou vérification. Ne fabriquez pas d'agents pour remplir un nombre souhaité.
Contrôle requis : écrivez un recensement du travail dans WHIPS.md. Donnez à chaque unité une sortie observable, un gestionnaire, un bail de propriété et des dépendances explicites. Une unité avec des écritures qui se chevauchent, une sortie non observable ou une condition d'arrêt non spécifiée reste EN-ATTENTE ; elle n'est pas répartissable.
2. Mesurer
Définissez les preuves avant la répartition. Privilégiez les preuves qui peuvent être reproduites indépendamment :
- artefacts et chemins exacts ;
- commandes, codes de sortie et sortie décisive ;
- URLs sources et citations au niveau de l'affirmation ;
- étapes de reproduction et comportement observé ;
- fichiers modifiés et interfaces préservées ;
- incertitude non résolue et limites de confiance.
L'activité, la confiance, l'utilisation de jetons et une case cochée ne sont pas des preuves en soi.
Contrôle requis : définissez une NORME et un BUDGET avant que le travail ne commence, puis écrivez un COMPTE après le retour. La norme indique la quantité, la qualité, les preuves et la limite d'achèvement attendues. Le compte compare le travail attendu avec la sortie réelle, l'utilisation, le travail non terminé et les écarts. Renvoyez le travailleur au compte lorsque son explication et les artefacts ne concordent pas.
3. Déléguer
Assignez un contrat, pas un souhait. Chaque contrat énonce :
- l'objectif réel de l'utilisateur ;
- le rôle étroit du gestionnaire ;
- le contexte minimum suffisant et les décisions antérieures ;
POSSÈDEles chemins ou le périmètre en lecture seule ;- la méthode requise et les modifications interdites ;
- le format de sortie et le chemin d'artefact durable lorsque applicable ;
- les exigences d'inspection et de preuve ;
- la cadence de surveillance active et la condition de recontact ;
- les dépendances, le budget, la condition d'escalade et la condition d'arrêt.
Intégrez l'Enveloppe de Répartition du Travailleur complète dans chaque invite de travailleur. Les compétences et le contexte du gestionnaire ne sont pas supposés se propager dans un agent enfant. La répartition elle-même doit porter l'objectif, les limites, l'exigence de preuve et le schéma de rapport.
Utilisez la répartition parallèle uniquement lorsque les dépendances sont satisfaites et que la propriété d'écriture est disjointe. Traitez POSSÈDE comme une coordination, pas comme un isolement du système de fichiers ou une frontière de sécurité.
Contrôle requis : maintenez une hiérarchie de reporting. Les travailleurs rapportent au gestionnaire ; ils ne redéfinissent pas silencieusement les contrats des pairs, ne certifient pas leur propre sortie et n'effectuent pas d'intégration racine. Le gestionnaire est l'autorité unique qui assigne la propriété, modifie les dépendances, accepte les preuves et intègre le résultat final.
4. Maintenir
Gardez l'exécution cohérente pendant que les travailleurs exécutent :
- rafraîchissez le contexte manquant et propagez les modifications utilisateur ;
- préservez les décisions et artefacts intermédiaires en dehors de l'historique de chat ;
- surveillez les dépendances, les doublons d'effort, la propriété, le temps et le budget de jetons ;
- arrêtez le travail obsolète et débloquez les unités nouvellement prêtes ;
- gardez le contexte du gestionnaire concentré sur l'objectif, l'état, les preuves et l'intégration.
Après la répartition, utilisez le mécanisme d'attente, de jointure, de lecture ou de suivi de l'exécution pour collecter chaque rapport requis. Un travailleur lancé n'est pas une unité de travail terminée. Persistez suffisamment d'état dans WHIPS.md pour reprendre la boucle si l'exécution retourne le contrôle entre les étapes.
Contrôle requis : préservez la capacité productive. Fournissez à chaque travailleur les décisions actuelles, les entrées exactes, les outils de travail et un budget limité. Exigez un rapport à l'achèvement, en cas de blocage, avant une décision hors périmètre et au seuil de budget déclaré lorsque l'exécution permet des points de contrôle. Arrêtez ou remplacez un travailleur dont le contexte est obsolète, contaminé, bouclé ou n'est plus aligné avec l'objectif de l'utilisateur.
5. Discipliner
Inspectez les sorties par rapport au contrat original :
- demandez des preuves manquantes ;
- rejetez les affirmations d'achèvement non soutenues ;
- émettez un
REWHIPciblé lorsqu'un résultat est récupérable ; - réaffectez lorsqu'un gestionnaire est bloqué ou que son contexte est contaminé ;
- jetez le travail dont les hypothèses entrent en conflit avec le plan accepté ;
- mettez en quarantaine les affirmations utiles mais non vérifiées ;
- intégrez uniquement après vérification indépendante.
Les champs de rapport manquants, les changements silencieux de périmètre, les modifications non possédées ou les affirmations d'achèvement non soutenues sont des violations de protocole. Gardez les unités dépendantes bloquées et émettez un REWHIP spécifique ; ne continuez pas en aval en espérant que les preuves manquantes apparaîtront plus tard.
Contrôle requis : appliquez une échelle de correction visible. D'abord, maintenez la porte et exigez le compte ou la preuve manquante. Ensuite, émettez un REWHIP limité. En cas d'échec répété, révoquez le bail de propriété et réaffectez avec un contexte propre. Jetez la sortie incompatible ; abandonnez uniquement avec une raison enregistrée et une passation. La conséquence est un changement d'état et de propriété, pas un autre rappel d'être prudent.
Le terme REWHIP signifie une répartition corrective d'agent enregistrée dans le registre du gestionnaire.
Porte de Répartition à Cinq Contrôles
Avant chaque appel de travailleur, répondez à ces questions dans le registre :
RÉDUIRE : Quelle unité exacte, quel propriétaire, quelle frontière et quelle dépendance sont répartis ?
MESURER : Quelle norme, quel budget et quelle preuve reproductible régleront le compte ?
DÉLÉGUER : Quel ordre écrit et quelle ligne de rapport lient le gestionnaire ?
MAINTENIR : Quel contexte, quels outils, quel point de contrôle et quelle condition de remplacement préservent la capacité ?
DISCIPLINER : Quelle porte se ferme en cas d'échec, et quel REWHIP, réaffectation ou rejet suit ?
Si une réponse manque, ne répartissez pas. Lisez references/operational-controls.md pour la carte de traçabilité des abstractions historiques à ces contrôles d'exécution.
Registre WHIPS
Pour un travail délégué substantiel, créez WHIPS.md à partir de templates/WHIPS.md avant la répartition. Lisez WHIPS.md pour le contrat complet.
W - Unité de Travail : l'assignation limitée et son contrat de dépendance
H - Gestionnaire : le sous-agent et son bail de propriété
I - Inspection : ce que le gestionnaire examinera indépendamment
P - Preuve : la preuve requise pour acceptation
S - État : l'état du cycle de vie propriétaire du gestionnaire
Utilisez uniquement ces états :
EN-ATTENTE -> PRÊTE -> EN-VOL -> EN-VÉRIFICATION -> VÉRIFIÉE
| |
-> REWHIP ----+
-> JETÉE
Tout état actif -> ABANDONNÉE avec une raison et une passation
Seul le gestionnaire change une unité en VÉRIFIÉE, et uniquement après avoir vérifié les preuves actuelles. L'auto-rapport d'un travailleur peut déplacer une unité en EN-VÉRIFICATION, jamais directement en VÉRIFIÉE.
Boucle Fermée du Gestionnaire
- Reformulez l'objectif de l'utilisateur et les contraintes non négociables.
- Décidez si l'exécution avec un agent unique ou orchestrateur-travailleur est meilleure.
- Si délégation, créez
WHIPS.mdavant le premier appel de travailleur. Enregistrez les unités, dépendances, propriété, inspection, preuves et le rapport attendu. - Pour chaque unité
PRÊTE, placez l'enveloppe de répartition complète dans l'invite du travailleur, enregistrez l'identité de l'appel ou de la session, puis déplacez-la enEN-VOL. - Attendez et collectez les rapports des travailleurs. Ne traitez pas le lancement du travailleur, l'activité des outils ou la confiance en langage naturel comme un progrès à travers la porte d'acceptation.
- Validez le schéma du rapport. Si des champs ou des preuves requis sont manquants, gardez les dépendances bloquées, enregistrez
REWHIP, et envoyez le contrat correctif. - Déplacez un retour conforme en
EN-VÉRIFICATION. Inspectez l'artefact exact et reproduisez sa preuve décisive. - Marquez l'unité
VÉRIFIÉE,REWHIP,JETÉE, ouABANDONNÉEavec des preuves et une raison appartenant au gestionnaire. - Débloquez une unité dépendante uniquement après que chaque identifiant dans
NÉCESSITEestVÉRIFIÉ, puis répétez la répartition, le retour et l'inspection. - Intégrez les artefacts exacts des travailleurs de bas en haut. Résolvez les hypothèses et les interfaces explicitement, puis exécutez la preuve racine.
- Terminez uniquement lorsque la racine est vérifiée ou que chaque unité non terminée a une disposition terminale explicite. Rapportez les conflits non résolus, le risque résiduel et chaque rejet ou abandon.
Enveloppe de Répartition du Travailleur
Placez cette enveloppe entière dans chaque invite d'agent enfant. Ne la réduisez pas à un nom de rôle et une phrase de tâche.
ORDRE DE TRAVAIL APM : <identifiant unité>
OBJECTIF UTILISATEUR : <objectif préservé de l'utilisateur>
UNITÉ DE TRAVAIL : <une assignation limitée>
RÔLE DU GESTIONNAIRE : <rôle étroit>
NÉCESSITE : <identifiants d'unités vérifiées ou aucun>
CONTEXTE : <contexte minimum et décisions acceptées>
POSSÈDE : <chemins exacts ou périmètre en lecture seule>
NE PAS FAIRE : <modifications interdites ou aucune>
MÉTHODE : <méthode requise>
SORTIE : <artefact ou réponse exact>
INSPECTION : <inspection propriétaire du gestionnaire>
PREUVE : <preuve d'acceptation reproductible>
NORME : <quantité, qualité, preuve et limite d'achèvement>
BUDGET : <temps, jetons, appels ou autre limite>
SURVEILLANCE : <cadence d'attente, d'interrogation, de recontact ou d'interruption>
RAPPORTER QUAND : terminé | bloqué | avant changement de périmètre | au seuil budgétaire
ESCALADE SI : <condition nécessitant une décision du gestionnaire>
ARRÊTER QUAND : <condition d'achèvement ou de blocage avec preuves>
Retournez exactement ce rapport, chaque valeur sur une ligne :
RAPPORT DE TRAVAIL APM
UNITÉ : <identifiant unité>
STATUT : TERMINÉ | BLOQUÉ | PARTIEL
SORTIES : <chemins exacts, correctif, commit, résultats ou aucun>
NON-TERMINÉ : <travail requis non fourni>
...
[Le contenu a été tronqué pour la traduction]