Wie bewahrt Event Sourcing einen Prüfpfad für Entscheidungen von KI-Agenten?

Event Sourcing bewahrt einen Prüfpfad für KI-Agenten, indem jede akzeptierte Entscheidung und Zustandsänderung als geordnetes Ereignis aufgezeichnet wird, anstatt einen veränderlichen aktuellen Zustand zu überschreiben.

Auf einem Heimserver macht das mehrstufige Automatisierung rekonstruierbar: Nach Abschluss des Workflows kann ein Betreiber den Vorschlag, die Genehmigung, den Tool-Aufruf, den Fehler, den Wiederholungsversuch, die Kompensation und den endgültigen Zustand nachvollziehen.

Event Sourcing speichert Zustandsänderungen als primären Datensatz

Event Sourcing zeichnet jede akzeptierte Zustandsänderung als Ereignis auf, anstatt die zuletzt veränderliche Zeile als einzige Quelle der Wahrheit zu behandeln. Der aktuelle Zustand wird aus der geordneten Historie abgeleitet.

Martin Fowler definiert Event Sourcing als die Speicherung jeder Änderung am Anwendungszustand in Form einer Sequenz von Ereignissen. Die Historie bewahrt, wie das System zu einem Zustand gelangt ist. Martin Fowler beschreibt Event Sourcing als Speicherung von Zustandsänderungen in einer Ereignissequenz, wodurch die Idee des primären Datensatzes erfasst wird, die in Martin Fowler zu Event Sourcing verwendet wird.

Bei einem KI-Agenten für zu Hause können ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed und CompensationCompleted als separate Fakten erhalten bleiben, anstatt zu einem einzigen Statusfeld zusammengefasst zu werden.

Jede Agentenentscheidung wird zu einem zeitlich geordneten Fakt

Ein Ereignis sollte etwas beschreiben, das bereits geschehen ist, und genügend Kontext enthalten, um es später zu interpretieren: Workflow-ID, Tool, Parameter-Hash, Richtlinienergebnis, Entscheidungsergebnis und gegebenenfalls Zeitstempel.

Fowler weist darauf hin, dass bei Event Sourcing der Ereignisspeicher zur maßgeblichen Quelle der Wahrheit wird und der Zustand durch Wiedergabe rekonstruiert werden kann. Diese geordnete Sequenz erzeugt einen kausalen Prüfpfad. Microsoft Azure beschreibt einen nur anhängbaren Ereignisspeicher, in dem Ereignisse Änderungen am Anwendungszustand darstellen und dadurch die zeitlich geordneten Entscheidungsfakten in Azure Event Sourcing pattern unterstützen.

Das nützliche Prüfobjekt ist das beobachtbare Entscheidungsartefakt, nicht eine private verborgene Begründung: Welche Aktion wurde vorgeschlagen, welche Richtlinie hat sie bewertet, welches Ergebnis wurde zurückgegeben und welcher Nebeneffekt ist tatsächlich eingetreten?

Projektionen verwandeln das Ereignisprotokoll in aktuelle Ansichten

Die gesamte Historie für jede Anzeige oder jede Agentenanfrage wiederzugeben, wäre ineffizient.

Event-basierte Systeme erstellen Projektionen wie den aktuellen Workflow-Zustand, ausstehende Genehmigungen oder kürzlich aufgetretene Fehler.

Event Sourcing kann den aktuellen Anwendungszustand aus aufgezeichneten Ereignissen rekonstruieren. Eine Projektion kann daher neu erstellt werden, wenn sich ihre Logik oder Datenbank ändert. Die AWS-Dokumentation beschreibt die Ableitung des aktuellen Zustands aus dauerhaft gespeicherten Ereignissen und veranschaulicht, wie Projektionen Leseansichten erstellen können, ohne die zugrunde liegende Historie in AWS-Leitfaden zu Event Sourcing zu ersetzen.

Auf einem kleinen Server können Snapshots die Wiedergabezeit verkürzen, während die Ereignisse maßgeblich bleiben. Der Snapshot ist eine Leistungsoptimierung; die Ereignissequenz ist die Historie.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Korrelations-IDs verbinden mehrstufige Abläufe zu einer einzigen Entscheidungshistorie

Eine Anfrage kann Abrufe, Planung, Genehmigung, mehrere Tool-Aufrufe, Wiederholungsversuche und Kompensation auslösen.

Eine Korrelations-ID gruppiert diese Ereignisse zu einer zusammenhängenden Operation.

Das unterscheidet sich davon, Protokolle einfach an anderer Stelle zu speichern. Die Isolation externer Prüfprotokolle von ZimaSpace erklärt, wie Belege einen Angriff auf die App überstehen; Event Sourcing erklärt, wie der Workflow-Zustand selbst zu einer geordneten Historie wird. Kurrent betont geordnete Ereignisströme und Bezeichner, wodurch sich zusammengehörige Schritte zu einer einzigen nachvollziehbaren Entscheidungshistorie in Kurrents Konzepten zu Event Sourcing korrelieren lassen.

Beides kann kombiniert werden: Ereignisdatensätze steuern die operative Wiedergabe, während anhängeorientierte Kopien für eine stärkere Beweissicherung an eine separate Protokollierungsgrenze exportiert werden.

Korrekturen fügen neue Ereignisse an, statt die Historie umzuschreiben

Wenn sich später herausstellt, dass eine Agentenentscheidung falsch war, zeichnet ein Event-Sourcing-Design ein kompensierendes oder korrigierendes Ereignis auf, anstatt das ursprüngliche Ereignis aus der Existenz zu löschen.

Fowlers Diskussion zur bitemporalen Modellierung veranschaulicht die weiter gefasste Idee, dass die Datensatzhistorie nur anhängbar bleiben kann, selbst wenn spätere Erkenntnisse frühere Annahmen korrigieren. Marten bewahrt Ereignisse als nur anhängbare Historie und erstellt den Aggregatzustand daraus neu. Das veranschaulicht, warum Korrekturen angehängt werden können, anstatt frühere Fakten stillschweigend in der Dokumentation des Marten-Ereignisspeichers umzuschreiben.

Das ist nützlich, wenn sich Richtlinien oder Prompts ändern. Ein Betreiber kann sehen, dass eine Aktion unter einer bestimmten Richtlinienversion akzeptiert und später rückgängig gemacht wurde, statt nur den reparierten Endzustand zu sehen.

Event Sourcing macht Belege nicht automatisch manipulationssicher

Wie vertrauenswürdig eine Ereignishistorie ist, hängt von den Kontrollen rund um Ereigniserstellung, Speicherung, Zugriff, Zeitmessung und Löschung ab.

Ein Prozess, der den Speicher umschreiben darf, kann seine eigene Historie weiterhin zerstören.

Fowler hebt die Vorteile für Prüfungen und historische Abfragen hervor, wenn das Ereignisprotokoll als maßgeblicher Informationsspeicher erhalten bleibt. Dauerhaftigkeit und Kontrollen für das Anhängen bleiben separate betriebliche Aufgaben. Aktuelle Forschung wendet strukturierte, nur anhängbare Ereignishistorien auf Aktivitäten autonomer Agenten an, macht aber zugleich deutlich, dass eine nur anhängbare Anwendungslogik nicht dasselbe ist wie manipulationssicherer Speicher; siehe Event Sourcing für autonome Agenten.

Das Read-only-first-Agentendesign von ZimaSpace reduziert gefährliche Aktionen, bevor sie stattfinden; Event Sourcing bewahrt die Entscheidungen und Aktionen, die tatsächlich stattgefunden haben.