Poza prosty prompt: Czym jest Agentic Workflow i dlaczego rewolucjonizuje pracę z LLM

Większość zespołów inżynierskich zaczyna przygodę z LLM od klasycznego wzorca: przygotowanie promptu, wstrzyknięcie kontekstu (często przez RAG) i oczekiwanie na poprawną odpowiedź w pojedynczym wywołaniu API. Przez długi czas optymalizacja tego procesu sprowadzała się do zaawansowanego Prompt Engineeringu lub fine-tuningu. W pewnym momencie natrafiamy jednak na twardy sufit inżynieryjny: model gubi wątek w skomplikowanej logice, halucynuje fakty lub nie radzi sobie z zadaniami wymagającymi planowania strategicznego.

Rozwiązaniem tego problemu nie jest kolejny, 2000-tokenowy system prompt z listą 50 reguł brzegowych. Prawdziwy przełom w architekturze systemów AI przynosi Agentic Workflow — podejście, które odchodzi od traktowania modelu jako wyroczni zwracającej wynik w jednym przebiegu, a czyni z niego procesor sterujący iteracyjną pętlą wykonawczą.

Anatomia problemu: Dlaczego pojedynczy prompt zawodzi?

Modele językowe generują tekst autoregresyjnie: token po tokenie, na podstawie prawdopodobieństwa warunkowego. Gdy wysyłamy pojedyncze zapytanie (ang. zero-shot lub few-shot), zmuszamy LLM do przejścia od problemu do ostatecznego rozwiązania w ramach jednego nieprzerwanego ciągu predykcji. Jeśli model popełni błąd logiczny na etapie generowania trzeciego zdania, każdy kolejny token będzie próbował uzasadnić ten błędny stan. LLM nie ma w tym trybie wbudowanego mechanizmu cofania się, weryfikacji faktów ani uruchomienia kompilatora.

Andrew Ng wielokrotnie podkreślał obserwację, która zmieniła wektor rozwoju branży: słabszy model (np. GPT-3.5) działający w iteracyjnym workflow agentowym potrafi osiągnąć lepsze rezultaty w złożonych benchmarkach kodowania niż potężniejszy GPT-4 odpytywany pojedynczym promptem. Dzieje się tak, ponieważ workflow pozwala na rozbicie problemu, weryfikację założeń i korektę kursu.

Pętla wnioskowania i wzorzec ReAct

Fundamentem Agentic Workflow jest pętla wnioskowania (ang. reasoning loop). Zamiast bezpośrednio generować odpowiedź końcową, model wchodzi w cykl analizy sytuacji, podejmowania decyzji i interpretacji wyników. Najpopularniejszą realizacją tej idei jest wzorzec ReAct (Reasoning + Acting), wprowadzony przez Yao i zespół w 2022 roku.

Wzorzec ReAct strukturyzuje interakcję modelu w trzy powtarzalne fazy:

1. Thought (Myśl): Model formułuje wewnętrzną hipotezę lub plan kolejnego kroku na podstawie dotychczasowej historii.
2. Action (Akcja): Model decyduje się na wywołanie konkretnego narzędzia z zadanymi parametrami (np. zapytanie SQL, kalkulator, wyszukiwarka wewnętrzna).
3. Observation (Obserwacja): Środowisko wykonawcze zwraca wynik akcji do kontekstu modelu, zamykając jeden cykl pętli.

Poniższy fragment kodu w Pythonie ilustruje minimalistyczną, koncepcyjną implementację pętli agentowej. Zwróć uwagę, jak odpowiedź modelu decyduje o przerwaniu pętli lub kontynuacji pracy z nowymi obserwacjami.

def run_agentic_loop(client, system_prompt: str, user_task: str, tools: dict, max_iterations: int = 5) -> str:
    messages = [
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_task}
    ]

    for iteration in range(max_iterations):
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=[tool["definition"] for tool in tools.values()],
            tool_choice="auto"
        )
        message = response.choices[0].message
        messages.append(message)

        # Jeśli model nie potrzebuje dalszych narzędzi, zwraca odpowiedź końcową
        if not message.tool_calls:
            return message.content

        # Wykonanie żądanych akcji i dopisanie wyników jako 'tool' role
        for tool_call in message.tool_calls:
            tool_name = tool_call.function.name
            tool_args = json.loads(tool_call.function.arguments)
            tool_output = tools[tool_name]["func"](**tool_args)
            
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": str(tool_output)
            })

    raise TimeoutError("Agent przekroczył maksymalną liczbę iteracji bez rozwiązania zadania.")

Kluczowe wzorce Agentic Workflows

Pętla ReAct to zaledwie punkt wyjścia. W nowoczesnych architekturach korporacyjnych korzysta się z wyspecjalizowanych wzorców, które rozwiązują konkretne klasy problemów logicznych i optymalizacyjnych.

1. Reflection i Self-Correction

Wzorzec refleksji oddziela rolę twórcy (Generator) od roli krytyka (Evaluator). Po wygenerowaniu wstępnego artefaktu — np. kodu w Pythonie lub skryptu migracji SQL — model (lub ten sam model w osobnym kontekście) ocenia go pod kątem zgodności z wymaganiami technicznymi, bezpieczeństwa czy wydajności. Jeśli recenzja wykaże braki, model sam sobie generuje listę poprawek i nanosi je w kolejnym przebiegu.

2. Plan-and-Solve (Dekompozycja zadania)

Zamiast podejmować decyzje ad-hoc w każdym kroku, agent w pierwszej fazie tworzy jawny graf lub listę podzadań. Dopiero po zatwierdzeniu planu przechodzi do ich sekwencyjnego lub równoległego wykonywania. Każde podzadanie ma wąski kontekst, co drastycznie redukuje tzw. attention drift — zjawisko, w którym model zapomina o wytycznych z początku promptu pod wpływem rosnącej liczby tokenów.

Architektoniczne trade-offy: Kiedy NIE stosować workflow agentowego?

Jako architekci musimy unikać pułapki nadmiernej komplikacji (over-engineering). Agentic Workflow nie jest darmowym ulepszeniem — wprowadza zupełnie inny profil kosztowy i operacyjny systemu, który należy wkalkulować w SLA.

Kiedy zatem warto ponieść te koszty, a kiedy pozostać przy klasycznym podejściu?

• Pozostań przy prostym wywołaniu / RAG: Tłumaczenia, klasyfikacja tekstu, ekstrakcja prostych encji, streszczenia, FAQ oparty o wyszukiwanie semantyczne bez skomplikowanego łączenia danych.
• Wdróż Agentic Workflow: Generowanie i debugowanie kodu, automatyzacja audytów bezpieczeństwa, analityka danych z dynamicznym pisaniem zapytań SQL, agregacja danych z wielu niejednolitych API wymagająca decyzji warunkowych.

Podsumowanie

Przejście od prostych promptów do Agentic Workflows to fundamentalna zmiana paradygmatu: od traktowania LLM jak pasywnego kalkulatora statystycznego do wykorzystania go jako silnika decyzyjnego w kontrolowanym środowisku programistycznym. Narzucenie dyscypliny w postaci pętli wnioskowania, jawnych narzędzi i etapów samokorekty pozwala przekroczyć ograniczenia samej architektury Transformerów bez konieczności kosztownego trenowania własnych modeli.

W kolejnym artykule z tej serii przyjrzymy się, jak te koncepcje przekładają się na architekturę systemów wieloagentowych (Multi-Agent Systems) i w jaki sposób skoordynować pracę wielu wyspecjalizowanych modeli operujących na wspólnym stanie.