Event sourcing zachowuje ścieżkę audytową agenta AI, rejestrując każdą zaakceptowaną decyzję i zmianę stanu jako uporządkowane zdarzenie zamiast nadpisywania jednego zmiennego bieżącego stanu.
Na serwerze domowym sprawia to, że wieloetapową automatyzację można odtworzyć: operator może prześledzić propozycję, zatwierdzenie, wywołanie narzędzia, błąd, ponowienie, kompensację i stan końcowy po zakończeniu przepływu pracy.
Event sourcing przechowuje zmiany stanu jako główny zapis
Event sourcing rejestruje każdą zaakceptowaną zmianę stanu jako zdarzenie, zamiast traktować najnowszy zmienny rekord jako jedyne źródło prawdy. Bieżący stan jest wyprowadzany z uporządkowanej historii.
Martin Fowler definiuje event sourcing jako przechowywanie każdej zmiany stanu aplikacji w postaci sekwencji zdarzeń. Historia zachowuje informację o tym, jak system osiągnął dany stan. Martin Fowler opisuje event sourcing jako przechowywanie zmian stanu w postaci sekwencji zdarzeń, co oddaje ideę głównego zapisu wykorzystaną w artykule Martina Fowlera o event sourcing.
W przypadku domowego agenta AI zdarzenia ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed i CompensationCompleted mogą pozostać oddzielnymi faktami, zamiast zostać scalone w jedno pole statusu.
Każda decyzja agenta staje się faktem uporządkowanym w czasie
Zdarzenie powinno opisywać coś, co już się wydarzyło, i zawierać wystarczający kontekst, aby można je było później zinterpretować: identyfikator przepływu pracy, narzędzie, skrót parametrów, wynik oceny zasad oraz rezultat decyzji i znaczniki czasu, jeśli są potrzebne.
Fowler zauważa, że w event sourcingu magazyn zdarzeń staje się głównym źródłem prawdy, a stan można odbudować przez odtwarzanie. Ta uporządkowana sekwencja tworzy przyczynową ścieżkę audytową. Microsoft Azure opisuje dołączany tylko na końcu magazyn zdarzeń, w którym zdarzenia reprezentują zmiany stanu aplikacji, wspierając fakty dotyczące decyzji uporządkowane w czasie w artykule Azure Event Sourcing pattern.
Przydatnym obiektem audytowym jest obserwowalny artefakt decyzji, a nie prywatne, ukryte rozumowanie: jaka czynność została zaproponowana, jakie zasady ją oceniły, jaki zwrócono wynik i jaki efekt uboczny faktycznie wystąpił.
Projekcje przekształcają dziennik zdarzeń w bieżące widoki
Odtwarzanie całej historii przy każdym ekranie lub żądaniu agenta byłoby nieefektywne.
Systemy korzystające z event sourcingu tworzą projekcje, takie jak bieżący stan przepływu pracy, oczekujące zatwierdzenia czy ostatnie błędy.
Event sourcing umożliwia odtworzenie bieżącego stanu aplikacji na podstawie zarejestrowanych zdarzeń. Projekcję można więc odbudować, jeśli zmieni się jej logika lub baza danych. Wytyczne AWS opisują wyprowadzanie bieżącego stanu z utrwalonych zdarzeń, pokazując, jak projekcje mogą tworzyć widoki do odczytu bez zastępowania podstawowej historii w wytycznych AWS dotyczących event sourcingu.
Na małym serwerze migawki mogą skrócić czas odtwarzania, podczas gdy zdarzenia pozostają źródłem nadrzędnym. Migawka jest skrótem poprawiającym wydajność; sekwencja zdarzeń stanowi historię.
Identyfikatory korelacji łączą wieloetapową pracę w jedną historię decyzji
Jedno żądanie może uruchomić pobieranie danych, planowanie, zatwierdzenie, kilka wywołań narzędzi, ponowienia i kompensację.
Identyfikator korelacji grupuje te zdarzenia w jedną spójną operację.
Różni się to od zwykłego przechowywania logów w innym miejscu. Artykuł ZimaSpace o zewnętrznej izolacji logów audytowych wyjaśnia, jak zachować dowody mimo przejęcia aplikacji; event sourcing wyjaśnia, jak sam stan przepływu pracy staje się uporządkowaną historią. Kurrent podkreśla uporządkowane strumienie zdarzeń i identyfikatory, co umożliwia korelowanie powiązanych kroków w jedną możliwą do prześledzenia historię decyzji w koncepcjach event sourcingu Kurrent.
Oba podejścia można połączyć: rekordy zdarzeń napędzają odtwarzanie operacyjne, a kopie zorientowane na dopisywanie są eksportowane do oddzielnej granicy logowania w celu lepszego zachowania dowodów.
Korekty są dopisywane jako nowe zdarzenia zamiast przepisywania historii
Jeśli później okaże się, że decyzja agenta była błędna, projekt oparty na event sourcingu rejestruje zdarzenie kompensujące lub korygujące, zamiast usuwać pierwotne zdarzenie z historii.
Omówienie bitemporalności autorstwa Fowlera ilustruje szerszą ideę, zgodnie z którą historia zapisów może pozostać przeznaczona wyłącznie do dopisywania, nawet gdy późniejsza wiedza koryguje wcześniejsze założenia. Marten zachowuje zdarzenia jako historię, do której można tylko dopisywać, i odbudowuje na ich podstawie stan agregatu, pokazując, dlaczego korekty można dopisywać zamiast po cichu przepisywać wcześniejsze fakty w dokumentacji magazynu zdarzeń Marten.
Jest to przydatne, gdy zmieniają się zasady lub prompty. Operator może zobaczyć, że czynność została zaakceptowana na podstawie jednej wersji zasad, a następnie odwrócona, zamiast widzieć wyłącznie naprawiony stan końcowy.
Event sourcing nie sprawia automatycznie, że dowody są odporne na manipulacje
Wiarygodność historii zdarzeń zależy od mechanizmów kontroli procesu tworzenia zdarzeń, przechowywania, dostępu, zegarów i usuwania.
Proces, który może przepisywać magazyn, nadal może zniszczyć własną historię.
Fowler podkreśla korzyści audytowe i możliwości wykonywania zapytań historycznych, gdy dziennik zdarzeń pozostaje nadrzędnym magazynem informacji. Trwałość i kontrola dopisywania pozostają odrębnymi kwestiami operacyjnymi. Nowsze badania stosują uporządkowane historie zdarzeń przeznaczone wyłącznie do dopisywania do aktywności autonomicznych agentów, jednocześnie wyraźnie wskazując, że logika aplikacji oparta na dopisywaniu nie jest tym samym co odporne na manipulacje przechowywanie danych; zobacz event sourcing dla autonomicznych agentów.
Projektowanie agentów zgodnie z zasadą „najpierw tylko do odczytu” firmy ZimaSpace ogranicza ryzykowne działania, zanim do nich dojdzie; event sourcing zachowuje decyzje i działania, które faktycznie miały miejsce.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Czy kamery domowe mogą synchronizować zdarzenia bez korzystania z chmurowych usług czasu?
Wyjaśnienie działania czasu kamery bez chmury, jego kompromisów związanych ze współdzielonymi zasobami, trzy często zadawane pytania dotyczące rozsyłania zapytań oraz praktyczny protokół weryfikacji.

Czy lokalna usługa AI może wykryć uszkodzone warstwy modelu przed wnioskowaniem?
Wyjaśnienie wykrywania uszkodzeń warstwy modelu oparte na mechanizmach, kompromisy związane ze współdzielonymi zasobami, trzy najczęściej zadawane pytania dotyczące rozgałęziania zapytań oraz praktyczny protokół weryfikacji.

Czy system RAG można przywrócić bez ponownego generowania wszystkich wektorów embeddingowych?
Wyjaśnienie działania mechanizmu przywracania RAG bez ponownego tworzenia osadzeń, kompromisy związane ze współdzielonymi zasobami, trzy często zadawane pytania dotyczące rozsyłania zapytań oraz praktyczny protokół...

