Multi-agent AI — kiedy jeden agent to za mało i jak budować systemy wieloagentowe

Piątek, 14:32. Bartosz, handlowiec w firmie dystrybucyjnej, uruchamia agenta AI z poleceniem: "przygotuj raport sprzedażowy za Q1, wyciągnij anomalie, napisz rekomendacje i wyślij do zarządu do piątku". Agent potwierdza zadanie i zaczyna pracę.

O 15:17 Bartosz sprawdza status. Agent przetwarza dane. O 16:00 — nadal przetwarza. O 16:45, tuż przed końcem pracy, Bartosz zagląda jeszcze raz. Agent wciąż "analizuje Q1". Nie wysłał nic. Nie podjął decyzji o formacie. Nie wygenerował rekomendacji. Utknął w pętli przetwarzania pierwszej warstwy danych i nie był w stanie przejść dalej.

To nie błąd modelu. To błąd architektury. Bartosz dał jednemu agentowi zadanie, które wymaga czterech.

Trzy symptomy że potrzebujesz więcej niż jednego agenta

Zanim powiem czym jest system wieloagentowy, pokażę jak go rozpoznać, że potrzebujesz. W swojej pracy widzę trzy wyraźne sygnały, po których diagnozuję problem.

Symptom 1: Agent "myśli za długo" i wpada w pętle

Jeden agent z nieograniczonym kontekstem i zadaniem złożonym z czterech logicznie oddzielnych faz będzie próbował trzymać cały stan w pamięci roboczej jednocześnie. To jak prosić jedną osobę żeby w tej samej chwili zbierała dane, je analizowała, pisała tekst i formatowała PDF. Efekt: nie kończy żadnego z kroków, bo każdy krok wymaga innego trybu przetwarzania.

W praktyce objawia się to jako: agent długo "myśli", nie generuje żadnych pośrednich outputów, a po przekroczeniu limitu czasu lub tokenów po prostu zatrzymuje się bez rezultatu.

Symptom 2: Zadanie wymaga równoległego przetwarzania

Masz raport, który składa się z pięciu sekcji branżowych. Dane dla każdej sekcji pochodzą z osobnego źródła. Przetworzone sekwencyjnie — 5 × 8 minut = 40 minut. Przetworzone równolegle przez 5 agentów — 8 minut. Jeden agent nie może wykonywać prawdziwego parallelu. Potrzebujesz systemu, który rozdziela pracę i scala wyniki.

Symptom 3: Różne etapy wymagają różnej specjalizacji

Zbieranie danych z API to zupełnie inna specjalizacja niż analiza statystyczna, pisanie narracji biznesowej i formatowanie dokumentu. Próba umieszczenia tych czterech ról w jednym prompcie systemu kończy się kompromisem — agent nie jest świetny w żadnej z tych ról, bo żadna nie dostaje pełnego kontekstu i instrukcji.

Specjalizacja nie jest tylko kwestią promptów. Chodzi o różne narzędzia (tools), różne uprawnienia do API, różne ograniczenia i różne kryteria sukcesu dla każdej fazy.

Co to jest system wieloagentowy — w jednym zdaniu

System wieloagentowy to architektura, w której wiele wyspecjalizowanych agentów AI współpracuje pod kontrolą koordynatora (supervisora), każdy odpowiadając za konkretny fragment zadania, przekazując sobie wyniki w określonym przepływie.

Kluczowe słowa: *wyspecjalizowanych*, *koordynatora*, *konkretny fragment*, *przepływ*. To nie jest "więcej ChatGPTów w jednym oknie". To inżynieria procesów.

Trzy topologie systemów wieloagentowych

Zanim zaczniesz pisać kod, musisz wybrać topologię. Każda ma swoje przypadki użycia i swoje wady.

Sequential (A→B→C→D) — pipeline

Każdy agent dostaje output poprzedniego jako input. Agent A kończy → wynik trafia do B → B kończy → wynik trafia do C. Klasyczny pipeline dokumentów.

Kiedy używać: Gdy każdy etap logicznie zależy od poprzedniego i nie można ich wykonać równolegle. Przykład: scraping danych → czyszczenie → analiza → raport. Nie możesz pisać raportu bez danych. Nie możesz analizować nieczystych danych.

Wady: Czas wykonania to suma czasów wszystkich agentów. Błąd w środku pipeline'u zatrzymuje wszystko. Wymaga solidnej obsługi błędów na każdym przejściu.

Parallel (Supervisor → [A, B, C] → merge) — fan-out/fan-in

Supervisor rozdziela zadanie na N równoległych podzadań, uruchamia N agentów jednocześnie, czeka na wszystkie wyniki, scala je w jeden output.

Kiedy używać: Gdy masz N niezależnych od siebie podzadań tego samego typu. Analiza 5 rynków jednocześnie. Tłumaczenie dokumentu na 4 języki równolegle. Zbieranie danych z 6 źródeł API naraz.

Wady: Supervisor musi umieć scalić wyniki o różnej strukturze i jakości. Jeden wolny agent blokuje cały merge (problem "najwolniejszego"). Wymaga idempotentności — jeśli agent się zawiesi, musi dać się uruchomić ponownie.

Hierarchical (Supervisor → [Menedżer1, Menedżer2] → Workers) — drzewo

Supervisor deleguje do menedżerów domenowych, każdy menedżer zarządza własnym zespołem workerów. Struktura korporacyjna przeniesiona na agentów.

Kiedy używać: Złożone projekty z wyraźnymi domenami. Kampania marketingowa: Supervisor → [Menedżer Treści, Menedżer Dystrybucji] → [Copywriter, Designer, Social, Email, Paid]. Każda domena ma swoją logikę i narzędzia.

Wady: Najwyższy overhead komunikacji. Najtrudniejsze do debugowania. Używaj tylko gdy naprawdę potrzebujesz — gdy jedno drzewo sekwencyjne lub paralel nie wystarczy.

Supervisor Agent Pattern — serce każdego systemu

Bez względu na topologię, każdy system wieloagentowy ma supervisora. To najważniejszy agent w całym systemie i najczęściej niedoceniany na etapie projektowania.

Jak supervisor decyduje o delegacji

Supervisor dostaje na wejściu: opis zadania, stan bieżący (co już zostało zrobione), listę dostępnych agentów z ich specjalizacjami i dostępnością. Na wyjściu musi zwrócić: który agent wywołać, z jakim inputem, w jakiej kolejności lub równolegle.

Dobry supervisor nie decyduje na podstawie słów kluczowych — decyduje na podstawie stanu. "Dane zebrane? → idź do analityka. Analiza gotowa? → idź do copywritera. Wszystko gotowe? → idź do wysyłającego." To maszyna stanów, nie chatbot.

Jak obsługuje błędy agentów

Każdy worker agent może się zawieść: przekroczyć limit tokenów, dostać błąd API, zwrócić output niezgodny ze schematem. Supervisor musi zaimplementować strategię retry: ile razy powtórzyć, z jakim cooldownem, co jeśli max_retries wyczerpane — escalacja do człowieka czy skip tego kroku?

Brak strategii obsługi błędów = system, który zawiesza się na produkcji bez jasnego komunikatu. Widziałem to zbyt wiele razy.

Jak scala wyniki

Scalanie wyników to osobny problem, często trudniejszy niż same obliczenia. Pięć agentów zwróciło pięć sekcji raportu o różnych długościach, stylach i formacie danych. Supervisor musi: zwalidować kompletność (czy każdy agent zwrócił wymagane pola?), ujednolicić format, rozwiązać konflikty (dwa agenty podały inne liczby dla tego samego wskaźnika) i złożyć finalny dokument.

Ten etap jest często pomijany w prototypach i "wyskakuje" na produkcji.

Przykład Python/LangGraph — Supervisor z 3 worker agentami

from langgraph.graph import StateGraph, ENDfrom langgraph.prebuilt import ToolNodefrom langchain_openai import ChatOpenAIfrom langchain_core.messages import HumanMessage, SystemMessagefrom typing import TypedDict, Annotated, Sequenceimport operatorimport json

# --- Stan systemu --- class AgentState(TypedDict): task: str research_output: str analysis_output: str final_report: str current_step: str error_count: int messages: Annotated[Sequence[dict], operator.add]

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# --- Agent 1: Research --- def research_agent(state: AgentState) -> AgentState: prompt = f"""Jestes agentem zbierajacym dane. Zadanie: {state['task']} Zbierz wszystkie niezbedne fakty, liczby i kontekst. Zwroc JSON: {{"findings": [...], "data_points": [...], "sources": [...]}}"""

response = llm.invoke([SystemMessage(content=prompt)]) return { **state, "research_output": response.content, "current_step": "research_done", "messages": [{"role": "research", "content": response.content}] }

# --- Agent 2: Analyst --- def analysis_agent(state: AgentState) -> AgentState: prompt = f"""Jestes agentem analitycznym. Dane z researchu: {state['research_output']} Wyciagnij anomalie, trendy i wnioski. Zwroc JSON: {{"anomalies": [...], "trends": [...], "recommendations": [...]}}"""

response = llm.invoke([SystemMessage(content=prompt)]) return { **state, "analysis_output": response.content, "current_step": "analysis_done", "messages": [{"role": "analyst", "content": response.content}] }

# --- Agent 3: Writer --- def writer_agent(state: AgentState) -> AgentState: prompt = f"""Jestes agentem piszacym raporty biznesowe. Research: {state['research_output']} Analiza: {state['analysis_output']} Napisz profesjonalny raport z sekcjami: Podsumowanie, Wyniki, Anomalie, Rekomendacje."""

response = llm.invoke([SystemMessage(content=prompt)]) return { **state, "final_report": response.content, "current_step": "report_done", "messages": [{"role": "writer", "content": response.content}] }

# --- Supervisor: decyduje o przeplywie --- def supervisor_router(state: AgentState) -> str: step = state.get("current_step", "start") errors = state.get("error_count", 0)

if errors >= 3: return "human_escalation" if step == "start": return "research" if step == "research_done": return "analysis" if step == "analysis_done": return "writer" if step == "report_done": return END return "research"

# --- Budowanie grafu --- workflow = StateGraph(AgentState) workflow.add_node("research", research_agent) workflow.add_node("analysis", analysis_agent) workflow.add_node("writer", writer_agent)

workflow.set_conditional_entry_point(supervisor_router) workflow.add_conditional_edges("research", supervisor_router) workflow.add_conditional_edges("analysis", supervisor_router) workflow.add_conditional_edges("writer", supervisor_router)

app = workflow.compile()

# --- Uruchomienie --- result = app.invoke({ "task": "Przygotuj raport sprzedazowy Q1 2026 dla dzialu zarządu", "research_output": "", "analysis_output": "", "final_report": "", "current_step": "start", "error_count": 0, "messages": [] })

print(result["final_report"])

Kilka kluczowych decyzji w tym kodzie:

AgentState jako single source of truth — cały stan systemu przepływa przez jeden obiekt TypedDict. Każdy agent czyta to co potrzebuje, zapisuje swój output, przekazuje dalej. Brak globalnych zmiennych, brak side effects.

supervisor_router jako maszyna stanów — supervisor nie generuje decyzji przez LLM za każdym razem (to byłoby kosztowne i niedeterministyczne). Decyduje na podstawie current_step — deterministycznie, szybko, tanio.

error_count z eskalacją — po 3 błędach system nie zapętla się nieskończenie, lecz eskaluje do człowieka. Zawsze.

Cztery realne przypadki wdrożeń z moich projektów

Przypadek 1: Pipeline generowania ofert handlowych

Klient: firma B2B, 15 handlowców, 30–50 zapytań ofertowych tygodniowo.

Architektura (4 agenty, sequential): - CRM Reader Agent — pobiera dane klienta z Salesforce, historię zakupów, segment, preferencje - Pricing Agent — na podstawie produktów z zapytania, marży, historii i segmentu kalkuluje cenę ofertową i rabaty - Copywriter Agent — pisze personalizowany tekst oferty z uwzględnieniem historii relacji i aktualnych potrzeb - PDF Generator Agent — formatuje do szablonu Word/PDF, dodaje logo, podpis handlowca, datę ważności

Czas przed wdrożeniem: 45–90 minut na ofertę. Czas po wdrożeniu: 4–7 minut (agent) + 10 minut (weryfikacja handlowca). Oszczędność: ~25 godzin tygodniowo na samym pisaniu ofert.

Przypadek 2: Automatyczny monitoring i raportowanie

Klient: sieć 12 sklepów stacjonarnych, codzienne raporty dla managementu.

Architektura (3 agenty, sequential z cron trigger o 6:00): - Data Collector Agent — odpytuje API POS systemu, Google Analytics, systemu magazynowego. Zbiera dane z poprzedniego dnia dla wszystkich 12 lokalizacji - Analyst Agent — porównuje z baseline (poprzedni tydzień, poprzedni rok), wykrywa anomalie: sklep z o >15% niższą sprzedażą, produkt z nagłym skokiem zwrotów, lokalizacja z brakami magazynowymi - Reporter Agent — generuje raport executive summary: 1 strona A4, bullet points, anomalie pogrubione, rekomendacje akcji do 10:00

Zarząd dostaje raport o 7:30. Zero pracy manualnej. Czas wdrożenia: 3 tygodnie. ROI: zwrot w 6 tygodniach.

Przypadek 3: Automatyzacja obsługi reklamacji

Klient: e-commerce, 60–120 reklamacji dziennie przez różne kanały.

Architektura (4 agenty, sequential z human-in-the-loop na etapie 3): - Classifier Agent — kategoryzuje reklamację: typ problemu (dostawa, jakość, płatność, zwrot), pilność, sentyment, wartość zamówienia - Empathy Responder Agent — generuje pierwszą odpowiedź: potwierdzenie przyjęcia, empatyczny ton, informacja o czasie rozwiązania. Wysyłana automatycznie w ciągu 90 sekund - Resolution Finder Agent — proponuje rozwiązanie: zwrot, wymiana, rabat, eskalacja. Dla decyzji powyżej 500 PLN — trafia do człowieka (human checkpoint) - Response Drafter Agent — pisze finalną odpowiedź z konkretną propozycją, linkami do formularzy, datą realizacji

Średni czas odpowiedzi przed: 18 godzin. Po: 90 sekund (empatyczna) + 4 godziny (rozwiązanie). CSAT +23 punkty w ciągu kwartału.

Przypadek 4: Content pipeline dla agencji

Klient: agencja contentowa, 40+ artykułów miesięcznie dla 8 klientów.

Architektura (4 agenty, sequential + równoległy etap 3): - Researcher Agent — research tematu: 10 źródeł, aktualne dane, cytaty, statystyki. Czas: 3 minuty - Writer Agent — pisze artykuł na podstawie researchu i briefu klienta (ton, keywords, długość, CTA). Czas: 4 minuty - SEO Optimizer Agent — sprawdza gęstość słów kluczowych, meta title, meta description, nagłówki, alt texty, linki wewnętrzne. Zwraca listę poprawek lub sugestię zatwierdzonego artykułu. Czas: 2 minuty - Publisher Agent — uploaduje do WordPress/Webflow, ustawia kategorię, tagi, featured image, scheduled publish date

Czas na artykuł przed: 3–5 godzin. Po: 15 minut (agenty) + 20 minut (redakcja człowieka). Throughput: z 40 do 90 artykułów miesięcznie tym samym zespołem.

Pięć błędów przy budowie systemów wieloagentowych

Błąd 1: Zbyt wiele agentów (microservice trap)

Tak jak w architekturze mikroserwisów możesz stworzyć 50 serwisów tam gdzie wystarczyłoby 5, tak przy agentach można wpaść w pułapkę granularności. Agent "tylko do normalizacji daty" albo agent "tylko do sprawdzania ortografii" — to absurd.

Zasada: każdy agent powinien być odpowiedzialny za logicznie kompletną fazę zadania, nie za jedną operację. Jeśli agent wykonuje jedną funkcję w jednej linii kodu — zastąp go wywołaniem funkcji, nie wywołaniem LLM.

Błąd 2: Brak obsługi błędów między agentami

Agent B dostał malformed JSON od agenta A i wyrzucił wyjątek. Supervisor nie ma procedury obsługi tego wyjątku. System wisi. Logi są puste, bo wyjątek nie był logowany. Nie wiesz co się stało.

Każde przejście między agentami musi mieć: walidację schematu outputu poprzedniego agenta, try/except z logowaniem, strategię retry, eskalację gdy retry się wyczerpie.

Błąd 3: Brak human-in-the-loop przy akcjach nieodwracalnych

Agent wysłał maila do 2000 klientów z błędną ceną. Agent usunął 500 rekordów z bazy. Agent przelał pieniądze na konto testowe zamiast produkcyjnego.

Akcje nieodwracalne — wysyłka emaila, modyfikacja bazy danych, transakcja finansowa, publiczne postowanie — zawsze wymagają human checkpoint. Nie "może" wymagają. Zawsze. Bez wyjątku.

Błąd 4: Nieskończone pętle (bez max_iterations)

Supervisor wywołał agenta A → agent A zwrócił błąd → supervisor ponowił → błąd → ponowił → błąd. Po 200 wywołaniach i 50 PLN tokenów system nadal "pracuje". Twój portfel OpenAI też.

Każdy agent i cały system musi mieć twardy limit: max_iterations, max_tokens, max_cost. Po przekroczeniu: zatrzymaj, zaloguj, eskaluj. Twardo. Bez możliwości pominięcia przez agenta.

Błąd 5: Brak logowania stanu między agentami

System wieloagentowy bez pełnego logowania stanu to czarna skrzynka. Gdy coś się posypie (a posypie się), nie masz pojęcia: który agent zawiódł, co miał na wejściu, co zwrócił, ile to trwało.

Loguj wszystko: timestamp wejścia i wyjścia każdego agenta, pełny input i output (lub jego hash dla dużych payloadów), status (success/retry/error), koszt tokenów per agent, total pipeline cost. Ten log to Twój debugger produkcyjny.

Kiedy NIE używać multi-agent

Uczciwa odpowiedź: większość zadań AI nie wymaga multi-agent. Jeśli twój usecase można opisać jako "wyślij prompt, dostań odpowiedź" — zostań przy jednym agencie. Multi-agent to narzędzie do konkretnych problemów, nie domyślna architektura.

Nie używaj multi-agent gdy: - Zadanie jest linearne i proste (pytanie → odpowiedź) - Masz mniej niż 200 uruchomień miesięcznie (overhead nie zwróci się) - Zespół nie ma doświadczenia z debugowaniem rozproszonych systemów - Nie masz monitoringu i alertowania produkcyjnego - Dane są zbyt wrażliwe, żeby przesyłać je między wieloma wywołaniami LLM - Czas wykonania nie ma znaczenia (sequential pipeline jest wolniejszy)

Zacznij od jednego agenta z dobrymi narzędziami (tools). Dopiero gdy trafisz na jeden z trzech symptomów z początku tego wpisu — projektuj multi-agent.

Najczęstsze pytania

---

Buduję systemy wieloagentowe na n8n i LangGraph — od prostych pipeline'ów po złożone systemy z supervisorem, loggingiem i human-in-the-loop. Napisz do mnie — jeśli masz zadanie, które przekracza możliwości jednego agenta, zaprojektujemy architekturę razem.