Ez a cikk az AI Ágens Rendszerek a Vállalati Gyakorlatban című átfogó tanulmányunk 4. része — a teljes whitepaper 14 fejezetben mutatja be az autonóm és multi-ágens rendszerek világát.
Miért kritikus a kommunikáció?
Egy multi-ágens rendszer ereje nem az egyedi ágensekben rejlik, hanem abban, hogyan dolgoznak együtt. A kommunikációs minta meghatározza a rendszer megbízhatóságát, költségét és skálázhatóságát.
Kommunikációs minták
1. Handoff (Átadás)
Az egyik ágens átadja a teljes beszélgetést egy másiknak. Az OpenAI Agents SDK ezt natívan támogatja.
Sales Ágens: „Ez számlázási téma — átadom a Finance Ágensnek."
→ [handoff, teljes kontextussal]
Finance Ágens: „Megnézem a számla részleteit..."
Előny: Egyszerű, egyértelmű felelősség-átruházás. Hátrány: A fogadó ágens megkapja az egész kontextust → token-költség, kontextus-zaj.
Mikor használjuk: Területváltás a beszélgetés közben — pl. sales kérdésből számlázási kérdés lesz.
2. Delegálás + eredmény (Tool-call)
Az orchestrator egy specializált ágenst hív meg mint „eszközt" — megkapja az eredményt, és maga dolgozza fel.
Orchestrator: „Kérdezd le a Q1 statisztikákat."
→ Analytics Ágens → { revenue: 12M, deals_won: 45 }
Orchestrator: [feldolgozza, formázza, válaszol]
Előny: Az orchestrator kontrollálja az outputot, a specializált ágens fókuszáltan dolgozik. Hátrány: Extra LLM hívás az orchestratornak a feldolgozáshoz.
Mikor használjuk: Adat-lekérdezés, számítás, háttér-feldolgozás.
3. Shared State (Közös munkaterület)
Az ágensek közös adatstruktúrát írnak/olvasnak — a kommunikáció a közös állapot változásain keresztül történik.
{
"customer": { "name": "Kovács Kft.", "id": 123 },
"order": null, // ← Logistics Ágens kitölti
"invoice": null, // ← Finance Ágens kitölti
"email_draft": null // ← Communication Ágens kitölti
}
Előny: Nincs közvetlen ágens-ágens kommunikáció → egyszerűbb, kevesebb hiba. Hátrány: Race condition lehetősége, bonyolultabb debug.
Mikor használjuk: Komplex, többlépéses feladatok, ahol több ágens egymásra épít.
4. Broadcast (Szórás)
Párhuzamos feladatkiosztás több ágensnek, eredmények összefésülése.
Előny: Gyors párhuzamos feldolgozás. Hátrány: Drága (több egyidejű LLM hívás), az összefésülés nem triviális.
Mikor használjuk: Független részfeladatok — pl. „Elemezd a Q1-et régiónként" → régió-ágensek párhuzamosan.
A memória három szintje
A memória az, ami az AI ágenst intelligens partnerré teszi a puszta válaszgép helyett. Három szintet különböztetünk meg:
1. Munkamemória (Working Memory)
A jelenlegi beszélgetés: üzenetváltások, tool-call eredmények, közbenső döntések.
- Élettartam: A beszélgetés ideje
- Méret: ~4K-32K token (modell kontextus-ablaktól függ)
- Technika: Automatikus — a message history maga
2. Rövid távú memória (Short-term Memory)
Session-szintű kontextus, ami a beszélgetésen túl él, de nem örökké.
- Élettartam: Napok-hetek
- Méret: Összefoglalók, kivonatok
- Technika: Adatbázisban tárolt összefoglalók, automatikus summarization
Példa: „Tegnap beszéltünk a Kovács deal-ről, ott tartottunk hogy..."
3. Hosszú távú memória (Long-term Memory)
Preferenciák, üzleti kontextus, korábbi tanulságok. Ez az, ami az ágenst a vállalat „veterán munkatársává" teszi.
- Élettartam: Hónapok-évek
- Méret: Egyre növekvő
- Technika: Knowledge Graph + vektoros keresés (embedding)
Példa: Az ágens tudja, hogy a Kovács Kft. mindig Q4-ben rendel, Márta a kontakt, és emailt preferálnak telefonhívás helyett.
Multi-ágens memória-megosztás
Architektúrális tipp
A specializált ágens ne kapja meg az egész memóriát — csak ami a feladatához szükséges.
Három ok:
- Token-hatékonyság: Kevesebb kontextus = olcsóbb és gyorsabb hívás
- Fókusz: A modell jobban teljesít kevesebb zajjal
- GDPR: Adatminimalizálás — a Finance Ágens ne lássa az ügyfél teljes kommunikációs előzményeit
A teljes ágens-rendszer architektúrája
Az eddig tárgyalt komponensek egy összefüggő rendszert alkotnak:
┌────────────────────────────────────────────────────────────┐
│ Felhasználói felületek │
│ Web Dashboard │ Mobile App │ Chat Widget │
└──────────────────────────┬─────────────────────────────────┘
│
┌──────────────────────────▼─────────────────────────────────┐
│ API Gateway │
│ Autentikáció │ Rate Limiting │
└──────────────────────────┬─────────────────────────────────┘
│
┌──────────────────────────▼─────────────────────────────────┐
│ AI Service Layer │
│ ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │
│ │ Agent │ │ Context │ │ Memory │ │ Tool │ │
│ │ Loop │ │ Builder │ │ Manager │ │ Executor │ │
│ └─────────┘ └──────────┘ └──────────┘ └────────────┘ │
└──────────────────────────┬─────────────────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
┌───────▼──────┐ ┌───────▼──────┐ ┌───────▼──────┐
│ CRM Tools │ │ MCP Registry │ │ Knowledge │
│ contacts │ │ Gmail │ │ Graph / RAG │
│ deals │ │ Calendar │ │ Embeddings │
│ tasks │ │ Számlázás │ │ Vektortár │
└──────────────┘ └──────────────┘ └──────────────┘
Agent Loop — Kontextus-felépítés → LLM hívás (provider-agnosztikus) → tool call-ok → iteráció.
MCP Registry — Dinamikus eszköznyilvántartás: plug-and-play, biztonsági szeparáció, token-hatékony.
Knowledge Graph / RAG — Strukturált (CRM), félig strukturált (emailek), strukturálatlan (dokumentumok) — vektoros keresés biztosítja a releváns kontextust.
A sorozat utolsó része: AI Ágens Biztonság és Bevezetés — GDPR, EU AI Act, jóváhagyási mátrix és lépésről-lépésre bevezetési útmutató.