AI Observabilidade: Construir um contrato de sinal de quatro camadas

A observabilidade AI não é uma categoria de painel de instrumentos. É a capacidade de responder a quatro perguntas diferentes com evidências: O trabalho era esperado? O que é que realmente correu? Está à espera de uma dependência legítima? O resultado pretendido existia e passava a verificação? Uma pilha que responde apenas à segunda pergunta pode produzir traços bonitos enquanto um agente programado nunca começa, uma aprovação humana fica despercebida ou uma corrida bem sucedida não deixa nada entregue. O padrão prático é, portanto, um contrato de sinal de quatro camadas: Agenda, execução, dependência e resultado . Mantenha a latência do modelo, os tokens, erros, chamadas de ferramentas e intervalos, mas não os confunda com todo o contrato. Este artigo testa as regras de um pequeno dispositivo NDJSON e dá lhe uma auditoria que você pode adaptar antes de comprar ou instrumentar outra plataforma. Tratar a observabilidade do AI como um problema de cobertura Os resultados de pesquisa para a observabilidade do AI misturam várias preocupações legítimas: qualidade do modelo, deriva de dados, desempenho da GPU e das aplicações, rastreamento de agentes, segurança, governança e custo. Essa amplitude é por isso que temos observabilidade é difícil de avaliar. Duas equipes podem usar a mesma frase enquanto coletam evidências discordantes. Para um agente que executa trabalho programado ou delegado, use o trabalho previsto como unidade de análise. Então, exigir uma camada para cada pergunta que pode mudar o veredicto operacional. Capa Evidências mínimas Falha que pode expor Programação Tempo esperado, prazo, hora de início, identidade do cronograma A corrida nunca começou. Execução ID de execução, passo ou período, resultado da ferramenta, estado do terminal, classe de erro a corrida parou, foi encurralada, voltou a ser tentada ou falhou Dependência Estado de espera explícito, tipo de dependência, aprovação ou referência do sistema externo A espera legítima foi erroneamente etiquetada como presa. Resultados Identidade do artefato ou do efeito colateral, verificação determinista, tempo de verificação Execução disse sucesso mas o trabalho estava ausente ou errado Estas camadas não são quatro produtos de fornecedores. São quatro conjuntos em torno de uma identificação de corrida estável. Um backend de rastreamento pode conter a maioria dos eventos de execução. Um agendador pode ter os horários esperados. Um sistema de aprovação pode possuir provas de espera. O próprio destino armazenamento de objetos, um repositório, uma API de bilhetes, um banco de dados geralmente possui a verificação de resultados mais forte. Este enquadramento mantém também o acompanhamento e a avaliação separados, sem forçá los a separarem se. Uma pontuação de qualidade baseada em rubrica pode ser um verificador de resultados quando não existe verificação determinista. Não deve substituir silenciosamente um hash de arquivo, resultado de teste, contagem de filas ou recibo de API quando um desses estiver disponível. Por que um rastro completo pode ainda perder o incidente Os padrões de rastreamento estão a melhorar rapidamente. No momento do compromisso 74fd2e0 , o modelo de cobertura e os intervalos de agentes do OpenTelemetry geração AI convenções semânticas, as métricas, os eventos, as exceções, as convenções específicas do fornecedor e o MCP. O documento marca as convenções da GenAI como Development , um importante limite de versão quando se desenham esquemas de longa duração. As especificações de intervalos de agentes definem operações como create agent , invoke agent , invoke workflow , plan e execute tool . Ele também carrega atributos úteis, incluindo gen ai.operation.name , gen ai.agent.name e error.type condicionalmente exigido; ver o Fonte de extensão do agente afixado. Isso é uma forte evidência de execução. Diz ao investigador qual operação aconteceu, como os intervalos se relacionam, quanto tempo demorou e se um erro relatado terminou a operação. O rastreamento de quadros pode ser ainda mais rico. O Documentação de rastreamento do SDK OpenAI Agents diz que o seu rastreamento padrão cobre invocações de corredores, intervalos de tarefas e viradas, agentes, gerações, ferramentas de função, guardrails e entregas. Também suporta extensões personalizadas e processadores. Isso torna possível anexar provas de negócios faltantes. No entanto, nem um período terminado nem um terminal ok estabelecem que uma corrida programada fosse prevista em primeiro lugar. Também não prova que a weekly report.pdf existe, que possui o novo período de comunicação e que passou por um analisador. A ausência não é um defeito no rastreamento. Trata se de uma fronteira entre a telemetria de execução e a evidência dos resultados operacionais. Esse limite é falsificável: faça duas corridas com eventos de execução de sucesso idênticos, adicione um evento outcome verified a apenas um, e o veredicto operacional deve diferir. Se a sua alerta atual dá a ambas as corridas o mesmo estado verde, não pode detectar falso sucesso. Realizar uma auditoria de quatro camadas em um dispositivo fixo O dispositivo de acompanhamento contém quatro corridas observadas no 2026 07 25T02:42:00Z : O run alpha inicia, chama a sua ferramenta de relatório, termina e registra um artefato verificado; O run beta tem a mesma forma de execução bem sucedida, mas não tem resultado verificado; O run gamma espera explicitamente a aprovação do approve 42 ; A run delta ultrapassa o prazo previsto sem um evento de início. Execute a auditoria com Node.js 20 ou mais recente: O classificador retorna uma corrida em cada estado: O código usa uma ordem de decisão deliberadamente chata. Um resultado verificado ganha. Uma espera explícita com uma razão e uma referência de aprovação está à espera, não presa. Uma corrida que nunca começou antes do seu prazo é perdida. Uma corrida completa sem evidências de resultado é um falso sucesso. Uma corrida iniciada após o prazo está presa. Tudo o resto continua a funcionar em vez de ser promovido a ser saudável. Isto é uma experiência, não um ponto de referência. Quatro casos feitos à mão não podem estimar as taxas de erro de produção, e um classificador real precisa de manipulação de eventos duplicados, tolerâncias de desvio do relógio, resultados de chegada tardia e prazos por trabalho. A fixação é útil porque cada veredicto é inspecionável e alterar um evento altera um resultado. Preserva a espera como seu próprio estado Um campo binário saudável/insalubre destrói a informação no momento em que o operador a necessita. Considere o run gamma : o processo não está progredindo, mas reiniciar seria o padrão errado. Tem uma dependência explícita de aprovação. A ação correta é apresentar o pedido à pessoa certa, preservando o seu alcance, idade e limites de autoridade. Armazenar pelo menos: Utilize a mesma abordagem para os tempos de redefinição dos limites de taxa, IDs de emprego externos, janelas de manutenção e chegadas de dados upstream. Uma mensagem de texto livre como still waiting é uma prova fraca: é difícil de encaminhar, expirar ou correlacionar. Uma dependência digitada mais uma referência opaca suporta uma resposta limitada sem copiar o conteúdo secreto, prompt ou aprovação na telemetria. A atividade é igualmente fácil de sobrevalorizar. As chamadas repetidas de ferramentas mostram que um processo está ocupado; somente os deltas no estado ou resultado mostram progresso útil. Um contador de retestamento pertence, portanto, ao lado do último tempo de mudança significativa, não ao lado de um selo de tempo genérico que um ciclo pode atualizar para sempre. Tornar o resultado da verificação nativa do destino O verificador mais forte vive onde o trabalho deveria ter aterrizado. Para um arquivo, gravar uma chave de objeto estável, tamanho, digest e resultado do parser. Para uma solicitação de retirada, registar o repositório, o número de relações públicas, o ramo alvo e a conclusão da verificação requerida. Para uma atualização do CRM, registar a identificação de entidade não secreta, a transição de campo esperada e o resultado de leitura após escrita. Não coloque o produto bruto em todos os vestígios. Armazenar a menor evidência necessária para repetir o controlo. A documentação do OpenAI Agents SDK adverte que os intervalos de geração e função podem conter entradas e saídas sensíveis e descreve controles para desativar essa captura. Aplique o mesmo princípio aos seus eventos personalizados: os identificadores e digestos são geralmente mais seguros do que as instruções, respostas, credenciais, caminhos locais absolutos ou conteúdo do cliente. A verificação dos resultados também requer frescura. Um arquivo deixado pela corrida de ontem não é prova de que a corrida de hoje tenha sido bem sucedida. Junte o artefato à execução atual através de um ID de execução, um período de relatórios esperado, uma janela de criação ou um digest calculado após a hora de início atual. Há uma troca. Os controlos nativos de destino acrescentam trabalho de integração e podem falhar de forma independente. Tratar um verificador indisponível como unknown , não saudável e não falhado automaticamente. Superficie as provas faltantes, a sua última verificação bem sucedida e a confiança do veredicto resultante. Ferramentas de auditoria contra o contrato antes de comparar características Uma avaliação útil do produto começa com quatro linhas, não com uma grade de logotipo. Para cada pilha de candidatos, pergunte onde cada camada se origina, como ela se une à corrida, quanto tempo ela é retida e qual consulta prova cobertura. 1. Pode importar ou derivar os intervalos esperados, incluindo fuso horário e prazo? 2. Pode rastrear modelos, ferramentas, transferências, retestes e erros sem exigir captura de carga útil sensível? 3. Pode representar a espera com uma dependência tipificada e um alvo de escalada? 4. Pode ingerir ou vincular receitas deterministas de resultados do destino? 5. Pode distinguir evidências inexistentes de um resultado saudável? 6. Pode exportar os dados através de um formato aberto ou API se a ferramenta mudar? Não rejeite uma ferramenta de rastreamento focada porque carece de programação ou semântica de resultados. Combine o com as fontes faltantes se as articulações forem confiáveis. Rejeita a arquitetura quando não possa representar a distinção que você precisa, oculte os dados faltantes por trás do status verde ou requer conteúdo sensível bruto para verificações de saúde rotineiras. O contrato de quatro camadas resolve a questão original: a observabilidade do AI para agentes operacionais é completa somente quando pode explicar a expectativa, a execução, a dependência e o resultado verificado separadamente. Os vestígios são evidências essenciais, mas são uma camada. A Sidewisp está atualmente em prévia privada. O seu papel pretendido é uma camada de saúde ao lado dos tempos de execução existentes, com evidências e limites de autoridade humana; os adaptadores de monitorização da produção e recuperação geralmente não são enviados hoje. Se este contrato de sinal coincidir com as falhas que você precisa detectar, você pode se juntar à lista de acesso precoce sem substituir o seu runtime ou modelo de gateway.