Intervjuer te pita: „Kako se implementira Multi-Agent saradnja?" Ako odgovoriš „svaki Agent radi svoje i na kraju se rezultati spoje", upravo si prosto bacao lako poene.

Zašto?

Zato što Multi-Agent bez mehanizma koordinacije samo završi tako da se Agent-i međusobno gade.

Danas za 3 minute do detalja razlažem mehanizam Multi-Agent saradnje.

Kad intervjuer postavi ovo pitanje, površinski pita o procesu, a zapravo proverava tri nivoa: prvo, koliko ti je poznato glavnih arhitektura saradnje; drugo, da li su ti jasni implementacioni detalji Orchestrator obrasca; treće, u kojim scenarijima treba uvesti Multi-Agent, a u kojima je jedan Agent dovoljan.

Važi, sad sledi odgovor za pun broj poena — nauči ga napamet i gotovo.

U produkciji je najzastupljenija Orchestrator arhitektura, centralna koordinacija. Glavni Agent raspada zadatak, dodeljuje posao, prikuplja rezultate, a podređeni Agent-i rade samo svoj deo.

Objasniću u četiri koraka.

Prvi korak, dekompozicija zadatka. Korisnik kaže „napravi mi izveštaj o konkurentnim proizvodima", pa Orchestrator poziva LLM i razbija zahtev na podzadatke — prikupljanje podataka, analiza i poređenje, pisanje izveštaja. Prva dva mogu paralelno, treći zavisi od njih.

Drugi korak, dodela Agent-ima. Orchestrator čita opis uloge svakog podređenog Agent-a i radi semantičko match-ovanje. Prikupljanje podataka ide Research Agent-u, analiza i poređenje Analysis Agent-u. Kako se matchuje? Ista logika kao za Skill okidanje iz prošlog dela — preko description-a.

Treći korak, izolovano izvršenje. Svaki podređeni Agent zaključuje u svom zasebnom context window-u. Paznja — podređeni Agent-i međusobno ne komuniciraju direktno, sve ide preko Orchestrator-a. Prednost? Ako jedan Agent pogreši, ne zagađuje kontekst ostalih.

Četvrti korak, agregacija rezultata. Podređeni Agent-i vraćaju strukturirani JSON, a Orchestrator, pošto ih sve prikupi, još jednom poziva LLM da sintetizuje i izda konačan odgovor.

Pored Orchestrator-a, treba da poznaješ još dva obrasca.

Handoff obrazac — Agent-i direktno predaju kontrolu jedni drugima. Na primer, u korisničkoj podršci korisnik najpre dobije opšti Agent za podršku, pa se usput ispostavi da je problem tehnički, pa mu kontrola ručno predaje tehničkom stručnjaku. Ali tu postoji kobna slabost — lako upadne u beskonačnu petlju: A preda B, B preda C, C vrati nazad A.

Pipeline obrazac — fiksni lanac, izlaz A ide kao ulaz B, izlaz B kao ulaz C. Odgovara zadacima sa utvrđenim koracima: generisanje koda, review, test — u tri koraka.

Ako intervjuer dodatno pita: „Kako birati između Multi-Agent-a i jednog Agent-a sa više Tool-ova?"

Reci mu — ključ je u stepenu specijalizacije. Za znanje koje prelazi domene, pravo plus finansije plus kod, jedan Agent ne može da stane u jedan context, pa ide Multi-Agent. Ako alata nema više od deset i domen je jedinstven, jedan Agent je dovoljan — nemoj dodavati trošak koordinacije.

I za kraj jedna mantra — koordinaciju vodi Orchestrator, izolovano trče bez međusobnog ometanja; za proste zadatke nemoj Multi, sačuvani token je pravi put.

Da li si savladao ovo pitanje? Za još detaljnih razlaganja pitanja sa Agent-intervjua na nivou izvornog koda —