Architektura systemów multi-agent: role, orkiestracja, koszty

Systemy multi-agent przestały być ciekawostką badawczą – to realna architektura wykorzystywana w produkcji do analizy dokumentów, generowania raportów, planowania i automatyzacji procesów. W tym artykule pokazuję, jak projektuję takie systemy w praktyce: od doboru ról, przez orkiestrację i osiąganie konsensusu, po kontrolę kosztów. A na końcu – kiedy nie budować multi-agenta.

Role agentów: projektuj system, nie chór głosów

Największy błąd początkujących: kilka agentów z identycznym promptem, które wzajemnie komentują swoje odpowiedzi. To nie jest system multi-agent – to drogi, powolny czat. Dobry system zaczyna się od dekompozycji zadania na role o rozłącznych odpowiedzialnościach:

• Orchestrator – rozbija cel na kroki, decyduje, który agent działa kiedy i kiedy zakończyć pracę.
• Researcher – zbiera informacje: wyszukiwanie, dokumenty, API, bazy danych.
• Analyst / Planner – interpretuje dane, tworzy plan lub warianty rozwiązań.
• Executor / Coder – wykonuje konkretne akcje: pisze kod, wysyła zapytania, aktualizuje rekordy.
• Reviewer / Critic – weryfikuje wyniki innych agentów pod kątem poprawności, zgodności z wymaganiami i spójności.
• Summarizer – kompresuje kontekst między etapami, żeby nie przekroczyć okna kontekstu i nie płacić za niepotrzebne tokeny.

Kluczowa zasada: każda rola ma własny system prompt, własny zestaw narzędzi i własny budżet tokenów. Researcher nie powinien mieć prawa zapisu do bazy, a Executor nie powinien decydować o kryteriach akceptacji. To ogranicza powierzchnię błędów i ułatwia audyt.

Orkiestracja: przepływ, pętle i warunki stopu

Są trzy podstawowe wzorce orkiestracji, które stosuję:

1. Pipeline (sekwencyjny) – Researcher → Planner → Executor → Reviewer. Najprostszy, przewidywalny, łatwy do przetestowania. Dobry, gdy kroki są liniowe.
2. Gwiazda (hub-and-spoke) – Orchestrator rozmawia z wyspecjalizowanymi agentami i składa wyniki. Elastyczny, ale wymaga dobrego orchestratora i jasnych formatów wymiany danych.
3. Debata / konsensus – dwóch lub więcej agentów pracuje nad tym samym zadaniem, a mechanizm głosowania lub recenzji wybiera najlepszy wynik. Drogie, ale skuteczne przy zadaniach o wysokim ryzyku błędu, np. analizie medycznej czy prawnej.

Warunek stopu to najważniejszy element orkiestracji. Bez niego system potrafi zapętlić się na dziesiątki wywołań. Stosuję trzy zabezpieczenia równocześnie:

• maksymalną liczbę iteracji (np. 5 rund pracy);
• próg akceptacji – Reviewer musi jednoznacznie zaakceptować wynik (struktura { approved: boolean, reason: string });
• budżet tokenów na zadanie – po przekroczeniu limitu system kończy pracę najlepszym dostępnym wynikiem i oznacza go jako „niezweryfikowany“.

Pseudokod orchestratora, którego używam jako szkieletu:

async function runTask(goal: string, budget = { maxRounds: 5, maxTokens: 50_000 }) {
  let context = { goal, plan: null, result: null, rounds: 0 };
  while (context.rounds < budget.maxRounds) {
    context = await orchestrator.nextStep(context);
    if (context.approved) return { ok: true, result: context.result };
    if (context.tokensUsed > budget.maxTokens) {
      return { ok: false, reason: 'budget-exceeded', partial: context.result };
    }
    context.rounds += 1;
  }
  return { ok: false, reason: 'max-rounds', partial: context.result };
}

Consensus: kiedy pytać drugiego agenta

Konsensus ma sens tylko wtedy, gdy koszt błędu jest wysoki, a niezależne spojrzenie realnie coś wnosi. W praktyce:

• Reviewer z innym promptem niż autor – inny zestaw kryteriów, inna perspektywa. Jeśli Reviewer ma ten sam prompt co Executor, dostaniesz potwierdzenie, nie weryfikację.
• Niezależne wykonanie – wariant A i wariant B liczone osobno, porównywane przez trzeci agent. Kosztuje 3× więcej; używaj tylko dla krytycznych decyzji.
• Głosowanie większościowe – 3 modele klasyfikują ten sam tekst; wynik to dominująca odpowiedź. Zaskakująco skuteczne przy redukcji halucynacji w zadaniach ekstrakcji.

Koszty: licz tokeny, nie wywołania

Najczęstsza niespodzianka w produkcji to koszt wywołań rosnący wykładniczo z liczbą agentów. Każda runda wymiany kontekstu mnoży tokeny wejściowe. W praktyce:

• 50–70% kosztów to kontekst, nie odpowiedzi. Kompresuj kontekst między etapami (Summarizer), zamiast przekazywać pełne historie rozmów.
• Model per rola: lekki model do klasyfikacji i ekstrakcji, cięższy tylko do analizy i planowania. Nie używaj najdroższego modelu wszędzie.
• Cache’owanie wspólnego kontekstu (system prompty, dokumenty) w API z obsługą prompt caching – potrafi zdjąć 50–80% kosztu tokenów wejściowych.
• Mierz koszt na zakończone zadanie, nie na wywołanie. W przeciwnym razie nie zobaczysz efektu zapętleń.

Załóżmy prostą pętlę Researcher → Planner → Executor → Reviewer z jednym poprawkiem: to typowo 10–20 wywołań API i 30–80 tysięcy tokenów na jedno zadanie. Przy modelu klasy gpt-5-nano to grosze; przy najdroższych modelach reasoning – kilka złotych. Dlatego dobór modeli do ról to nie optymalizacja, tylko konieczność.

Kiedy nie używać multi-agenta

Szczerze: większość zadań nie potrzebuje architektury multi-agent. Unikaj jej, gdy:

• zadanie jest liniowe i dobrze zdefiniowane – jeden model z dobrym promptem i structured output wystarczy;
• masz ścisły budżet opóźnień – każda runda to sekundy, a często dziesiątki sekund;
• nie masz testów i obserwowalności – system multi-agent bez logowania pełnych konwersacji i metryk to czarna skrzynka, w której nie znajdziesz błędu;
• zespół nie ma doświadczenia z LLM – zacznij od jednego agenta i jednej integracji, a architekturę rozbuduj, gdy zobaczysz realną wartość.

Podsumowanie

Dobry system multi-agent to przede wszystkim dobra dekompozycja: role z rozłącznymi obowiązkami, orkiestrator z twardymi warunkami stopu i świadome zarządzanie kosztami tokenów. Konsensus i debata to narzędzia, nie cel – używaj ich tam, gdzie błąd kosztuje więcej niż dodatkowe wywołania. A jeśli masz wątpliwość, czy multi-agent jest potrzebny – zacznij od jednego agenta i dodawaj kolejnych dopiero na podstawie danych, nie przeczuć.