Uma abordagem de depuração unificada por meio da sinergia multiagente baseada em LLM: verifique o reparo

Uma abordagem de depuração unificada por meio da sinergia multiagente baseada em LLM é útil apenas quando seus agentes deixam evidências que sobrevivem à sua própria conversa. Um localizador pode parecer certo, um reparador pode emitir um patch e um revisor pode aprová lo enquanto a falha original nunca foi reproduzida ou o caso limite decisivo nunca foi testado. O padrão razoável é, portanto: permitir que agentes especializados proponham e contestem um reparo, mas promovam o patch somente depois que um recibo vinculado comprove reprodução, linhagem, cobertura de teste, qualidade oracular e revisão. Essa regra de funcionamento segue a arquitetura do artigo FixAgent sem confundir resultados de pesquisa com garantia de produção. O artigo separa localização de falhas, geração de patches e análise pós erro entre agentes especializados. Ele também distingue um patch plausível que passa nos testes disponíveis de um patch correto estabelecido por meio de verificação manual. Essa distinção é o limite da saúde. O que o resultado FixAgent prova – e o que não prova O design publicado de FixAgent é mais específico do que “pedir a vários modelos para depurar”. Sua metodologia usa um localizador, reparador e revisitador, além de um agente criador de entradas para testes adicionais. Os agentes explicam seu raciocínio, rastreiam variáveis ​​importantes e transmitem os resultados do estágio anterior posteriormente. Se o patch gerado falhar, o estágio de reparo poderá ser amostrado novamente com feedback de teste. O artigo relata resultados fortes em QuixBugs, Codeflaws e ConDefects. Esses são resultados de pesquisa de acordo com os conjuntos de dados, modelos, solicitações e procedimento de verificação do artigo. Eles não estabelecem que é seguro mesclar um patch de repositório arbitrário. Dois detalhes da fonte primária alteram a decisão operacional: 1. O artigo define um patch plausível como aquele que passa nos testes escritos por humanos, enquanto a correção requer verificação manual separada. 2. Sua seção de limitações diz que o agente extra de entrada de teste não pode calcular os resultados esperados sozinho. Uma entrada gerada sem um oráculo confiável não é um teste completo. A implementação Rudra lançada torna o limite inspecionável. Seu executor multi round trata zero casos de falha observados como um reparo bem sucedido e retorna esse sinalizador ao lançador. Isso é apropriado para o ciclo de teste de um experimento. Um operador ainda precisa perguntar quais suítes foram executadas, se seu oráculo é confiável, se o resultado pertence a esse patch e se um revisor aceitou a comparação real. A lição não é que a revisão do agente seja inútil. A discordância entre especialistas pode expor uma má localização ou um ponto fraco. A lição é que o texto de um agente não deve ser a única evidência consumida pelo próximo. Vincule cada estágio de depuração a um recibo de reparo Um recibo de reparo mínimo pode ser isento de conteúdo. Não precisa de prompts, código fonte, saída de teste ou raciocínio de modelo. Precisa de identidades estáveis ​​e veredictos que permitam que um portão humano ou determinístico reconstrua a fronteira: Limite Campos mínimos de recebimento Falha que pega Reprodução ID de execução, hash de comando, falha original observada Um patch para um bug que nunca foi reproduzido Localização ID de execução, revisão de origem, carimbo de data/hora da evidência Um resultado do localizador reutilizado de outra revisão Remendo hash de patch, revisão pai, contagem de linhas alteradas Um reparo vazio, obsoleto ou não relacionado Validação IDs de suítes necessárias, IDs de suítes observadas, contagem com falha “Todos os testes passam” quando um conjunto necessário nunca foi executado Oráculo verificado, desconhecido ou contestado Casos gerados sem resultado esperado confiável Revisão espera aprovada, rejeitada ou de propriedade Acordo modelo confundido com autoridade de fusão Resultado reclamação de conclusão e recibo de destino Uma execução concluída cujo patch não foi verificado ou entregue O ID de execução é especialmente importante. Uma resposta de localização de run old não deve justificar silenciosamente um patch de run 42 . O hash do patch é igualmente importante: um registro de teste verde para uma comparação não pode ser anexado a uma nova amostra posterior. Esta é uma linhagem comum, mas os fluxos de trabalho dos agentes muitas vezes a perdem porque o contexto conversacional faz com que as mensagens próximas pareçam relacionadas. Aqui está o formato usado pelo acessório que acompanha: As strings são identificadores, não conteúdo armazenado. Em um sistema real, os hashes devem ser calculados sobre entradas e artefatos canônicos, e o registro de teste deve incluir a versão da ferramenta, a revisão da configuração, a hora de início, a hora de término e a origem da saída. Segredos, prompts, conteúdo de arquivos e argumentos brutos de ferramentas devem ficar fora do recibo de integridade. Repita nove estados inconvenientes antes de confiar no verde O artefato do artigo contém nove casos sintéticos e um classificador Node.js ordenado por precedência. Execute o no diretório do relatório do artigo: O resultado observado é: Os casos são deliberadamente inconvenientes: UNREPRODUCED interrompe o fluxo de trabalho antes que um patch confiável possa ocultar uma linha de base ausente. LOCALIZATION DRIFT captura um recibo do localizador de uma execução diferente. NO EFFECTIVE PATCH recusa um hash ausente ou uma alteração de linha zero. TEST GAP relata um conjunto de integração necessário que nunca foi executado, mesmo quando os conjuntos observados estão verdes. ORACLE UNCERTAIN preserva a incerteza quando as entradas geradas não têm saídas esperadas verificadas. REVIEW REJECTED evita que um patch tecnicamente verde se torne aprovado. WAITING representa uma dependência legítima somente quando o recibo nomeia um proprietário e um prazo. FALSE COMPLETE supera uma declaração de conclusão quando qualquer teste observado ainda falha. VERIFIED REPAIR exige que todos os limites anteriores sejam acordados. A ordem é importante. Uma declaração de conclusão não pode substituir um teste com falha. Um contador de falha zero não pode substituir um conjunto ausente. Um caso limite gerado não pode estabelecer a correção sem um oráculo. Uma espera de revisão não deve ser classificada como parada quando tem dono e prazo. Este experimento também mostra por que uma única pontuação de integridade é um artefato de depuração ruim. Ambos os casos suite gap e verified repair relatam zero testes com falha, mas seus estados operacionais diferem porque nunca foi executado o conjunto de integração necessário. A evidência que falta é mais importante que o contador verde. Adicione a porta a um fluxo de trabalho de agente de codificação real Comece com um pequeno limite de promoção em vez de reconstruir a estrutura do agente: 1. Congelar a revisão de entrada. Registre o commit do repositório ou o instantâneo do espaço de trabalho antes da localização. 2. Reproduza a falha. Armazene um hash de comando/configuração e um resultado estruturado. Se a reprodução for escamosa, rotule a como incerta e não trate um eventual green run como prova de reparo. 3. Vincule cada transferência. Exija que os recibos do localizador, do reparador e do revisor façam referência à mesma execução e revisão principal. 4. Reamostragem vinculada. O ciclo de feedback do documento FixAgent é útil, mas as novas tentativas consomem orçamento e podem alterar o patch. Dê a cada novo patch seu próprio hash, limite as tentativas e invalide as evidências de testes anteriores quando a diferença mudar. 5. Declare os conjuntos necessários antes da execução. Caso contrário, um agente poderá redefinir “todos os testes” após ver os resultados. 6. Execução de teste separada da autoridade oracle. As entradas geradas podem melhorar a cobertura, mas uma pessoa, especificação, implementação de referência ou regra determinística independente deve fornecer o resultado esperado. 7. Mantenha a autoridade de mesclagem ou implantação controlada por humanos. Um recibo aprovado pode preparar a decisão; não deve ampliar a permissão do agente. 8. Verifique o destino. Se a tarefa era abrir uma solicitação pull, atualizar um problema ou produzir um artefato de lançamento, verifique esse destino de forma independente. Um patch local é uma atividade, não necessariamente o resultado solicitado. Para uma pausa de aprovação, use um registro explícito: Não pager simplesmente porque o agente está quieto enquanto o registro está atual. Escalar quando o prazo expirar, o proprietário estiver ausente ou a execução retomada não produzir novas evidências. Esperar não está preso; atividade repetida sem um resultado delta não é progresso. O limite para Sidewisp A tese sustentável é limitada: a depuração multiagente torna se operacionalmente confiável quando os resultados especializados são unidos a evidências de reparo determinísticas, e o verde é retido quando faltam evidências de linhagem, cobertura, qualidade do oráculo, revisão ou resultado. O cenário de nove casos falsifica o atalho “zero falha observada significa reparo verificado” porque dois casos de falha zero chegam a veredictos diferentes. Este é um padrão operacional, não uma afirmação de que Sidewisp atualmente executa FixAgent ou monitora reparos do agente de codificação. A Sidewisp está atualmente em prévia privada. É uma plataforma de integridade do agente de IA, mas o mecanismo de monitoramento de produção, os adaptadores de tempo de execução e o executor de recuperação geralmente não são enviados. A camada de saúde pretendida é relevante aqui porque distingue o progresso útil, a espera legítima, a conclusão falsa e a evidência incerta, ao mesmo tempo que deixa a autoridade fundida com o humano. Use o recibo primeiro em um fluxo de trabalho de depuração repetido. Se não for possível distinguir um conjunto perdido de um reparo verificado sem ler a transcrição, o contrato de evidências ainda será muito fraco.