AI Agente Observabilidade: impressão digital a cada corrida

A resposta mais curta e útil é: anexe uma impressão digital run manifest a cada execução do agente, então compare a saúde apenas depois de saber se o tempo de execução, o modelo de instantâneo, o prompt, a política, o esquema de ferramenta e a imagem de implantação foram os mesmos. Um rastro diz o que uma corrida fez. O manifesto diz lhe que versão do sistema o fez. Essa impressão digital não é uma pontuação de saúde e não prova porque uma corrida falhou. É uma chave de ramificação. Se uma regressão aparecer sob uma nova impressão digital, inspecione primeiro a deriva de configuração. Se aparecer sob a antiga impressão digital, procure mudanças de ambiente não gravadas, dependência, provedor, dados ou permissões. Um nome de agente estável pode esconder um sistema diferente Suponhamos que a support triage preencha dois bilhetes corretamente na sexta feira e perde a escalada necessária na segunda feira. Ambas as corridas têm o mesmo nome de agente. Ambos emitem batimentos cardíacos. Ambas as ferramentas de chamada. A agrupá los parece natural e pode ser errado. Entre essas corridas, qualquer uma destas pode ter mudado: Componente manifesto Registo Evite a gravação Tempo de execução nome e versão exata ou compromisso caminho de hospedagem, token de acesso Modelo fornecedor e snapshot afixado quando disponível Chave API, resposta completa Rapido SHA 256 do pacote de solicitações revisto Cliente bruto ou sistema imediato Políticas hash ou revisão imutável Valores secretos incorporados na política Ferramentas hash de esquema canônico credenciais, cargas úteis de ferramentas Deploição Digestamento de imagem ou autorização de fonte senha de registro Isso segue uma ideia de observabilidade estabelecida em vez de inventar um segundo formato de rastreamento. O OpenTelemetry Resource SDK descreve um recurso como uma representação imutável da entidade que produz telemetria. Para uma execução de agente, a configuração de execução é parte dessa identidade. Mantenha a identificação de rastreamento para uma execução e a impressão digital do manifesto para a versão que a produziu; nenhum substitui o outro. Um manifesto útil é deliberadamente chato. Contém identificadores estáveis, não observações como latência, contagem de tokens, estado de saída ou resultado. Estes pertencem ao lado do manifesto. Misturar as no hash criaria uma nova impressão digital para cada corrida e destruiria a comparação. Há também um limite de privacidade: hash um prompt ou política localmente, mas não carregue o original apenas para explicar a sua identidade. Os hashs ainda podem vazar informações quando a entrada vem de um conjunto pequeno e adivinável, por isso, use IDs de liberação opacas ou um digest local com teclado quando essa ameaça for importante. Nunca coloque credenciais no manifesto, mesmo antes de hashar todo o objeto. Canonizar antes do hashing Hashing JSON bruto é uma armadilha porque a ordem de chave de objeto e as escolhas de serialização insignificantes podem diferir enquanto a configuração representada permanece a mesma. O Sistema de canonização JSON no RFC 8785 define a serialização determinista, incluindo a classificação de propriedades recursivas. O código de produção deve utilizar uma implementação revisada do JCS quando for relevante a interoperabilidade. Para um experimento local compacto, a seguinte função Node.js é suficiente para valores JSON finitos ordinários: O experimento usou Node.js v22.23.1 . É intencionalmente mais estreita que a RFC 8785: classifica as chaves de objeto de forma recorrente e rejeita números não finitos, mas não é uma reivindicação de conformidade completa com o JCS translanguagem. Essa limitação pertence ao lado do código, não numa nota de rodapé depois que um leitor o copiou. O manifesto em si pode permanecer pequeno: Os valores de posicionamento acima são identificadores de fixação, não reivindicações de fornecedores. Em um coletor real, obtém los no anfitrião a partir de lançamentos fixados. O princípio mais amplo se assemelha à Província da SLSA: manter informações verificáveis sobre onde, quando e como algo foi produzido. Um manifesto de execução leva emprestado esse princípio para o diagnóstico; não é automaticamente uma certificação SLSA. Uma repetição de seis corridas expõe o valor e o limite Testei a regra contra seis registos sintéticos do NDJSON para um agente. As corridas 101 e 102 contêm os mesmos valores manifestos em diferentes ordens de chaves JSON. Execute 103 altera apenas o hash de prompt, 104 altera apenas o snapshot do modelo e 105 altera apenas o hash do esquema de ferramenta. A execução 106 falha por causa de uma interrupção de dependência que o manifesto de fixação não representa. O comando de auditoria foi: O resultado determinista: Duas observações são mais importantes do que as contagens. Primeiro, um nome do agente escondeu quatro configurações gravadas. Em segundo lugar, os dois objetos de linha de base ordenados de forma diferente produziram a mesma impressão digital SHA 256, de modo que a ordem de serialização não criou uma falsa deriva. O contra exemplo é a parte importante: a run 106 falhou com a impressão digital de base. Uma impressão digital inalterada não tornou a corrida saudável, e não provou que o ambiente fosse inalterado. Só mostrou que os campos de configuração gravados não foram alterados. A próxima investigação deve examinar evidências fora dessa disponibilidade do fornecedor, dados de entrada, rota da rede, estado de permissão e frescura da dependência. O dispositivo é sintético, por isso demonstra a mecânica e falsifica uma reivindicação excessiva; não estima a frequência com que a deriva de configuração causa incidentes reais. Isso exigiria dados de produção com libertações controladas e resultados verificados. Transformar a impressão digital numa decisão de triagem Usar a impressão digital somente após a corrida ter um resultado observável. A atividade por si só tokens emitidos, ferramentas chamadas ou um processo ainda vivo não estabelece progressos úteis. Evidências de resultados Comparação das impressões digitais Primeira sucursal Passado O mesmo que na linha de base Manter como referência saudável comparável Falha Mudanças Diferenciar os campos do manifesto editados; considerar um retrocesso ou repetição limitados Falha O mesmo. Inspeccionar dependências, permissões, entradas, estado do fornecedor e cobertura de manifesto ausente Desconhecido Ou seja: Recolher ou definir o resultado esperado antes do diagnóstico de deriva Três regras operacionais mantêm isto honesto: 1. Freeze the comparison point. Escolha uma execução verificada com sucesso para a mesma classe de tarefas, não apenas o status verde mais recente. 2. Mantenha um mapa de nível de campo editado. O hash inteiro manifestado diz diferente. Digestes de componentes individuais dizem onde inspecionar sem revelar conteúdo. 3. Verificar o resultado após a intervenção. Um comando de retrocesso que é bem sucedido é a atividade. Recuperação significa que o resultado esperado aparece, o teste passa ou outro teste de aceitação determinista é aprovado. Não reverter automaticamente todas as impressões digitais alteradas. Uma liberação pode ser intencional, e uma falha pode vir da entrada em vez da liberação. Use a mudança como evidência para uma revisão, preserve a aprovação humana para as ações consequentes e registre o que aconteceu após a ação. Quando isso se encaixa no controlo da saúde do agente A impressão digital de execução conecta três questões de saúde que só os vestígios não podem resolver de forma limpa: mudou se uma política de decisão, mudou um contrato de ferramenta e regressou a qualidade dos resultados no mesmo sistema registado? Também melhora as transferências de incidentes porque outro operador pode comparar a identidade exata da liberação sem receber pedidos, segredos ou cargas úteis de ferramentas brutas. O modelo de saúde pretendido do Sidewisp inclui execução, memória e contexto, ferramentas, resultados, disponibilidade e custo. Um futuro adaptador do lado hospedeiro poderia usar um manifesto editado como evidência de apoio para esses diagnósticos, mas esse é o território planejadonão uma alegação de monitoramento enviada. A Sidewisp está atualmente em prévia privada. O sistema público de sites e artigos está em operação; coleção de agentes de produção e saúde, adaptadores de tempo de execução e recuperação automática não estão geralmente disponíveis. Se este modelo de evidência coincidir com uma falha que você opera hoje, o próximo passo restringido é juntar se à lista de espera de pré visualização privada e descrever a verificação de tempo de execução e resultados que você precisanão assumir que a Sidewisp já a recolhe.