Obtenir AX Code · GratuitDocumentation
AX Code.
fr
English繁體中文简体中文日本語한국어FrançaisDeutschBahasa IndonesiaItalianoPortuguês (Brasil)РусскийEspañolTürkçeTiếng Việt
Commencer

Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Changements multi-modèles vérifiés

Statut : Actif Portée : état actuel Dernière revue : 2026-08-21 Responsable : runtime AX Code

Une page de flux pour le travail « j’ai un changement conséquent, je veux plus d’une tentative, et je veux que les contrôles propres du dépôt décident quelle tentative vaut d’être gardée ».

Pour la référence des modes — drapeaux, clés de configuration, entrées de classement — voir Modes d’exécution. Cette page est la tâche de bout en bout.

Quand cela en vaut la peine

Exécuter plusieurs modèles coûte plusieurs fois plus qu’en exécuter un. Cela se justifie lorsque le changement est conséquent et que l’échec est coûteux à découvrir plus tard : un remaniement à travers les frontières de modules, une migration, un correctif dans du code sensible à la sécurité, ou un changement dont vous ne savez vraiment pas quelle approche est la bonne.

Cela n’en vaut pas la peine pour une modification d’une ligne, un renommage, ou tout ce que vous pourriez vérifier en lisant.

Deux outils différents

Outil Ce qu’il produit Écrit des fichiers ?
council avis de revue indépendants, agrégés Non
arena implémentations candidates, classées Seulement dans des worktrees isolés

Utilisez council pour décider quoi faire — il disperse une question de conception ou de revue vers plusieurs fournisseurs connectés et agrège les réponses en constats de consensus, de majorité stricte, de minorité et de singleton, avec des tours de débat anonyme facultatifs. C’est consultatif. L’accord entre modèles n’est pas une preuve d’exactitude ; c’est un signal sur le degré de contestation de la question.

Utilisez arena pour décider quelle implémentation garder.

Le flux d'implémentation de l'arène

1. Préparer

Le mode implémentation exige un projet Git avec au moins un commit et un worktree principal propre. Les worktrees des concurrents sont créés depuis un commit de base exact et ne peuvent pas hériter de changements non validés, donc validez ou mettez de côté d’abord.

Il vous faut aussi au moins deux modèles sélectionnables distincts sur des fournisseurs connectés (une passerelle partagée est prise en charge), et modes.arena.enabled: true.

2. Exécuter

/arena <task description>

Chaque concurrent obtient son propre worktree Git créé depuis le commit de base enregistré, et un agent d’implémentation s’y exécute. Votre arbre de travail principal n’est pas modifié par les concurrents.

3. Ce qu'AX Code fait de chaque candidat

  • Instantané des changements suivis et non suivis du concurrent dans un commit de branche durable, y compris les commits que l’agent a faits lui-même.
  • Exécution des commandes de vérification de projet détectées — vérification de types, tests, lint — mais seulement après la capture d’un correctif non vide. Un correctif vide ne peut pas gagner.
  • Classement vérification d’abord par défaut : seuls les correctifs achevés, non vides et qui passent la vérification sont éligibles pour gagner. Parmi les candidats qui réussissent, il préfère un risque plus bas et des correctifs plus divers.

4. Décider

Le rapport vous donne les chemins de worktree, les noms de branches et les plages de commits.

AX Code ne fusionne pas le gagnant. Inspectez, fusionnez ou faites un cherry-pick vous-même. C’est voulu : la vérification signifie « vos contrôles configurés ont réussi sur ce correctif », ce qui est un signal réel mais pas un substitut de revue.

5. Revoir et, si besoin, inverser

Une fois un candidat dans votre arbre, les commandes de preuves s’appliquent comme d’habitude :

ax-code graph <sessionID>       # what the winning run actually did
ax-code risk <sessionID>        # heuristic risk signals for the change
ax-code session rollback <sessionID> --dry-run

Voir Preuves d’exécution.

Ce que « vérifié » signifie ici, précisément

Cela signifie : les commandes détectées de vérification de types, de lint et de tests du projet ont tourné contre le correctif de ce candidat, et elles ont réussi.

Cela ne signifie pas que le changement est correct, complet, sûr ou bien conçu. Si votre suite de tests ne couvre pas le comportement modifié, un candidat qui réussit prouve seulement que rien de déjà couvert n’a cassé. La vérification relève le plancher ; elle ne certifie pas le plafond.

Cela ne s’étend pas non plus à l’édition interactive ordinaire. Les candidats d’Arena et l’application de remaniement sous porte exécutent des contrôles ; un edit ou write normal dans une session ordinaire ne le fait pas automatiquement. Exécutez verify_project lorsque vous voulez que ces preuves soient enregistrées pour une exécution ordinaire.

Coût et modes d'échec

  • Le coût croît avec les concurrents. Chacun exécute un agent d’implémentation complet.
  • Un worktree sale arrête l’exécution avant toute autre chose, par conception.
  • Moins de deux modèles distincts rend la comparaison sans signification, et l’outil le signale au lieu d’inventer un classement.
  • Tous les candidats peuvent échouer à la vérification. C’est un résultat utile : cela signifie en général que la tâche était sous-spécifiée ou que les contrôles du dépôt sont plus stricts que ce que les agents supposaient.