Observabilidade do agente AI: Determinação do verde estável com uma prova de frescura

Um veredicto de saúde do agente AI deve expirar. Se um painel de instrumentos escrever "saudável" sem mostrar quando a sua evidência decisiva foi observada, pode manter um "verde" desconectado muito depois dos fatos terem mudado. O padrão prático é um certificado de frescura avaliado em um momento explícito. Para cada sinal requerido, mantenha o tempo do evento da fonte, o tempo de observação do coletor, uma sequência monotonicamente crescente e uma idade máxima específica da tarefa. Marque a corrida saudável apenas enquanto todo o sinal necessário estiver presente, fresco, não repetido e consistente com o resultado reivindicado. Se a prova exigida expirar, o veredicto torna se unknown não saudável e não falha automaticamente. Este artigo torna essa regra testável. A ficha de cinco casos que acompanha não altera nenhum modelo, fornecedor de rastreamento ou agente de solicitação. Altera apenas a idade, a hora de chegada, a sequência ou o valor do resultado e mostra por que um status verde em cache não pode ser confiável por si mesmo. Um veredicto de saúde precisa de um prazo de validade Os sistemas de observabilidade são bons para manter o valor mais recente. A saúde do agente requer saber se esse valor ainda é admissível. Imaginem um agente de pesquisa com três campos verdes: batimento cardíaco: ok ; Progresso útil: 3 sources accepted ; Verificação de resultados: brief schema valid . Esses valores descrevem diferentes promessas. Um batimento cardíaco pode expirar após dois intervalos de recolha. O progresso pode razoavelmente permanecer inalterado durante uma fase de leitura limitada. Um recibo de resultado pode permanecer válido para sempre para a corrida específica, mas deve ainda ser associado a essa corrida em vez de herdado de ontem. Um único tempo global Última atualização apagou essas distinções. O certificado mais seguro armazena um prazo de validade para cada facto exigido: O mínimo importa. Um novo recibo de resultado não pode provar que o tempo de execução é atualmente alcançável; um novo batimento de coração não pode provar que o artefato prometido existe. Quando o primeiro sinal requerido expira, o veredicto saudável combinado expira com ele. Este não é um requisito novo inventado para LLM. Kubernetes usa a API Lease para batimentos cardíacos de nós: cada kubelet atualiza um Leases spec.renewTime , e o plano de controle usa esse timestamp para determinar a disponibilidade de nós. O Kubernetes Documentação de arrendamento na versão original 9a8df52 oficial é útil aqui porque trata a disponibilidade como uma reivindicação limitada por tempo, e não como uma propriedade permanente da última atualização bem sucedida. Prometheus faz um limite relacionado explícito. Seu documentação de consulta na revisão ab225f6 descreve um retorno de cinco minutos padrão e comportamento de série obsoleta. Esse padrão de cinco minutos é uma regra de consulta Prometheus, não um prazo universal apropriado para agentes. O princípio transferível é que uma amostra antiga deve eventualmente parar de responder a uma pergunta atual. Usar dois relógios e um tempo de avaliação Um evento pode ter pelo menos dois momentos relevantes: quando a fonte diz que ocorreu e quando o sistema de coleta o observou. Fica com os dois. O estável OpenTelemetry Logs Modelo de dados em revisão f62b146 define o Timestamp como o tempo medido pelo relógio de origem e o ObservedTimestamp como o tempo em que o sistema de recolha observou o evento. Diz também que a marca de tempo da fonte pode estar ausente. Essa separação impede que um campo sobrecarregado pretenda responder ao pedido de eventos, atrasar o transporte e monitorar a frescura de uma só vez. Para um certificado de saúde, avaliar a idade em um domínio de relógio: Use source time para ordenar eventos de fonte apenas quando você sabe o limite de sincronização do relógio de origem. Subtrair um relógio host de um relógio coletor e chamar a latência da rede resultante é injustificado sem esse limite. Se um relógio portátil for quatro minutos mais rápido, um batimento cardíaco recém coletado pode parecer vir do futuro; se for lento, um agente vivo pode parecer obsoleto. O collector time tem um significado mais estreito, mas confiável: o monitor tinha essa evidência naquele momento. Não pode provar quando a ação subjacente realmente ocorreu, mas pode provar se a própria visão do monitor é recente. Retardar a recolha de registos separadamente quando a fonte fornecer relógios confiáveis ou um recibo de transporte. Um tempo de avaliação é igualmente importante. Sem o evaluated at , um certificado não pode ser reproduzido num ensaio ou numa revisão de incidentes. Fresh now não é uma declaração verificável. Fresco em 2026 07 26T00:42:00Z sob a política freshness v1 é. Construa um certificado, não um cache de valor mais recente O menor registro útil é deliberadamente simples: Cada campo fecha uma lacuna específica: Campo O que impede run id aceitação de um resultado de outra corrida evaluated at um movimento, irreprodutível agora collector time reter evidências após a janela de frescura do monitor source time Perder a ordem do evento da fonte quando esse relógio é confiável sequence aceitar um batimento cardíaco reproduzido ou fora de ordem como novo max age s Aplicação de um prazo arbitrário para sinais diferentes required Tratar silenciosamente a falta de provas decisivas como opcional policy Mudanças de limiares sem rastro de auditoria Não deduzir o progresso da sequência de batimentos cardíacos. Um ciclo pode emitir batimentos cardíacos perfeitos sem produzir mudanças úteis. Dê batimentos cardíacos, progresso, dependência de espera, e resultados seus próprios registros de evidências. Uma aprovação com nome pode ser nova e válida enquanto o progresso é intencionalmente interrompido; o certificado deve classificar as corridas como waiting , não bloqueadas. A prioridade do veredicto deve preservar a incerteza: 1. uma falha determinista nova produz attention ; 2. Um sinal requerido faltante, obsoleto, de chegada futura ou reproduzido produz unknown ; 3. uma dependência de nome novo produz waiting ; 4. Apenas evidências completas, frescas e atuais podem produzir healthy . Esta ordem não esconde falhas por trás da falta de telemetria. Um novo resultado fracassado é uma prova mais forte do que um batimento cardíaco obsoleto. Por outro lado, as evidências obsoletas por si só não estabelecem que o agente falhou; estabelece que o monitor não pode atualmente apoiar uma alegação saudável. Exercer cinco contraexemplos O equipamento que acompanha o presente artigo contém cinco corridas avaliadas ao mesmo tempo: O fresh run possui três sinais novos, avançados e bem sucedidos; O stale green ainda carrega o heartbeat: ok , mas o coletor viu o pela última vez há 240 segundos contra um limite de 120 segundos; O delayed batch contém um registo de progresso cujo tempo de recolha é após o tempo de avaliação, de modo que as provas ainda não estavam disponíveis; O replayed sequence repete uma sequência de resultados em vez de avançá la; A failed outcome tem novas evidências de que a verificação requerida dos artefatos falhou. Execute o classificador Node.js 20+: A sua saída exacta é: A tese falsificável é estreita: alterar apenas a admissibilidade das provas deve ser capaz de revogar um veredicto verde. O fresh run e o stale green contêm ambos o heartbeat: ok ; apenas a idade do colector difere. Se um painel de instrumentos ainda apresentar ambos os valores como saudáveis no momento da avaliação, ele está a exibir um valor armazenado em cache em vez de uma conclusão atual de saúde. O caso delayed batch lida com um erro mais sutil. A telemetria de retroalimentação pode melhorar o diagnóstico histórico, mas não deve reescrever o que o monitor sabia no momento da decisão anterior. Comparar o collector time com o evaluated at mantém a reprodução do incidente honesta. A verificação de sequência bloqueia uma nova fraqueza falsa. Uma rede de fila pode retransmitir o último batimento cardíaco com uma nova hora de chegada do transporte. Se o monitor atualizar a idade usando apenas a chegada, a repetição faz com que uma fonte morta pareça atual. Requer uma sequência de fonte, identificador de inicialização ou outro token monótono onde o tempo de execução possa fornecer um. Ao longo dos restarts, acoplem a sequência com um ID de encarnação para que um reset legítimo não seja confundido com repetição. O dispositivo é um conjunto de contra exemplos inspeccionáveis, não um ponto de referência de produção. Não estima taxas falsas positivas, conta para cada fila, ou prova que os limites de exemplo se adequam à sua carga de trabalho. O seu valor é que cada veredicto tem uma explicação de um campo e pode ser alterado editando um tempo ou sequência. Calibre a frescura em torno das promessas Escolha os limites do comportamento esperado do fluxo de trabalho, e não de um painel universal padrão. Para um pesquisador esperado a cada 60 segundos, um limite de batimento cardíaco pode ser dois intervalos perdidos mais o nervio medido. Para uma fase do compilador que deverá ser executada em silêncio durante oito minutos, o progresso pode utilizar um prazo de fase em vez de uma regra de mudança de 60 segundos. Para um recibo de resultado vinculado inmutablemente a uma corrida e a um hash de artefatos, a frescura pode significar pertence a esta corrida e foi verificada após o seu início, não foi criada nos últimos cinco minutos. Teste estes limites antes de alertar: Jitter normal do agendador; Reinicialização do coletor e atrasos na fila; Desvio do relógio de hospedeiro; Entrega duplicada e fora de ordem; Reiniciar o tempo de execução com uma sequência de reinicialização; uma espera legítima de aprovação humana; Um comando concluído cuja verificação de destino falhe; Uma interrupção do monitor enquanto o agente continua a trabalhar. Registrar a primeira violação separadamente da última observação. Requer perseverança quando as evidências são barulhentas, mas não permita que um novo batimento cardíaco reinicie um relógio de progresso obsoleto. Eliminar um incidente só com novas provas que abordam a condição que o abriu. Um processo reiniciado não é prova de que o relatório desaparecido existe agora. Há um custo para este rigor: mais campos, política por fluxo de trabalho e um estado explícito unknown . O benefício é evitar uma ficção mais cara e um estatuto verde apoiado por evidências de que o monitor não tem mais o direito de usar. Comece com os três sinais que podem alterar a ação: acessibilidade, progresso ou dependência útil e verificação de resultados. Mantenha o diagnóstico e as alegações de produtos limitadas Um certificado de frescura fica acima de registros, rastreos, métricas, registros de agendadores e verificações de destino. Não os substitui. Regista quais provas foram admissíveis para uma decisão de saúde e quando essa decisão expira. Também não deve desencadear uma recuperação irreversível por si só. A unknown exige a restauração das provas ou a inspeção humana. A attention pode justificar uma recomendação limitada, mas segredos, mudanças destrutivas e diagnósticos incertos ainda exigem autoridade explícita. A recuperação só é completa após um novo progresso ou após a observação do resultado previsto. Isso resolve a questão original: a observabilidade do agente AI nunca deve preservar o estado saudável indefinidamente. Dê a cada sinal decisivo um timestamp do coletor, idade máxima vinculada à política, identidade atual e guarda de repetição; avaliá los em um instante designado; e expire o veredicto combinado no limite mais cedo necessário. A Sidewisp está atualmente em prévia privada. O seu papel pretendido é uma camada de saúde ao lado dos tempos de execução dos agentes existentes, com evidências visíveis e limites de aprovação humana. A coleta de agentes de produção saúde, adaptadores de tempo de execução, recuperação automática, gerenciamento de cron e análise de custos de token geralmente não são enviados hoje. Se as provas de frescura coincidirem com as falhas que você precisa detectar, você pode Junte se à pré visualização privada.