W pierwszym artykule tej serii rozłożyliśmy na czynniki pierwsze pojęcie inteligentnego agenta: systemu, który odbiera bodźce z otoczenia i podejmuje działania, żeby osiągnąć jakiś cel.
Teraz zrobimy krok głębiej: zobaczymy, jak taki agent jest zbudowany od środka.
- Jak wygląda klasyczna architektura agenta?
- Co oznacza słynne Perceive–Decide–Act?
- Czym jest model BDI (Belief–Desire–Intention)?
- Jakie wzorce projektowe przydają się przy budowaniu agentów?
To będzie jeszcze teoria, ale już bardzo blisko kodu.
Przypomnienie: czym jest agent, ale z perspektywy architektury
W ujęciu architektonicznym agent to nie tylko „jakiś mądry program”. To zestaw współpracujących ze sobą elementów:
- coś odbiera informacje ze świata (percepcja),
- coś przetwarza i podejmuje decyzje (logika, strategie, modele),
- coś wykonuje działania (efektory, akcje, wywołania funkcji).
Możemy to narysować jako prosty schemat:
Środowisko → [Percepcja] → [Decyzja] → [Działanie] → Środowisko
To właśnie pętla Perceive–Decide–Act (PDA).
Pętla Perceive–Decide–Act: serce agenta
Klasyczna architektura agenta opiera się na ciągłej pętli:
- Perceive (percepcja)
Agent zbiera dane:- wejście od użytkownika (tekst, kliknięcia),
- odczyty z sensorów (robot),
- dane z API lub bazy (systemy IT).
- Decide (decyzja)
Na podstawie tego, co „zobaczył”, agent:- ocenia sytuację,
- aktualizuje swój stan wewnętrzny,
- wybiera działanie.
- Act (działanie)
Agent:- odsyła odpowiedź użytkownikowi,
- wykonuje ruch (w grze, w robocie),
- wywołuje funkcję/API,
- modyfikuje środowisko.
W prostym pseudokodzie:
while True:
percept = perceive()
decision = decide(percept)
act(decision)Code language: Python (python)Brzmi banalnie, ale w środku tych trzech funkcji może dziać się naprawdę dużo magii.
Typy architektur agentów – małe przypomnienie
Zanim pójdziemy w model BDI i wzorce, warto zrozumieć, że pod hasłem „architektura agenta” kryje się kilka podejść (o tym było już w poprzednim artykule, ale tutaj warto przypomnieć).
Agenci reaktywni (reflex agents)
To najbardziej podstawowa architektura:
- brak stanu (prawie),
- brak planowania,
- proste reguły: „jeśli X, to Y”.
Przykład:
- jeśli temperatura > 25 → włącz klimatyzację,
- jeśli odległość od ściany < 10 cm → skręć w lewo.
Schemat:
def decide(percept):
if percept == "przeszkoda":
return "skrec_w_lewo"
else:
return "idz_prosto"Code language: Python (python)Plusy: prostota, szybkość.
Minusy: brak elastyczności, brak pamięci, brak wyższych celów.
Agenci ze stanem (stateful / model-based)
Kolejny poziom to agenci, którzy:
- pamiętają coś z przeszłości,
- mają prosty model świata (albo choćby pamięć odwiedzonych miejsc).
Schemat decyzyjny uwzględnia już nie tylko percepcję, ale i stan. To już podstawa do bardziej ciekawych architektur.
Agenci oparci na celu (goal-based)
Tu wchodzi ważna zmiana: agent ma jasno zdefiniowany cel.
Przykłady celów:
- dostań się do punktu (X, Y),
- zminimalizuj koszt,
- dotrzyj do celu w jak najmniejszej liczbie kroków.
Architektura musi zatem zawierać:
- reprezentację celu,
- mechanizm oceny, które działania przybliżają agenta do tego celu (planowanie).
Agenci oparci na użyteczności (utility-based)
Kolejny poziom: zamiast prostego „cel osiągnięty / nieosiągnięty”, agent potrafi ocenić korzystność różnych stanów.
- definiujemy funkcję użyteczności (utility function),
- agent wybiera działania maksymalizujące wartość tej funkcji.
Przykład:
- dla systemu rekomendacyjnego użyteczność = szansa, że użytkownik będzie zadowolony,
- dla robota użyteczność = kompromis między czasem trasy a zużyciem energii.
Agenci uczący się (learning agents)
Tutaj architektura rozszerza się o moduł uczenia:
- agent nie tylko działa według z góry ustalonych zasad,
- ale też aktualizuje swoje strategie na podstawie doświadczenia,
- np. wzmacnia dobre decyzje (nagrody), osłabia złe (kary).
To miejsce na takie rzeczy jak:
- Q-learning,
- deep reinforcement learning,
- adaptacyjne strategie sterowania.
Model BDI: Belief, Desire, Intention
Jednym z najciekawszych sposobów opisu architektury agenta jest model BDI.
- Beliefs (przekonania)
To, co agent uważa za prawdę o świecie.
Przykład: „drzwi do magazynu są zamknięte”, „użytkownik jest zalogowany”. - Desires (pragnienia)
Co agent chciałby osiągnąć.
Przykład: „dostarczyć paczkę”, „zminimalizować opóźnienia”. - Intentions (intencje)
Cele, które agent realnie realizuje w danym momencie.
Przykład: „aktualnie jadę do punktu A”, „aktualnie tworzę raport”.
Beliefs to wiedza, desires to potencjalne cele, intentions to wybrane, aktywne cele.
Przykład BDI w ludzkim wydaniu
Wyobraź sobie:
- Beliefs: „jest 7:45”, „mam spotkanie o 8:00 w biurze oddalonym o 15 minut drogi”.
- Desires: „nie spóźnić się”, „po drodze wziąć kawę”.
- Intention: „wyjść z domu teraz i jechać bez kawy”.
Agent (Ty) ma wiele możliwych pragnień, ale wybiera takie, które przy aktualnych przekonaniach mają sens.
BDI w architekturze
Model BDI często rozbija się na moduły:
- moduł aktualizacji przekonań (przetwarzanie percepcji),
- moduł generowania celów,
- moduł wybierania intencji (planowanie i wybór),
- moduł realizacji intencji (akcje, wykonanie planów).
Wzorce projektowe w architekturze agenta
To wszystko brzmi bardzo koncepcyjnie, więc zejdźmy poziom bliżej do programisty. Jakie konkretne wzorce warto znać, projektując agenta?
Event loop (pętla zdarzeń)
Klasyk:
- agent nasłuchuje zdarzeń (wejście użytkownika, wiadomości, zmiany stanu),
- dodaje je do kolejki,
- przetwarza jedno po drugim.
W Pythonie może to wyglądać tak:
while True:
event = pobierz_zdarzenie()
state = zaktualizuj_stan(event)
action = wybierz_akcje(state)
wykonaj_akcje(action)Code language: Python (python)To dobra baza do:
- agentów konwersacyjnych,
- botów systemowych,
- serwisów działających 24/7.
System reguł (rule engine)
Dla agentów reaktywnych i prostych decyzyjnych świetnie sprawdza się silnik reguł:
- zbiór zasad „jeśli warunek, to działanie”,
- możliwość dodawania reguł bez grzebania w głównym kodzie.
Przykład koncepcyjny:
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"Code language: Python (python)Planowanie (planner + actions)
Dla agentów opartych na celu przydaje się architektura:
- planner: moduł, który generuje plan (sekwencję kroków),
- actions: zestaw możliwych akcji, które agent umie wykonać.
Planowanie można robić:
- algorytmami grafowymi (BFS, A*),
- logiką (planner STRIPS),
- heurystycznie,
- albo z pomocą LLM (tam, gdzie używamy GPT jako „planisty”).
Blackboard / wspólny stan (przy wielu agentach)
W systemach multi-agentowych często pojawia się wzorzec:
- blackboard (tablica), czyli wspólne miejsce na informacje,
- agenci odczytują i zapisują dane na tej tablicy,
- to ułatwia koordynację i wymianę wiedzy.
To wstęp do bardziej zaawansowanych architektur, które będziemy omawiać przy multiagentach.
Jak to przełożyć na kod? Prosty szablon agenta
Poniżej bardzo uproszczony szablon architektury agenta w Pythonie, który łączy większość pojęć:
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)Code language: Python (python)To nadal wysoki poziom, ale pokazuje:
- percepcję,
- aktualizację przekonań,
- wybór celów,
- intencje,
- planowanie działania,
- wykonanie.
W kolejnych artykułach będziemy z tego robić żywe, działające przykłady.
Typowe błędy przy projektowaniu architektury agenta
Na koniec kilka rzeczy, na które warto uważać:
- Brak rozdzielenia warstw
Mieszanie percepcji, logiki i akcji w jednym wielkim „if-else” szybko kończy się spaghetti-kodem. - Brak stanu lub nadmiar stanu
Albo agent niczego nie pamięta, albo pamięta wszystko i tonie w chaosie.
Dobry projekt to przemyślany, świadomy stan. - Brak pojęcia celu
Agent, który „tylko reaguje”, często robi za mało.
Dodanie jawnych celów i intencji mocno porządkuje architekturę. - Brak miejsca na rozwój
Jeśli w kodzie nie ma wyraźnie wydzielonych punktów na:- nowych agentów,
- nowe akcje,
- nowe źródła danych,
To rozbudowa systemu będzie bolała.
Podsumowanie
Architektura agenta AI to coś więcej niż „pętla z ifami”. To:
- Perceive–Decide–Act jako podstawowy wzorzec działania,
- różne poziomy złożoności: od prostego reagowania po planowanie i uczenie,
- modele takie jak BDI, które pomagają myśleć o agencie jak o „systemie z przekonaniami i intencjami”,
- konkretne wzorce projektowe: event loop, systemy reguł, planery, blackboard.
Dzięki temu w kolejnych artykułach będziemy mogli przejść do praktyki:
- w artykule 3 zbudujemy prostego agenta eksplorującego środowisko w Pythonie,
- a potem zaczniemy dodawać mu pamięć, uczenie i integrację z LLM.
