AI Observabilidade do Agente sob o relógio Skew: Reconstruir a ordem do evento

Um agente AI pode produzir um rastro perfeitamente plausível cujas marcas de tempo contam uma história impossível. Um resultado da ferramenta aparece antes da solicitação que a causou. Uma conclusão aterrissa antes do início da corrida. Um registro de progresso atrasado chega após o resultado e faz com que uma corrida concluída pareça novamente ativa. A resposta prática não é corrigir a linha do tempo, ordenando mais duramente. Não deduzir o estado do agente apenas a partir dos selos de tempo do relógio de parede. Mantenha quatro provas event at , observed at , source seq e depends on e use cada uma para o trabalho que pode realmente suportar. Reconstruir a ordem causal a partir de dependências e sequência por fonte. Use o relógio do coletor para a frescura das provas. Medir as durações com um relógio monótono dentro de um processo. Se um antecessor necessário estiver faltando, o veredicto de saúde é uncertain , não preso, saudável ou completo. Essa regra é pequena o suficiente para testar. A fixação abaixo coloca dois tipos de desordem do relógio e uma cadeia causal quebrada em onze eventos. Uma auditoria determinista recupera dois fluxos de trabalho e se recusa a inventar uma ordem para o terceiro. Um tipo de relógio de parede pode reverter o trabalho O trabalho de agente distribuído cruza os relógios: o host de tempo de execução, um servidor de ferramentas, uma fila, um verificador e o coletor podem todos marcar a mesma execução. A sincronização do relógio reduz a discórdia entre eles; não transforma esses relógios em uma autoridade causal. O próprio NTP modela o offset do relógio, o atraso da rede, a dispersão e a distância de sincronização em vez de prometer o mesmo tempo em todos os lugares (RFC 5905). O primeiro fluxo de trabalho do dispositivo torna o problema visível. Seu relógio de agente é rápido de 45 segundos, enquanto seu relógio de ferramentas é lento de 30 segundos. A cadeia de dependência real é: A classificação dos mesmos registros por event at coloca o g3 antes do g1 . Um painel construído sobre essa ordem pode calcular uma duração negativa da ferramenta, mostrar um resultado terminal antes do início ou confundir evidências que chegam mais tarde para uma nova transição de estado. Nenhuma dessas conclusões resulta do trabalho. Conseguem se a partir da comparação de relógios de parede que têm diferentes offsets. O Modelo de Dados de Registros estável da OpenTelemetry preserva a distinção necessária aqui. Timestamp é quando o evento ocorreu de acordo com o relógio de origem; ObservedTimestamp é quando o sistema de recolha o observou (Modelo de dados OpenTelemetry Logs). Manter ambos é útil, mas nenhum campo é uma chave de ordem universal: Campo Uso seguro Infecção insegura event at Exibição da fonte hora local; correlação com a evidência do hospedeiro Ordem causal ou latência entre hospedeiros observed at Frescidez relativa ao colector e atraso na ingestão O tempo do trabalho realmente aconteceu source seq Ordem emitida por uma encarnação fonte Ordem através de fontes não relacionadas depends on Arredores causais transversais explícitos Prova de que ocorreu um evento omitido transcurso monótono Duração dentro de uma vida útil de processo Marca de tempo comparável entre máquinas A origem da encarnação importa. Um contador deve ser escopoado por algo como (source id, boot id) , porque um processo reiniciado pode começar novamente na sequência 1. Um número inteiro de aparência global invita um falso alarme diferente: o colecionador lê uma reinicialização esperada como repetição ou regressão. A distinção entre o tempo de parede e o tempo monótono também é operacional, não acadêmica. O pacote time da Go explica que os relógios de parede estão sujeitos a alterações de sincronização, enquanto os relógios monotônicos são para medir o tempo; os valores devolvidos pela time.Now podem transportar ambas as leituras para que as operações de tempo passado permaneçam robustas quando o tempo de parede muda (Passa se relógios monótonicos). Outros tempos de execução expõem diferentes APIs, mas a decisão permanece a mesma: calcular uma duração local da ferramenta a partir de um intervalo monótono local, em seguida, exportar essa duração como evidência. Não subtrair os tempos de parede de duas máquinas não relacionadas e chamar o resultado de latência. Reconstruir a causalidade antes de classificar a saúde O contrato do evento é deliberadamente compacto: dependsOn cria a borda transversal de pedido para resultado. Os valores consecutivos sourceSeq criam bordas locais dentro de um fluxo (source, bootId) . A auditoria combina essas bordas, verifica as falhas de predecessores e as lacunas de sequência e, em seguida, realiza um tipo topológico. O relógio de parede e as inversões do tempo do coletor tornam se diagnósticos ligados às bordas; não reescrevem o gráfico. Execute o artefato do seu diretório: O seu resumo fixo é: O primeiro fluxo de trabalho é reconstruído apesar da inversão de origem relógio. O segundo tem uma falha diferente de ordem ingênua: o d3 chega ao coletor antes de seu antecessor d2 , de modo que a classificação por observed at inverte sua dependência. O gráfico ainda recupera a ordem pretendida. O terceiro fluxo de trabalho contém um resultado de ferramenta que nomeia b missing request , um evento ausente do conjunto de evidências. Também parece terminal antes de arranque sob um tipo de relógio de parede, mas a auditoria não o repara adivinhando. O seu status é uncertain . Isso produz uma ordem de decisão útil para a saúde do agente: 1. Validade de identidade. Rejeitar IDs duplicados de eventos e números de sequência de alcance para uma encarnação fonte. 2. Construir bordas locais. Os valores consecutivos da sequência de origem estabelecem a ordem de emissão; uma lacuna é a perda de evidências, não a permissão para fechar a lacuna. 3. Build cross source edges. Junte se a solicitações, resultados de ferramentas, trabalho delegado, aprovações e verificações de resultados com IDs de antecessores explícitos. 4. Reject inventou certeza. Um antecessor perdido, uma lacuna de sequência ou um ciclo torna o veredicto afetado incerto. 5. Ordenar o gráfico admissível. Ordenar topologicamente a porção completa; reter as inversões do relógio de parede como evidência da qualidade do relógio. 6. Clasifique o estado apenas agora. Aplique as regras de trabalho, espera, bloqueio e resultado à ordem causal em vez da ordem de chegada. Isto mantém a atividade separada do progresso útil. Um batimento cardíaco atrasado pode ser novo no coletor, mas causalmente mais antigo do que um resultado já verificado. Não deve reabrir a corrida. O resultado da ferramenta pode ser observado recentemente, mas depende de um pedido que o coletor nunca viu. Não deve ser concluída. Um evento de aprovação humana pode legitimamente deixar uma corrida à espera mesmo que não se sigam novos eventos de execução; a dependência nomeia o bloqueador. Um detalhe da implementação impede muitas regressões acidentais: tornar o reductor de saúde monótono quando o contrato de fluxo de trabalho o permite. Uma vez que o resultado invoice 42 é verificado de forma independente para executar r7 , um evento tool requested mais antigo não pode rebaixar esse resultado para working. Pode atualizar o livro de evidências, revelar atrasos na entrega ou levantar um problema de qualidade de telemetria, mas não pode apagar um fato verificado mais forte. Trate o tempo como evidência com um limite A reconstrução causal não é um substituto de sincronização do relógio. Você ainda precisa de hospedeiros sincronizados para cronogramas de incidentes legíveis, validação de certificado, comportamento do agendador e correlação operacional. A regra simplesmente impede que o modelo de saúde reivindique mais do que os relógios provam. Também tem quatro limites nítidos. Em primeiro lugar, a observed at só é autorizada em relação ao colecionador que a estampou. A fila, as retas, a contrapressão e a falha do coletor podem aumentar o atraso observado. Usá lo para perguntar há quanto tempo este coletor viu evidências aceitáveis? Não informe automaticamente o observed at event at como latência da rede. Em segundo lugar, um gráfico de dependência é tão completo quanto a sua instrumentação. Um antecessor faltante pode significar perda de pacotes, amostragem, um erro do exportador ou um produtor que nunca emitiu o evento. O resultado seguro é a incerteza mais uma lacuna de evidências. Não é prova de que o agente falhou. Em terceiro lugar, a ordem causal não verifica o resultado pretendido. A tool succeeded diz que a ferramenta foi devolvida com sucesso sob seu próprio contrato. Não prova que o arquivo exista no destino, que o e mail tenha chegado ao destinatário pretendido ou que a implantação serve a versão esperada. Mantenha a verificação dos resultados como um evento separado com as suas próprias provas. Quarto, a ordem topológica pode ser parcial. Os ramos independentes podem não ter uma ordem significativa entre eles. Não o fabrique para uma linha de tempo mais bonita. Presentar os ramos simultâneos juntos, e exigir um quórum explícito de união ou de conclusão antes de declarar o pai completo. A alegação falsificável para este artigo é estreita: para a fixação de onze eventos fornecida, a auditoria deve reconstruir dois fluxos de trabalho, marcar a cadeia quebrada incerta, manter uma inversão do tempo de origem e uma inversão do tempo de coleção como diagnóstico e expor ambos os casos ingênuos de terminais antes do início. Se alguma dessas contagens mudar, o artefato falha. O que isso significa para o Sidewisp O Sidewisp destina se a adicionar uma camada de saúde em torno dos tempos de execução dos agentes existentes: distinguir os estados de funcionamento, de espera, de bloqueio, de incerteza e de verificação de resultados utilizando evidências com frescura e confiança. A evidência causal consciente do relógio corresponde a essa direção porque um rastro verde não é útil se a sua ordem foi inferida a partir de relógios incompatíveis. A Sidewisp está atualmente em prévia privada. O site público e o sistema de artigos estão ao vivo, mas a coleta de agentes de produção saúde, adaptadores de tempo de execução, gerenciamento de cron, análise de custos de tokens e recuperação geralmente não são enviados. Este artigo descreve um padrão de funcionamento e um artefato de ensaio, não uma alegação de que a Sidewisp atualmente reconstrua as linhas de tempo de produção ou corrige a distorção do relógio. O produto pretendido não é um dispositivo de reposição, um gateway obrigatório, um produto de rastreamento bruto, um plano de controlo empresarial ou um fixador autônomo. Deve estar ao lado dos agentes existentes, mostrar incerteza quando a cadeia é incompleta e manter a autoridade humana sobre qualquer ação de recuperação. Se o relógio e o desordem de entrega estão a esconder o estado real dos seus agentes, juntar se à prévia privada é o próximo passo restringido; não é uma promessa que o monitoramento da produção esteja disponível hoje. O padrão operacional é, por conseguinte, simples: conservar o tempo de origem para o contexto, o tempo de recolha para a frescura, o tempo transcurrido monótono para as durações locais e as margens explícitas para a causalidade. Quando as bordas estiverem incompletas, diga o. Um uncertain honesto é mais saudável do que uma história falsa bem organizada.