Jeden Agent w jednym oknie wystarcza do demonstracji. W produkcji dziesiątki równoległych zadań wymagają osobnych środowisk, bo inaczej sesje się mieszają, karty konkurują o kontrolę, a awarie trudno zdiagnozować.
Jedno okno przeglądarki wystarcza, aby pokazać, co potrafi AI Agent. Gdy jednak trafia do rzeczywistego procesu biznesowego, potrzeba szybko rośnie do dziesiątek okien, które nie mogą sobie wzajemnie przeszkadzać. Przyczyna nie leży w samym Agencie, lecz w przeglądarce, na której działa.
Jakie problemy powstają przy współdzieleniu jednego środowiska
Najbardziej oczywisty problem to wzajemne zanieczyszczanie ciasteczek i stanów logowania. Jeśli dwa zadania w tym samym katalogu danych przeglądarki kolejno logują się na różne konta, późniejsze logowanie może nadpisać sesję wcześniejszego. Gdy jedno zadanie wyczyści pamięć podręczną, może również zniknąć stan strony drugiego zadania.
Następny problem to rywalizacja o zasoby. W jednej instancji przeglądarki karty, fokus, katalog pobierania i wyskakujące okna są współdzielone. Jeśli dwa zadania jednocześnie otwierają nowe karty, przestaje być jasne, które zadanie obsługuje którą stronę. Okno dialogowe wywołane przez jedno zadanie może zablokować skrypt drugiego. Konflikty logowania, nadpisywanie danych i wzajemne zakłócenia są niemal nieuniknione przy współbieżności.
Trzeci problem ujawnia się po awarii. Trudno wtedy ustalić, czy zawiodła logika skryptu, czy środowisko zostało zakłócone przez inne zadanie na konkretnym etapie. Gdy wiele zadań współdzieli jeden proces i jeden log, objawy awarii mogą być niespójne, co wielokrotnie zwiększa koszt diagnostyki.
Jest też mniej oczywiste ryzyko: wiele tożsamości działających długo w tym samym środowisku pozostawia sygnały korelacyjne. Parametry urządzenia, stan pamięci i wyjście sieciowe są takie same, więc platforma może łatwo uznać je za masowe działania z jednego urządzenia. Jeśli jedno konto zostanie uznane za nietypowe, pozostałe również mogą odczuć skutki.
Wiele okien nie oznacza izolacji
Pierwszym odruchem bywa ręczne otwarcie kilku okien. Wyglądają na oddzielne, ale w rzeczywistości współdzielą ten sam profil przeglądarki: te same ciasteczka, tę samą pamięć lokalną i te same informacje o urządzeniu. Okna widzą wzajemnie swoje stany logowania, a operacja w jednym może wpływać na inne.
Prawdziwa izolacja musi obejmować katalog danych i parametry środowiska. Każde środowisko potrzebuje własnego katalogu pamięci, własnych parametrów urządzenia — rozdzielczości, języka, strefy czasowej, czcionek, Canvas, WebGL i innych — oraz własnego wyjścia sieciowego. Brak któregokolwiek z tych trzech elementów oznacza niepełną izolację. Nawet przy oddzielnych środowiskach współdzielone wyjście sieciowe może nadal uruchamiać korelację.
Koszt izolacji i korzyści, które daje
Izolacja nie jest bezpłatna. Za każdym środowiskiem stoi osobny proces przeglądarki i oddzielny katalog danych. Wraz ze wzrostem liczby środowisk najpierw rośnie presja na pamięć i CPU. Jeśli dziesiątki środowisk mają działać na jednej maszynie, lepiej wcześniej policzyć dostępny zapas niż reagować dopiero po awarii.
Można zastosować kilka kompromisów: usuwać rzadko używane środowiska i uruchamiać je ponownie na żądanie; rozdzielać zadania według obciążenia na kilka maszyn zamiast skupiać wszystko na jednej; oraz definiować jasny cykl życia środowisk, by setki instancji nie działały bez końca. Ważna jest też struktura zadań. Zadania sekwencyjne w ramach tego samego konta nie wymagają osobnych środowisk; ich rozdzielenie tylko marnuje zasoby.
Z drugiej strony są korzyści. Po prawidłowym wdrożeniu izolacji awarie stają się stabilne i możliwe do przypisania: problem dotyczy konkretnego środowiska, a nie niejasnego przypadku. W dużej skali ta przewidywalność jest znacznie cenniejsza niż niewielka oszczędność zasobów wynikająca ze współdzielenia.
Trzy funkcje, które po skalowaniu powinny znaleźć się na poziomie środowiska
Pierwsza to harmonogramowanie wsadowe. Środowiska powinny być przydzielane i zwalniane jak zasoby obliczeniowe, z obsługą tworzenia na żądanie, uruchamiania grupowego, kontroli współbieżności, ponawiania po błędach i automatycznego odzyskiwania, zamiast tworzenia i sprzątania każdego z osobna w skryptach.
Druga to niezależne wyjście sieciowe. Każde środowisko powinno mieć własne wyjście, a jego region powinien odpowiadać parametrom geograficznym środowiska. Ten element łatwo pominąć, ale jest warunkiem spójnej izolacji.
Trzecia to możliwość odpytywania o stan. W każdej chwili powinno być wiadomo, które środowiska działają, które są wolne, a które są w stanie błędu. Agenty pracują bez nadzoru; jeśli statusu nie da się sprawdzić, diagnoza sprowadza się do zgadywania.
Te trzy funkcje są niewygodne do realizowania wewnątrz skryptów. Wymagają pamięci, konfiguracji i harmonogramowania na poziomie środowiska. Niektóre narzędzia do zarządzania wieloma środowiskami działają właśnie na tej warstwie. PurpleMark jest jednym z nich i zamienia środowiska przeglądarki w zasoby, które można izolować, planować grupowo i wywoływać przez interfejsy.
Kiedy wiele środowisk nie jest potrzebne
Jeśli Agent używa tylko jednego konta i działa rzadko, zwykła przeglądarka rzeczywiście wystarcza, a dodatkowa izolacja jedynie zwiększa koszty utrzymania. Gdy jednak wystąpi choć jeden z poniższych warunków, warstwa środowiska powinna zostać wydzielona: zadania muszą działać równolegle, wiele tożsamości musi korzystać z tej samej platformy, stan logowania trzeba utrzymywać przez długi czas albo współbieżność będzie nadal rosnąć.
Wspólny mianownik jest ten sam: problem nie polega na tym, czy Agent jest wystarczająco inteligentny, lecz czy środowisko pod nim jest dostatecznie czyste i odseparowane.
Granice
Niezależnie od wybranego rozwiązania granice zasad się nie zmieniają: przestrzegaj warunków usług i reguł robots poszczególnych platform, nie używaj fałszywych danych tożsamości, nie omijaj technicznych zabezpieczeń, kontroluj częstotliwość żądań i nie zakłócaj normalnego działania cudzych usług.
