Agente Watchdog: Um proprietário, provas frescas, trabalho verificado

Um vigilante agent é um observador separado que segue a execução de outro agente, decide se ele está funcionando, esperando legitimamente, preso, incerto, falhado ou terminado, e verifica o resultado reivindicado. O padrão útil é um cachorro de vigilância com um contrato de arrendamento, uma cadência lenta baseada em evidências e nenhuma autoridade de mutação automática. O processo está vivo e o trabalho solicitado é correto são veredictos separados. Essa definição também resolve uma ambigüidade nos resultados de pesquisa atuais. Watchdog pode significar um antigo demônio de reinicialização de infraestrutura, um produto de segurança AI, ou um agente que supervisiona outro agente. Este guia aborda o terceiro significado. A atual habilidade agent watchdog do Builder.io descreve a mesma transferência concreta: esperar por outro agente, reconstruir a solicitação, em seguida, verificar as reivindicações em relação a diferenças, arquivos, testes, CI, capturas de tela e estado de revisão. O seu modo de reparação é separado e requer autorização. Essa separação é o ponto de partida certo. Dê exactamente um proprietário de um cão de guarda Um cão de guarda precisa de sua própria identidade e arrendamento. Sem eles, dois controlos programados podem concluir que ambos possuem a mesma corrida. Mesmo que ambos os diagnósticos sejam corretos, dois empurrões, retomadas ou reinicializações podem produzir efeitos duplicados. Use um disco como este: O runId liga o observador a uma obra. watchdogId identifica o proprietário. A expiração obriga a reeleição depois de um observador ter caído em vez de deixar a propriedade permanente para trás. O observedAt diz o quão recente é o veredicto; não é intercambiável com o lastProgressAt . Um observador pode manter um registro recente de progresso enquanto a sua própria conexão se tornou obsoleta. Antes de cada veredicto, aplique três regras de propriedade: 1. Deve haver exactamente um contrato de arrendamento de cães de guarda não expirado para a corrida. 2. O observador deve atualizar as provas antes de classificar ou recomendar uma intervenção. 3. Um cão de vigilância substitutivo só pode assumir o cargo após o vencimento do contrato de locação anterior ou após a sua expulsão explícita. Se existirem duas identidades vivas, devolva o conflict . Não deixe que os dois só ajudem a tornar se uma política de concurrença implícita. Observação, intervenção e portões de resultado separados Kubernetes documenta as sondas de inicialização, prontidão e vitalidade separadamente porque respondem a perguntas diferentes e desencadeiam ações diferentes. A sua documentação também adverte que uma má regra de vida pode transformar reinicialização sob carga em falha em cascata. Um agente de vigilância AI precisa de uma separação equivalente, com um portão de saída adicional. Observação: É a evidência suficientemente recente para classificar a corrida? Verifique o timestamp do observador, a acessibilidade do agente, o recebimento do progresso, os metadados de espera e o estado atual do terminal. Um timeout ou uma amostra ausente produz uncertain ; não prova stuck . Porta de intervenção: É justificada e autorizada uma ação? Um cachorro de vigilância que só lê pode relatar uma credencial obsoleta, uma espera sem proprietário, ou dez minutos sem progressos úteis. Pode não inferir permissão para reiniciar, cancelar, editar arquivos, enviar mensagens ou gastar mais orçamento. Dê a cada ação permitida sua própria retomada, tempo e custo limite. O porta de saída: O trabalho solicitado passou o seu verificador? Um estado de processo terminal é apenas evidência de atividade. Para uma tarefa de código, o recibo pode combinar um compromisso esperado, um teste direcionado limpo e uma captura de tela necessária. Para uma tarefa de publicação, pode exigir paridade de API, uma página HTTP 200, inclusão de sitemap e recursos renderizados. Para um efeito colateral externo, pode ser necessário um registo de leitura de destino ou de idempotencia. A orientação SRE do Google faz a mesma distinção prática de outra direção: os sinais de caixa branca explicam os internos, enquanto as verificações de caixa negra expõem conteúdo errado que um status de protocolo bem sucedido não pode detectar. O cão de guarda deve preservar os dois. Os registos podem explicar por que a execução parou; o recibo de resultado determina se a solicitação do usuário foi satisfeita. Usar uma regra do estado que preserva a incerteza A seguinte ordem é importante. A propriedade e a frescura vêm antes do progresso. Um auto relatório do terminal vem antes de um temporizador genérico, mas ainda assim não contorna a verificação. A novidade da observação de dois minutos e a janela de progresso de dez minutos são valores fixos, não padrões universais. Deriva os do fluxo de trabalho. Uma implantação que normalmente produz um marco a cada quarenta minutos precisa de uma janela de progresso diferente de uma execução de codificação interativa que muda arquivos a cada minuto. Executa a regra contra casos que variam uma condição por vez: Caso Alteração da evidência O veredicto Ação seguinte limitada Novos progressos Novo marco de ensaio working Observe mais tarde . A espera de propriedade Proprietário e prazo futuro waiting Notificar o prazo próximo Esperar sem propriedade Nenhum proprietário ou prazo needs human Assinar os dois Corrida retardada Nenhum progresso durante 18 minutos. stuck Preparar um diagnóstico Observador estável A última observação é de quatro minutos. uncertain Novas evidências Cães de vigilância duplicados Duas identidades de guarda ao vivo conflict Escolher um proprietário Relatório feito Não há recibo de resultado audit required Verificar o artefato Verificado feito Passos de recibo complete Licença de locação No dispositivo executável utilizado para este artigo, todas as oito classificações esperadas foram aprovadas. Duas comparações são especialmente úteis. O novo progresso com um observador vivo é working ; a mesma evidência com dois identificadores de observador vivo é conflict . Um auto relatório preenchido com um recibo faltante é o audit required ; a adição de um recibo verificado é a única alteração necessária para chegar ao complete . Escolha a cadência das alterações esperadas das evidências Escolher mais depressa não detecta necessariamente falhas mais cedo. Pode criar custos, ruído, pressão de limite de taxa e julgamentos repetidos sobre dados inalterados. Estabelecer a cadência das evidências da taxa de alteração esperada e das consequências do atraso. Para um longo período de pesquisa, uma observação de cinco minutos pode ser razoável se os marcos normalmente chegam a cada quinze minutos. Uma necessidade de entrega programada verifica o seu início esperado e prazo, não uma votação constante durante todo o dia. Uma espera de aprovação humana requer um proprietário nomeado e um prazo de escalada; chamadas repetidas ainda aguardando não adicionam informações. Um cronograma útil tem quatro números: Intervalo de observação quando se atualizar a acessibilidade e o estado; Limite de frescura quando as próprias provas do observador se tornam inutilizáveis; vindo de progresso a maior diferença normal entre marcos significativos; Ação refrigeração o atraso mínimo antes de outra intervenção autorizada. Regista a última evidência hash, bem como o timestamp. Novas linhas de registro não são necessariamente novos progressos. Uma chamada repetida de ferramenta, falha de ensaio inalterada ou um projeto idêntico regenerado não devem reiniciar o relógio de progresso apenas porque o processo está ativo. O padrão de recuperação razoável ainda é primeiro relatado. Se a corrida for stuck , prepare um diagnóstico ou empurrão limitado. Se for waiting , encaminhe a decisão para o proprietário designado. Se for uncertain , recolha provas melhores. Se for conflict , remova supervisores extras. Apenas uma política aprovada separadamente deve permitir uma reinicialização reversível e o organismo de vigilância deve verificar os progressos úteis posteriormente. Mantenha o cão de guarda menor do que o trabalho Um agente de vigilância não deve tornar se um segundo tempo de execução, um revisor ilimitado, e um fixador autônomo ao mesmo tempo. As suas entradas úteis mínimas são a solicitação original, mudanças posteriores de âmbito, uma identidade de execução estável, evidências de progresso frescas, propriedade de espera, estado do terminal e um verificador de resultados específico da tarefa. Tudo o resto deve ganhar o seu custo de coleta. Este projeto tem um limite duro: a telemetria genérica não pode ser um produto arbitrário. Alguém deve definir o que "feito" significa para a tarefa. Quando não existe verificação determinista, o vigilante pode encaminhar o resultado para um humano ou um juiz de escassez de alcance, preservar a evidência e rotular a confiança. Não deve produzir um estado verde. O território do produto destinado à Sidewisp é a camada de saúde em torno dos agentes existentes: acessibilidade, progresso útil, espera, ferramentas, resultados e limites de recuperação seguros. A Sidewisp está atualmente em prévia privada. O seu motor de monitoramento de produção e os adaptadores de tempo de execução não são geralmente enviados, por isso o contrato neste artigo é um padrão de operação que você pode implementar em seu tempo de execução atualnão uma alegação de que a Sidewisp já observa ou repara agentes vivos. Comece com uma corrida e um observador. Exigir um contrato de locação, manter a observação em leitura, preservar o uncertain e definir o recibo do resultado antes do início do trabalho. Isso é suficiente para tornar um agente de vigilância útil sem deixar que a supervisão se torne outra fonte de fracasso. Fontes O agente observador de Builder.io README no commit 51bb048 Kubernetes: Vivulidade, prontidão e sondas iniciais Google SRE Book: Monitoramento de Sistemas Distribuídos