Orquestração de agente de codificação de IA: controle cada mesclagem por meio de evidências

Os agentes de codificação paralela não devem ser mesclados porque cada sessão diz “concluído”. O padrão razoável é mais rigoroso: dê a cada agente mutante uma árvore de trabalho e uma ramificação isoladas, declare o que ele pode mudar e admita sua ramificação somente quando as verificações, a revisão, a atualização da base e um recibo de entrega se referirem ao commit principal exato. Esse é o núcleo operacional da orquestração do agente de codificação de IA . O orquestrador pode agendar trabalho e exibir atividades, mas a prontidão para mesclagem é uma decisão baseada em evidências. Uma ramificação pode estar funcionando, aguardando legitimamente, bloqueada, obsoleta, fora do escopo ou completa, mas não verificada. O colapso desses estados é como o paralelismo se transforma em um fracasso silencioso de integração. Este guia cria um recibo de mesclagem sem conteúdo e reproduz oito casos contra ele. O resultado é deliberadamente inconveniente: apenas uma caixa está pronta. Os outros preservam o motivo para esperar ou rejeitar, em vez de escondê lo atrás de um crachá verde de sessão. Orquestre a admissão da mesclagem, não a conclusão da sessão O cenário atual de ferramentas facilita a execução paralela. OA equipe do VS Code descreve os modos local, em segundo plano e de agente em nuvem na versão 1.109; seus agentes em segundo plano usam o isolamento da árvore de trabalho, enquanto os subagentes paralelos mantêm a exploração fora do contexto principal. O código abertoProjeto do Agent Orchestratorda mesma forma, coloca sessões de codificação em árvores de trabalho isoladas e roteia falhas de CI, revisa comentários e mescla conflitos de volta à sessão relevante. Essas são propriedades de execução úteis. Eles não são, por si só, um veredicto de fusão. Documentação git worktree do Gitexplica o limite importante. As árvores de trabalho vinculadas compartilham dados do repositório, mas cada uma possui um estado por árvore de trabalho, como HEAD e o índice.Gittambém se recusa a verificar uma ramificação em múltiplas árvores de trabalho, a menos que as salvaguardas sejam substituídas. Isso evita uma classe de colisões de sistema de arquivos e índice. Isso não prova que dois patches sejam compatíveis, que um agente tenha permanecido dentro de sua missão ou que o resultado do teste de ontem se aplique à cabeça de hoje. Use um recibo por filial candidata: Os identificadores são sintéticos. Nenhum prompt, arquivo de origem, segredo, comparação ou log de teste é necessário. O recibo contém apenas os fatos mínimos necessários para decidir se o chefe exato da filial pode avançar. Cinco verificações tornam o padrão útil: 1. Isolamento: a árvore de trabalho e a ramificação pertencem a uma sessão de mutação ativa. 2. Propriedade: todo caminho alterado está dentro da atribuição declarada. 3. Frescura: o candidato é baseado na base esperada e cada verificação refere se ao seu chefe atual. 4. Revisão: uma aprovação se aplica ao mesmo cabeçote, sem nenhuma solicitação de alterações não resolvida. 5. Resultado: um artefato determinístico comprova o trabalho solicitado, e não apenas a conclusão do comando. Documentação do branch protegido do GitHubapoia o meio deste contrato: as filiais podem exigir revisões e verificações de status bem sucedidas, e verificações rigorosas podem exigir que uma filial esteja em dia com a base. O recebimento do resultado amplia esse mecanismo. Uma compilação bem sucedida prova que um comando de compilação foi aprovado; isso não prova necessariamente que a exportação solicitada existe, que o contrato da API funciona ou que o comportamento visível ao usuário está correto. Execute a auditoria de preparação para mesclagem de oito casos Codifiquei o contrato em um pequenoNode.jsclassificador e reproduziu oito recibos de filial. O fixture usa uma base atual, duas verificações obrigatórias e nenhum conteúdo de repositório. Execute o com: O classificador aplica as portas nesta ordem: A ordem é importante. Uma espera legítima não deve se tornar uma construção com falha simplesmente porque as verificações não foram iniciadas. O desvio de escopo deve interromper a ramificação antes de uma avaliação dispendiosa. Evidências obsoletas não devem ser reinterpretadas como uma falha atual: elas dizem “nova execução contra esta cabeça”, e não “o código está quebrado”. O experimento produziu um veredicto em cada categoria: Caso Veredicto Evidência decisiva Filial completa merge ready Cabeçalho atual, caminhos próprios, novas verificações, aprovação, artefato verificado Espaço de trabalho compartilhado isolation failed Outra sessão mutante possui o espaço de trabalho Edição de autenticação extra scope drift src/auth.ts está fora da atribuição de documentos Decisão de esquema waiting O revisor nomeado, o motivo e o prazo estão presentes Base de mesclagem antiga stale base Candidato viu base 101 ; base atual é base 104 Novo commit após CI stale evidence Verificações e revisões pertencem a cli 8 , não cli 9 Alterações solicitadas review blocked A revisão se aplica ao chefe, mas não é aprovada Nenhuma prova de entrega outcome unverified A compilação e o teste são aprovados, mas o resultado solicitado não foi verificado Este é um resultado operacional mais forte do que “sete falhas”. O caso do esquema não está falhando; está aguardando uma decisão explícita. O caso de verificação obsoleta pode conter código perfeitamente bom; sua evidência é sobre o commit errado. O caso de resultado faltante pode ter passado em todos os testes genéricos e ainda ter falhado na tarefa que justificou a ramificação. A auditoria é falsificável. Se o classificador marcar qualquer caso incompleto como pronto, a tese falha. Se recusar o recebimento completo, o contrato é muito rigoroso ou implementado incorretamente. Nesta corrida, exatamente um dos oito casos tornou se merge ready . Vincule todos os sinais verdes à cabeça do candidato A regra mais reutilizável do aparelho é simples: Suponha que um agente passe no CI no commit cli 8 , então faz um pequeno commit de “limpeza” cli 9 . Um painel ainda pode exibir verificações verdes e uma revisão aprovada. O estado correto não é verde nem vermelho. É uma evidência obsoleta. Execute novamente as verificações afetadas e renove a revisão ou use um mecanismo de plataforma que invalide as aprovações quando a diferença revisada for alterada. Aplique a mesma ligação de identidade à entrega. Recibos úteis incluem: um teste de contrato que chama a nova API e valida sua resposta; um hash de artefato gerado mais uma verificação de decodificador ou analisador; uma afirmação do navegador contra a rota integrada; um ensaio de migração contra um banco de dados descartável; uma importação de pacote e teste de fumaça do pacote construído, não da árvore de origem; uma pesquisa de destino provando que um efeito externo atingiu o registro pretendido. Evite um resumo LLM como o único recibo de resultado quando o resultado for determinístico. Um agente de codificação pode dizer com segurança que criou um arquivo que está ausente, executou testes que foram posteriormente invalidados ou corrigiu um comentário de revisão em uma ramificação diferente. Prefira a inspeção direta. Use um juiz modelo apenas para propriedades que não podem ser verificadas mecanicamente e registre a versão do juiz, a rubrica, a identidade de entrada e a incerteza. Esperar também precisa de identidade. Registre o proprietário, o motivo, o prazo e a condição do currículo. “Aguardando revisão” sem proprietário pode ficar parado para sempre. “Aguardando o revisor da plataforma até 12h UTC para aprovar a compatibilidade do esquema; retomar às schema 3 ”é acionável e deve ficar fora da fila de falhas até que seu prazo ou evidência sejam alterados. Saiba onde o portão para A propriedade do caminho é um filtro antecipado, não uma detecção de conflito semântico. Duas ramificações podem editar arquivos diferentes e ainda discordar sobre um tipo compartilhado, esquema de evento, cliente gerado, ordem de migração, sinalizador de recurso ou comportamento da API. O isolamento da árvore de trabalho evita colisões simultâneas de estado de arquivo; não pode provar que patches independentemente corretos são compostos. Portanto, execute uma porta de integração final no candidato de mesclagem real: 1. atualizar ou recriar o candidato a partir da base pretendida; 2. combinar as alterações aprovadas sem contornar conflitos; 3. execute as verificações necessárias no cabeçote combinado; 4. repetir a verificação determinística do resultado; 5. anexe a evidência resultante a esse cabeçalho combinado; 6. exigir aprovação humana para a fusão ou qualquer etapa de recuperação irreversível. Isso adiciona trabalho. O frescor estrito da base também pode causar reconstruções repetidas enquanto outros ramos pousam.GitDocumentos centrais que compensam: verificações rigorosas exigidas melhoram o alinhamento da base, mas podem exigir mais construções; verificações soltas reduzem reconstruções, mas podem permitir que apareça incompatibilidade após a mesclagem. Escolha a política pelo custo da falha e não pelo desejo de manter todos os agentes ocupados. O contrato de mesclagem também não substitui a revisão de código, a revisão de segurança, os controles de implantação ou a resposta a incidentes. Dá a esses sistemas uma identidade de candidato confiável e um motivo claro quando o trabalho não está pronto. A Sidewisp está atualmente em prévia privada.A direção do produto é uma camada de integridade em torno dos tempos de execução dos agentes existentes, com evidências úteis de progresso, espera, ferramenta e resultado mantidas distintas; Os adaptadores de coleta e recuperação de integridade do agente de produção geralmente não são enviados. Se você opera agentes de codificação paralelos, esse recibo de mesclagem é o tipo de contrato de saúde limitado que vale a pena testar agora – antes de adicionar intervenção autônoma. A regra final é intencionalmente conservadora: a parada de um agente é atividade; uma filial fixada, revisada e com resultados verificados é um progresso que pode ser aprovado para integração.