Depuração interativa e direção de sistemas de AI multiagentes: Gate Every Reset

A depuração interativa e a orientação de sistemas de AI multiagentes não devem ser tratadas como edição de transcrição. Uma redefinição segura cria uma nova ramificação com sua própria linhagem, evidência de Estado restaurada, registro de autoridade e recebimento de resultados. Se um navegador, espaço de trabalho, fila, credencial ou destino externo não puder ser restaurado ou reconciliado, o estado correto será incerto—não "pronto".” Esta é a lição prática a tirar Depuração interativa e orientação de sistemas de AI multiagentes, o artigo do CHI 2025 por trás do Código Aberto da Microsoft AGDebugger. A Pesquisa torna o rewind and edit utilizável para depuração de vários agentes. Uma implantação operacional precisa de mais um limite: uma redefinição pode recriar um estado interno de perto o suficiente para testar uma hipótese, mas não pode desfazer automaticamente um e mail, reverter um ticket, cancelar a publicação de uma página ou provar que a nova ramificação concluiu a tarefa do Usuário. O padrão razoável é um recibo de direção com seis portões: 1. o pai e o ramo têm identidades distintas; 2. o ponto de verificação abrange todos os agentes necessários e a chave do estado da ferramenta; 3. os efeitos após o ponto de verificação serem revertidos ou reconciliados; 4. o operador está autorizado a efectuar a intervenção; 5. a configuração do agente é fixada para a nova ramificação; 6. a sucursal retomada recebe um novo recibo de resultado. Apenas os cinco primeiros fazem um ramo pronto para retomar . O sexto faz com que seja verificado . Um reset é uma ramificação, não um retrocesso O documento AGDebugger parte de um problema concreto. Cinco desenvolvedores de agentes descreveram dificuldade em localizar erros em conversas longas, falta de controles de depuração interativos e iteração lenta nas configurações do agente. Os autores construíram um sistema que permite que um desenvolvedor passe pelas mensagens, redefina para um ponto anterior, edite uma mensagem anterior e compare os ramos de conversa resultantes. Um estudo de duas partes com 14 participantes examinou as estratégias de diagnóstico e orientação. Esta é uma interacção mais forte do que a procura de registos. Um desenvolvedor pode fazer duas perguntas falsificáveis no limite de falha: o que acontece se o mesmo estado for executado novamente e o que acontece se uma mensagem específica mudar? O documento relata três formas comuns de orientação no seu estudo: acrescentar pormenores, simplificar uma tarefa e alterar um plano. Mas o pormenor da execução é mais importante do que a possibilidade de edição. AGDebugger checkpoints estado do agente antes de uma mensagem ser processada. Na reinicialização, ele restaura o ponto de verificação correspondente e cria uma nova sessão. Mensagens e pontos de verificação antes da bifurcação permanecem compartilhados; novas mensagens e pontos de verificação pertencem à ramificação. Isso é linhagem, mesmo que a interface pareça um retrocesso. Tratar a operação como uma ramificação dá ao operador Três invariantes úteis: a execução com falha original permanece inspecionável; o ponto exacto da bifurcação é imutável; a edição e todos os efeitos posteriores pertencem a uma nova sessão. Sem essas invariantes, uma transcrição editada pode reescrever as evidências usadas para diagnosticar o incidente. A "execução bem sucedida" resultante pode ser impossível de reproduzir porque ninguém pode dizer qual histórico, prompt, esquema de ferramenta ou configuração de modelo o produziu. O registo de ramificação não necessita de conteúdo de mensagem: Identificadores de Hash e classes de edição grosseira são suficientes para uma trilha de evidência. Não exporte prompts, argumentos de ferramentas, segredos ou dados do usuário apenas para provar que existe uma bifurcação. Restaurar a cobertura do estado antes de alterar o plano Excluir mensagens de uma transcrição não é uma restauração de Estado. O documento diz que os agentes AGDebugger implementam métodos de salvamento e carregamento de Estado. O estado de um agente da web pode incluir uma URL e uma posição de janela de visualização; outros agentes podem precisar de um estado diferente. Ele também descreve a Política de ponto de verificação como "boa o suficiente", porque a restauração completa do JavaScript do navegador e do Estado do aplicativo remoto pode ser impraticável ou impossível. Essa limitação deve situar se ao lado do botão reset, e não numa autópsia. Defina as chaves de Estado exigidas pelo fluxo de trabalho antes do início de uma execução. Para uma pequena equipe de pesquisa e publicação, eles podem ser: Este ponto de verificação está incompleto porque falta a fila de aprovação. Uma repetição da transcrição pode fazer com que o ramo pergunte novamente, pule uma decisão existente ou aja como se a autoridade fosse transferida. O operador deverá ver restore uncertain , não um controle de currículo verde. A cobertura é necessária, mas não suficiente. Para cada chave de Estado, Registre uma revisão ou impressão digital sem conteúdo e um resultado de restauração: Chave do estado Evidência antes da reposição Teste de restauro necessário Memória do agente revisão e hash do ponto de verificação a revisão carregada corresponde à bifurcação Navegador origem, hash de rota e classe de sessão local a rota esperada é alcançável e a classe de sessão é válida Espaço de trabalho confirmação do repositório e resumo do Estado sujo revisão exacta Mais alterações locais intencionais Registo da ferramenta hash do esquema e contagem de capacidades as correspondências ou desvios actuais do registo são reconhecidos Fila de aprovação IDs e estatuto de receção da decisão as decisões pendentes e resolvidas são preservadas Um sistema remoto ativo pode ter se movido desde o posto de controle. Isso nem sempre é um fracasso. É uma razão para rotular as provas. Se o navegador puder retornar à página gravada, mas o registro subjacente da Página tiver sido alterado, a fidelidade do instantâneo será parcial. O operador ainda pode executar uma ramificação de diagnóstico, mas não deve apresentá la como uma repetição exata. A configuração faz parte do estado. Fixe as funções do Agente, os identificadores do modelo, o conjunto de ferramentas, os prompts do sistema e as regras de roteamento usadas pela ramificação. Caso contrário, uma edição bem sucedida prova apenas que alguma combinação desconhecida funcionou. Manter a configuração original imutável e registar o delta intencional. Reconciliar efeitos antes de repetir uma chamada de Ferramenta Um ponto de verificação restaura o estado sob o controlo do depurador. NÃO Inverte o mundo exterior. Suponha que a filial pai tenha criado um ticket após o ponto de verificação e, em seguida, não tenha produzido o relatório público prometido. Redefinir antes da chamada da ferramenta e repetir pode criar um segundo ticket. A ausência de resposta não é prova de que a primeira chamada não tenha tido efeito. Antes de retomar, enumerar todas as operações pós checkpoint com um efeito externo e classificá las: reverted : o efeito original foi desfeito com segurança; reconciled : o efeito permanece e o novo ramo irá reutilizá lo ou ignorá lo; pending : faltam provas de destino; irreversible : o efeito não pode ser desfeito e necessita de uma nova decisão humana. Qualquer coisa pending ou irreversible bloqueia a repetição automática nesse limite. Use teclas de operação estáveis onde o destino as Suporte. Para uma operação de publicação, consulte o destino por um ID de rascunho imutável antes de criar outro. Para um e mail, Mantenha o ID da mensagem do provedor sem o corpo da mensagem. Para uma alteração de repositório, compare o commit esperado ou o hash de árvore. Para um ticket, recupere o ticket pela chave de idempotência da solicitação. A intervenção do operador também necessita de um limite de autoridade. A edição de um plano é de baixo risco quando a filial está confinada a um dispositivo local. É materialmente diferente quando a edição altera destinatários, orçamento, permissões, metas de produção ou ações destrutivas. Encaminhe essas edições para um proprietário autorizado e mantenha a filial em needs approval até que chegue a recepção da decisão. Esperar por essa decisão não está preso. Retomar repetidamente enquanto a autoridade ou o estado de destino são desconhecidos é o fracasso. Executar o recibo de direção contra casos inconvenientes O artefacto que o acompanha é um dispositivo fixo e um classificador determinístico sem conteúdo. Não executa o AGDebugger nem pretende reproduzir o seu estudo de utilizador. Ele testa a decisão operacional que envolve uma redefinição. Execute o localmente: O dispositivo elétrico contém oito ramos. O classificador produzido: O teste adiciona uma nona afirmação: um ramo cujo ID é igual ao seu pai é rejeitado como invalid lineage . A precedência é deliberada. Os bloqueios de estado em falta afectam a interpretação porque o operador não pode estabelecer o ponto de partida da sucursal. Os efeitos não reconciliados bloqueiam a retomada antes da aprovação ser considerada. A aprovação e uma configuração fixa tornam a filial pronta, não saudável. Após a retomada, o resultado esperado ainda precisa de um verificador determinístico. Altere um campo e o resultado deve mover se previsivelmente. Adicione a chave de Fila de aprovação ausente à restauração parcial e ela poderá avançar. Marque um efeito de bilhete pendente reconciliado e a sucursal pode chegar à porta da Autoridade. Conjunto outcomeVerified para false após uma resposta final fluente e o resultado permanece false success . Isto produz uma importante distinção Operacional: "Pronto a retomar" significa que o limite de intervenção está controlado. "Verificado" significa que a nova sucursal concluiu o trabalho previsto. Não fundir esses estados num distintivo verde. O que a experiência não prova O artefato valida uma regra de decisão, não a fidelidade do instantâneo. Não pode provar que um navegador foi restaurado exactamente, que um LLM seguirá o mesmo caminho ou que nunca ocorreu um efeito secundário não documentado. Uma integração real precisa de adaptadores de Estado específicos do tempo de execução e consultas de destino. O estudo AGDebugger também tem um âmbito limitado: cinco entrevistados formativos, 14 participantes do estudo, duas tarefas de estudo e um protótipo de investigação construído sobre AutoGen. As suas conclusões justificam o padrão de interacção; não estabelecem uma redução da taxa de incidentes para cada arquitectura multiagente. O próprio documento identifica desafios em aberto, incluindo a dissociação da orientação da implementação de um agente e a determinação do efeito de uma edição. Esses limites reforçam a regra de funcionamento. Use reset interativo para isolar uma hipótese, não para fabricar certeza. Preservar o pai, bifurcar explicitamente, restaurar o que pode ser provado, rotular o que não pode, conciliar efeitos externos, exigir autoridade e verificar o novo resultado no seu destino. A Sidewisp está atualmente em prévia privada. Seus adaptadores de monitoramento de produção e executor de recuperação geralmente não são enviados. O método aqui é um padrão operacional inspecionável, não uma alegação de que o Sidewisp já verifica ou dirige equipes de agentes em tempo real. A direção do produto da Sidewisp mantém a autoridade humana, as provas e a verificação dos resultados centrais para uma recuperação segura. Se você opera sistemas multiagentes hoje, comece com um fluxo de trabalho propenso a falhas. Defina suas chaves de estado e razão de efeito externo antes do próximo incidente. O primeiro ponto de verificação útil não é aquele que mais pode repetir a história; é aquele que pode explicar exatamente o que foi restaurado, o que permaneceu alterado, quem autorizou a filial e como o resultado final foi verificado.