Architektura agenta AI pod lupą: Od pętli PDA do modelu BDI i wzorców projektowych

W pierwszym artykule tej serii rozłożyliśmy na czynniki pierwsze koncepcję inteligentnego agenta jako systemu, który wchodzi w interakcję z otoczeniem, aby osiągnąć określony cel. Czas zejść poziom głębiej i przyjrzeć się jego wewnętrznej architekturze. Zamiast traktować agenta jak czarną skrzynkę, zobaczymy, jak przełożyć teorię na konkretne komponenty i strukturę kodu.

Przejdziemy przez klasyczną pętlę działania, przyjrzymy się modelowi BDI (Belief-Desire-Intention) oraz omówimy wzorce projektowe, które ratują programistów przed utonięciem w spaghetti-kodzie. To wciąż solidna dawka inżynieryjnej teorii, ale osadzona bardzo blisko praktyki.

Serce systemu, czyli pętla Perceive–Decide–Act (PDA)

W ujęciu architektonicznym agent to nie magiczny, monolityczny algorytm, ale system ściśle współpracujących komponentów. Jego fundamentem jest nieustannie działająca pętla Perceive-Decide-Act (PDA), która definiuje sposób interakcji z otoczeniem.

• Perceive (Percepcja): Odbieranie bodźców z otoczenia. Mogą to być zapytania od użytkownika (tekst, kliknięcia), odczyty z sensorów fizycznych lub dane spływające z zewnętrznych API.
• Decyzje (Decide): Przetwarzanie zebranych informacji, analiza stanu i wybór optymalnego działania na podstawie zaimplementowanej logiki, reguł lub modeli.
• Działanie (Act): Wykonanie wybranej akcji za pomocą efektorów, wywołań funkcji czy operacji na zewnętrznych systemach.

W najprostszej postaci, w kodzie sprowadza się to do nieskończonej pętli:

while True:
    percept = perceive()
    decision = decide(percept)
    act(decision)

Choć ten pseudokod wygląda banalnie, diabeł tkwi w szczegółach implementacji każdej z tych trzech funkcji. Wewnątrz nich może dziać się naprawdę dużo magii.

Ewolucja architektur: Od odruchu do nauki

W zależności od stopnia skomplikowania zadań, architektura agenta może przybierać różne formy. Warto znać te klasy systemów, aby dobrać odpowiednie narzędzie do problemu.

Agenci reaktywni (Simple Reflex Agents)

To najprostsza możliwa architektura, działająca na zasadzie bezpośredniego bodźca i reakcji. Agent nie utrzymuje stanu ani nie planuje przyszłości – opiera się wyłącznie na sztywnych regułach typu "jeśli X, to Y".

• jeśli temperatura > 25 → włącz klimatyzację,
• jeśli odległość od ściany < 10 cm → skręć w lewo.

def decide(percept):
    if percept == "przeszkoda":
        return "skrec_w_lewo"
    else:
        return "idz_prosto"

Zaletą tego podejścia jest ekstremalna szybkość i prostota działania. Wadą – całkowity brak elastyczności, brak pamięci oraz niemożność realizacji wyższych celów.

Agenci ze stanem (Stateful / Model-Based)

Krok wyżej stoją agenci, którzy potrafią przechowywać informacje o przeszłości. Posiadają oni wewnętrzny model świata, który pozwala im śledzić zmiany, nawet gdy dany element otoczenia nie jest w tym momencie bezpośrednio widoczny (np. robot pamięta, które obszary już odwiedził). Decyzja zależy tu zarówno od bieżącej percepcji, jak i od zapisanego stanu.

Agenci oparci na celu (Goal-Based)

W tej architekturze agent nie tylko reaguje na stan środowiska, ale dąży do konkretnego, zdefiniowanego celu. Przykłady celów to dotarcie do punktu (X, Y) czy zminimalizowanie kosztów operacji. System musi posiadać reprezentację tego celu oraz mechanizm planowania, który ocenia, które sekwencje akcji przybliżają go do sukcesu.

Agenci oparci na użyteczności (Utility-Based)

Gdy cel można osiągnąć na wiele sposobów, sam podział na "cel osiągnięty / nieosiągnięty" nie wystarcza. Agenci ci korzystają z funkcji użyteczności (utility function), która ocenia "jakość" lub "koszt" poszczególnych stanów. Agent dąży do maksymalizacji tej wartości – na przykład balansując między czasem dostawy a zużyciem energii przez drona, czy też maksymalizując szansę na zadowolenie użytkownika w systemie rekomendacyjnym.

Agenci uczący się (Learning Agents)

Najbardziej zaawansowana grupa, która potrafi samodzielnie modyfikować swoje zachowanie na podstawie zebranych doświadczeń. Architektura ta zawiera dedykowany moduł uczenia się, który analizuje sukcesy i porażki i na tej podstawie aktualizuje strategię działania (np. poprzez mechanizm nagród i kar). To idealne miejsce na zastosowanie algorytmów takich jak Q-learning, deep reinforcement learning czy adaptacyjnych strategii sterowania.

Model BDI: Belief, Desire, Intention

Jednym z najbardziej eleganckich i sprawdzonych podejść do modelowania zachowań agentowych jest architektura BDI (Belief-Desire-Intention). Opiera się ona na filozoficznej koncepcji ludzkiego działania i świetnie porządkuje architekturę systemów AI:

• Beliefs (Przekonania): To wewnętrzna wiedza agenta o świecie i samym sobie. Są to fakty, które agent uważa za prawdziwe (np. "drzwi do magazynu są zamknięte", "użytkownik jest zalogowany").
• Desires (Pragnienia): Wszystkie potencjalne cele, które agent chciałby lub mógłby zrealizować (np. "dostarczyć paczkę", "zminimalizować opóźnienia"). Często pragnienia mogą być ze sobą sprzeczne.
• Intentions (Intencje): Konkretne pragnienia, które agent zdecydował się aktywnie realizować w danym momencie. To cele przełożone na konkretny plan działania (np. "aktualnie jadę do punktu A", "aktualnie generuję raport").

Przykład BDI w ludzkim wydaniu

Wyobraź sobie prosty scenariusz z życia wzięty:

• Beliefs: Jest godzina 7:45. O 8:00 mam ważne spotkanie w biurze oddalonym o 15 minut drogi.
• Desires: Chcę dotrzeć na spotkanie na czas. Chcę też po drodze kupić ciepłą kawę (co zajmie dodatkowe 10 minut).
• Intention: Ponieważ moje przekonania (brak czasu) wykluczają realizację obu pragnień, wybieram to o wyższym priorytecie: rezygnuję z kawy i natychmiast wychodzę z domu.

W architekturze oprogramowania model BDI implementuje się poprzez podział na moduły odpowiedzialne za aktualizację przekonań (przetwarzanie percepcji), generowanie celów, selekcję intencji (planowanie) oraz ich fizyczne wykonanie.

Wzorce projektowe w architekturze agenta

Jak przełożyć te koncepcje na czysty kod? W praktyce inżynierskiej najczęściej stosuje się cztery sprawdzone wzorce projektowe:

Event Loop (Pętla zdarzeń)

To idealne rozwiązanie dla agentów konwersacyjnych, botów czy systemów działających w trybie ciągłym (24/7). Agent nasłuchuje zdarzeń, kolejkuje je i przetwarza asynchronicznie.

while True:
    event = pobierz_zdarzenie()
    state = zaktualizuj_stan(event)
    action = wybierz_akcje(state)
    wykonaj_akcje(action)

Silnik reguł (Rule Engine)

Świetnie sprawdza się w systemach reaktywnych. Pozwala odseparować logikę biznesową (reguły) od samego silnika wykonawczego, co ułatwia późniejsze modyfikacje systemu bez dotykania rdzenia aplikacji.

rules = [
    {"if": lambda s: s["temperatura"] > 25, "then": "wlacz_klime"},
    {"if": lambda s: s["bateria"] < 10, "then": "idz_do_ladowarki"},
]

def decide(state):
    for rule in rules:
        if rule["if"](state):
            return rule["then"]
    return "nic_nie_rob"

Planer i akcje (Planner + Actions)

Wzorce dedykowane dla agentów zorientowanych na cel. Wydzielamy osobny moduł planisty (Planner), który na podstawie celu i stanu wiedzy generuje sekwencję kroków, oraz zestaw atomowych akcji (Actions), które agent potrafi fizycznie wykonać. Planowanie może opierać się na klasycznych algorytmach grafowych (np. A*), logice formalnej (STRIPS) lub wywołaniach modeli LLM, gdzie GPT służy jako główny planista.

Tablica (Blackboard Pattern)

Kluczowy wzorzec w systemach wieloagentowych (multi-agent). Agentów integruje się wokół wspólnej przestrzeni pamięci dzielonej (tablicy). Agenci mogą niezależnie odczytywać z niej dane, przetwarzać je i zapisywać wyniki, co drastycznie upraszcza komunikację i koordynację pracy w zespole.

Szablon agenta w Pythonie

Poniższy kod to uproszczony, ale kompletny architektonicznie szablon agenta BDI w Pythonie. Pokazuje on, jak połączyć percepcję, aktualizację wiedzy, deliberację (wybór celów i intencji) oraz planowanie akcji w spójną całość.

class Agent:
    def __init__(self, initial_beliefs=None):
        self.beliefs = initial_beliefs or {}
        self.goals = []
        self.intentions = []

    def perceive(self, environment):
        percept = environment.get_state()
        self.update_beliefs(percept)

    def update_beliefs(self, percept):
        # aktualizacja wiedzy o świecie
        self.beliefs.update(percept)

    def deliberate(self):
        # wybór celów i intencji – tu może być logika BDI
        self.goals = self.generate_goals(self.beliefs)
        self.intentions = self.filter_goals(self.goals)

    def decide(self):
        # wybór konkretnej akcji na podstawie intencji
        if not self.intentions:
            return None
        return self.plan_action(self.intentions[0])

    def act(self, action, environment):
        if action:
            environment.apply_action(action)

    def step(self, environment):
        self.perceive(environment)
        self.deliberate()
        action = self.decide()
        self.act(action, environment)

Ten szkielet stanowi doskonały punkt wyjścia do budowy bardziej zaawansowanych systemów, które w kolejnych krokach wyposażymy w pamięć długotrwałą czy integrację z modelami językowymi.

Najczęstsze grzechy przy projektowaniu agentów

Podczas implementacji systemów agentowych łatwo wpaść w architektoniczne pułapki. Oto cztery najpopularniejsze błędy, na które musisz uważać:

• Brak separacji warstw: Łączenie kodu odpowiedzialnego za pobieranie danych (percepcję), logikę decyzyjną oraz fizyczne wykonywanie akcji w jednej, gigantycznej strukturze `if-else`. Taki kod błyskawicznie staje się nieutrzymywalny.
• Złe zarządzanie stanem: Skrajności są groźne. Agent bezstanowy nie potrafi realizować złożonych zadań, z kolei agent, który przechowuje zbyt wiele nieprzefiltrowanych informacji, szybko "tonie" w szumie informacyjnym. Stan musi być projektowany świadomie.
• Ignorowanie koncepcji celu: Próba zmuszenia agenta reaktywnego do wykonywania złożonych, wieloetapowych zadań. Bez jawnej reprezentacji celu i intencji system szybko utknie w pętli bezużytecznych akcji.
• Brak modularności: Projektowanie systemu w sposób uniemożliwiający łatwe dodawanie nowych akcji, sensorów czy integracji z nowymi źródłami danych bez głębokiej modyfikacji istniejącego kodu.

Podsumowanie

Dobrze zaprojektowana architektura to klucz do stabilnego i skalowalnego systemu agentowego. Pętla Perceive-Decide-Act daje nam ramy działania, modele takie jak BDI pozwalają ustrukturyzować procesy myślowe maszyny, a sprawdzone wzorce projektowe (takie jak Event Loop czy Blackboard) ułatwiają czystą implementację w kodzie.

W kolejnym artykule przejdziemy od teorii do praktyki – napiszemy w Pythonie od zera naszego pierwszego, w pełni działającego agenta eksplorującego środowisko, a następnie krok po kroku dodamy mu pamięć oraz integrację z LLM.