Monitoramento de agentes AI: Política de alerta silenciosa para falhas reais

O monitoramento do agente AI só deve interromper uma pessoa quando puder identificar uma falha em curso, mostrar as evidências e apontar para uma próxima ação limitada. Uma chamada de ferramenta, um sinal de ponta ou um longo rastreamento podem ajudar a explicar um problema; nenhum deles prova que o agente deixou de entregar um trabalho útil. Para uma primeira política prática, observe três coisas separadamente: 1. Runtime freshness: começou a corrida programada, e o seu batimento cardíaco ainda está atual? 2. Usuoso progresso: mudou se a evidência específica da tarefa no prazo esperado? 3. O Verificação de resultados: Existe o produto prometido e passa a verificação de aceitação? Então encaminhe o resultado. Página para uma falha persistente, relevante para o usuário. Criar um bilhete ou notificação do proprietário para uma espera legítima ou uma investigação lenta. Suprimir uma única amostra ruim e trabalho saudável. Este artigo transforma essa regra em um contrato de pequeno evento e um conjunto executável de oito casos. A página deve indicar a promessa quebrada. Um agente pode estar online enquanto o seu trabalho está errado. Também pode ser silencioso porque está corretamente à espera de aprovação. É por isso que a execução de processos é muito fraca para o monitoramento de agentes e que nenhuma chamada recente de ferramentas é demasiado barulhenta para paging. O capítulo Monitoramento dos sistemas distribuídos do Google traça uma linha útil entre evidências de caixa branca e sintomas de caixa negra. A telemetria interna é essencial para o diagnóstico, mas uma página deve representar uma falha clara que afeta o serviço. O capítulo também observa que uma resposta de protocolo bem sucedida pode ainda ser um erro quando o conteúdo devolvido é errado. Para um agente, a falha correspondente é uma corrida que diz completed enquanto o artefato necessário está ausente ou inválido. Comece escrevendo um contrato de monitoramento por fluxo de trabalho: Campo do contrato Exemplo para um agente de repositório Por que existe Começo esperado Dias de semana às 09:00 UTC, graça de cinco minutos Detectar um horário perdido Batimento cardíaco Observação do tempo de execução não superior a dez minutos Detectar uma corrida inacessível ou morta Evidências de progresso Novos compromissos, resultados de teste alterados ou bloqueadores gravados Movimento separado da atividade repetida Esperar legítimo Identificação de aprovação mais proprietário responsável Continuem a esperar trabalho fora da página do estábulo Recurso de conclusão O estado do tempo de execução é completed Regista o que o agente declarou . Predicado de resultados O ramo alvo contém a passagem de verificação obrigatória e obrigatória Verificar o resultado prometido de forma independente A última fila deve ser deliberadamente específica. Generada uma resposta pode ser suficiente para uma tarefa de bate papo. Criou um arquivo não é suficiente para uma tarefa de liberação se o arquivo for inválido, não publicado ou anexado ao destino errado. O monitor não pode deduzir este contrato a partir de um período de tempo; o proprietário do fluxo de trabalho deve definí lo. Instrumento de corrida sem tratar as tensões como conclusão As convenções semânticas geracionais do AI definem agora operações de agente e fluxo de trabalho como invoke agent , invoke workflow , plan e execute tool . O Documento de duração do agente atual também fornece campos como gen ai.agent.id , gen ai.agent.name , gen ai.agent.version e error.type . Estes são campos de correlação e diagnóstico úteis. Não são um esquema de resultados. O documento está marcado Development , por isso, a fixação de uma versão é importante. Também adverte que as mensagens de entrada e saída capturadas podem conter informações confidenciais. Você pode implementar a política de alerta abaixo sem armazenar pedidos, respostas, segredos ou cargas úteis de ferramentas completas. Um evento compacto pode parecer assim: Mantenha o runId estável através do agendador, telemetria de tempo de execução e verificador de resultados. Armazenar um agente de baixa cardinalidade ou nome de fluxo de trabalho para agregação. Coloque identificadores de rastro diagnóstico atrás do alerta, em vez de dentro da sua identidade. Caso contrário, cada nova tentativa pode criar um novo incidente para a mesma promessa quebrada. A faixa superior da ilustração é movimentada, mas circular. A pista inferior muda de estado e produz um resultado inspecionável. Essa distinção é o centro da política: a actividade é a evidência para a depuração; o progresso e os resultados determinam a saúde. Teste a política com oito casos inconvenientes O artefato que acompanha este artigo utiliza um registro NDJSON por execução observada. Refere se à conclusão verificada, ao falso sucesso, a falta de cronograma, a duração de execução inacessível, a espera legítima de aprovação, a persistência de não progressos, uma má amostra transitória e um trabalho ativo saudável. Execute o do diretório de artefatos: Output esperado: O avaliador utiliza uma prioridade fixa. Um resultado falso de sucesso vence a telemetria obsoleta porque o resultado quebrado já é conhecido. Um horário perdido ganha quando a corrida nunca começou. Um tempo de execução inacessível ganha um diagnóstico sem progresso porque o monitor não tem provas de execução frescas. Uma espera explícita ganha a regra do estábulo. Somente assim, uma marca de tempo de progresso obsoleta torna se stuck . Isto impede que um registro abra três incidentes. Também torna cada decisão explicável: a saída pode nomear a condição, a marca de tempo da prova e o limiar que foi atravessado. Os limiares incluídos são exemplos, não padrões universais: Cinco minutos após o início previsto; dez minutos sem batimento cardíaco; quinze minutos sem progressos úteis; Duas amostras negativas consecutivas para condições de página; Três amostras negativas consecutivas por um bilhete sem progresso. Um agente de codificação que corre um cronograma de dois minutos e um agente de pesquisa que lê artigos por uma hora não devem compartilhar esses números. A parte importante é a sequência e o requisito de persistência, não a duração particular. Adicionar persistência antes da escalada As regras de alerta do Prometheus fornecem duas mecânicas relevantes. A cláusula for documentada mantém uma condição recém ativa pendente até que tenha permanecido ativa por um período. O keep firing for pode manter um alerta aberto após a última amostra de correspondência para reduzir os flaps ou a falsa resolução causada por dados faltantes. As mesmas ideias se aplicam mesmo que não utilize Prometheus: Requerem observações repetidas antes de fazer um pedido de silêncio; registar o primeiro período de violação separadamente da amostra mais recente; Alertas de grupo por fluxo de trabalho e promessa não cumprida, não por retest ou rastreamento; manter o incidente aberto até que novas provas confirmem a recuperação; re page apenas quando a gravidade ou os resultados afetados mudam. Não coloque todas as condições atrás do mesmo atraso. Uma alegação de conclusão cujo artefato requerido falha numa verificação determinista é prova mais forte do que um batimento cardíaco perdido. Por outro lado, uma pontuação de qualidade LLM perto de um limiar é uma evidência mais fraca e pode pertencer a uma fila de revisão em vez de um pager. Uma tabela de roteamento silenciosa é mais útil do que um longo inventário métrico: Condição observada Rota padrão Condição clara Recurso de conclusão; falha a verificação dos resultados exigidos após a sua graça de verificação Página quando relevante para o usuário, caso contrário bilhete Resultados de prédicatos passos ou reivindicação é corrigido A corrida esperada não começou depois de Grace e dois cheques Página quando a corrida tem uma obrigação atual Iniciação da execução ou expectativa do agendador é explicitamente alterada A batida cardíaca está obsoleta por dois exames. Página quando o trabalho ativo é afetado Batimento cardíaco fresco mais uma nova amostra de saúde A aprovação nomeada, a decisão secreta ou irreversível está pendente Notificar o proprietário responsável ou criar um bilhete A dependência é fornecida ou o trabalho é cancelado A atividade continua, mas a evidência da tarefa não mudou por três verificações Bilhete de investigação Mudanças na evidência de progresso ou uma espera legítima é registada Uma amostra ultrapassada ou ausente Sem notificação humana Reavaliação na próxima amostra Trabalhar os casos de borda antes de escolher uma ferramenta Os erros de política de alerta geralmente aparecem nas fronteiras, não no caminho feliz. Verificação atraso: Um editor pode relatar a conclusão segundos antes de uma atualização do CDN ou do índice de pesquisa. Dê ao resultado um período de graça documentado e verifique novamente. Não considere um sono arbitrário como prova; a segunda verificação deve inspecionar o destino real. Human waits: armazenar tanto a dependência quanto o seu proprietário. A waitingOn: "approval" , sem um responsável, simplesmente esconde a barraca. Uma espera pode permanecer saudável para o agente enquanto ainda cria uma tarefa humana atrasada. Longo trabalho silencioso: uma etapa de investigação ou de compilação pode ser saudável sem eventos frequentes de ferramentas. Escolha evidências de progresso que o tempo de execução possa emitir com segurança: um fragmento concluído, um hash de conteúdo alterado, uma nova fase de teste ou um prazo de fase limitado explícito. Retries: Retries podem mascarar as falhas dos fornecedores enquanto aumentam a atividade e o custo. Grupá los sob a mesma execução e registar tentativas contam como contexto de diagnóstico. Uma nova tentativa não deve reiniciar o tempo da primeira violação, a menos que produzir progressos úteis. Sinais desconhecidos: falta telemetria não é verde. Reporte o como indisponível e evite a recuperação automatizada quando o monitor não consegue distinguir o bloqueado do desconectado. Um diagnóstico incerto deve pedir uma inspecção, não executar uma correção destrutiva. Recovery: fechando um incidente porque um comando de restart retornou zero repete o problema de falso sucesso. Usar o mesmo resultado ou progresso predicado que abriu o incidente. A recuperação só é completa quando há novas evidências de que o trabalho está em movimento ou o resultado prometido existe. O que esta experiência prova e o que não A fixação torna falsificável uma tese estreita: com a prioridade documentada e os limiares, os oito casos fornecidos produzem exatamente três páginas, dois bilhetes e três notificações suprimidas. Você pode editar um timestamp ou contagem de violação e ver a rota mudar. Não prova que os limites correspondam à sua carga de trabalho. Os casos são sintéticos, e o avaliador lê registos já normalizados. As integrações reais devem lidar com a distorção do relógio, a entrega duplicada, amostras atrasadas, políticas de agendamento, fusos horários e interrupções do coletor. Eles também precisam de um limite de privacidade para qualquer coisa derivada de pedidos ou chamadas de ferramentas. A política não substitui rastreamentos, avaliações ou registos de tempo de execução. Esses sinais explicam por que um resultado falhou. Também não garante que um predicado específico de tarefa capte todos os problemas de qualidade. Alguns resultados são deterministas, como um hash de arquivo ou resultado de teste; outros precisam de amostragem, revisão ou um processo de avaliação com um nível explícito de incerteza. O mais importante é que a política não deve autorizar a recuperação autónoma. Um monitor pode recomendar uma nova tentativa limitada ou preparar um passo de reparo, mas ações irreversíveis, acesso secreto e diagnósticos incertos ainda exigem autoridade humana. Transformar o aparelho num teste de aceitação Antes de ligar um destino de alerta real, substitua os casos sintéticos por exemplos recentes de um fluxo de trabalho: 1. Defina o início esperado e o atraso aceitável. 2. Escolha um batimento cardíaco produzido fora da resposta do modelo. 3. Nomear a menor evidência de progresso útil. 4. Registrem as razões legítimas de espera e os proprietários. 5. Implementar o predicado de resultados no destino real. 6. Repete casos conhecidos saudáveis, esperando, presos, perdidos, inacessíveis e falsamente bem sucedidos. 7. Execute a política silenciosamente o tempo suficiente para revisar páginas falsas e incidentes perdidos. Só após essa revisão deve ser ativada uma rota de página. Mantenha as evidências brutas, a decisão, a versão de limiar e a verificação da resolução inspecionáveis para que o operador possa entender por que o monitor falou. O Sidewisp foi concebido em torno deste primeiro limite da saúde: detectar, explicar, pedir autoridade quando necessário e verificar o resultado. A Sidewisp está atualmente em prévia privada. Os adaptadores de monitorização de produção e o motor de recuperação não são geralmente enviados hoje. Se esta abordagem coincidir com a forma como você opera agentes, você pode descrever o Junte se à pré visualização privada e os casos de execução e falhas que você precisa cobrir.