Como é que o Event Sourcing preserva um registo de auditoria das decisões dos agentes de IA?
O event sourcing preserva um registo de auditoria do agente de IA ao registar cada decisão aceite e alteração de estado como um evento ordenado, em vez de substituir um único estado atual mutável.
Num servidor doméstico, isto torna a automatização em várias etapas reconstruível: um operador pode acompanhar a proposta, a aprovação, a chamada de ferramenta, a falha, a nova tentativa, a compensação e o estado final depois de o fluxo de trabalho terminar.
O Event Sourcing Armazena as Alterações de Estado como Registo Principal
O event sourcing regista cada alteração de estado aceite como um evento, em vez de tratar a linha mutável mais recente como a única fonte de verdade. O estado atual é obtido a partir do histórico ordenado.
Martin Fowler define o event sourcing como o armazenamento de todas as alterações ao estado da aplicação sob a forma de uma sequência de eventos. O histórico preserva a forma como o sistema chegou a determinado estado. Martin Fowler define o event sourcing com base no armazenamento das alterações de estado como uma sequência de eventos, captando a ideia de registo principal utilizada em Martin Fowler sobre event sourcing.
Para um agente de IA doméstico, ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed e CompensationCompleted podem permanecer como factos separados, em vez de serem condensados num único campo de estado.
Cada Decisão do Agente Torna-se um Facto Ordenado no Tempo
Um evento deve descrever algo que já aconteceu e conter contexto suficiente para ser interpretado mais tarde: ID do fluxo de trabalho, ferramenta, hash dos parâmetros, resultado da política, resultado da decisão e marcas temporais, quando apropriado.
Fowler observa que, com event sourcing, o arquivo de eventos se torna a principal fonte de verdade e o estado pode ser reconstruído através de reprodução. Essa sequência ordenada cria um percurso de auditoria causal. A Microsoft Azure descreve um arquivo de eventos apenas de adição, no qual os eventos representam alterações ao estado da aplicação, apoiando os factos de decisão ordenados no tempo descritos em padrão Event Sourcing da Azure.
O objeto de auditoria útil é o artefacto de decisão observável, não o raciocínio privado oculto: que ação foi proposta, que política a avaliou, que resultado foi devolvido e que efeito secundário ocorreu efetivamente.
As Projeções Transformam o Registo de Eventos em Vistas Atuais
Reproduzir todo o histórico para cada ecrã ou pedido do agente seria ineficiente.
Os sistemas baseados em event sourcing criam projeções, como o estado atual do fluxo de trabalho, aprovações pendentes ou falhas recentes.
O event sourcing pode reconstruir o estado atual da aplicação a partir dos eventos registados. Assim, uma projeção pode ser reconstruída se a sua lógica ou base de dados mudar. As orientações da AWS descrevem a obtenção do estado atual a partir de eventos persistidos, ilustrando como as projeções podem criar vistas de leitura sem substituir o histórico subjacente em orientações da AWS sobre event sourcing.
Num servidor pequeno, os instantâneos podem reduzir o tempo de reprodução, enquanto os eventos continuam a ser a autoridade. O instantâneo é um atalho de desempenho; a sequência de eventos é o histórico.
Os IDs de Correlação Ligam o Trabalho em Várias Etapas a um Único Histórico de Decisão
Um pedido pode desencadear a obtenção de dados, o planeamento, a aprovação, várias chamadas de ferramentas, novas tentativas e compensação.
Um ID de correlação agrupa esses eventos numa operação coerente.
Isto é diferente de simplesmente armazenar os registos noutro local. O isolamento externo dos registos de auditoria da ZimaSpace explica como as provas sobrevivem ao comprometimento da aplicação; o event sourcing explica como o próprio estado do fluxo de trabalho se torna um histórico ordenado. A Kurrent salienta fluxos de eventos ordenados e identificadores, o que permite correlacionar etapas relacionadas num único histórico de decisões rastreável em conceitos de event sourcing da Kurrent.
Ambos podem ser combinados: os registos de eventos alimentam a reprodução operacional, enquanto cópias orientadas para adição são exportadas para um limite de registo separado, garantindo uma preservação mais robusta das provas.
As Correções Adicionam Novos Eventos em Vez de Reescreverem o Histórico
Se mais tarde se descobrir que uma decisão do agente estava errada, um sistema baseado em event sourcing regista um evento de compensação ou correção, em vez de editar o evento original até este desaparecer.
A discussão de Fowler sobre a temporalidade dupla ilustra a ideia mais ampla de que o histórico dos registos pode permanecer apenas de adição, mesmo quando conhecimentos posteriores corrigem pressupostos anteriores. O Marten mantém os eventos como um histórico apenas de adição e reconstrói o estado do agregado a partir deles, ilustrando por que motivo as correções podem ser adicionadas em vez de reescreverem silenciosamente factos anteriores na documentação do arquivo de eventos do Marten.
Isto é útil quando as políticas ou os prompts mudam. Um operador pode ver que uma ação foi aceite ao abrigo de uma determinada versão da política e posteriormente revertida, em vez de ver apenas o estado final corrigido.
O Event Sourcing Não Torna Automaticamente as Provas à Prova de Adulteração
Um histórico de eventos só é tão fiável quanto os controlos aplicados à criação, ao armazenamento, ao acesso, aos relógios e à eliminação dos eventos.
Um processo autorizado a reescrever o arquivo pode continuar a destruir o seu próprio histórico.
Fowler salienta as vantagens de auditoria e de consulta histórica quando o registo de eventos permanece como o arquivo de informação autoritativo. A durabilidade e os controlos de adição continuam a ser questões operacionais distintas. Investigação recente aplica históricos de eventos estruturados e apenas de adição à atividade de agentes autónomos, deixando também claro que uma lógica de aplicação apenas de adição não equivale a armazenamento à prova de adulteração; consulte event sourcing para agentes autónomos.
O design de agentes com prioridade às ferramentas só de leitura da ZimaSpace reduz as ações perigosas antes de estas ocorrerem; o event sourcing preserva as decisões e ações que efetivamente aconteceram.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
As câmaras domésticas conseguem sincronizar eventos sem serviços de hora na nuvem?
Uma explicação baseada primeiro no mecanismo do tempo da câmara sem cloud, as suas contrapartidas na partilha de recursos, três perguntas frequentes sobre a...
Um serviço de IA local consegue detetar camadas de modelos corrompidas antes da inferência?
Uma explicação baseada primeiro no mecanismo da deteção de corrupção na camada do modelo, dos seus compromissos em termos de recursos partilhados, de três...
É possível restaurar um sistema RAG sem regenerar todos os embeddings?
Uma explicação, centrada no mecanismo, do restauro de RAG sem re-embedding, das suas contrapartidas em recursos partilhados, de três perguntas frequentes sobre a expansão...
