Observabilidade multiagente: auditar a topologia de coordenação

A observabilidade multiagente deve responder a uma pergunta mais rigorosa do que “todos os intervalos registrados terminaram?” Deve informar se os agentes que realmente participaram e as rotas que eles realmente usaram correspondem ao projeto de coordenação aprovado para esta execução. O padrão prático é um contrato de topologia versionado : um pequeno manifesto de agentes permitidos, arestas direcionadas permitidas e as arestas esperadas na fase de execução atual. Junte se a esse manifesto para obter receitas de interação sem conteúdo. Um rastreamento bem sucedido pode então ser classificado como funcionando, em espera, incompleto, inseguro, ambíguo ou falso completo, em vez de se tornar verde por padrão. Isso é importante porque um rastreamento registra o que aconteceu. Não pode conter um intervalo para uma delegação necessária que nunca ocorreu. Ele também não pode decidir que uma rota direta observada foi proibida, a menos que você forneça o gráfico pretendido. A mesma distinção aparece nas orientações de arquitetura atuais: Microsoft'sarquitetura de referência multiagentechama fluxos de mensagens entre agentes e padrões de coordenação como sinais especiais de observabilidade, enquanto oAzure Architecture Centeralerta que a orquestração multiagente adiciona sobrecarga de coordenação e novos modos de falha. Use a menor complexidade que satisfaça a tarefa de maneira confiável; quando vários agentes são justificados, torne sua topologia testável. Um rastreamento não pode provar a topologia pretendida API de rastreamento de OpenTelemetryfornece as primitivas de correlação corretas: identidade de rastreamento e extensão, parentesco, links, eventos, carimbos de data/hora, atributos e status. Essas primitivas podem descrever uma árvore de chamadas observada ou um relacionamento assíncrono. Eles não declaram quais agentes foram permitidos, qual versão da rota estava ativa ou qual borda deveria ter aparecido, mas não apareceu. Suponha que um orquestrador delegue a pesquisa, o pesquisador entregue as evidências a um verificador e o verificador retorne um veredicto. Cada evento observado pode ter status: "ok" em pelo menos cinco situações ruins: a execução usou a política de roteamento de ontem; o pesquisador ligou diretamente para um editor, evitando a revisão; um agente não cadastrado entrou no gráfico; o orquestrador delegou duas vezes a mesma rota própria; o pai declarou a conclusão antes do verificador retornar. Uma consulta “todos os eventos OK” não vê erros nesses registros. Em vez disso, uma auditoria de topologia compara dois conjuntos: Mantenha esta camada livre de conteúdo. Um recibo precisa de identidades estáveis ​​de execução e agente, tipo de rota, versão da topologia, identidade do evento, tempo de observação e status local. Não são necessários prompts, respostas, segredos, argumentos de ferramentas ou caminhos absolutos de arquivos. O contrato é deliberadamente separado de um quórum de conclusão de distribuição. Um quórum pergunta se as ramificações necessárias foram retornadas. Um gráfico de espera pergunta qual dependência está bloqueando o progresso. Um recibo de transferência durável pergunta se a responsabilidade sobreviveu a uma fila ou limite de reinicialização. A conformidade da topologia faz uma pergunta prévia: este é mesmo o gráfico de coordenação que pretendíamos executar? Crie um contrato de coordenação versionado Comece com identidades explícitas e arestas direcionadas. Não infira o gráfico permitido a partir do que apareceu no último traço; isso apenas abençoa a deriva após o fato. O conjunto permitido não é igual ao conjunto esperado. Uma fase apenas de pesquisa pode esperar duas delegações e nenhuma vantagem para os editores. Uma fase de publicação completa pode esperar a transferência da pesquisa, o retorno do verificador, a delegação do editor e o retorno do editor. Fixe esse conjunto específico de fase quando a execução começar. Caso contrário, uma vantagem opcional pode tornar se silenciosamente obrigatória no meio de uma falha, ou uma vantagem necessária pode desaparecer da definição antes que alguém perceba. Um classificador compacto pode usar esta precedência: 1. contrato obsoleto — a versão do evento é diferente da versão fixada; 2. agente desconhecido — qualquer endpoint está fora do conjunto de identidades aprovado; 3. borda proibida — a rota direcionada e o tipo de interação não são permitidos; 4. rota ambígua — a mesma aresta pertencente aparece mais de uma vez sem uma regra de multiplicidade explícita; 5. falso completo — um pai terminal não possui uma vantagem esperada ou recibo de resultado verificado; 6. esperando — uma vantagem esperada está ausente, a dependência nomeada é explícita e o prazo não expirou; 7. incompleto — uma vantagem esperada ainda está ausente após seu prazo; 8. saudável ou funcionando — o conjunto observado corresponde ao plano atual, com “saudável” reservado para um resultado final verificado. Encomendar é importante. Se um agente sombra usa uma rota proibida e o pai também está atrasado, “incompleto” é muito fraco: o operador primeiro precisa conter uma topologia não aprovada. Por outro lado, uma espera declarada antes do prazo não é uma paralisação. É um estado de dependência íntegro que deve atingir o proprietário correto sem desencadear uma redefinição destrutiva. O roteamento dinâmico é a principal limitação. Um sistema pode escolher legitimamente entre agentes especializados em tempo de execução. Represente essa escolha como uma classe de borda limitada ou produza o plano de execução exato antes do envio. Um curinga como orchestrator é fácil de manter, mas remove a maior parte do valor de diagnóstico. As alterações de versão devem ser auditáveis ​​e uma execução nunca deve adotar silenciosamente uma nova versão no meio do caminho. A amostragem é outro limite. Traços pesados ​​podem ser amostrados, mas as receitas de topologia compacta usadas para decisões de saúde não podem desaparecer sob a mesma política. Se um recibo obrigatório não estiver disponível, informe uncertain ou incomplete ; não reconstrua o verde a partir de um traço parcial. Repita o desvio antes de confiar na conclusão Repassei nove casos sem conteúdo contra o contrato acima. O dispositivo incluía uma conclusão saudável, trabalho atual, uma espera legítima, uma borda perdida após o prazo, uma topologia obsoleta, uma rota direta proibida, um agente desconhecido, propriedade de rota duplicada e um terminal pai sem aviso de recebimento. A auditoria determinística correspondeu a todos os nove estados esperados. Uma regra ingênua – existe pelo menos um evento, o status de cada evento local é ok e o pai não falhou – marcada todos os nove casos em verde . Apenas um estava saudável. Seis desses nove verdes ingênuos eram inseguros, incompletos, obsoletos, ambíguos ou falsamente completos; os dois restantes estavam trabalhando e esperando, afirma que não deveria entrar em colapso com a saúde completa. Caso Todos os eventos registrados estão bem? Veredicto de topologia Significado do operador : Gráfico completo mais recibo de resultado Sim healthy O gráfico planejado e o resultado final são verificados Arestas planejadas atuais Sim working O trabalho útil pode continuar; não intervenha Falta de devolução antes do prazo Sim waiting Notifique ou observe a dependência nomeada Mesma devolução faltando após o prazo Sim incomplete Investigue a primeira aresta esperada ausente Versão antiga da topologia Sim stale contract Pare de comparar a execução com o design errado Rota direta não aprovada Sim forbidden edge Contenha a rota antes de tentar novamente o trabalho Participante desconhecido Sim unknown agent Verifique a identidade e autoridade Rota de propriedade duplicada Sim ambiguous route Reconciliar propriedade e possíveis efeitos duplicados Terminal pai, retorno ausente Sim false complete Reabra a corrida; conclusão carece de evidências exigidas Você pode reproduzir a decisão com uma pequena função em teclas de borda normalizadas: Execute as verificações de topologia antes da pontuação de progresso, qualidade ou resultado. Em seguida, mantenha os limites do veredicto explícitos: a conformidade da topologia prova apenas que a forma de coordenação aprovada foi observada; working requer novas evidências de movimento útil, e não apenas mais eventos; waiting requer uma dependência e um prazo nomeados; A conclusão de healthy requer um destino determinístico ou recibo de entrega quando disponível; as evidências incertas devem permanecer incertas; qualquer recuperação ativa precisa de autoridade limitada, visibilidade e verificação pós ação. Isso dá ao operador uma regra de adoção restrita: não confie em uma conclusão multiagente até que a topologia fixada da execução, a fase atual e o recebimento do resultado final estejam de acordo. Um gráfico correspondente é uma evidência necessária, não uma prova de que a resposta está correta. A Sidewisp está atualmente em prévia privada. Seu site público de acesso antecipado e demonstração interativa são ao vivo, mas um adaptador de monitoramento multiagente de produção, coletor de integridade ativo e executor de recuperação automatizado não são fornecidos. A função pretendida do Sidewisp é adicionar uma camada de integridade em torno dos tempos de execução existentes e tornar mais fáceis de inspecionar evidências, gravidade, incerteza e a próxima ação mais segura não substituir o tempo de execução ou agir sem autoridade humana.