Databricks pokazuje, jak tworzyć trwałych agentów z Temporal i Lakebase, ale demo ujawnia najtrudniejszą część

Databricks opublikował 8 września implementację referencyjną pokazującą, jak tworzyć trwałych agentów z Temporal i Lakebase mimo awarii workerów, ponownych prób i wielodniowych weryfikacji. System stosuje tę architekturę do oceny wniosków o pożyczki osobiste, gdzie utrata jednego zakończonego sprawdzenia może zakłócić ślad decyzyjny.

Istotną zmianą nie jest kolejny framework agentowy ani większy model. Databricks i Temporal podzieliły stan agenta między dwa systemy o różnych odpowiedzialnościach. Temporal zachowuje przepływ sterowania, podczas gdy Lakebase udostępnia dane operacyjne, które mogą odpytywać aplikacje, recenzenci i analitycy.

Ten podział tworzy również główne napięcie. Trwałe wykonywanie może odzyskać zarejestrowaną pracę, ale nie może zagwarantować, że każdy efekt zewnętrzny wystąpi dokładnie raz. Aplikacja nadal potrzebuje stabilnych identyfikatorów, zabezpieczonych zapisów do bazy danych, zasad wersjonowania polityk i uzgadniania danych, gdy komponenty się nie zgadzają.

Databricks przekształca trwałość agentów w system możliwy do testowania

Implementacja referencyjna traktuje agenta jako długotrwały proces biznesowy, a nie tymczasową sesję czatu.

Implementacja referencyjna śledzi wniosek pożyczkowy od zebrania dowodów do decyzji człowieka. Jej agent wykonuje kontrole dotyczące zdolności kredytowej, dochodów, wskaźnika zadłużenia do dochodów oraz polityki underwritingowej jako odrębne operacje.

Przykład wykorzystuje symulowanych wnioskodawców i dostawców danych, więc nie przetwarza rzeczywistych wniosków pożyczkowych. Ten wybór pozwala skupić eksperyment na zachowaniu podczas wykonywania, a nie na skuteczności modelu kredytowego.

Jeden przykładowy wnioskodawca ma ocenę kredytową 665 oraz jedną niematerialną flagę zaległości. Agent zbiera dowody, ocenia progi polityki specyficzne dla celu pożyczki i generuje rekomendację. Nie może podjąć ostatecznej decyzji kredytowej.

Underwriter musi zatwierdzić, odrzucić wniosek lub poprosić o więcej informacji. Ta ostatnia opcja rozszerza tę samą sprawę o kolejną turę agenta, zachowując wcześniejsze dowody i uzasadnienie recenzenta.

Scenariusz jest celowo trudniejszy niż pojedyncze zapytanie do modelu. Worker może zatrzymać się po zakończeniu kilku kontroli. Zapis do bazy danych może zostać zatwierdzony, zanim informacja o jego ukończeniu dotrze do Temporal. Recenzent może pozostawić sprawę otwartą przez kilka dni.

Nieaktualna przeglądarka może również wysłać przestarzałe polecenie po tym, jak sprawa posunęła się dalej. Tymczasem polityka underwritingowa może zmienić się bez odpowiadającego jej wdrożenia aplikacji.

Sytuacje te rodzą sześć praktycznych wymagań: odzyskiwanie, kontrolowane ponawianie prób, trwałe oczekiwanie, widoczność operacyjną, zarządzanie w czasie działania i historię audytu. Sam zapis rozmowy nie może ich spełnić.

Zapis rozmowy rejestruje wiadomości, lecz niekoniecznie pełny przepływ sterowania. Nie pokazuje automatycznie, która operacja się zakończyła, który wynik został zaakceptowany ani które polecenie posunęło proces naprzód.

Implementacja przypisuje więc każdemu uruchomieniu obsługi pożyczki Workflow Temporal. Workflow to trwały przepływ sterowania, którego zarejestrowana historia pozwala innemu workerowi odtworzyć jego stan.

Wywołania modeli, baz danych i narzędzi underwritingowych działają jako Activities. Activity to operacja z możliwością ponawiania prób, której wynik można zarejestrować w historii zdarzeń Workflow.

Odpowiedzi recenzentów docierają jako Signals, czyli asynchroniczne polecenia dostarczane do otwartego Workflow. Temporal może utrzymywać to oczekiwanie bez rezerwowania procesu workera na kilka dni.

React i FastAPI obsługują aplikację skierowaną do użytkownika. Uruchamiają procesy, wyświetlają dowody, listują sprawy i przesyłają decyzje z weryfikacji. Temporal Cloud przechowuje historię wykonywania i rozdziela zadania workerom.

Lakebase Postgres przechowuje projekcję skierowaną do aplikacji. Projekcja to odpytywalna reprezentacja bieżącego stanu workflow, budowana na podstawie aktualizacji tworzonych podczas wykonywania.

Unity Catalog pozostaje źródłem reguł underwritingowych. Tabela synchronizowana w sposób ciągły udostępnia te reguły przez Lakebase, dzięki czemu workery mogą odczytywać zaktualizowaną politykę bez wdrażania kodu.

Ta architektura sprawia, że zachowanie agenta w razie awarii jest widoczne i możliwe do odtworzenia. Przekształca trwałość z ogólnej obietnicy w zestaw konkretnych kontraktów odzyskiwania i spójności.

Demo nie scala jednak tych kontraktów w jednej bazie danych. Temporal i Lakebase pozostają odrębnymi systemami, a luka między nimi napędza trudniejsze pytania inżynieryjne.

Pamięć agenta nie jest stanem wykonywania

Trwały agent potrzebuje zarejestrowanych decyzji dotyczących przepływu sterowania, a nie tylko zapisanych wiadomości lub odzyskanych wspomnień.

Wiele systemów agentowych opisuje trwałość jako pamięć. Zapisują rozmowę, odzyskują wcześniejsze dokumenty lub umieszczają wynik pośredni w bazie danych. Te możliwości pomagają modelom odzyskać kontekst, ale nie odtwarzają wykonywania.

Załóżmy, że worker kończy kontrolę kredytową, a następnie kończy działanie. Zastępujący go worker musi ustalić, czy wynik został zarejestrowany, czy kolejna próba jest bezpieczna i która operacja powinna uruchomić się jako następna.

To problem przepływu sterowania. Obejmuje zaplanowane Activities, zakończone wyniki, timery, zaakceptowane polecenia człowieka, próby ponowienia i bieżącą rundę weryfikacji.

Temporal przechowuje te informacje w uporządkowanej historii zdarzeń. Podczas odtwarzania kod workflow konsumuje zarejestrowane zdarzenia i odbudowuje zmienne, takie jak dowody, wykorzystanie tokenów i stan weryfikacji.

Zarejestrowany wynik Activity jest zwracany podczas odtwarzania zamiast wykonywania go ponownie. Dlatego zakończona kontrola kredytowa lub zarejestrowana odpowiedź modelu pozostaje stała dla danego wykonania workflow.

Niezarejestrowane zakończenie stanowi inny przypadek. Dostawca modelu może zakończyć przetwarzanie żądania tuż przed utratą łączności przez workera. Jeśli Temporal nigdy nie otrzyma wyniku, może zaplanować kolejną próbę.

To ograniczenie ma znaczenie, ponieważ wywołania modeli nie są ani wolne od skutków ubocznych, ani gwarantowanie deterministyczne. Druga odpowiedź może różnić się od pierwszej nawet przy identycznych danych wejściowych.

Demonstracja przypisuje polityki ponawiania prób do poszczególnych typów operacji. Activities modeli dopuszczają maksymalnie cztery próby w trzyminutowym oknie schedule-to-close.

Activities narzędzi dopuszczają maksymalnie trzy próby z 60-sekundowym limitem start-to-close. Activities Lakebase dopuszczają maksymalnie pięć prób z 15-sekundowym limitem start-to-close.

Wartości te opisują konfigurację przykładu, a nie uniwersalne ustawienia domyślne dla środowisk produkcyjnych. Zespoły muszą ustalać limity ponawiania prób zgodnie z zachowaniem dostawcy, celami opóźnień, trybami awarii i konsekwencjami dla systemów podrzędnych.

Model trwałego wykonywania Temporal rozwiązuje problem odzyskiwania procesu, zachowując historię potrzebną do odtworzenia. Nie sprawia automatycznie, że płatność, e-mail, mutacja bazy danych lub żądanie do modelu są bezpieczne do powtórzenia.

Każda operacja zewnętrzna potrzebuje kontraktu idempotencji. Idempotencja oznacza, że powtarzane próby zbiegają się do jednego zamierzonego wyniku zamiast tworzyć zduplikowane efekty.

Demo pożyczkowe buduje ten kontrakt za pomocą deterministycznych identyfikatorów. Uruchomienie, wiadomość, wywołanie narzędzia, zdarzenie, runda weryfikacji i decyzja recenzenta otrzymują własną stabilną tożsamość.

Klucze podstawowe Postgres i ograniczenia unikalności uniemożliwiają ponownym próbom tworzenie nieograniczonej liczby kopii. Upserty pozwalają powtarzanej próbie wskazywać ten sam logiczny wiersz.

Zabezpieczone aktualizacje dodają kolejną warstwę. Dopuszczają wyłącznie prawidłowe przejścia stanu, takie jak przeniesienie oczekującego wywołania narzędzia do stanu ukończenia bez ponownego otwierania zamkniętego rekordu.

Nawet zabezpieczona aktualizacja wymaga jednak uważnej interpretacji. PostgreSQL może zmodyfikować zero wierszy bez zgłoszenia błędu, gdy cel osiągnął już stan końcowy.

Artykuł Databricks przyznaje, że obecny wrapper Activity nie zawsze zamienia wynik zero wierszy w błąd. Kod produkcyjny powinien sprawdzić zapisany stan, zanim uzna taki rezultat za nieszkodliwy.

Ten szczegół odróżnia użyteczną referencję inżynieryjną od ukończonego wzorca produkcyjnego. Trwała orkiestracja zapewnia mechanizm odzyskiwania, podczas gdy twórcy aplikacji nadal definiują bezpieczną semantykę biznesową.

Ta sama zasada obowiązuje poza underwritingiem. Dostawcy płatności potrzebują kluczy idempotencji, systemy e-mailowe potrzebują stabilnych identyfikatorów wiadomości, a niewspierane narzędzia potrzebują rekordów uzgadniających.

Zespoły budujące wewnętrznego agenta potrzebują również warstwy dowodowej z możliwością wyszukiwania. Ustrukturyzowana baza wiedzy inżynieryjnej może pomóc ludziom analizować dokumentację, decyzje i kontekst techniczny wokół tych workflow.

Szersza lekcja jest precyzyjna: pamięć pomaga modelowi pamiętać, a trwałe wykonywanie pomaga systemowi kontynuować działanie. Agenci produkcyjni zwykle potrzebują obu, ale nie są one wymienne.

Twórz trwałych agentów z Temporal i Lakebase, rozdzielając odpowiedzialności

Projekt działa, ponieważ Temporal i Lakebase przechowują różne rodzaje prawdy dla różnych odbiorców.

Temporal odpowiada za prawdę o wykonaniu. Jego historia określa, które zadania się zakończyły, które timery zostały uruchomione, które Signals dotarły i co worker odtwarzający stan powinien zrobić dalej.

Lakebase odpowiada za bieżący widok aplikacji. Przechowuje w tabelach relacyjnych status uruchomienia, wiadomości, dowody narzędziowe, rekordy weryfikacji, zdarzenia operacyjne, metadane rekomendacji i metryki ponawiania prób.

Ten podział pozwala interfejsowi użytkownika odpytywać bieżące sprawy przy użyciu zwykłych wzorców SQL. Recenzenci mogą znajdować oczekujące sprawy, analizować jedną rekomendację lub porównywać pomiary operacyjne między wykonaniami.

Dowody pojawiają się przed zamknięciem Workflow. Po zakończeniu wyszukiwania polityki ustrukturyzowany wynik staje się dostępny wraz z progami, rzeczywistymi wartościami, wynikami reguł, uzasadnieniem i źródłem polityki.

Ma to znaczenie w systemach z weryfikacją przez człowieka. Recenzent nie powinien czekać na zakończenie całego procesu, aby zobaczyć dowody stojące za rekomendacją.

Aplikacja korzysta z dwóch schematów Lakebase. Schemat agent_ops przechowuje rekordy operacyjne, natomiast agent_policy zawiera kopię zarządzanej polityki underwritingowej tylko do odczytu.

Każde Activity zapisuje wiersze przy użyciu identyfikatorów dopasowanych do Workflow. Ponowna próba może więc zaktualizować ten sam logiczny rekord, gdy projekcja bazy danych nadrabia zaległości.

Lakebase nie staje się częścią odtwarzania Temporal. Ta granica uniemożliwia zwykłym zapytaniom aplikacyjnym decydowanie o wykonaniu workflow, ale oznacza też, że aktualizacje nie są atomowe w obu systemach.

Zdarzenie Temporal może zostać zarejestrowane, podczas gdy projekcja Lakebase pozostaje tymczasowo w tyle. Zapis do bazy danych może również zostać zatwierdzony, zanim Temporal zarejestruje odpowiadające mu ukończenie Activity.

Architektura akceptuje tę lukę i wykorzystuje spójność ostateczną. Spójność ostateczna oznacza, że odrębne widoki mogą przez krótki czas się różnić, lecz zbliżają się do siebie dzięki ponawianiu prób i deterministycznym zapisom.

To rozsądny projekt dla pulpitów i list spraw. Wymaga większej ostrożności, gdy widok bazy danych jest wykorzystywany do walidacji polecenia wpływającego na stan biznesowy.

Lakebase zapewnia znany dostęp Postgres i indeksowanie ukierunkowane na aplikacje. Jego model operacyjnej bazy danych obsługuje również pamięć agenta, bieżący stan i obciążenia związane z udostępnianiem funkcji.

Jego zasoby obliczeniowe mogą automatycznie skalować się w skonfigurowanych limitach. Scale-to-zero może zawiesić bezczynne zasoby, choć pierwsze zapytanie po okresie nieaktywności może doświadczyć opóźnienia aktywacji.

Te funkcje bazodanowe pomagają przy nierównomiernym ruchu agentów. Nie eliminują potrzeby planowania pojemności, limitów połączeń, konfiguracji puli ani testów odzyskiwania.

Ścieżka polityk jest równie ważna. Unity Catalog przechowuje progi specyficzne dla danego celu, w tym reguły dotyczące kredytu i wskaźnika zadłużenia do dochodu. Ciągle synchronizowana tabela udostępnia te wartości w Lakebase.

Właściciele polityk mogą aktualizować źródło bez ponownego wdrażania workera ani API. Późniejsze wyszukiwanie może odczytać rozpropagowane reguły z Postgres.

Pozwala to uniknąć osadzania każdego progu biznesowego w kodzie aplikacji. Wprowadza jednak również kwestię czasu obowiązywania polityki, na którą warstwa orkiestracji musi odpowiedzieć wprost.

Czy otwarta sprawa powinna zachować reguły zastosowane na początku, czy przyjąć nowszą politykę podczas późniejszej tury? Oba wybory mają konsekwencje dla spójności, audytowalności i traktowania klientów.

Demonstracja zapisuje zastosowane progi oraz źródło wraz z rekomendacją. Te dowody pozwalają osobom dokonującym przeglądu odtworzyć, która polityka wpłynęła na konkretny wynik.

Gdy Lakebase jest niedostępne, przykład może użyć polityki testowej i odnotować tę ścieżkę awaryjną. Artykuł słusznie zauważa, że regulowany proces mógłby zamiast tego bezpiecznie zakończyć działanie błędem.

Tej decyzji nie można przekazać bibliotece ponawiania prób. Właściciele produktu, zespoły ds. zgodności i inżynierowie muszą określić, czy nieaktualna lub awaryjna polityka jest dopuszczalna prawnie i operacyjnie.

Proponowana ścieżka zwrotna wykorzystuje Lakebase Change Data Feed. Po włączeniu może ona przechwytywać zmiany w bazie danych i publikować je w tabelach historii Delta zarządzanych przez Unity Catalog.

Databricks podaje, że kanał grupuje zmiany mniej więcej co 15 sekund. Taki interwał nadaje się do retrospektywnego audytu i analiz, podczas gdy aplikacja odczytuje bieżący stan bezpośrednio z Lakebase.

Repozytorium przygotowuje jednak jedynie schematy dla tej ścieżki. Nie zawiera zaobserwowanego, kompleksowego uruchomienia kanału w docelowym środowisku.

Budowanie trwałych agentów z Temporal i Lakebase wymaga zatem trzech wyraźnych granic: prawdy wykonawczej, prawdy operacyjnej oraz zarządzanej historii analitycznej.

Wzorzec staje się wartościowy, gdy te granice są jawne. Staje się niebezpieczny, gdy zespoły zakładają, że słowo „trwały” oznacza, iż każdy komponent zawsze pozostaje zgodny z pozostałymi.

Weryfikacja przez człowieka ujawnia kompromis dotyczący spójności

Oczekiwanie na decyzję analityka kredytowego pokazuje, dlaczego trwałość musi obejmować tożsamość polecenia, odrzucanie nieaktualnego stanu oraz niezależną walidację Workflow.

Po wygenerowaniu rekomendacji przez model Workflow tworzy identyfikator weryfikacji na podstawie uruchomienia i bieżącej tury. Zapisuje oczekującą weryfikację w Lakebase i przechodzi do stanu AWAITING_REVIEW.

Temporal następnie oczekuje na warunek bez zajmowania workera. Otwarte Workflow może przetrwać wymianę procesu, gdy człowiek poświęca czas na odpowiedź.

API przyjmuje zatwierdzenie, odrzucenie albo prośbę o dodatkowe informacje. Najpierw sprawdza, czy Lakebase nadal pokazuje odpowiednią weryfikację jako oczekującą.

Porównuje też przesłany identyfikator weryfikacji z bieżącą rundą weryfikacji. Niezgodność powoduje konflikt zamiast przekazania oczywiście nieaktualnej decyzji.

Ta wstępna kontrola bazy danych poprawia doświadczenie użytkownika, ale nie jest autorytatywna. Projekcja Lakebase może pozostawać w tyle za Temporal, zwłaszcza gdy Activity ponawia próby.

Dlatego API wysyła polecenie jako Signal, a Workflow ponownie waliduje je względem stanu wykonania. Zduplikowane lub nieaktualne decyzje są ignorowane w trwałym przepływie sterowania.

Ta druga kontrola jest niezbędna. Karta przeglądarki może pozostać otwarta, podczas gdy inny recenzent posunie sprawę naprzód, albo wcześniejsze żądanie może dotrzeć po rozpoczęciu nowej rundy weryfikacji.

Odpowiedź HTTP 202 potwierdza jedynie, że Temporal otrzymał Signal. Nie oznacza, że Workflow zaakceptował decyzję biznesową.

Klient musi odświeżyć widok Lakebase, aby zobaczyć wynikowy stan. To rozróżnienie zapobiega pomyleniu potwierdzenia transportowego z zatwierdzeniem kredytu.

Gdy Workflow zaakceptuje decyzję, idempotentne Lakebase Activity ją utrwala. Zatwierdzenie lub odrzucenie kończy uruchomienie.

Prośba o dodatkowe informacje wznawia wykonanie. Uzasadnienie recenzenta staje się nową wiadomością użytkownika, tura przechodzi dalej, a kolejna rekomendacja otrzymuje nowy identyfikator weryfikacji.

Mechanizm ten daje każdej rundzie weryfikacji stabilną granicę. Uwidacznia też główny kompromis: responsywny stan aplikacji jest oddzielony od autorytatywnego stanu wykonania.

Zespoły muszą projektować z myślą o tymczasowej rozbieżności. Interfejsy powinny jasno komunikować oczekujące polecenia, konflikty, opóźnione projekcje i odrzucone nieaktualne działania.

Panele operacyjne muszą również odróżniać zamierzone oczekiwanie od awarii. Sprawa oczekująca na analityka kredytowego jest w dobrym stanie, podczas gdy Activity utknięte w ponawianych próbach wymaga interwencji.

Demonstracja udostępnia metryki na poziomie Workflow, tury i próby Activity. Operatorzy mogą osobno sprawdzać historię Temporal, odpytywać stan Lakebase oraz weryfikować środowisko workera.

Ten podział pomaga zdiagnozować, czy opóźnienie wynika z weryfikacji przez człowieka, dostępności modelu, uwierzytelniania bazy danych czy nieudanego narzędzia.

Dodaje też obszarów wymagających obsługi operacyjnej. Zespoły muszą monitorować Temporal, Lakebase, wdrożenia workerów, pule połączeń, zadania synchronizacji oraz kontrakty, które je łączą.

Uwierzytelnianie wprowadza kolejny problem długotrwałego działania. Klient Lakebase używa OAuth w komunikacji machine-to-machine i odświeża pulę połączeń przed wygaśnięciem tymczasowych poświadczeń bazy danych.

Bez rotacji poświadczeń worker może zawodzić według przewidywalnego harmonogramu, nawet jeśli jego Workflow pozostaje możliwe do odzyskania. Trwały przepływ sterowania nie sprawia, że wygasłe połączenia stają się użyteczne.

Deweloperzy porównujący frameworki trwałych agentów powinni zatem wyjść poza obsługę punktów kontrolnych. Powinni pytać, jak identyfikowane są polecenia, jak deduplikowane są skutki uboczne i gdzie znajduje się autorytatywny stan.

Powinni też celowo testować nieaktualne interakcje. Należy otworzyć dwie sesje weryfikacji, przejść dalej w jednej z nich, a następnie przesłać starszą decyzję.

Prawidłowa implementacja powinna odrzucić lub bezpiecznie zignorować takie polecenie. Powinna zachować wystarczające dowody, aby później wyjaśnić wynik.

Przykład kredytowy jest użyteczny, ponieważ łączy te szczegóły z decyzją o istotnych konsekwencjach. Zatwierdzenie przez człowieka nie jest ozdobną pauzą między wywołaniami modelu.

Jest przejściem stanu z tożsamością, autoryzacją, kontekstem polityki i wymaganiami audytowymi. To czyni je bardziej wymagającym testem trwałości niż asystent konwersacyjny uruchamiany ponownie po błędzie.

Demonstracja nie dowodzi gotowości produkcyjnej

Databricks przedstawia wiarygodną architekturę, ale jego własne dowody pozostawiają nierozstrzygnięte kwestie zgodności kredytowej, skali i pełnej walidacji pętli danych.

Repozytorium zgłasza 21 przechodzących testów obejmujących sekwencjonowanie workflow, zachowanie weryfikacji, konstrukcję OAuth, idempotentne utrwalanie, kontrakty metryk, uruchamianie API i ustawienia workera.

Ćwiczenie odzyskiwania po awarii korzysta z deterministycznego dostawcy. Zatrzymuje wykonanie workera i weryfikuje, że zapisany postęp przetrwa po powrocie procesu.

Testy te wspierają wąskie twierdzenie dotyczące trwałości. Pokazują, że przepływ sterowania i kontrakty utrwalania w przykładzie działają zgodnie z założeniami w wybranych sytuacjach awaryjnych.

Nie walidują one agenta jako systemu kredytowego. Dane wnioskodawców i odpowiedzi dostawców są danymi testowymi, a domyślny skryptowy dostawca pozwala uniknąć zależności od działającego modelu.

Repozytorium nie potwierdza jakości modelu kredytowego, zgodności regulacyjnej, bezpieczeństwa produkcyjnego, dostępności regionalnej ani wydajności na dużą skalę. Databricks bezpośrednio wskazuje te ograniczenia.

Lokalne ćwiczenie awaryjne przeprowadzono również z wyłączonym Lakebase. Izoluje ono odzyskiwanie Temporal, lecz nie weryfikuje odzyskiwania w całej zintegrowanej ścieżce danych.

Podobnie ścieżka Change Data Feed pozostaje zadaniem związanym z włączeniem i wdrożeniem. Przykład przygotowuje tabele, ale nie pokazuje, że obserwowana historia dociera kompleksowo do celu.

Change Data Feed miał status Public Preview, gdy ukazał się artykuł. Status wersji zapoznawczej ma znaczenie dla zespołów wymagających dojrzałych zobowiązań wsparcia lub zweryfikowanego zasięgu regionalnego.

Baza danych i Workflow nie współdzielą transakcji. Stabilne identyfikatory i ponawianie prób zapewniają zbieżność, ale zespoły nadal potrzebują mechanizmów uzgadniania w przypadku przedłużającej się lub nieoczekiwanej rozbieżności.

Produkcyjny proces uzgadniania powinien znajdować Workflow bez odpowiadających im projekcji. Powinien też wykrywać zatwierdzone skutki w bazie danych, których wyniki Activity nigdy nie trafiły do Event History.

Synchronizacja polityk zasługuje na taką samą wnikliwość. Późniejsze uruchomienie może wykorzystać zaktualizowaną politykę bez wdrożenia, ale otwarte uruchomienie wymaga udokumentowanej reguły wersjonowania polityki.

Zachowanie awaryjne tworzy kolejne ryzyko. Demonstracja może zastąpić politykę testową, gdy Lakebase jest wyłączone albo wiersz polityki jest niedostępny.

Takie zachowanie pomaga w lokalnym rozwoju, lecz ciche użycie rozwiązania awaryjnego byłoby niedopuszczalne w wielu regulowanych środowiskach. System zapisuje użycie ścieżki awaryjnej, ale właściciele polityk muszą zdecydować, czy wykonanie powinno być kontynuowane.

Wydajność pozostaje nieprzetestowana w opublikowanych dowodach. Obciążenia agentowe mogą generować skokowe zapisy, długie historie, obszerne transkrypcje i nierównomierne kolejki weryfikacji.

Retencja historii Temporal, liczba ponawianych prób, opóźnienia modelu, współbieżność workerów, limity połączeń z bazą danych oraz aktualizacje projekcji wpływają na zachowanie systemu.

Autoskalowanie Lakebase może reagować na popyt, ale nowe połączenia i rozgrzane dane nadal mają znaczenie. Skalowanie do zera może także wymieniać wydajność w spoczynku na opóźnienie wybudzenia.

Wymagania bezpieczeństwa wykraczają poza TLS i tymczasowe poświadczenia. Rzeczywista platforma underwritingowa potrzebowałaby ścisłej autoryzacji, kontroli nad danymi wrażliwymi, zasad retencji i granic dostępu audytowego.

Rekomendacja modelu również wymaga niezależnego nadzoru. Rejestrowanie dowodów i polityki poprawia możliwość śledzenia, lecz nie potwierdza, że rekomendacja jest uczciwa ani trafna.

Kompletna ocena przetestowałaby uzasadnianie działań niekorzystnych dla klienta, brakujące dowody, sprzeczne dane dostawców, zmiany polityk oraz próby manipulowania danymi wejściowymi narzędzi.

Przetestowałaby również incydenty operacyjne przekraczające granice komponentów. Przykłady obejmują niedostępną synchronizację polityk, opóźnione projekcje, częściową rotację poświadczeń oraz niedostępnych zewnętrznych dostawców.

Architekturę należy zatem postrzegać jako ukształtowaną z myślą o produkcji, a nie jako certyfikowaną do produkcji. To rozróżnienie wzmacnia materiał referencyjny, ponieważ uwidacznia pozostałą pracę.

Databricks pokazał, jak przypisać odpowiedzialność między orkiestrację, magazyn operacyjny i zarządzane dane. Nie wyeliminował potrzeby walidowania każdego kontraktu przy rzeczywistym obciążeniu.

Trzy sygnały pokażą, czy ten wzorzec się sprawdzi

Kolejne dowody powinny przetestować zintegrowane odzyskiwanie, spójność polityk oraz wdrożenia wykraczające poza kontrolowaną demonstrację underwritingową.

Pierwszym sygnałem jest zaobserwowane, kompleksowe wdrożenie Change Data Feed. Opublikowany system przygotowuje tabele operacyjne, lecz pozostawia niedokończone aktywowanie kanału i weryfikację miejsca docelowego.

Udana walidacja powinna prześledzić jedno uruchomienie od dowodów z narzędzi, przez weryfikację przez człowieka, do historii zarządzanej przez Unity Catalog. Powinna również udokumentować opóźnienie, duplikaty, zmiany schematu i odzyskiwanie po przerwaniu działania.

Taki wynik wzmocniłby twierdzenie, że aktywność operacyjna może powrócić do zarządzanej historii analitycznej. Dalsze poleganie na niezweryfikowanej ścieżce osłabiłoby narrację o kompletnej pętli danych.

Drugim sygnałem jest publiczne badanie obciążenia i awarii wykorzystujące Lakebase w całym teście odzyskiwania. Powinno ono obejmować awarie workerów, ponawianie prób bazy danych, rotację poświadczeń i opóźnienie projekcji.

Przydatne wyniki opisałyby zachowanie przy kończeniu zadań, rozkład ponawianych prób, odrzucanie nieaktualnych poleceń oraz czas potrzebny do zbieżności stanu aplikacji.

Przetestowałoby to architekturę jako połączony system, zamiast walidować odzyskiwanie Temporal w izolacji. Ujawniłoby także miejsca, w których pojawiają się limity skalowania lub wąskie gardła operacyjne.

Trzecim sygnałem jest zastosowanie w rzeczywistym procesie z weryfikacją przez człowieka. Kredytowanie jest jedynie demonstracją, ale podobne wymagania występują w obsłudze roszczeń, zakupach, reagowaniu na incydenty bezpieczeństwa i regulowanych procesach zatwierdzania.

Wiarygodne wdrożenie powinno wyjaśniać, jak wersjonuje politykę, uzgadnia stan, kontroluje zachowanie awaryjne i audytuje interwencje człowieka. Te praktyki są ważniejsze niż konkretny dostawca modelu.

Dowody z takiego wdrożenia wsparłyby główną ocenę artykułu. Trwałe agenty to aplikacje rozproszone, których awarie muszą być modelowane w sposób jawny.

Wdrożenie, które sprowadza trwałość do punktów kontrolnych rozmowy, wskazywałoby na coś przeciwnego. Pozostawiałoby skutki uboczne, długie oczekiwania i zmieniającą się politykę poza kontraktem odzyskiwania.

Dla deweloperów najpilniejsze pytanie nie brzmi, czy każdy agent potrzebuje Temporal i Lakebase. Wiele krótkich zadań tylko do odczytu nie uzasadnia stosowania dwóch systemów zarządzanych i warstwy projekcji.

Pytanie brzmi, czy agent może przetrwać swojego workera, zmieniać stan zewnętrzny, czekać na ludzi lub stosować politykę zmieniającą się niezależnie. Te cechy tworzą potrzebę trwałego wykonywania.

Jeśli opisują one Twój system, przeanalizuj architekturę agenta, odtwórz jej testy awarii i podważ każdy efekt uboczny, który można ponowić. Następnie sprawdź, co dzieje się, gdy prawda wykonawcza i prawda operacyjna tymczasowo są ze sobą sprzeczne.

To praktyczny standard dla zespołów próbujących tworzyć trwałe agenty z Temporal i Lakebase. Zacznij od jednego istotnego przepływu pracy, określ uprawnienia każdego systemu i uczyń dowody odzyskiwania częścią przeglądu produktu.