Projektowanie agentów AI otoczeniowych: lejki przebudzenia, tani tryb snu oraz bezpieczne przebudzanie.

Większość tekstów na temat agentów AI rozpoczyna się od chwili, gdy przychodzi żądanie i zaczyna się pętla. Agent otoczeniowy, który sam obserwuje skrzynki odbiorcze, kolejki i tablice kontrolne, spędza niemal cały swój czas w przeciwnym stanie: nic się nie dzieje, a system musi raz po raz decydować, czy coś właśnie się zaczęło. Ten przewodnik dotyczy właśnie tego czasu bezczynności. Pod koniec będziesz w stanie zaprojektować warstwę, która decyduje, kiedy agent się budzi, utrzymać koszt „snu” na poziomie bliskim zera, zapewnić bezpieczeństwo każdego przebudzenia przed duplikatami, przestarzałymi danymi i próbami iniekcji, a także ocenić, czy całe to rozwiązanie rzeczywiście pomaga ludziom, których przerywa.

Scenariusz ostrzegawczy: płacenie za każde „nie”

Załóżmy zespół, który tworzy agenta do monitorowania skrzynki pocztowej z zapytaniami klientów oraz kanału obsługi w trybie 24/7. Cel jest prosty: zaznaczyć wszystko, co wymaga interwencji człowieka, zanim ktokolwiek to zauważy. Prototyp sprawia wrażenie imponującego podczas demonstracji. Następnie przychodzi pierwsza miesięczna rachunek – jego wysokość przewyższa łączną cenę licencji IDE zespołu, minut użytych w procesach CI oraz narzędzi do monitorowania, mimo że agent wykonał zaledwie około jedenaście użytecznych działań w ciągu trzydziestu dni.

Powodem jest architektura, której nikt nie spisał. Aby „obserwować” skrzynkę odbiorczą, co dwie minuty uruchamiano zaplanowane zadanie, które zbierało najnowsze wiadomości i pytało model o to, czy któreś z nich wymagają uwagi. W ciągu miesiąca działo się to około dwudziestu dwa tysięcy razy. Prawie każda odpowiedź brzmiała na starannie uzasadnione „nie”. Jedenastka odpowiedzi „tak” była doskonała, ale rachunek w dużej mierze składał się z negatywnych wyników. Najdroższą czynnością wykonywaną przez system, o około trzy rzędy wielkości, było potwierdzenie, że nic się nie zmieniło.

W innej części tej samej infrastruktury znajdowało się stare zadanie cron, które co minutę sprawdzało progę na dysku. Przez cały okres swojego funkcjonowania nie kosztowało praktycznie nic. Różnica jest właśnie nauką płynącą z całego tego tematu: czekanie to coś, co projektuje się specjalnie, a nie coś, co dzieje się automatycznie.

Idea, którą należy przyjąć, jest następująca: agent otoczeniowy jest definiowany przede wszystkim przez to, co go aktywuje, a nie przez to, co robi po przebudzeniu. Prawdziwa inżynieria polega na stworzeniu mechanizmu, który w jak najtańszy sposób określi, które z tysięcy przychodzących zdarzeń zasługują na uwagę modelu, w połączeniu ze stanem uśpionym, który nie generuje żadnych kosztów dopóki do akcji nie dojdzie. Agenci do rozmów online nigdy nie borykają się z tym problemem, ponieważ osoba, która pisze wiadomość, już wcześniej oceniła, czy warto ją wysłać. Gdy usuniemy tę osobę z procesu wyzwalania akcji, naszym zadaniem staje się sortowanie wiadomości. Rozwiązanie tego problemu za pomocą dużego modelu oznacza w praktyce zatrudnienie najdroższego specjalisty do sortowania wiadomości.

To opiera się na kilku koncepcjach, które wymagają osobnego omówienia: trwała eksploatacja (proces, który może działać przez dni bez zużywania zasobów obliczeniowych), ugruntowanie w czasie (to, czego agent musi na nowo nauczyć się o „teraz”, gdy się budzi) oraz dewiacja celu u agentów długowiecznych. Są one omówione poniżej, tam gdzie mają znaczenie.

Każde zapytanie było już wydarzeniem

Zaproszenie do rozmowy wydaje się naturalnym punktem startowym dla agenta, ale kryje w sobie wiele niepotrzebnego wysiłku. Osoba, która je wysłała, wykonała trzy czynności przed przetworzeniem jakiegokolwiek tokena. Najpierw oceniła, czy sytuacja wymaga działania – to jest etap triażu. Następnie streściła ją w kilku zdaniach – to jest budowanie kontekstu. Wreszcie wysłała je w określonym momencie – to jest kwestia timingu. Agent do rozmów w rzeczywistości jest agentem działającym na podstawie warstwy wydarzeń generowanych przez człowieka.

Agenty otoczeniowe, termin upowszechniony przez LangChain na określenie agentów, które przetwarzają strumień zdarzeń i na nie reagują, mogąc jednocześnie obsługiwać kilka zdarzeń, eliminują rolę człowieka. Wszystkie trzy usługi darmowe znikają. Pozostaje problem inżynieryjny z pięcioma różnymi rodzajami danych wejściowych, z których każdy zachowuje się inaczej:

• Wiadomości. Osoba pisze do agenta. Są one rzadkie, już filtrowane przez ocenę człowieka i pełne intencji. To prosty przypadek.
• Harmonogramy. Cron i wszystko, co od niego pochodzi. Harmonogram jest uruchamiany niezależnie od tego, czy coś się wydarzyło, czy nie. Jest to przydatne, ponieważ uchwytuje to, co umyka strumieniom zdarzeń, ale marnotrawne, ponieważ większość uruchomień kończy się bez żadnej reakcji.

Zdarzenia. Webhooki, wiadomości z kolejki, nowe wiersze w tabeli. Świat zewnętrzny przesyła je do Ciebie. Przychodzą w dużych ilościach, falami, bez żadnej selekcji, a są generowane przez inne systemy i obce osoby, a nie przez Twojego użytkownika.

Nadzór. Warunki dotyczące stanu: prośba o połączenie stała się możliwa do zrealizowania, dokument został edytowany, klient przestał odpowiadać. Nic nie przesyła tego do Ciebie. Ktoś musi to zauważyć, a takie obserwowanie ma swoją cenę.

Progi. Wskaźnik przekroczył określoną granicę. To najstarszy mechanizm wyzwalania działań w obszarze operacji, który obejmuje dziesięciolecia zdobytej wiedzy na temat alertów dotyczących zmęczenia, niestabilności i stref martwych, które twórcy agentów odkrywają na nowo.

Projektowanie agenta w stanie spoczynku oznacza decydowanie o tym, w jaki sposób one się łączą. Który z nich może obudzić agenta? Co znajduje się pomiędzy surowym sygnałem a modelem? Co agent odbudowuje na temat świata, gdy się budzi? Błąd w jednym kierunku prowadzi do opisanego powyżej scenariusza – modela, który co dwie minuty interpretuje ciszę jako sygnał. Błąd w drugim kierunku sprawia, że agent śpi przez cały incydent, który miałby wykryć.

Kanał budzenia: triaż jako schody

Kluczowym faktem ekonomicznym jest to, że wywołanie modelu stanowi najdroższe warunkowe zapytanie, jakie kiedykolwiek zostanie napisane. Zadanie modelowi granicznemu pytania „czy to ma znaczenie?” kosztuje około pięciu do siedmiu rzędów wielkości więcej niż filtr bazy danych, który odpowiada na to samo pytanie w przypadku danych strukturalnych. Dlatego architektura pracy nigdy nie polega na bezpośredniej ścieżce od zdarzenia do modelu – jest to lejek: seria etapów, z których każdy jest tańszy od następnego i odrzuca większość tego, co do niego trafia.

Etap pierwszy: reguły strukturalne

Pierwszy etap w praktyce nie kosztuje nic. Jest to zwykły kod, który sprawdza charakterystykę zdarzenia: jego typ, nadawcę, etykiety oraz repozytorium lub kolejkę, z której pochodzi. Newslettery, automatyczne powiadomienia, komentarze botów oraz zdarzenia dotyczące projektów, którymi agent nie zarządza, mogą być tutaj umieszczane bez żadnej oceny. W typowej skrzynce odbiorczej duża część surowych danych nie musi trafiać dalej. Jeśli w tym etapie odrzuca się mniej niż połowę surowych zdarzeń, twoje reguły są prawdopodobnie zbyt restrykcyjne.

Etap drugi: debounce i łączenie

Zdarzenia pojawiają się falami, które mają wspólną przyczynę: dziesiątki e-maili w jednym temacie, wiadomość typu push zawierająca trzydzieści zmian, setki alertów z powodu awarii jednego przełącznika. Odpowiednią jednostką wymagającą uwagi agenta nie jest pojedyncze zdarzenie, lecz sytuacja, która za nim stoi. Dlatego ta etap zawiera krótki okres czasowy, grupuje przychodzące zdarzenia według klucza korelacji, takiego jak temat, pull request lub incydent, i przekazuje pojedynczy, połączony sygnał dla każdej sytuacji.

Cierpliwość jest również potrzebna na tym etapie. Dokument, który zmienił się raz, najprawdopodobniej ulegnie jeszcze kilku zmianom w ciągu najbliższych minut. Jeśli uruchamiasz proces po upływie określonego interwału od najnowszej zmiany, a nie od pierwszej, znacznie zmniejszasz liczbę takich uruchomień, a każde z nich obejmuje pełniejszy obraz sytuacji. Ten sam princip ma zastosowanie wtedy, gdy kilku użytkowników edytuje wspólny stan: seria czterdziestu zdarzeń zazwyczaj opisuje jeden fakt.

Uwaga dotycząca mechanizmów monitorowania: poll i diff, nigdy poll i ocena

Mechanizmy monitorowania wiążą się z koniecznością podjęcia decyzji dotyczącej kosztów, czego nie ma w przypadku innych mechanizmów wyzwalania. Ktoś musi zauważyć zmianę, a istnieją dokładnie trzy sposoby na to:

• Źródło wysyła sygnał. webhook lub subskrypcja informuje o zmianie stanu. Gdy taka możliwość istnieje, należy z niej skorzystać.

Przeprowadzasz pomiary i porównania. Zgodnie z harmonogramem pobierasz aktualny stan, porównujesz go z poprzednim zrzutem obrazu i wyświetlasz zdarzenie tylko wtedy, gdy coś się zmieniło.

Przeprowadzasz pomiary i oceniasz. Zgodnie z harmonogramem pobierasz stan i zadajesz pytanie modelowi na jego temat. To właśnie poszło nie tak w opisanym wcześniej scenariuszu.

Samo przeprowadzanie pomiarów zasługuje na lepszą reputację, niż sugeruje ten scenariusz. Pomiarы są tanie; drogie jest ocenianie. Zadanie zaplanowane na określony czas, które pobiera stronę, tworzy jej hasz i porównuje go z poprzednim haszem, kosztuje znikomą kwotę rocznie. Wiele systemów nie oferuje webhooków, więc zasada „nigdy nie przeprowadzać pomiarów” nie jest realistyczna. Prawdziwą zasadą jest to, że pomiar musi skończyć się porównaniem różnic, a nie wywołaniem modelu. Należy zrobić zrzut stanu, go porównać i dopuścić do dalszej obróbki jedynie wykryte zmiany jako zdarzenia, które podlegają tym samym regułom i klasyfikatorowi co wszystko inne. To, czy coś się zmieniło, to kwestia funkcji haszującej. To, czy ta zmiana ma znaczenie, to pytanie, na które przeznaczamy model.

Etap trzeci: tania klasyfikacja

To, co przeżyje reguły i proces łączenia informacji, trafia do małego, szybkiego i taniego modelu z celowo wąskim opisem zadania, na przykład „odpowiedz jednym słowem: pilne, istotne lub zignoruj”. To jest znana kaskada routingu modeli zastosowana w systemach alarmowych: ta tania warstwa pochłania niejednoznaczność, której nie mogłyby wyrazić stałe reguły, a tylko wyniki typu „istotne” i „niepewne” są przekazywane dalej. Mały model, który prawidłowo odpowiada w 92% przypadków, stojący naprzeciw dużego modelu kosztującego trzydzieści razy więcej, stanowi całe uzasadnienie biznesowe tej warstwy. Aby uzyskać szerszy obraz źródeł wydatków na agenty, zapoznaj się z modeliem kosztów opartym na architekturze dla AI agentów.

Etap czwarty: agent

Dopiero w tym momencie rozpoczyna się pełne przygotowanie – z rzeczywistym montażem kontekstu, narzędziami oraz budżetem. W zdrowym lejku tylko niewielka część surowego ruchu dociera aż tutaj, a każdy taki przypadek przybywa już zapakowany jako konkretna sytuacja, a nie jako zwykłe zdarzenie.

Faza piąta: człowiek

Lejek trwa dalej po agentze, ponieważ agent jest również filtrem – decyduje, które z jego ustaleń są warte czasu osoby. To właśnie na tej ostatniej fazie systemy otoczeniowe odnoszą sukces lub ponoszą porażkę, i znajduje się ona w osobnym rozdziale poniżej.

Arytmetyka przeprojektowania

Zastosuj to do zespołu od samego początku. Załóżmy, że zmienią skrzynkę odbiorczą z mechanizmu polling na webhooks i dodadzą reguły strukturalne, co usunie około 70% surowych zdarzeń, ponieważ są to newslettery i automatyczne wiadomości e-mail. Połączenie zdarzeń według wątków usunie około 60% tego, co pozostanie. Następnie mały klasyfikator oznaczy około 85% pozostałych zdarzeń jako „ignoruj”. Model frontier teraz działa mniej więcej trzydzieści razy miesięcznie, w porównaniu z dwudziestoma dwa tysiącami wcześniej, przy czym nadal zachodzą te same jedenaście cennych działań. Koszt każdego przydatnego przebudzenia spada o wiele powyżej jednej rzędu wielkości.

Zaskakujące jest to, że poprawia się również dokładność. Każde przebudzenie analizuje teraz spójną sytuację, a nie dowolny fragment, który przypadkowo znalazł się w oknie dwuminutowym, dzięki czemu model ma lepsze dane do analizy.

Dobry sen: dlaczego agent w stanie spoczynku nie kosztuje nic

Pomiędzy przebudzeniami idealnego agenta otoczenia w ogóle nie istnieje. Nie działa on cicho w tle; nie ma żadnego procesu, żadnego kontenera ani żadnego „ciepłego kontekstu”. Cała jego egzystencja to zapis w bazie danych: tożsamość, konfiguracja, wskaźnik do jego pamięci oraz lista subskrypcji. To jest realizacja koncepcji „czekanie to po prostu stan” doprowadzona do jej logicznego końca. Proces w stanie zawieszenia to dane w spoczynku, a przechowywanie danych w tym stanie to jedna z najtańszych usług oferowanych przez dostawców chmury.

To oznacza, że przebudzenie jest aktem rekonstrukcji. Wszystko, co dotyczy wznowienia przerwanego procesu pracy, ma tu zastosowanie jeszcze silniej, ponieważ nikt nie obserwuje tego procesu.

Odbudowanie zegara

Agent, który się budzi po sześciu dniach, musi otrzymać informację o bieżącej godzinie oraz ponownie obliczyć wszystkie odniesienia względne, które posiada. Notatka z napisem „termin jest w piątek”, napisana we wtorek, jest już błędna do następnego poniedziałku. Należy podać agentowi aktualną godzinę w strefie czasowej jego przełożonego oraz czas ostatniego przebudzenia, aby wiedział, jak długo był uśpiony.

Traktuj pamięć jako możliwie przestarzałą

Szczegóły świata zmieniały się podczas nieobecności agenta. Informacje przechowywane w pamięci powinny mieć datę aktualizacji i być ponownie weryfikowane przed użyciem, a kontekst przebudzenia powinien faworyzować aktualne dane zamiast tych zapamiętanych. To ta sama zasada, którą stosuje się, gdy krok zatwierdzenia przez człowieka wstrzymuje przepływ pracy: decyzje należy powiązać z konkretnym momentem, a następnie ponownie je zweryfikować po wznowieniu działania.

Ponownie skup się na celu

W agentach działających przez długi czas cel jest efektywnie odbudowywany na podstawie kontekstu przy każdej turze, dlatego cele mogą się zmieniać na przestrzeni tygodni. „Wake” buduje swój kontekst od zera, co czyni to albo najbardziej ryzykownym momentem dla odchylenia, albo najlepszą szansą na jego skorygowanie. Przy prawidłowym wykonaniu każdy „wake” ponownie odczytuje definicję celu. Jeśli agent jest odbudowywany dwieście razy w roku, to są to dwieście szans na przywrócenie go do jego pierwotnego celu bez żadnych dodatkowych kosztów.

Dlatego też projekty, które rozpoczynają nową sesję po każdym przebudzeniu, zachowując ciągłość w pamięci zewnętrznej i plikach zamiast tworzyć coraz dłuższe zapisy, radzą sobie znacznie lepiej niż pojedyncza, nieśmiertelna sesja, która gromadzi miesiące danych. Funkcje agentów zaplanowanych w obecnych narzędziach programistycznych, przy czym rutyny Claude Code stanowią dobrze znany przykład w momencie pisania tego tekstu, w dużej mierze opierają się na tym modelu nowej sesji przy każdym uruchomieniu. Jest to rozsądny wybór dla każdego, kto widział, jaki wpływ ma kontekst trwający kilka tygodni na zachowanie agenta.

Czym powinien się charakteryzować dobry kontekst po przebudzeniu

„Rekonstrukcja” brzmi abstrakcyjnie, dopóki jej nie stworzymy. Dobrze skonstruowany prompt po przebudzeniu przypomina instrukcje, które narzędzie kompiluje krok po kroku:

• Plik z celem, niewyedytowany. Powód istnienia tego agenta oraz ograniczenia dotyczące tego, co może robić.

Zegar. Obecna godzina w strefie czasowej kierownika, wraz z datą i godziną poprzedniego przebudzenia.

Sytuacja. Zsumowany zarys wydarzeń, które spowodowały to przebudzenie. Nie czterdzieści surowych zdarzeń, lecz opis ich charakteru.

Stan aktualny. Obecne wartości wszystkich elementów dotkniętych przez sytuację, pobrane w momencie przebudzenia i każde z nich opatrzone datą aktualizacji.

Pamięć istotna. Mała grupa trwałych notatek pozostawionych przez wcześniejsze przebudzenia, takich jak „ten klient woli rozmowy wieczorami” lub „ostatnim razem, gdy aktywowano ten alert, przyczyną była pamięć podręczna”. Są one pobierane w razie potrzeby, a nie gromadzone.

Budżet. Limity tokenów, dostępne narzędzia oraz górna granica autonomii dla tego konkretnego przebudzenia.

Zauważ, czego brakuje: transkrypcji wcześniejszych sesji. Ich wnioski przetrwają, ponieważ każda sesja przechowuje w pamięci to, czego się nauczyła, zanim się zakończy, ale tymczasowe dane z każdej sesji są usuwane. Dzięki temu dwusta pierwsza sesja pozostaje tak samo precyzyjna jak druga. Pomaga to również w oszczędnościach, gdyż krótka prezentacja składająca się z kilku tysięcy tokenów zastępuje transkrypcję, która mogłaby liczyć setki tysięcy tokenów.

Gwarancje dostawy z elementem LLM

Sesje te niosą ze sobą również klasyczne problemy systemów rozproszonych.

Dostawa odbywa się co najmniej raz, więc każde wezwanie musi być idempotentne. Zarówno kolejki, jak i usługi webhook mają prawo wysłać ci tę samą wiadomość dwa razy. Dla notyfikatora bez stanu duplikat to po prostu szum. Dla agenta posiadającego narzędzia duplikat może oznaczać wykonywanie tej samej, nieodwracalnej czynności dwukrotnie. Rozwiązaniem jest standardowe: wygeneruj klucz idempotencji na podstawie zdarzenia i sprawdź go przed wykonaniem jakichkolwiek działań, których nie da się cofnąć. Jeśli potrzebujesz przypomnienia dotyczącego tej mechaniki, zapoznaj się z tym, jak działają klucze idempotencji w Node.js POST endpointach.

Agenty środowiskowe potrzebują również drugiej weryfikacji na poziomie sytuacji. Agent obudzony z powodu informacji „PR #482 można połączyć” powinien upewnić się, że prośba o połączenie nadal jest możliwa do realizacji, zanim podejmie działanie. Obudzenie mogło nastąpić kilka minut temu, a inna osoba lub drugi agent mogli już się tym zająć. Wyścigi na czas obudzenia to zwykłe sytuacje konfliktu stanów ze względu na dłuższy opóźnienie pomiędzy przyczyną a skutkiem.

Strumienie zawierają błędy, dlatego każde zastosowanie wymaga okresowego sprawdzenia spójności danych. Punkty końcowe mogą przestać działać, subskrypcje wygasają, a dostawcy czasami przerywają dostawy bez uprzedzenia. Zastosowanie oparte wyłącznie na reakcji na zdarzenia w końcu przeoczy jakieś zdarzenie, a nikt tego nie zauważy; z zewnątrz agent, który milczy, ponieważ nic się nie stało, wygląda identycznie jak agent, który milczy, ponieważ stracił zdolność widzenia. Rozwiązanie jest stare i niepozorne: powolne, zaplanowane sprawdzanie, które porównuje rzeczywisty stan z tym, co zgłosił strumień zdarzeń, podobnie jak systemy płatnicze porównują to, co było zamierzone, to, za co pobrano opłatę, oraz to, co faktycznie zostało dostarczone. Wykorzystaj mechanizm push do radzenia sobie z opóźnieniami, a takie sprawdzanie do ustalania prawdy.

Zaawansowane kwestie: przeciwnicy, uwaga, równoczesność i awarie

Powodem jest powierzchnia ataku

Przyjrzyj się ponownie pięciu typom danych wejściowych z myślą o bezpieczeństwie. Każda osoba, która może wysłać zdarzenie, może w praktyce uruchomić agenta. Treści webhooków, treść e-maili oraz komentarze do zadań, które mogą wywołać aktywację agenta, to wszystko teksty niewiarygodne, które trafiają do modelu posiadającego dostęp do narzędzi. W odróżnieniu od czatu, w momencie aktywacji nie ma osoby obecnej, która mogłaby zauważyć, że coś jest nie tak. Starannie przygotowany e-mail o charakterze „pilnym” nie tylko marnuje zasoby agenta; decyduje również o tym, co agent będzie myśleć, a to jest pierwszym krokiem w niemal każdej łańcuchu iniekcji poleceń.

Wszystkie standardowe środki łagodzące są stosowane. Traktuj treść zdarzeń ściśle jako dane. Izoluj agenta otoczeniowego jeszcze mocniej niż agenta do rozmów. Trzymaj oddzielnie trzy niebezpieczne funkcje: dostęp do danych prywatnych, ekspozycję na niezaufane treści oraz możliwość komunikacji z zewnątrz; agent monitorujący skrzynkę pocztową, posiadający szeroki zakres narzędzi i możliwość wysyłania wiadomości, ma wszystkie trzy te funkcje plus dodatkową możliwość działania. Dodaj jedną zasadę specyficzną dla systemów otoczeniowych: autonomia powinna być proporcjonalna do stopnia zaufania do wyzwalacza. Akcja może zostać uruchomiona przez twój własny harmonogram, natomiast akcja spowodowana treścią od osoby z zewnątrz powinna przede wszystkim służyć do powiadamiania.

Człowiek jest najrzadszym zasobem w tym cyklu

Większość tego, co wytwarza agent otoczeniowy, to przerywanie działania ludzi, a przerywania te są „walutą”, której wartość spada w momencie nadmiernego ich używania. Przydatnym wzorcem, dobrze opisanym w przykładzie skrzynki odbiorczej agentów LangChain, jest trzystopniowy proces, który agent może zastosować wobec osoby:

• Poinformuj. Tylko w celu dostarczenia informacji; nie wymaga żadnych działań.
• Zadaj pytanie. Agent potrzebuje jednego faktu, zanim będzie mógł kontynuować.
• Przedstaw i poproś o zatwierdzenie. Agent przygotował działanie i chce uzyskać na nie zgodę.

Kluczową informacją dotyczącą konkretnego środowiska jest to, że ta drabina służy jednocześnie jako wskaźnik jakości. Zapisz, jak ludzie reagują na każde przerwanie: czy podejmują działania, ignorują je, czy odrzucają. Dzięki temu uzyskasz dokładną miarę efektywności całego procesu. Agent, którego powiadomienia są ignorowane w 80% przypadków, nie tylko traci 80% swojej efektywności – to także skłania ludzi do wyłączania dźwięku, a gdy to zrobią, nawet te przydatne 20% znika. Zmęczenie powiadomieniami utrudniało wdrażanie systemów monitoringu od dziesięcioleci, jeszcze zanim pojawiły się modele językowe, a elokwentny tekst powiadomień nic nie zmienia w tej sytuacji.

Konkurencja zadań: supermoc z towarzyszącym jej zagrożeniem

Definicja agenta otoczeniowego obejmuje możliwość działania na kilku zdarzeniach jednocześnie, a ten szczegół łatwo przeoczyć. Agent czatowy obsługuje jedną rozmowę. Agent otoczeniowy mógłby mieć jednocześnie czterdzieści procesów w trakcie działania, z których każdy znajduje się w odrębnym, czystym kontekście i posiada częściowy obraz wspólnej rzeczywistości. Zdobyłeś system wielu agentów bez żadnego decyzji, wraz z towarzyszącymi mu problemami stanu wspólnego. Dwa procesy powstałe w wyniku powiązanych zdarzeń mogą przejąć ten sam bilet, zapisać sprzeczne odpowiedzi w jednym wątku lub oba przyjąć to samo zadanie, a żaden z nich nie będzie w stanie tego stwierdzić, ponieważ czyste konteksty nie dzielą się ze sobą żadnymi danymi.

Sposoby łagodzenia tych problemów, w przybliżonej kolejności priorytetów:

• Dzielenie procesów według klucza korelacji, tak aby każda sytuacja miała swój własny stan. Grupowanie utworzone na drugim etapie pełni również rolę reguły przypisania: każda sytuacja otrzymuje dokładnie jeden proces i nie ma żadnego równoległego odpowiednika.

Zapis tras przez pojedynczego pisarza, gdy podział nie wystarcza.

Wykorzystaj optymistyczną współbieżność, gdy dwa obiekty naprawdę muszą dotknąć tego samego obiektu, i traktuj konflikt jako błąd, aby drugi pisarz ponownie ocenił swoją decyzję zamiast nadpisać pierwszy.

Jeśli lejek jest dobrze zaprojektowany, większość z tego działa bez dodatkowych kosztów, i to nie jest przypadek. Klucze korelacji, które grupują wydarzenia, oraz klucze własności, które chronią stan, naturalnie powinny być tymi samymi kluczami.

Tryb burzy

Jedno incydent w górnej części łańcucha może wygenerować dziesięć tysięcy powiązanych wydarzeń. Prosty lejek zamienia je w dziesięć tysięcy obiektów, co powoduje gwałtowny wzrost zużycia tokenów oraz czterdzieści powiadomień, które prowadzą do wyciszenia kanału w trakcie incydentu. Zespoły operacyjne dawno temu rozwiązały tę sytuację dzięki wykrywaniu flappingów i grupowaniu incydentów.

Odpowiednikiem agenta jest detektor burz, który porównuje aktualną szybkość występowania zdarzeń z wartością bazową, a gdy ta gwałtownie rośnie, przechodzi lejek do innego trybu. W trybie burzy wszystko, co jest ze sobą powiązane, zostaje połączone w jedną sytuację – budzi się jeden agent z podsumowaniem i otrzymuje konkretne polecenie: to jest burza; podsumuj ją, zidentyfikuj najprawdopodobniejszą przyczynę i wyślij jedno powiadomienie. Kontrola kosztów jest ważna, ponieważ to właśnie w końcowej fazie obciążenia pracą niszczą się budżety, ale argument związany z uwagą jest jeszcze ważniejszy. Podczas incydentu zdolność osoby do radzenia sobie z przerwami spada dokładnie w momencie, gdy szybkość występowania zdarzeń rośnie. Tryb burzy to lejek, który uwzględnia tę odwróconą zależność.

Mierzyć nieaktywnych agentów jak produkt

Najważniejsze są dwa liczby:

• Koszt na każde przydatne wywołanie. Łączna kwota wydana podzielona przez liczbę wywołań, które osoba po fakcie uznaje za wartościowe. To ekonomia jednostkowa zastosowana do twojego własnego systemu.
• Dokładność i trafność triażu. Można je bardzo skutecznie ocenić offline. Przesuń trzydzieści dni danych o przeszłych zdarzeniach przez mechanizm filtrowania kandydatów i porównaj wywołania, które miałby on wygenerować, z rzeczywistymi reakcjami ludzi.

To narzędzie do ponownego odtwarzania jest jedną z nielicznych metod oceny, której budowa jest prawie bezpłatna, ponieważ etykiety już istnieją w historii twoich zleceń. Przekształca zmiany w mechanizmie filtrowania z kwestii subiektywnych w mierzalne różnice.

Autonomia zależna od czasu

Kolejny wzorzec jest tani w wdrożeniu, a jednocześnie dziwnie rzadki: niech górna granica autonomii systemu zależy od momentu jego uruchomienia oraz od tego, kogo można dotrzeć. Odkrycie to, które uzasadnia automatyczną korektę o 11 rano w wtorek, gdy ludzie są online, przycisk zatrzymania jest pod ręką, a zasięg eksplozji dobrze znany, mogłoby wymagać jedynie alertu we wczesnych godzinach niedzieli.

To nie jest nadmierna ostrożność. To decyzja oparta na wartości oczekiwanej, przy czym czas stanowi jeden z parametrów. Koszt zadania pytania jest niski w godzinach pracy, a bardzo wysoki w nocy. Jednocześnie korzyść z ludzkiego nadzoru – prawdopodobieństwo, że ktoś wykryje błąd pomnożone o koszt tego błędu – maleje w nocy, ponieważ nikt nie jest czujny. Dlatego term błędu dominuje i próg powinien przesunąć się w stronę zadawania pytań, co w praktyce oznacza odroczenie, ponieważ nie ma nikogo czuwającego, aby odpowiedzieć.

Zakoduj to jako wyszukiwanie w systemie, który łączy poziom zaufania do wyzwalacza, stopień powagi działania oraz dostępność człowieka, i przyporządkowuje je do jednego z trzech wyników: podjąć działanie natychmiast, umieścić w kolejce na ranek lub powiadomić od razu. Opcja kolejki na ranek jest prawdziwym bohaterem nie docenianym. Większość rzeczy, które agent otoczeniowy zauważa o 3 rano, jest w pełni przydatna jako element do przejrzenia o 8:55 rano, już zapakowany wraz z proponowanym przez agenta działaniem i dostarczany mniej więcej w czasie, gdy parzy się pierwszą kawę.

Wzorce w rzeczywistych systemach

Pomocnik e-mailowy z skrzynką odbiorczą dla ludzi

Referencyjny agent otoczeniowy LangChain zajmuje się e-mailem: sporządza projekty odpowiedzi, przechowuje wiadomości i przekazuje je dalej. Jego projekt interakcji jest bardziej pouczający niż funkcja tworzenia tekstów. Zespół odpowiedzialny za niego postrzega udział człowieka nie jako kompromis, lecz jako coś, co zmniejsza ryzyko, ułatwia wdrożenie rozwiązań, buduje zaufanie i wspomaga długoterminową pamięć. Ich Agent Inbox – pojedyncza lista wszystkich otwartych rozmów pomiędzy osobą a jej agentami, dostępna do przeglądania – stanowi fizyczną wersję mechanizmu powiadamiania, zadawania pytań i przeglądania. Popularny żart z tego projektu, mówiący, że jeśli ktoś zostanie zignorowany, to na pewno wina agenta, doskonale oddaje zasadę gospodarki uwagi: agent istnieje po to, by osoba mogła lepiej zarządzać swoją uwagą, a żarty pojawiają się wtedy, gdy tego nie robi.

Agenci zaplanowani w narzędziach programistycznych

Główne platformy do programowania dodają agenty, które działają zgodnie z harmonogramem lub wydarzeniami w repozytorium, zamiast na podstawie poleceń; przykładami są rutyny w Claude Code oraz wykonywania uruchamiane przez GitHub – zjawiska, z którymi spotkało się wielu programistów. Sprawdź aktualną dokumentację, ponieważ te funkcje rozwijają się szybko. W obu przypadkach pojawiają się dwa podobne podejścia projektowe, które wspierają przedstawiony tu argument. Każde wykonywanie rozpoczyna nową sesję, a ciągłość jest przechowywana w plikach i pamięci, a nie w nieskończonej transkrypcji. Warstwa wyzwalaczy to klasyczna infrastruktura, takia jak wyrażenia cron, filtry webhook oraz warunkowe pliki YAML – w całym procesie nie ma żadnego modelu. Inteligencja jest droga, natomiast zegar alarmowy tani, dlatego produkty trzymają je oddzielnie.

Nadzorcy infrastruktury

Dostawcy chmury opisali wzorce działania agentów otoczeniowych, które monitorują infrastrukturę i proaktywnie zgłaszają stwierdzone problemy. Dobrze zaprojektowane rozwiązania przypominają praktyczne zastosowanie tej instrukcji. Zdarzenia pochodzą z wbudowanego bufora zdarzeń platformy, więc filtrowanie strukturalne jest dostępne bezpłatnie. Zdarzenia są powiązane ze sobą przed uruchomieniem jakiegokolwiek agenta. W przypadku problemów istotnych agenci tworzą raporty do przeanalizowania, zamiast samodzielnie stosować naprawy. Cennym elementem do przejęcia jest gradient zaufania: im dalej sięga proponowana akcja, tym wyżej w hierarchii powiadamiania, pytania i analizy znajduje się. Obserwacja może być autonomiczna; interwencja wymaga nadzoru.

Zespół sprawdzający, kwartał później

Powrót do zespołu po rozpoczęciu pracy nastąpi, gdy redesign zostanie w pełni wdrożony. Ich system składa się teraz z webhooków, łączenia wątków z dziesięciominutowym okresem ciszy, małego klasyfikatora, którego cały prompt zmieściłby się na karcie indeksowej, oraz około trzydziestu aktywności modeli typu frontier miesięcznie. Wyróżniają się dwa efekty: koszt za każdą przydatną aktywność spadł mniej więcej czterdzieści razy, a co zaskakujące, wzrosła również szybkość wykrywania. Poprzedni design dzielił sytuacje na arbitralne dwuminutowe fragmenty, przez co przynajmniej dwa razy odrzucił częściowy obraz czegoś, co jako całość wyraźnie zasługiwało na odpowiedź „tak”.

Zatem redesign przyniósł coś więcej niż tylko obniżkę kosztów. Grupowanie zdarzeń poprawiło jakość ocen, ponieważ model mógł w końcu analizować całe sytuacje, a nie tylko ich arbitralne fragmenty. Problemem nigdy nie była sama zaplanowana praca – problemem było proszenie modelu o ocenę każdego jej etapu.

Wybór elementów budulcowych

Większość składników tego stacku powinna być zakupiona lub ponownie wykorzystana, zamiast budowana od nowa.

• Infrastruktura wyzwalaczy. Cron i jego zarządzane odpowiedniki; autobusy zdarzeń i kolejki takie jak EventBridge, Pub/Sub, Kafka lub proste webhooki; a także harmonogramy i sygnały w silnikach procesów takich jak Temporal, Restate czy Inngest, które zapewniają również trwałe przechowywanie danych. Etapy pierwszy i drugi mapują się bezpośrednio na to, co te narzędzia już robią.

Ramy robocze typu Ambient-agent. LangGraph, który zapewnia trwałość danych, obsługę przerw i zadań cron, a także otwarte oprogramowanie Agent Inbox; tryby planowane i uruchamiane przez główne agenty programistyczne, takie jak rutyny Claude Code i integracje z GitHub Actions; oraz coraz większa liczba łączników, które przekształcają e-maile lub webhooki w wykonywanie zadań przez agenty. Oceniaj je wszystkie według trzech kryteriów: gdzie odbywa się triaż (powinien nastąpić przed modelem), co odtwarza mechanizm wake oraz co ostatecznie widzi użytkownik.

Poziom triażu. Wystarczy każdy mały, szybki model. Kluczem jest precyzyjny prompt oraz ocena pozałączeniowa, a nie wybór konkretnego modelu.

Poštówka. Użyj Agent Inbox z LangChain, jeśli chcesz gotowej platformy, albo obecnych kanałów twojego zespołu, takich jak Slack, e-maile czy systemy zgłoszeń, zachowując trzy kluczowe czynności w sposób wyraźny i kontrolowany.

Wydaj swój budżet na elementy typu funnel oraz na rekonstrukcję kontekstu po zakończeniu działania, a resztę rzeczy kupuj oddzielnie. Schedulerzy to już rozwiązane problemy, które przeszły dziesięciolecia testów w praktyce. Domowy mechanizm, który sprawdza model co dwie minuty, nie jest takim rozwiązaniem.

Cała struktura mieści się w kilku liniach pseudokodu. Przeczytaj go od góry do dołu, tak jak funnel: bezpłatna weryfikacja reguł, łączenie informacji w jedną całość (brak zwrotu żadnych danych, dopóki sytuacja się nie uspokoi), tania klasyfikacja, mechanizm zapobiegający duplikatom w dostawie danych, rekonstrukcja kontekstu z aktualnego czasu, plik z celem i ponowne odczyty, uruchomienie agenta według ustalonego budżetu, a na koniec dostawa danych za pomocą jednego z trzech narzędzi do obsługi skrzynki odbiorczej.

async def on_event(evt):
    if not rules_pass(evt):            return                  # stage 1: free
    sit = coalesce(evt, window="10m")                          # stage 2: situations, not events
    if sit is None:                    return                  # burst still settling
    if triage_small_model(sit) == "ignore": return             # stage 3: cheap
    if seen(sit.idempotency_key):      return                  # at-least-once armor
    ctx = rebuild(now(), goal_file, fresh_reads(sit))          # stage 4: wake = reconstruction
    outcome = await agent.run(sit, ctx, budget=WAKE_BUDGET)
    inbox.deliver(outcome.verb, outcome.summary)               # notify | question | review

Zwróć uwagę, gdzie znajduje się sprawdzenie idempotencji: po tanich filtrach, ale przed czymkolwiek kosztownym lub nieodwracalnym. Może znajdować się również wcześniej; ważne jest, aby żadna duplikata nie dotarła do agent.run. W rzeczywistym systemie rebuild to również miejsce, gdzie powinno odbywać się sprawdzenie sytuacji przed podjęciem działań, ponieważ to w tym momencie dostępny jest nowy stan.

Prowadnik po trybach awarii

• Ognisko pytań. Kosztowny model jest wielokrotnie proszony o sprawdzenie czegoś, co w rzeczywistości nie istnieje. Rozwiązanie: zasady i fuzja danych przed każdym wywołaniem modelu, a następnie tani model przed kosztownym.
• Tysiące skutków jednej awarii. Jedna awaria rozprzestrzenia się na tysiące innych problemów. Rozwiązanie: tryb burzy, z detektorem szybkości, pełną fuzją danych, jednym agentem i jedną notyfikacją.

Ponownie dostarczone zdarzenie trafia do agenta, który może podjąć rzeczywiste działania. Rozwiązanie: klucze idempotencji dla sygnałów oraz sprawdzenie sytuacji przed podjęciem działań.

Decyzje opierają się na zrzutce stanu z chwili uruchomienia wyzwalacza, mimo że rzeczywistość już się zmieniła. Rozwiązanie: każdy sygnał ponownie sprawdza czas, pobiera aktualny stan i ponownie weryfikuje fakty przed podjęciem jakichkolwiek działań.

Treść pochodząca od osób z zewnątrz decyduje o tym, na co zwraca uwagę twój autonomiczny agent. Rozwiązanie: traktować treść zdarzeń jako dane, skalować stopień autonomii w zależności od poziomu zaufania do wyzwalaczy oraz bardziej rygorystycznie kontrolować agenty otoczenia niż agenty do rozmów.

Zamrożona skrzynka odbiorcza. Dokładność przerwania komunikacji spada, aż ludzie przestają słuchać. Rozwiązanie: śledź akcje podjęte, odrzucone i zignorowane dla każdej powiadomienia oraz traktuj wskaźnik akcji poniżej 50% jako awarię.

Cicha luka. webhook przestał dostarczać dane miesiące temu, a nikt tego nie zauważył, dopóki nie doszło do opóźnienia w odnowieniu. Rozwiązanie: monitoruj opóźnienia, sprawdzaj rzeczywisty stan i stosuj powolne procesy synchronizacji, zakładając, że strumień danych podaje fałszywe informacje.

Niezmienny demon. Jedna sesja pozostaje aktywna przez miesiące i stopniowo odbiega od swojego celu. Rozwiązanie: twórz nową sesję przy każdym uruchomieniu, przechowując ciągłość w plikach i pamięci zamiast w transkrypcjach.

Niespodzianka o północy. Najniebezpieczniejsze działania przeprowadza się w środku nocy, ponieważ nikt nie jest dostępny, by się sprzeciwić. Rozwiązanie: sprawdzaj wszystkie konsekwencje działań, ustaw próg autonomii w zależności od godziny oraz trzymaj pod ręką funkcję anulowania.

Plan na pierwszy tydzień

1. Zbadaj swoje wyzwalacze. Zapisz każdą ścieżkę, która może uruchomić twój agent dzisiaj, oraz koszt każdego takiego uruchomienia. Oznacz jako pierwszą rzecz do poprawy te ścieżki, które polegają na „wywołaniu modelu po upływie czasu”.
2. Zbuduj pierwszy etap. Umieść filtry strukturalne przed każdym wyzwalaczem i zmierz wskaźnik odrzuceń. Jeśli jest on poniżej połowy, twoje zasady są zbyt ostrożne.

Koalescencja. Wybierz klucze korelacji takie jak wątek, prośba o integrację, incydent lub klient, dodaj mechanizm zwłoki na końcu procesu oraz zmień typ danych wprowadzanych przez agenta z „zdarzenia” na „sytuację”.

Dodanie poziomu triażu. Użyj małego modelu generującego wynik składający się z jednego słowa. Następnie stwórz ocenę na podstawie zdarzeń z zeszłego miesiąca oraz odpowiedzi, które faktycznie udzielono, i ocenij dokładność oraz trafność tego procesu przed jego użyciem.

Zabezpieczenie procesów. Dodaj klucze idempotencji, mechanizm weryfikacji przed działaniem oraz procedurę rekonstrukcji: zegar, świeże odczyty, plik celowy.

Zainstalowanie narzędzi pomocniczych. Uczyń typy wyjściowe „powiadomienie”, „pytanie” i „przegląd” wyraźnie określonymi, dostarczaj je w miejscu, gdzie można je śledzić, i zacznij rejestrować, czy każde z nich zostało potraktowane, odrzucone lub zignorowane.

Zrób dwa testy. Odtwórz sekwencję zdarzeń, aby upewnić się, że tryb burzy je łączy, a następnie wyłącz webhook na godzinę, by sprawdzić, czy funkcja skanowania wykrywa lukę. Na koniec oblicz po raz pierwszy koszt za każdą przydatną sekwencję zdarzeń i wyświetl go obok kwoty wydanej na tokeny.

Podsumowanie: percepcja otoczenia, zaangażowanie człowieka

Istnieje prawdziwa debata na temat kierunku rozwoju interfejsów agentów. Jedna ze stron twierdzi, że czat jest interfejsem przejściowym, a agenci będą coraz częściej funkcjonować wewnątrz strumieni zdarzeń, dostrzegając problemy przed ludźmi. Uwaga jest najcenniejszym zasobem pracowników zajmujących się wiedzą, a oprogramowanie, które samo poświęca uwagę na obserwację i wykorzystuje twoją jedynie wtedy, gdy jest to konieczne, jest po prostu lepszym oprogramowaniem.

Druga strona wskazuje, że agent dostępny cały czas i wyposażony w odpowiednie narzędzia łączy dokładnie te ryzyka, o których mowa powyżej: niepewne sygnały wyzwalające, brak osoby obecnej w momencie aktywacji oraz możliwość samodzielnych działań w środku nocy. Z tego punktu widzenia prośba o pomoc nie była żadnym dodatkowym obciążeniem. Było to wyrażenie zgody, a każdy krok polegający na wykluczeniu osoby z procesu przenosi ryzyko z samego momentu działania na jakość wprowadzonych ograniczeń.

Oba strony mają rację, a lejek to miejsce, w którym się spotykają. Obserwowanie wszystkiego jest możliwe, ale należy zauważyć, że to tradycyjna inżynieria sprawiła, iż powyższe przykłady odniosły sukces: filtrowanie, radzenie sobie z opóźnieniami, obsługa idempotentna, zadania synchronizacyjne oraz uwzględnienie ryzyka przeciążenia alertami. Zobowiązanie nadal wymaga zgody, co dokładnie wyraża hierarchia powiadamiania, pytania i przeglądu: autonomia w zakresie obserwacji oraz eskalacja przy podejmowaniu działań. Kluczem jest wykorzystanie agentów, które obserwują szeroko, budzą się rzadko i szukają zatwierdzenia przed zmianą czegokolwiek ważnego.

Korzystne ćwiczenie można przeprowadzić jednego wieczoru. Wybierz najgłośniejszy strumień powiadomień w swoim dniu pracy i zaprojektuj dla niego lejek: jakie proste zasady mogłyby je odfiltrować, co mogłoby zostać połączone, jaki prosty model mógłby je sklasyfikować oraz co naprawdę zasługuje na uwagę. Zanim napiszesz choćby fragment kodu, zaprojektujesz już swojego pierwszego agenta bezczynnego.