Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.4 · SDK 2.6.7. Testo inglese

Modifiche multi-modello verificate

Stato: attivo Ambito: stato attuale Ultima revisione: 2026-08-21 Responsabile: runtime di AX Code

Una pagina di flusso di lavoro per il compito «Ho una modifica consequenziale, voglio più di un tentativo e voglio che i controlli del repository stesso decidano quale tentativo vale la pena conservare».

Per il riferimento delle modalità — flag, chiavi di configurazione, input di classifica — vedi Modalità di esecuzione. Questa pagina è il compito dall’inizio alla fine.

Quando ne vale la pena

Eseguire più modelli costa diverse volte quanto eseguirne uno. Conviene quando la modifica è consequenziale e il fallimento è costoso da scoprire dopo: un refactoring attraverso i confini dei moduli, una migrazione, una correzione in codice sensibile alla sicurezza, o una modifica per cui davvero non sai quale approccio sia giusto.

Non conviene per una modifica di una riga, una rinomina o qualsiasi cosa che potresti verificare leggendo.

Due strumenti diversi

Usa council per decidere che cosa fare: dirama una domanda di progettazione o di revisione verso più provider connessi e aggrega le risposte in esiti di consenso, maggioranza stretta, minoranza e singoli, con round di dibattito anonimo facoltativi. È consultivo. L’accordo tra modelli non è una prova di correttezza; è un segnale su quanto la domanda sia contestata.

Usa arena per decidere quale implementazione conservare.

Il flusso di lavoro implement di Arena

1. Prepara

La modalità implement richiede un progetto Git con almeno un commit e un worktree primario pulito. I worktree dei contendenti vengono creati da un commit di base esatto e non possono ereditare modifiche non committate, quindi fai commit o stash prima.

Ti servono anche almeno due modelli selezionabili distinti su provider connessi (un gateway condiviso è supportato) e modes.arena.enabled: true.

2. Esegui

/arena <task description>

Ogni contendente ottiene un proprio worktree Git creato dal commit di base registrato, e un agente implement vi gira dentro. Il tuo albero di lavoro primario non viene modificato dai contendenti.

3. Che cosa fa AX Code con ogni candidato

• Cattura in un’istantanea le modifiche tracciate e non tracciate del contendente in un commit durevole di ramo, inclusi gli eventuali commit fatti dall’agente stesso.
• Esegue i comandi di verifica del progetto rilevati — typecheck, test, lint — ma solo dopo che è stata catturata una patch non vuota. Una patch vuota non può vincere.
• Classifica prima la verifica per impostazione predefinita: sono idonee a vincere solo le patch completate, non vuote, che superano la verifica. Tra i candidati che passano preferisce rischio più basso e patch più diverse.

4. Decidi

Il rapporto fornisce percorsi dei worktree, nomi dei rami e intervalli di commit.

AX Code non unisce il vincitore. Ispeziona, unisci o fai cherry-pick tu stesso. È deliberato: la verifica significa «i controlli configurati sono passati su questa patch», che è un segnale reale ma non sostituisce la revisione.

5. Rivedi e, se serve, inverti

Una volta che un candidato è nel tuo albero, i comandi di prova si applicano come di consueto:

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

Vedi Prove di esecuzione.

Che cosa significa qui «verificato», con precisione

Significa: i comandi di typecheck, lint e test rilevati del progetto sono stati eseguiti contro la patch di quel candidato, e sono passati.

Non significa che la modifica sia corretta, completa, sicura o ben progettata. Se la suite di test non copre il comportamento modificato, un candidato che passa prova solo che nulla di già coperto si è rotto. La verifica alza il minimo; non certifica il massimo.

Non si estende nemmeno alla modifica interattiva ordinaria. I candidati Arena e l’applicazione di refactoring vincolata eseguono i controlli; un edit o write normale in una sessione regolare non lo fa automaticamente. Esegui verify_project quando vuoi che quelle prove siano registrate per un’esecuzione ordinaria.

Costo e modi di fallimento

• Il costo scala con i contendenti. Ognuno esegue un agente implement completo.
• Un worktree sporco ferma l’esecuzione prima che accada altro, per progettazione.
• Meno di due modelli distinti rende il confronto privo di senso, e lo strumento lo segnala invece di inventare una classifica.
• Tutti i candidati possono fallire la verifica. È un risultato utile: di solito significa che il compito era sottespecificato o che i controlli del repository sono più severi di quanto gli agenti avessero assunto.

Correlati

• Modalità di esecuzione — riferimento completo per council, arena e le altre modalità
• Prove di esecuzione — rivedere e invertire il risultato
• Perché AX Code — perché la classifica che mette prima la verifica è il cuneo
• Buone pratiche di instradamento multi-modello — separare il lavoro premium da quello di supporto