Monitoramento de Agentes Após uma Resolução: Prove Recuperação em Cinco Passo

Um agente AI não é recuperado meramente porque uma reinicialização, uma nova tentativa ou um empurrão retornaram com sucesso. O padrão prático para o monitoramento do agent é verificar a recuperação em cinco etapas: registar a intervenção autorizada, confirmar a acessibilidade e prontidão, observar o progresso específico da tarefa, verificar o resultado prometido de forma independente e observar uma janela de estabilidade para a recaída. Até que o controlo mais forte aplicável seja aprovado, mantenha o estado como recovering , uncertain ou needs human não saudável. Esta distinção é importante porque o comando de reparação e o trabalho do utilizador vivem em camadas diferentes. Um processo pode reiniciar se enquanto a sua credencial permanece expirada. Um batimento cardíaco pode retomar enquanto o agente repete a mesma chamada de ferramenta. Um agente pode declarar a conclusão enquanto o arquivo, bilhete, mensagem ou implantação ainda estiver ausente. A recuperação é uma alegação de evidência, não um evento de atividade. Eliminar um incidente com uma escada de verificação Use uma escada em vez de um status verde. Cada passo responde a uma pergunta diferente e deve preservar seu próprio tempo, fonte e confiança. Passo Pergunta Evidências mínimas Indicar se falhar Intervenção Foi autorizada e executada a ação limitada exata? Referência de aprovação, tipo de ação, ID de tentativa, resultado de saída ou API needs human ou intervention failed Accessibilidade O tempo de execução é contatável e pronto para sua tarefa? batimento cardíaco fresco e uma verificação de prontidão relevante para a tarefa unreachable ou alive only Progressos O trabalho útil mudou desde a intervenção? Artefato monótono, unidade concluída, cursor, delta de ensaio ou alteração de destino alive only ou recovering Resultados O resultado prometido existe e satisfaz a sua verificação determinista? Pesquisa, digestão, ensaio, revisão ou receção nativo de destino false recovery , recovering , ou uncertain Estabilidade A falha diagnosticada permaneceu ausente o tempo suficiente para se repetir? Uma janela de observação específica da carga de trabalho sem sintomas repetidos relapsed ou recovered O padrão razoável é conservador: um agente que é acessível, mas não tem movido trabalho útil é alive only ; um que retomou o trabalho mensurável, mas não alcançou o seu resultado é recovering ; somente a evidência de resultados frescos que sobrevive à janela de estabilidade ganha recovered . Kubernetes usa uma separação relacionada para recipientes. O seu documentação da sonda fornece diferentes funções de inicialização, vitalidade e prontidão: a vitalidade pode desencadear uma reinicialização, enquanto a prontidão controla se um contêiner deve receber tráfego. Também adverte que sondas de vida incorretas podem causar falhas em cascata. A analogia tem um limite uma tarefa de agente não é um Pod, mas a lição de operação transfere: o processo deve ser reiniciado e o trabalho pronto não deve ser o mesmo teste. Uma janela de estabilidade não é um sono arbitrário de cinco minutos. Escolha o intervalo mais curto em que a falha original tenha uma boa chance de voltar. Para um loop que repete cada duas chamadas de ferramenta, observe pelo menos duas oportunidades limpas de chamada de ferramenta. Para um editor programado, espere até o seu próximo prazo final de resultados. Para uma falha de credenciais, exerça a permissão afectada uma vez com um controlo não destrutivo. A janela deve ser longa o suficiente para falsificar a reparação, mas não tanto que o incidente permaneça ambíguo após a existência de provas decisivas. Gravar uma tentativa de recuperação, não uma sequência de comandos solta Ligue o diagnóstico, a autoridade, a intervenção e a verificação a uma identificação imutável da tentativa. Caso contrário, o monitor pode juntar um batimento cardíaco de uma reinicialização manual posterior a um empurrão automático anterior e relatar uma recuperação que ninguém pode explicar. Um evento limitado à privacidade pode parecer assim: Este evento não precisa de pedidos, respostas, segredos, ferramentas úteis, ou caminhos absolutos. Ele precisa do limite da ação e do limite da evidência. Guarde o action completed como um recibo, não como o veredicto de recuperação. Essa regra é especialmente importante para as APIs asincronas. RFC 9110 secção 15.3.3 diz que uma resposta HTTP 202 Accepted significa que o processamento não foi concluído e pode nunca ocorrer; a resposta deve descrever o estado atual e apontar para um monitor de estado. Se um adaptador de recuperação de um agente receber 202 , siga esse monitor ou consulta o destino. Não traduza acceptado para fixed. Os vestígios têm o mesmo limite de alcance. A OpenTelemetry define um span como uma unidade de trabalho e o seu status como o status da operação que acompanha. Um espaço de tempo limpo restart agent prova que a operação não relatou um erro. Não define se um relatório foi produzido, um bilhete chegado ou uma implantação serve a revisão pretendida. Ligue o período de intervenção aos progressos posteriores e às evidências dos resultados; não sobrecarregue o seu estado. A autoridade também pertence ao registro. Se uma reinicialização, atualização de credenciais, envio de mensagens ou retrocesso exigir aprovação e não existir aprovação válida, o monitor deve emitir needs human . Não deve tentar a acção e depois pedir permissão retrospectiva. A recuperação também requer uma nova tentativa e um orçamento de tempo. Uma segunda intervenção após o primeiro falhar é uma nova decisão, não uma extensão invisível do comando original. Reproduzir o batimento cardíaco falso positivo O equipamento de acompanhamento contém oito casos de pós intervenção sintéticos: falta de autoridade, erro de ação, atividade de batimento cardíaco apenas, progressos retomados, recuperação estável verificada, recaída, evidências obsoletas do verificador e conclusão declarada pelo agente com um resultado de destino faltante. Execute o classificador do diretório de artefatos: O resultado decisivo é: A regra ingênua da acção completa e do batimento cardíaco presente relata seis recuperações. A escada diz um. Isso não é porque a escada seja pessimista. Um caso é genuinamente recovering : avanços úteis retomados e o resultado ainda está pendente. Outra tem provas de resultados novos, mas depois repete a falha diagnosticada, por isso é relapsed . Um terceiro tem um resultado de aparência verificada que tem dez minutos de idade sob um contrato de frescura de dois minutos, por isso é uncertain , não falhou ou saudável. O limiar de frescura dos dispositivos 120 segundo é ilustrativo, não é um padrão de produção. A novidade das provas pertence ao verificador. Uma digestão de arquivos no armazenamento local pode ser decisiva imediatamente. Um índice de pesquisa eventualmente consistente pode precisar de um atraso documentado. Se o próprio verificador não estiver disponível, preservar o uncertain e expor o sinal faltante. Não reinicie o agente apenas para tornar o painel verde. O capítulo Monitoramento dos sistemas distribuídos do Google separa os sintomas das causas e a caixa negra das evidências da caixa branca. Ele também trata uma resposta de protocolo bem sucedida com conteúdo errado como um erro que pode exigir testes de ponta a ponta. Nesta escada de recuperação, o recibo de intervenção e a telemetria no tempo de execução são evidências de causa em caixa branca; a verificação de resultados nativos do destino é o teste de sintomas em caixa negra. Ambos são úteis, mas apenas este último resolve o que o usuário realmente perdeu. Transformar a verificação da recuperação num contrato de exploração Para cada classe de tarefas monitorada, definir a escada antes de um incidente: Os estados de incumprimento que permitem uma intervenção limitada; A pessoa ou a política autorizada a aprovar cada ação; A ação reversível e os seus limites de esforço, tempo e custos; A verificação da prontidão de execução após a ação; um campo de progresso útil com uma direção esperada; O verificador de resultados deterministas, o seu prazo e o seu limite de frescura; A oportunidade de recorrência que fecha a janela de estabilidade; o caminho de retrocesso ou escalada quando a tentativa falhar. Mantém o vocabulário do veredicto pequeno. Needs human significa falta de autoridade, segredo ou decisão irreversível. Intervention failed significa que a ação aprovada não foi concluída. Alive only significa que o tempo de execução está pronto, mas o progresso útil está ausente. Recovering significa que o progresso foi retomado enquanto o controlo de resultados ou de estabilidade permanece aberto. Uncertain significa que faltam ou estão obsoletas provas decisivas. False recovery significa o prazo final do resultado passado sem o resultado prometido. Relapsed significa que o sintoma original retornou. Recovered significa que o resultado específico da tarefa é verificado e a janela de recorrência manteve se limpa. Há limites honestos. Alguns resultados não podem ser verificados deterministicamente. O cliente aceitou a análise pode exigir uma decisão humana; o resumo é bom pode precisar de uma rubrica cuja confiabilidade é medida. Um destino também pode cometer um efeito colateral antes do fim dos tempos de resposta. Reconciliar com uma chave de impotência ou uma pesquisa independente antes de tentar novamente. Quando as evidências não podem resolver o estado, mantenha a incerteza visível. A Sidewisp está atualmente em prévia privada. Os seus adaptadores de monitoramento de produção, análise de custos de tokens e execução de recuperação geralmente não são enviados. A direção pretendida é uma camada de saúde ao lado dos tempos de execução existentes que torna explícito o diagnóstico, a autoridade, a frescura das evidências, o progresso útil e a verificação dos resultados. Não deve tornar se uma porta de entrada de modelo obrigatória ou um fixador autónomo. Se esse modelo operacional se encaixa nos seus agentes, Junte se à pré visualização privada. Fontes Kubernetes: Vivulidade, prontidão e sondas iniciais Google SRE Book: Monitoramento de Sistemas Distribuídos RFC 9110: HTTP Semantics, 202 Aceito OpenTelemetry: Traços