Esta página é uma tradução da documentação em inglês. Comandos, identificadores e exemplos permanecem iguais. Runtime 7.24.4 · SDK 2.6.7. Original em inglês

Mudanças verificadas com vários modelos

Status: Ativo Escopo: estado atual Última revisão: 2026-08-21 Responsável: runtime do AX Code

Uma página de fluxo para a tarefa: «Tenho uma mudança importante, quero mais de uma tentativa e quero que as verificações do próprio repositório decidam qual tentativa vale a pena manter.»

Para a referência do modo — sinalizadores, chaves de configuração e entradas de classificação — veja Modos de execução. Esta página é a tarefa de ponta a ponta.

Quando isso vale a pena

Executar vários modelos custa várias vezes mais do que executar um. Compensa quando a mudança é importante e descobrir a falha depois sai caro: uma refatoração que cruza limites de módulo, uma migração, uma correção em código sensível à segurança, ou uma mudança em que você realmente não sabe qual abordagem é a certa.

Não vale a pena para uma edição de uma linha, uma renomeação ou qualquer coisa que você possa conferir apenas lendo.

Duas ferramentas diferentes

Use council para decidir o que fazer — ele espalha uma pergunta de desenho ou de revisão para vários provedores conectados e agrega as respostas em achados de consenso, de maioria estrita, de minoria e isolados, com rodadas opcionais de debate anônimo. É consultivo. A concordância entre modelos não é prova de correção; é um sinal de quanto a pergunta está em disputa.

Use arena para decidir qual implementação manter.

O fluxo Arena implement

1. Preparar

O modo de implementação exige um projeto Git com pelo menos um commit e uma worktree primária limpa. As worktrees dos concorrentes são criadas a partir de um commit de base exato e não podem herdar mudanças não confirmadas; faça commit ou use stash primeiro.

Você também precisa de pelo menos dois modelos selecionáveis e distintos, em provedores conectados (um gateway compartilhado é suportado), e de modes.arena.enabled: true.

2. Executar

/arena <task description>

Cada concorrente recebe a própria worktree Git, criada a partir do commit de base registrado, e um agente de implementação roda nela. A árvore de trabalho primária não é modificada pelos concorrentes.

3. O que o AX Code faz com cada candidato

• Grava em instantâneo as mudanças rastreadas e não rastreadas do concorrente em um commit durável de branch, inclusive os commits que o próprio agente fez.
• Executa os comandos de verificação detectados do projeto — verificação de tipos, teste e lint — mas somente depois que um patch não vazio é capturado. Um patch vazio não pode vencer.
• Classifica com verificação primeiro, por padrão: só patches concluídos, não vazios e que passam na verificação podem vencer. Entre os candidatos aprovados, prefere menor risco e patches mais diversos.

4. Decidir

O relatório informa os caminhos das worktrees, os nomes das branches e os intervalos de commit.

O AX Code não mescla o vencedor. Inspecione, mescle ou faça cherry-pick você mesmo. Isso é deliberado: verificação significa que as verificações configuradas passaram neste patch, o que é um sinal real, mas não substitui a revisão.

5. Revisar e, se preciso, reverter

Quando um candidato está na sua árvore, os comandos de evidência valem como de costume:

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

Veja Evidência de execução.

O que «verificado» significa aqui, com precisão

Significa que os comandos detectados de verificação de tipos, de lint e de teste do projeto rodaram contra o patch desse candidato e passaram.

Não significa que a mudança esteja correta, completa, segura ou bem desenhada. Se a suíte de testes não cobre o comportamento alterado, um candidato aprovado prova apenas que nada já coberto quebrou. A verificação eleva o piso; não certifica o teto.

Também não se estende à edição interativa comum. Candidatos da Arena e a aplicação condicionada de uma refatoração executam verificações; um edit ou write normal, em uma sessão comum, não faz isso automaticamente. Execute verify_project quando quiser essa evidência registrada para uma execução comum.

Custo e modos de falha

• O custo cresce com os concorrentes. Cada um executa um agente de implementação completo.
• Uma worktree suja interrompe a execução antes de qualquer outra coisa, de propósito.
• Menos de dois modelos distintos torna a comparação sem sentido, e a ferramenta informa isso em vez de inventar uma classificação.
• Todos os candidatos podem falhar na verificação. Esse resultado é útil: em geral significa que a tarefa foi pouco especificada, ou que as verificações do repositório são mais rígidas do que os agentes supuseram.

Relacionados

• Modos de execução — referência completa de council, de arena e dos outros modos
• Evidência de execução — revisar e reverter o resultado
• Por que o AX Code — por que a classificação com verificação primeiro é o diferencial
• Boas práticas de roteamento entre vários modelos — separar trabalho premium e trabalho de apoio