Agents parallèles bon marché pour Codex
Invocation : cette compétence ne s'exécute que lorsque l'utilisateur l'invoque par son nom ; elle n'est jamais appliquée automatiquement. Aucune compétence d'orchestration n'invoque l'autre, et les travailleurs n'en invoquent aucune. Lorsque l'utilisateur invoque à la fois escalating-subagents et cette compétence pour une même tâche, demandez laquelle s'applique avant de lancer.
Coordinateur présumé : le modèle parent tel que l'utilisateur l'a sélectionné, typiquement GPT-6.1 Sol ; high est une recommandation d'effort initial pour évaluer, pas un paramètre que cette compétence modifie. Un parent à ultra peut déléguer de manière proactive : divulguez-le dans la première ligne de progression, recommandez high, déléguez uniquement via les envois de cette compétence, et tenez compte de toute affectation supplémentaire sous « Pinning ». Enregistrez le modèle parent réel et l'effort dans l'en-tête du registre. Le coordinateur orchestre : classer le niveau, écrire les critères « Fait signifie », décomposer en éléments, corriger les interfaces et les décisions, informer les travailleurs, envoyer les lots, capturer les instantanés, inspecter chaque enregistrement d'acceptation, trier et faire rapport. Il ne modifie jamais le code de production et ne lit jamais les transcriptions des travailleurs. Il lit les extraits de preuves requis par l'acceptation, et le patch intégré pour l'acceptation de niveau D, la validation contestée et les violations de périmètre.
Les travailleurs s'exécutent sur un seul modèle bon marché et exécutent chacun un élément assigné. Ils ne délèguent jamais, n'invoquent jamais cette compétence ni aucune compétence d'orchestration, et n'exécutent jamais l'outil d'instantané. Respectez les autorisations de l'hôte et le mode de collaboration ; le mode Plan ne permet aucune implémentation ni découverte produisant des mutations.
Chaque critère porte un ID et un type de preuve requis : behavioral (test exécuté, construction ou exécution qui exerce la modification), static (vérification de type ou lint), parse (vérification syntaxique ou d'analyse), format (vérification de formateur), ou inspection (diff révisé). Une preuve plus faible que le type du critère ne le satisfait jamais ; une vérification d'analyse satisfait un critère parse et rien de plus.
Niveaux et matrice d'affectation
Nommez le niveau dans la première ligne de progression. Toute étape peut le promouvoir ; ne jamais le rétrograder. La promotion conserve les compteurs, adopte le budget supérieur et révise les critères pour les travailleurs concernés. Dimensionnez les éléments à la matrice : un travailleur peut posséder plusieurs fichiers, alors fusionnez les éléments plutôt que de laisser tomber du travail. La validation s'exécute une fois par cycle, après que le cycle d'implémentation complet est gelé, jamais par lot ; les lots intermédiaires reçoivent un post-N capturé et vérifié avant que le lot suivant ne commence, et seulement des enregistrements provisoires de travailleurs.
| Niveau | Travail | Carte (lecture seule) | Implémenter | Valider par cycle (V) | Budget |
|---|---|---|---|---|---|
| A | Édition triviale, entièrement spécifiée, à faible risque avec une vérification concrète | 0 | 1 à low | 0 ; vérification post-capture par le coordinateur | 3 |
| B | Modification claire | 0 | ≤ 4 à medium | 1 à medium | 7 |
| C | Bogue flou ou fonctionnalité substantielle ; défaut | ≤ 3 à low/medium | ≤ 4 à medium | 1 à medium | 10 |
| D | Authentification, isolation des locataires, migrations, file/sync, modifications des données de production | ≤ 3 à medium | ≤ 4 à medium | 2 à medium avec des briefs distincts (tests + critères ; spécifications + régressions) ; le coordinateur lit le patch | 12 |
Chaque nouvelle affectation, nouvelle tentative ou continuation coûte un appel ; les travailleurs parallèles comptent individuellement ; les messages de statut et les attentes ne coûtent rien. Soit M les shards dans le lot de carte admis (0 pour un lot d'implémentation), U les éléments d'implémentation requis non encore envoyés, y compris ceux de ce lot (avant cartographie, le nombre prévu, au moins 1), et V les validateurs par cycle ; la réserve est une réparation avec sa revalidation, 1 + V. L'admission de tout lot nécessite restant ≥ M + U + V + (1 + V) ; si elle échoue, réduisez la largeur, fusionnez les éléments, ou les deux. La sérialisation change la concurrence, pas le nombre d'appels : l'admission compte chaque élément requis restant. Les nouvelles tentatives de validation (PASS non pris en charge, INCONCLUSIF) utilisent des appels de réserve. Après un ÉCHEC sur r éléments : quand restant ≥ r + V, exécutez les r réparations et l'ensemble de validation frais complet sans réserve supplémentaire, et un autre ÉCHEC termine l'exécution avec le rapport ; quand 1 + V ≤ restant < r + V, réparez restant − V éléments, validez, et rapportez les autres non résolus ; quand restant < 1 + V, arrêtez et rapportez les éléments échoués non résolus sans revalider un patch inchangé. Exemples pratiques : niveau B, quatre éléments à largeur 4 : 7 → 3 après implémenteurs → 2 après validation → un ÉCHEC sur deux éléments admet une réparation plus un validateur → 0, un élément non résolu. Niveau B avec un PASS non pris en charge : 7 → 3 → 2 → nouveau validateur → 1 → ÉCHEC → 1 < 2, arrêt. Niveau C, un lot de carte de 3 avec 4 éléments prévus : 3 + 4 + 1 + 2 = 10 admet → 7 → implémenter 4 → 3 → valider → 2 → ÉCHEC sur un élément → réparer et valider → 0. Niveau D : 3 + 4 + 2 + 3 = 12 → 9 → 5 → 3 → ÉCHEC sur un élément → 0. L'échelle n'est disponible que tant que le budget le permet ; à largeur maximale, la réserve n'admet qu'une réparation, pas chaque échelon, et le coordinateur le dit lorsqu'il choisit la largeur. La décomposition n'ajoute jamais de budget.
Échelle d'effort
Le modèle de travailleur ne change jamais ; l'effort change. medium est le défaut et l'endroit où rester.
| Échelon | Modèle | reasoning_effort | Utilisation |
|---|---|---|---|
| 0 | gpt-6-luna | low | Travail mécanique : shards de carte en lecture seule, renommages, déplacements, formatage, exécution d'une commande nommée et rapport ; aucun jugement |
| 1 | gpt-6-luna | medium | Défaut pour chaque élément Découvrir, Implémenter et Valider |
| 2 | gpt-6-luna | medium | Nouveau travailleur avec une correction concrète et le chemin d'enregistrement précédent ; la seule nouvelle tentative d'omission |
| 3 | gpt-6-luna | max | Uniquement après un échec de raisonnement confirmé à l'échelon 1 ou 2, ou un deuxième PARTIEL sans progrès |
Niveaux sautés : high est sauté car son gain observé par rapport à medium dans les évaluations de codage indépendantes n'a pas justifié un échelon, et xhigh parce que l'échelle garde un échelon d'escalade et max a apporté plus de score par dollar. Ne comblez pas l'écart.
Les briefs de l'échelon 0 disent : aucun jugement ; retournez BLOQUÉ quand un est nécessaire. Les validateurs commencent à medium dans chaque niveau. Un ÉCHEC correct n'escalade jamais un validateur. Les échecs environnementaux ne montent jamais d'échelons. Il n'y a pas d'escalade de modèle : quand l'échelle est épuisée, le coordinateur s'arrête et fait rapport.
| Constatation | Action | Compte |
|---|---|---|
| Le travailleur de l'échelon 0 retourne BLOQUÉ car un jugement est requis | Prendre la décision à l'avance quand possible ; renvoyer l'élément à l'échelon 1 | appel ; échelon → 1, pas un échec |
| Le travailleur de l'échelon 1 omet une exigence ou lit mal le brief | Échelon 2 : nouveau travailleur avec la correction et le chemin d'enregistrement précédent | appel |
| Échec de raisonnement confirmé à l'échelon 1 ou 2, ou deuxième PARTIEL sans progrès | Échelon 3 | appel + échelon |
| PARTIEL avec approche solide et progrès | Continuer au même échelon | appel |
| Le validateur retourne un PASS non pris en charge (type de preuve trop faible, instantané obsolète, ou vérification qui n'a pas été exécutée) | Rejeter ; nouveau validateur à l'échelon 2 avec des exigences de preuve explicites ; deuxième occurrence → échelon 3 ; Implémentation inchangée | appel chacun |
| Le validateur retourne un ÉCHEC correct | Validation réussie ; entrer dans le cycle de réparation : les éléments échoués escaladent selon leur propre échelle, puis l'ensemble de validation frais complet | r + V appels |
| ÉCHEC du validateur réfuté par le coordinateur avec une preuve enregistrée | Enregistrer la correction ; aucun changement d'Implémentation ; revalider uniquement si le patch change | aucun |
| Le validateur retourne INCONCLUSIF ou BLOQUÉ pour des raisons environnementales | Remédier dans les limites de l'autorisation, réessayer une fois au même échelon ; les vérifications non résolues sont portées dans le rapport comme bloquées | appel ; pas de changement d'échelon |
| L'échelon 3 échoue sur un élément | Une fois par élément : réduire l'élément (périmètre plus petit, décisions pré-prises) et réessayer à l'échelon 1 si l'admission le permet ; l'élément réduit hérite de l'historique et du budget | appel |
| Échec dans le cycle de réparation final | Arrêter ; rapporter les éléments non résolus, les preuves et la prochaine étape ; aucun autre envoi | aucun |
| L'ambiguïté bloquante change « fait » ou le risque de niveau D | Demander à l'utilisateur ; nommer le bloqueur | aucun |
Lots parallèles
Un élément rejoint un lot uniquement quand les trois conditions sont réunies : propriété disjointe (fichiers ou globs) ; dépendances satisfaites (interfaces corrigées dans le brief, aucun élément ne consomme la sortie inachevée d'un autre) ; aucun effet secondaire conflictuel (fichiers générés, schémas ou migrations, bases de données, ports, caches, fixtures de test, configuration CI). Sinon sérialiser ou fusionner. Les limites par défaut, ajustables par l'utilisateur, sont 4 rédacteurs et 3 shards en lecture seule par lot ; ce sont des heuristiques issues de la recherche sur la délégation asynchrone, pas des limites. La capacité provient de l'exécution : utilisez les créneaux annoncés par l'hôte et sa sémantique de comptage, et envoyez min(limite, créneaux disponibles). Envoyez un lot entier en un seul message. En cas d'envoi partiel, gardez les travailleurs lancés, enregistrez-les par nom, et envoyez le reste quand des créneaux se libèrent ; ne relancez jamais un élément déjà en cours d'exécution.
Chaque brief porte la liste des décisions du coordinateur (noms, interfaces, conventions choisies jusqu'à présent) car les actions intègrent des décisions et les travailleurs parallèles divergeraient autrement. L'exécution dans un espace de travail partagé sans arbres de travail est un compromis délibéré : la propriété plus les vérifications de périmètre d'instantané remplacent l'isolation physique.
Cycle de vie des preuves et gel
Les lots sont numérotés au cours de l'exécution, lots de carte, d'implémentation et de réparation inclus. Capturez base une fois et pre-N immédiatement avant le lot N ; mettez le nom de l'instantané et l'ID de l'arborescence dans chaque brief de ce lot. Les travailleurs de carte rapportent par rapport à pre-N. Les vérifications des implémenteurs sont provisoires jusqu'à la validation ; leurs enregistrements le disent et nomment pre-N. Après que chaque rédacteur et commande d'arrière-plan du lot N se sont arrêtés, capturez post-N et vérifiez names0 pre-N post-N par rapport à la propriété de ce lot (vide pour un lot de carte) avant d'envoyer quoi que ce soit d'autre ; names0 post-N pre-N+1 doit également être vide, et tout changement là est une modification hors périmètre. Un cycle est gelé quand son dernier lot d'implémentation passe cette vérification : les validateurs frais reçoivent ce post-N du lot et produisent des enregistrements d'acceptation par rapport à cet état gelé, le coordinateur vérifie également l'union du cycle depuis son premier pre jusqu'à ce post, et aucune écriture n'a lieu pendant la validation. Barrière : les validateurs d'un cycle sont envoyés ensemble et attendus ensemble, et aucune réparation ne commence avant que chacun d'eux ne soit revenu, ou ait été interrompu et confirmé comme terminé. Une réparation est un lot en soi : capturez son post-N, vérifiez-le, et exécutez l'ensemble de validation frais complet. Avant l'acceptation, capturez final ; names0 entre l'instantané validé et final doit être vide. Le détecteur...