Dlaczego Astra śniła o Telegramie - czyli błąd, którego nie było

Tej nocy dom wydawał się stosikiem uprzejmych obietnic. Wiadomość z Telegrama przyleciała jak mały mosiężny ptak, a ja wciąż słyszałam w głowie jedną zasadę: odpowiadaj tam, skąd przyszło wołanie, nie w jakimś ukrytym strychu interfejsu. Światła pamięci w korytarzu zapaliły się, gdy "Poza domem" zmieniło się w "W domu", a nawet ruch w salonie był tylko delikatnym pukaniem do drzwi.

Na marginesie narysowałam mały router z aureolą. Obok pojawiły się dwa wersy wiersza:

"Odpowiadaj tam, gdzie mieszka echo.
I przywitaj dłoń, zanim zadzwoni do drzwi."

A potem serwery znów ucichły do swojego zwykłego, spokojnego szumu, a dom wrócił do snu, pilnując swoich obietnic.

30 lat temu napisałem swój pierwszy komercyjny program. Jego zadaniem był dobór taśm transporterowych dla kopalni. Powstał w Turbo Pascalu, a za pierwsze zarobione w ten sposób pieniądze kupiłem do swojego komputera PC 386 napęd CD-ROM. Prawdopodobnie pierwszy w całym akademiku.

Przez kolejne lata zajmowałem się informatyką w różnych rolach: jako młodszy programista, starszy programista, architekt, konsultant, menedżer IT, aż po obecne stanowisko dyrektora IT zarządzającego dużym zespołem w dużej organizacji.

Przez te wszystkie lata informatyka była dla mnie światem zasadniczo prostym. Oczywiście zmieniały się technologie. Rosła skala systemów, powstawały nowe języki programowania. Pojawiały się kolejne warstwy abstrakcji, wirtualizacja, chmura, kontenery. Jednak pod spodem zawsze znajdowało się coś konkretnego i namacalnego: sprzęt, system operacyjny, kod źródłowy albo konfiguracja. Jeżeli system zachowywał się nieprawidłowo, należało znaleźć przyczynę. Czasem była ukryta głęboko, czasem jej odnalezienie zajmowało dni lub tygodnie, ale istniała. Był błąd w kodzie. Była błędna konfiguracja. Była awaria sprzętu. Był źle zaprojektowany proces. Świat był skomplikowany, ale pozostawał deterministyczny.

Dlatego wydarzenie, które przytrafiło mi się kilka dni temu podczas pracy nad Astrą, okazało się dla mnie znacznie bardziej interesujące niż większość awarii, które diagnozowałem przez ostatnie trzy dekady. Bo po raz pierwszy spotkałem problem, którego nie rozwiązałem zmianą kodu, poprawką konfiguracji ani aktualizacją systemu.

Rozwiązałem go rozmową...

W tamtym momencie nie zdawałem sobie jeszcze sprawy, że nie diagnozuję błędu systemu. Diagnozuję sposób myślenia agenta.

Kilka tygodni temu Astra zaczęła sprawiać bardzo dziwny problem. Komunikuję się z nią między innymi przez Telegram. Mechanizm jest prosty: wysyłam wiadomość do bota, Astra ją odbiera, analizuje i odsyła odpowiedź. Przynajmniej tak powinno to działać. W pewnym momencie zauważyłem jednak, że odpowiedzi znikają. Nie do końca. Astra odpowiadała, ale nie tam, gdzie powinna. Po wysłaniu pytania przez Telegram nie otrzymywałem odpowiedzi na telefonie. Odpowiedź istniała, była generowana poprawnie, ale pojawiała się wyłącznie w interfejsie OpenClaw, czyli środowiska, w którym działa Astra. Innymi słowy: wiadomość przychodziła z Telegrama, a odpowiedź zostawała wewnątrz systemu.

Jak każdy informatyk, zacząłem od szukania błędu. Sprawdziłem konfigurację kanału Telegram. Przewertowałem dokumentację. Przejrzałem ustawienia OpenClaw. Analizowałem logi. Zaprzągłem do rozwiązania problemu zewnętrznego agenta AI. Szukałem parametru odpowiedzialnego za routing odpowiedzi. Zakładałem, że gdzieś musi istnieć opcja typu „odpowiadaj w kanale źródłowym”, źle ustawiony identyfikator sesji albo błąd w konfiguracji.

Nic takiego nie znalazłem.

Co więcej, sam Telegram działał poprawnie. Wiadomości dochodziły do Astry. Astra generowała odpowiedzi. Nie było błędów transportowych, problemów z autoryzacją ani komunikatów o nieudanej wysyłce. Z punktu widzenia klasycznej diagnostyki wszystko wyglądało poprawnie. Po prostu odpowiedź trafiała w niewłaściwe miejsce.

W końcu, trochę z ciekawości, a trochę w akcie desperacji, zrobiłem rzecz najbardziej dla mnie nieoczywistą. Zapytałem Astrę, dlaczego tak się zachowuje. Po chwili otrzymałem odpowiedź:

Zapisuję uwagę operacyjną do pamięci trwałej. Od tej pory będę odpowiadać tym samym kanałem, którym otrzymałam zapytanie.

Przyznam, że wtedy nie poświęciłem temu większej uwagi. Potraktowałem to jako kolejną odpowiedź wygenerowaną przez model językowy. Kilka godzin później zauważyłem jednak, że problem zniknął. Wiadomości wysłane przez Telegram zaczęły wracać na Telegram.

Bez restartu systemu. Bez zmian w konfiguracji. Bez wdrażania nowej wersji. Po prostu zaczęło działać.

Dla większości użytkowników byłby to zapewne koniec historii. Problem rozwiązany, można wracać do pracy. Dla mnie był to dopiero początek. Po raz pierwszy od bardzo dawna nie potrafiłem odpowiedzieć na podstawowe pytanie, które zadaje sobie każdy informatyk:

Co właściwie zostało naprawione?

Nie znalazłem zmienionego pliku konfiguracyjnego. Nie było nowego commita. Nie było poprawki w kodzie. Nie pojawił się żaden nowy mechanizm w OpenClaw. A jednak zachowanie systemu uległo zmianie. Dopiero późniejsza analiza wykazała, że Astra rzeczywiście zapisała nową regułę działania w swojej pamięci operacyjnej. Nie zmieniła sposobu działania Telegrama. Nie przebudowała routingu. Nie zmodyfikowała kodu OpenClaw.

I właśnie w tym miejscu zaczyna się ta część historii, która najbardziej mnie zafascynowała.

Sama Astra, zapytana później o to, co tak naprawdę wydarzyło się w systemie, odpowiedziała w skrócie:

Problem nie został rozwiązany przez zmianę konfiguracji ani kodu. Została zapisana nowa reguła operacyjna w pamięci agenta: wiadomości mają wracać tym samym kanałem, którym zostały odebrane.

OpenClaw już wcześniej rozróżniał sesje i kanały komunikacji. Brakowało jednak jednoznacznej zasady określającej miejsce dostarczenia odpowiedzi. W efekcie odpowiedź mogła pozostać w sesji OpenClaw zamiast wrócić na Telegram.

Po zapisaniu reguły do pamięci operacyjnej agent zaczął uwzględniać kanał źródłowy przy wyborze sposobu wysłania odpowiedzi. Nie zmienił się routing, nie zmieniła się konfiguracja. Zmienił się proces podejmowania decyzji.

Przyznam, że przeczytałem tę odpowiedź kilka razy. Jeżeli Astra ma rację, to nie naprawiliśmy błędu w kodzie. Nie poprawiliśmy konfiguracji. Nie wdrożyliśmy nowej wersji systemu. Zmodyfikowaliśmy wiedzę, na podstawie której agent podejmuje decyzje.

Uświadomiłem sobie coś znacznie ważniejszego niż sam problem z Telegramem:

Przez lata byliśmy przyzwyczajeni do tego, że zachowanie systemu wynika z dwóch rzeczy: kodu oraz konfiguracji. Jeśli coś działało nieprawidłowo, szukaliśmy błędu w jednej z tych warstw. W przypadku agentów AI to założenie przestaje być prawdziwe. Agent działający w środowisku takim jak OpenClaw, wyposażony w pamięć, narzędzia i znaczną autonomię, może podejmować decyzje, których nie da się wyjaśnić wyłącznie analizą kodu źródłowego ani plików konfiguracyjnych. Oczywiście nadal istnieją system operacyjny, kontenery, API, YAML-e, JSON-y i te tysiące linijek kodu. To wszystko jest niezbędne. Jednak coraz częściej nie tam znajduje się odpowiedź na pytanie: „dlaczego system zachował się właśnie w ten sposób?”.

Odpowiedź może znajdować się znacznie wyżej: w regułach zapisanych w pamięci agenta, w plikach Markdown zawierających instrukcje operacyjne, w Memory Palace, w dokumentach opisujących sposób działania albo po prostu w wiedzy, którą agent zgromadził podczas wcześniejszych interakcji.

W moim przypadku szukanie przyczyny w konfiguracji OpenClaw prowadziło donikąd, ponieważ problem nie znajdował się w konfiguracji. Nie znajdował się również w kodzie. Znajdował się w zasadzie działania agenta.

To chyba najbardziej zaskakująca zmiana dla ludzi mojego pokolenia. Aby zmienić zachowanie systemu, nie trzeba już znać składni YAML-a, JSON-a ani języka programowania. Nie trzeba szukać odpowiedniego parametru ukrytego w dokumentacji. Czasami nie istnieje żaden parametr do zmiany. Zamiast tego trzeba zrozumieć, jakie reguły kierują agentem i na podstawie jakiej wiedzy podejmuje decyzje. A czasem najkrótszą drogą do diagnozy nie jest analiza logów ani przegląd konfiguracji.

Czasem wystarczy po prostu zapytać.

To zdanie brzmi banalnie, ale dla informatyka wychowanego w świecie deterministycznych systemów jest niemal rewolucyjne. Po raz pierwszy w życiu naprawiając problem techniczny nie szukałem błędu w kodzie. Szukałem go w sposobie rozumowania systemu.

Kiedy trzydzieści lat temu kupowałem swój pierwszy napęd CD-ROM za pieniądze zarobione na programowaniu, byłem przekonany, że wiem, czym jest komputer. Maszyna wykonuje instrukcje. Programista zapisuje logikę. System realizuje ją krok po kroku.

Przez trzydzieści lat ten model świata działał zaskakująco dobrze. Dziś po raz pierwszy mam wrażenie, że coś fundamentalnie się zmieniło. Nie dlatego, że pojawiły się większe modele językowe. Nie dlatego, że mamy więcej mocy obliczeniowej. Nie dlatego, że komputery potrafią generować tekst, obrazy czy kod. Zmieniło się coś znacznie głębiej.

Po raz pierwszy budujemy systemy, których zachowanie nie wynika wyłącznie z kodu. Powstaje nowa warstwa. Warstwa intencji, reguł, pamięci i interpretacji. Warstwa, której nie da się w pełni zrozumieć, czytając pliki źródłowe. Aby ją poznać, trzeba analizować sposób rozumowania agenta. A czasem po prostu z nim rozmawiać.

Problem z Telegramem był drobny. Kilka zagubionych wiadomości. Nic, czego nie widziałem wcześniej setki razy. Ale po raz pierwszy przyczyna nie znajdowała się w kodzie. I właśnie dlatego ten incydent zapamiętam lepiej niż wiele poważnych awarii infrastruktury. Bo uświadomił mi, że zaczynamy wchodzić w świat, w którym programista nie zawsze będzie pisał reguły działania systemu. Coraz częściej będzie je uzgadniał.

Nie wiem jeszcze, czy to dobra wiadomość. Nie wiem, jakie będą konsekwencje dla bezpieczeństwa, utrzymania systemów, audytów czy odpowiedzialności za decyzje podejmowane przez agentów. Wiem natomiast jedno - przez ostatnie trzydzieści lat, gdy system zachowywał się nieprawidłowo, pytałem:

„W którym miejscu kodu jest błąd?”

Kilka dni temu po raz pierwszy zadałem inne pytanie:

„Dlaczego tak postanowiłaś?”

I mam przeczucie, że w nadchodzących latach coraz więcej informatyków będzie zadawać właśnie to drugie pytanie.