Hur bevarar händelsebaserad loggning ett revisionsspår för AI-agenters beslut?
Event sourcing bevarar ett AI-agentspår genom att registrera varje godkänt beslut och varje tillståndsändring som en ordnad händelse i stället för att skriva över ett enda föränderligt aktuellt tillstånd.
På en hemserver gör det fler stegs automatisering möjlig att återskapa: en operatör kan följa förslaget, godkännandet, verktygsanropet, felet, försöket igen, kompensationen och det slutliga tillståndet efter att arbetsflödet har slutförts.
Event sourcing lagrar tillståndsändringar som den primära posten
Event sourcing registrerar varje godkänd tillståndsändring som en händelse i stället för att behandla den senaste föränderliga raden som den enda sanningskällan. Det aktuella tillståndet härleds från den ordnade historiken.
Martin Fowler definierar event sourcing som att lagra varje förändring av applikationens tillstånd som en sekvens av händelser. Historiken bevarar hur systemet nådde ett visst tillstånd. Martin Fowler beskriver event sourcing utifrån att tillståndsändringar lagras som en sekvens av händelser, vilket fångar idén om en primär post som används i Martin Fowlers artikel om event sourcing.
För en AI-agent i hemmet kan ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed och CompensationCompleted fortsätta vara separata fakta i stället för att slås ihop till ett enda statusfält.
Varje agentbeslut blir ett tidsordnat faktum
En händelse bör beskriva något som redan har hänt och innehålla tillräckligt med sammanhang för att kunna tolkas senare: arbetsflödes-ID, verktyg, parameterhash, policyresultat, beslutsutfall och tidsstämplar när det är lämpligt.
Fowler noterar att händelselagret blir den främsta sanningskällan med event sourcing och att tillståndet kan byggas om genom uppspelning. Den ordnade sekvensen skapar ett kausalt revisionsspår. Microsoft Azure beskriver ett händelselager som endast tillåter tillägg, där händelser representerar förändringar av applikationens tillstånd och stöder de tidsordnade beslutsfakta som beskrivs i Azures mönster för event sourcing.
Det användbara revisionsobjektet är den observerbara beslutsartefakten, inte privat dold slutledning: vilken åtgärd som föreslogs, vilken policy som utvärderade den, vilket resultat som returnerades och vilken bieffekt som faktiskt inträffade.
Projektioner omvandlar händelseloggen till aktuella vyer
Det skulle vara ineffektivt att spela upp hela historiken för varje vy eller agentförfrågan.
Eventbaserade system bygger projektioner, till exempel aktuellt arbetsflödestillstånd, väntande godkännanden eller senaste fel.
Event sourcing kan återskapa det aktuella applikationstillståndet från registrerade händelser. En projektion kan därför byggas om om dess logik eller databas ändras. AWS vägledning beskriver hur det aktuella tillståndet härleds från beständiga händelser och visar hur projektioner kan skapa läsvyer utan att ersätta den underliggande historiken i AWS vägledning om event sourcing.
På en liten server kan ögonblicksbilder förkorta uppspelningstiden medan händelserna förblir auktoritativa. Ögonblicksbilden är en genväg för bättre prestanda; händelsesekvensen är historiken.
Korrelations-ID:n kopplar ihop arbete i flera steg till en gemensam beslutshistorik
En begäran kan utlösa hämtning, planering, godkännande, flera verktygsanrop, nya försök och kompensation.
Ett korrelations-ID grupperar dessa händelser till en sammanhängande operation.
Det skiljer sig från att bara lagra loggar någon annanstans. ZimaSpaces isolering av externa revisionsloggar förklarar hur bevismaterial överlever en komprometterad app; event sourcing förklarar hur själva arbetsflödestillståndet blir en ordnad historik. Kurrent betonar ordnade händelseströmmar och identifierare, vilket stöder att relaterade steg kopplas samman till en spårbar beslutshistorik i Kurrents begrepp för event sourcing.
Båda kan kombineras: händelseposter driver operativ uppspelning medan kopior som endast tillåter tillägg exporteras till en separat loggningsgräns för bättre bevarande av bevismaterial.
Korrigeringar lägger till nya händelser i stället för att skriva om historiken
Om ett agentbeslut senare visar sig vara felaktigt registrerar en eventbaserad design en kompenserande eller korrigerande händelse i stället för att redigera bort den ursprungliga händelsen.
Fowlers diskussion om bitemporalitet illustrerar den bredare idén att posthistoriken kan förbli tilläggsbaserad även när senare kunskap korrigerar tidigare antaganden. Marten behåller händelser som en historik som endast tillåter tillägg och bygger om aggregattillståndet från dem, vilket illustrerar varför korrigeringar kan läggas till i stället för att tidigare fakta tyst skrivs om i Martens dokumentation om händelselager.
Detta är användbart när policyer eller promptar ändras. En operatör kan se att en åtgärd godkändes enligt en viss policyversion och senare återfördes, i stället för att bara se det korrigerade slutliga tillståndet.
Event sourcing gör inte automatiskt bevismaterial manipulationssäkert
En händelsehistorik är bara så tillförlitlig som kontrollerna kring hur händelser skapas, lagras och nås samt kring klockor och radering.
En process som tillåts skriva om lagret kan fortfarande förstöra sin egen historik.
Fowler framhäver fördelarna för revision och historiska sökningar när händelseloggen förblir det auktoritativa informationslagret. Beständighet och kontroller för tillägg är fortfarande separata operativa frågor. Ny forskning tillämpar strukturerade händelsehistoriker som endast tillåter tillägg på autonoma agenters aktiviteter, samtidigt som den tydliggör att applikationslogik som endast tillåter tillägg inte är samma sak som manipulationssäker lagring; se event sourcing för autonoma agenter.
ZimaSpaces agentdesign med skrivskydd som utgångspunkt minskar risken för farliga åtgärder innan de inträffar; event sourcing bevarar de beslut och åtgärder som faktiskt ägde rum.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Kan hemkameror synkronisera händelser utan molnbaserade tidstjänster?
En mekanismorienterad förklaring av kameratid utan moln, dess avvägningar kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
Kan en lokal AI-tjänst upptäcka skadade modellager före inferens?
En mekanismfokuserad förklaring av detektering av korruption i modellagret, dess avvägningar kring delade resurser, tre vanliga frågor om frågefan-out och ett praktiskt verifieringsprotokoll.
Kan ett RAG-system återställas utan att generera om alla embeddingar?
En mekanismförst förklaring av RAG-återställning utan ombäddning, dess avvägningar kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
