Wzorzec ReAct (Reasoning + Acting)

1. Przegląd koncepcji i problem systemowy

Przed pojawieniem się koncepcji ReAct (opublikowanej przez badaczy z Princeton University oraz Google Research w 2022 roku) w społeczności istniał podział na dwa podejścia do automatyzacji LLM:

1. Chain-of-Thought (Tylko myślenie): Model generuje długie łańcuchy rozumowania, ale nie ma dostępu do świata zewnętrznego. W rezultacie logika wnioskowania wydaje się przekonująca, lecz opiera się na wymyślonych faktach i przestarzałych danych.
2. Act-Only (Tylko działanie): Model wywołuje API lub wykonuje komendy bash bez pośredniej autorefleksji. Prowadzi to do chaotycznych powtórzeń, ślepego przeszukiwania parametrów oraz braku zdolności rozwiązania nawet prostych wieloetapowych zadań.

Wzorzec ReAct (Reasoning + Acting) połączył te dwie siły w jeden iteracyjny cykl: model najpierw werbalizuje swoje myśli i planuje kolejny krok, następnie wykonuje celowe działanie, analizuje faktyczny wynik środowiska (Observation) i dopiero wtedy podejmuje następną decyzję.

2. Taksonomia architektoniczna i model mentalny

Klasyczny krok cyklu ReAct składa się z trzech sekwencyjnych stanów:

• 1. Thought (Wewnętrzne rozumowanie): Agent analizuje bieżący stan zadania, wysuwa hipotezę i formułuje konkretne zamierzenie: „Muszę sprawdzić, czy usługa Redis działa na porcie 6379, zanim uruchomię testy”. Ten etap krytycznie zmniejsza prawdopodobieństwo błędów w argumentach narzędzi.
• 2. Action (Wywołanie działania / narzędzia): Agent formułuje konkretną akcję ze sztywnymi parametrami: nazwę funkcji oraz poprawny obiekt JSON (np. execute_bash(command="systemctl status redis")).
• 3. Observation (Obserwacja środowiska): Zewnętrzny runtime przechwytuje akcję, wykonuje ją na serwerze lub w bazie danych i zwraca surowy tekst wyjściowy albo kod błędu z powrotem do kontekstu agenta.
• 4. Finish / Final Answer (Stan końcowy): Gdy agent widzi w ostatnim Observation, że cel został osiągnięty, zatrzymuje cykl i formułuje ostateczną odpowiedź dla użytkownika.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia agenta ReAct w środowisku programistycznym:

1. Context & Scratchpad Injection (Przygotowanie promptu): Do promptu systemowego wbudowuje się zasady interakcji, opisy dostępnych narzędzi oraz historię poprzednich iteracji bieżącej sesji (Scratchpad).
2. Inference with Tool Delimiter (Generowanie rozumowania i intencji): LLM generuje tokeny sekcji Thought. Gdy tylko model dochodzi do wywołania narzędzia, generowanie jest wstrzymywane przez klienta, a argumenty wywołania są walidowane.
3. Execution & Observation Feedback (Wykonanie w środowisku): Orkiestrator przekazuje komendę właściwemu podsystemowi (lokalnemu terminalowi, bazie danych lub przeglądarce), odczytuje wyjście, ogranicza jego długość w celu oszczędności tokenów i dodaje komunikat Observation: ... do kontekstu.
4. Loop Progression & Termination Check (Sprawdzenie warunków wyjścia): Jeśli agent osiągnął cel lub limit licznika max_iterations = 10, cykl zostaje przerwany. W przeciwnym razie rozpoczyna się kolejna iteracja z nowym blokiem Thought.

4. Praktyczne scenariusze inżynierskie w produkcji

01. Interaktywna diagnostyka i naprawa infrastruktury serwerowej

• Thought: Usługa zwraca błąd 502. Najpierw sprawdzę logi Nginx z ostatnich 5 minut.
• Action: read_logs(service="nginx", lines=20)
• Observation: connect() failed (111: Connection refused) while connecting to upstream 127.0.0.1:3000
• Thought: Upstream na porcie 3000 padł. Muszę sprawdzić status procesu Node.js za pomocą PM2.
• Action: execute_cmd(command="pm2 status")
• Observation: app-server: errored (out of memory)
• Thought: Usługa padła z powodu braku pamięci. Uruchomię ją ponownie z większym limitem heap.

02. Iteracyjne wyszukiwanie w dokumentacji i API

Agent próbuje wywołać zewnętrzny serwis Stripe. Na pierwszym kroku otrzymuje błąd invalid_api_key. Dzięki bloku Thought agent przypomina sobie, że tryb testowy wymaga prefiksu sk_test_, pobiera prawidłową zmienną środowiskową i przy drugiej próbie pomyślnie tworzy zamiar płatności.

03. Krokowe debugowanie testów jednostkowych

Agent kodowy widzi awarię testu spowodowaną rozbieżnością oczekiwanej wartości. Wysuwa hipotezę, wprowadza minimalną zmianę w jednym wierszu, ponownie uruchamia test, widzi zielony wynik i dopiero wtedy raportuje wykonanie zadania.

5. Pułapki, typowe błędy i bezpieczeństwo

• Zapętlenie na błędnej hipotezie (Self-Reinforcing Delusion): Jeśli na pierwszym kroku model wyciągnął błędny wniosek, ma tendencję do interpretowania wszystkich kolejnych Observation jako potwierdzenia swojego błędu. Rozwiązanie: obowiązkowe dodanie kroku krytyki (Reflection) po 3 nieudanych działaniach z rzędu.
• Rozrost kontekstu przez surowe obserwacje: Komenda cat huge_file.json zwraca 50 000 tokenów „szumu”, wypierając prompt systemowy. Zawsze ograniczaj rozmiar zwracanej obserwacji Observation w runtime (np. do maksymalnie 2000 znaków).
• Wywoływanie nieistniejących narzędzi (Action Hallucination): Model próbuje wywołać narzędzie, które nie znajduje się na liście. Rozwiązanie: korzystanie z natywnego API Tool Calling zamiast surowego parsowania tekstu.