AI Agente Observabilidade para retrospectivas: captura de efeitos duplicados

Um agente não deve retomar uma chamada de ferramenta apenas porque o rastreamento termina em um tempo intercalar. A solicitação pode ter chegado ao prestador, alterado o estado real e ter perdido apenas a resposta. Uma segunda tentativa pode então enviar a mensagem duas vezes, criar dois bilhetes ou fornecer dois recursos enquanto ambos os vestígios parecem razoáveis individualmente. A regra de saúde útil é mais rigorosa: a operação lógica do one não deve produzir mais de um efeito verificado . Dê à operação uma identidade estável, mantenha essa identidade em todas as tentativas, registre os recibos de efeitos do lado do fornecedor e bloqueie a retomada automática quando o efeito não pode ser analisado com segurança. As tentativas de contagem e o status HTTP ainda ajudam com o diagnóstico, mas nenhum deles prova o resultado. Este artigo constrói essa regra em um pequeno livro de efeitos e a testa contra quatro operações. O dispositivo contém oito tentativas e quatro observações do fornecedor. Uma política de apenas tentativa veria temporadas e continuaria a tentar três operações. A auditoria consciente dos efeitos encontra, em vez disso, uma repetição saudável, um incidente de duplicado efeito, um conflito de chave de independência e uma operação honestamente incerta. Uma pausa não é prova de que nada aconteceu. A janela perigosa fica entre a execução remota e o reconhecimento local. Um provedor pode cometer um efeito e depois perder a resposta no caminho de volta. Do lado do agente, estas duas histórias são observacionalmente semelhantes: 1. o pedido nunca chegou ao prestador; 2. O pedido foi concluído, mas a resposta não chegou ao agente. Só a primeira história é segura para repetir sem outra salvaguarda. O segundo cria um duplicado quando a operação não é naturalmente idempotente. A semântica HTTP fornece um limite útil. A RFC 9110 define um método idempotente como um cujo efeito de servidor pretendido é o mesmo após várias solicitações idênticas que após uma única solicitação. Permite repetição automática após uma falha de comunicação para métodos idempotentes, mas diz que um cliente não deve retomar automaticamente uma solicitação não idempotente a menos que saiba que a operação é efetivamente idempotente ou possa detectar que o original nunca foi aplicado. Essa distinção pertence à saúde dos agentes. Um PUT que substitui um registro conhecido e um POST que envia um e mail podem ambos tempo fora, mas eles não têm o mesmo limite de retest. Uma política genérica timeout → retry elimina o fato semântico que mais importa. O apoio do fornecedor ajuda, mas o contrato deve ser lido com precisão. Documentos de tiras que armazena o código de status e corpo para a primeira solicitação feita com uma chave de idempotency, em seguida, retorna esse resultado para solicitações posteriores com a mesma chave. Também compara os parâmetros e rejeita a reutilização com diferentes parâmetros. A chave não é, portanto, um rótulo aleatório ligado a cada tentativa. Representa uma operação lógica estável. Documentos da Amazon EC2 um padrão similar de token do cliente: uma tentativa bem sucedida com o mesmo token e parâmetros não realiza mais nenhuma ação, enquanto os parâmetros alterados podem produzir IdempotentParameterMismatch . A EC2 também abrange algumas garantias a nível regional ou regional. Tenha um token não é suficiente; o registro de saúde precisa do escopo do token, da identidade da carga útil, da janela de retenção e do comportamento do provedor. O padrão razoável é: Reutilizar uma identidade de operação em todas as tentativas; Reutilizar a chave de independência do prestador apenas para a mesma carga útil canónica; Após um resultado ambíguo, consulta por essa identidade antes de retomar a tentativa; Se o prestador não oferecer nem independência nem procura, exigir uma decisão humana para efeitos consequentes. O retorno reduz a pressão sobre um serviço falhado. Não transforma uma ação não idempotente em idempotente. Efeitos registados, não apenas tentativas Um rastreamento comum responde o que tentou o agente? Um livro de efeitos responde à pergunta diferente que alteração durável podemos provar? Mantenha os dois registros ligados, porque as tentativas permanecem evidências úteis, mas não trate o período terminal de uma tentativa como o resultado comercial. Um livro razão mínimo requer estes campos: Campo Propósito Falha de saúde que expõe operationId Identidade estável para a operação prevista pelo utilizador Uma nova identificação gerada para cada nova tentativa attemptId Identidade por uma tentativa de transporte Tentativas perdidas ou sobrepostas idempotencyKey Identidade de deduplicação do fornecedor, quando suportada Mudanças chave em retrospectivas payloadHash Hash de uma carga útil canônica, editada A mesma chave reutilizada para diferentes propósitos effectRef Identidade do fornecedor ou do destino do efeito real Mais de um efeito duradouro result Observação de transporte, como timeout ou success Reconhecimento ambíguo observedAt Tempo em que as provas foram recolhidas Evidências obsoletas confundidas com o estado atual Não coloque segredos, endereços de e mail, pedidos completos ou ferramentas cruas em esses campos. Hash uma representação canônica após a remoção de valores voláteis. Manter a matéria prima sensível na origem quando for exigido pela investigação. A identidade da operação deve ser impressa quando a intenção se torna duradoura, e não dentro do ciclo de retest. Por exemplo: O fragmento é incompleto por conceito: capturar uma exceção e continuar não é prova de segurança. O chamador deve também conservar a identificação do objeto devolvido do prestador ou consultar o prestador pela mesma identidade comercial após uma resposta ambígua. Contem efeitos únicos, não respostas bem sucedidas. Duas respostas bem sucedidas que ambos chamam ticket 908 descrevem um efeito. Um timeout seguido por um sucesso que nomeia delivery a e delivery b descreve dois efeitos. Por outro lado, os recibos de zero não provam efeitos de zero quando o canal de busca não está disponível. Esse estado é uncertain , não saudável e não automaticamente preso. A identidade da carga útil é um portal separado. Se duas tentativas compartilharem uma chave de idempotencia, mas tiverem hashes de carga útil canônicos diferentes, pare antes de interpretar a contagem de efeitos. O chamador pode ter reutilizado acidentalmente uma chave após alterar a região, destinatário, quantidade ou forma do recurso solicitado. Os erros de parâmetro desconformidade do lado do fornecedor são uma prova útil desta falha exata. Realizar uma auditoria de efeitos de quatro operações O dispositivo inspecionável utilizado para este artigo é NDJSON. Cada linha é uma observação attempt ou uma observação effect . O artefato local completo contém quatro operações lógicas: op ticket 42 : duas tentativas compartilham uma chave e uma carga útil; ambas as observações apontam para ticket 908 ; op webhook 77 : duas tentativas não têm chave de idempotencia e revelam delivery a mais delivery b ; op vm 5 : duas tentativas de reutilização de uma chave com hashes de carga útil diferentes; op email 3 : duas tentativas de tempo fora, nenhum recibo de efeito está disponível e o prestador não tem caminho de busca. Os grupos de auditoria registam por operationId , rejeitam a deriva da carga útil antes de contar os efeitos e contam valores effectRef distintos em vez de linhas de observação de efeitos: Execução do artefato do repositório: produz: Três observações alteram a decisão operacional. Primeiro, o op ticket 42 tem dois registros de tentativas e duas observações de efeitos, mas ambas as observações resolvem se a um objeto fornecedor. Alerta em linhas de efeito 1 seria falsa positiva. A referência do fornecedor estável é o que prova a deduplicação. Em segundo lugar, o op webhook 77 inclui uma segunda tentativa bem sucedida. Um painel de transporte só pode fechar o incidente. As duas referências de efeito provam que a recuperação criou uma segunda entrega, então o estado correto é duplicado e a próxima tarefa é a reconciliação, não outra tentativa. Em terceiro lugar, o op vm 5 não tem efeito duplicado na fixação, mas ainda não é seguro. A chave reutilizada cobre dois hashes de carga útil diferentes. Esperar até que apareça um segundo recurso detectaria o problema demasiado tarde; o principal conflito é uma falha preventiva na saúde. A auditoria tem uma importante limitação: só pode classificar as provas fornecidas. Para o op email 3 , nenhum recibo e nenhum caminho de busca deixam o resultado desconhecido. O livro razão não pode fabricar certeza. A repetição pode completar o trabalho faltante ou duplicar o trabalho concluído, por isso a resposta limitada é surgir a ambigüidade e pedir autoridade. Transformar o resultado em um limite de retest Use classificação para controlar a próxima ação, não apenas a cor de um painel: Classificação Evidências Segurança por defeito healthy Uma identidade de carga útil e exatamente um efeito único Parar de retestar; verificar a entrega prevista duplicate Mais de um efeito único para uma operação Repetições em blocos; reconciliar ou compensar com a aprovação key conflict Uma chave ligada a múltiplos hashes de carga útil Execução de blocos; não uma nova operação somente após a revisão da intenção uncertain Não há prova de efeito e não há prova de ausência confiável Pergunte outra vez, espere por novas provas, ou pergunte a um ser humano Ainda é necessário um limite de tempo. Os registos de idempotencia do fornecedor podem expirar, os índices de busca podem atrasar e um destino pode estar fora dos limites de transação do fornecedor. Armazenar a armazenagem documentada e o escopo ao lado da chave. Após a expiração desse limite, a mesma solicitação pode deixar de ser segura, mesmo que o caminho do código original não tenha mudado. A verificação da recuperação deve alcançar o resultado original. Um único objeto fornecedor pode ainda estar errado: um ticket pode existir com o projeto errado, ou um recurso pode ser criado mas nunca se tornar pronto. O invariante de um efeito impede a duplicação; um contrato de resultado separado verifica que o efeito de sobrevivência é o que o usuário pretendia. Para uma visão da saúde operacional, informe cinco fatos em conjunto: 1. A operação lógica e a impressão digital da carga útil; 2. As tentativas e os seus resultados de transporte; 3. O âmbito e a frescura da independência do prestador; 4. Os diferentes efeitos duradouros observados; 5. O limite da autoridade para a retomada, a compensação ou a reconciliação. Isso faz do "retiro" um sucesso uma prova em vez do veredicto. O veredicto mais saudável é que existe um efeito pretendido e foi verificado, ou, quando a evidência é incompleta, o efeito é incerto; a retomada automática é bloqueada. A Sidewisp está atualmente em prévia privada. Seu sistema de artigos públicos e demonstração de produtos interativos sã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. Os exemplos acima apresentados constituem um padrão de funcionamento e não uma alegação de que a Sidewisp atualmente inspeciona ou repara agentes vivos. O Sidewisp não é um tempo de execução de substituição, um gateway obrigatório, um produto de rastreamento bruto, um plano de controlo empresarial ou um fixador autônomo. Se uma regra de saúde do livro de efeitos o ajudaria a operar agentes existentes, considere aderir à pré visualização privada. Mantenha a execução onde já está; faça com que as tentativas retomadas ganhem a sua segurança através de provas.