AI Agent intervjujska pitanja prva serija: ReAct, Plan-and-Execute, Multi-Agent osnovna arhitektura 13 pitanja

Marko Marković3455 reči12 minuta

Prva serija, fokus na osnovnu arhitekturu Agent-a — ReAct, Plan-and-Execute, Multi-Agent, asinhroni paralelizam.

Ovi pravci se najčešće pojavljuju na intervjuu, i to su sadržaji 1., 2., 5. i 7. izdanja PaiCLI-ja.

01, Šta je ReAct mod?

ReAct je skraćenica od Reasoning + Acting, Yao et al. (Yao Shunyu) predložio 2022. godine.

Sve se svodi na jednu rečenicu: omogućiti LLM-u da istovremeno vrši zaključivanje i izvršavanje radnji, na osnovu rezultata radnji nastavlja zaključivanje, formira se zatvorena petlja.

Agent.java iz prvog izdanja PaiCLI-ja je standardna ReAct implementacija. Srce je while petlja, svaki krug radi tri stvari:

šalje istoriju poruka LLM-u,
proverava da li odgovor sadrži tool_calls,
ako da, izvršava alat i rezultat vraća u istoriju.

Kada LLM više ne vraća tool_calls, petlja se izlazi, konačni odgovor se šalje korisniku.

Kostur Agent-a je toliko jednostavan.

Kako se razlikuje od Chain-of-Thought?

Chain-of-Thought (CoT) samo zaključuje, ne izvršava.

LLM odjednom zamisli sve korake, direktno izlazi konačan odgovor. Za matematike, logičko zaključivanje može, ali kad naleti na "pomozi mi da pročitam pom.xml" zadatak koji zahteva eksterne informacije — ne ide, LLM nema mogućnost čitanja fajla, koliko god dobro zamislio, ne zna.

ReAct prekrećenje je dodavanje Action i Observation koraka. LLM zamisli "trebam da pročitam pom.xml", izlazi sa tool_call read_file, Agent zaista čita fajl, vraća sadržaj, LLM na osnovu stvarnog sadržaja nastavlja zaključivati.

Jednom tabelom jasno kažemo granicu između ova dva:

Dimenzija	CoT	ReAct
Opseg sposobnosti	Čisto zaključivanje	Zaključivanje + poziv eksternog alata
Izvor informacija	Znanje iz obuka podataka	Dobijanje u realnom vremenu (fajl, komanda, pretraga)
Pogodni scenariji	Matematika, logika, generisanje koda	Zadaci koji zahtevaju interakciju sa spoljnim svetom
Tipični proizvodi	ChatGPT-ov proces razmišljanja	Claude Code, PaiCLI, Cursor

Na intervjuu kada intervjuer dođe do ove tačke, možeš dodati:

PaiCLI-jev odgovor LLM-a takođe sadrži reasoning_content (proces razmišljanja), ovo je zapravo deo CoT-a.

ReAct ne zamenjuje CoT, već na osnovu CoT-a dodaje sposobnost delovanja. U PaiCLI izvornom kodu, reasoning_content se samo piše u dnevnik, ne ide u sledeći krug istorije razgovora, izbjegava se da proces razmišljanja troši Token budžet.

02, Kako Agent zna koji alat da pozove?

Ovo pitanje mnogi pogrešno odgovore, misle da u Agent-u postoji neko pravilo rutiranja koje radi podudaranje alata. U stvari Agent sam ne bira alat, pravo izbora je potpuno u rukama LLM-a.

Proces je ovakav: Agent pri konstruisanju zahteva, u polje tools tela zahteva stavlja definicije svih dostupnih alata (naziv + opis + JSON Schema parametara) i šalje LLM-u. LLM na osnovu namere korisnika i opisa alata, u polju tool_calls odgovora vraća naziv alata i JSON parametre.

Ovo je Function Calling protokol koji je definisao OpenAI, GLM, DeepSeek, Kimi i ostali kineski modeli takođe podržavaju.

PaiCLI-jev ToolRegistry.java održava registar alata. Svaki alat pri registraciji pruža name, description, parameters schema. Agent pre svakog zahteva LLM-u, iz registra izvlači kompletne definicije alata i stavlja u telo zahteva. LLM vraća tool_calls: [{name: "read_file", arguments: {path: "pom.xml"}}], Agent iz registra pronalazi izvršnu logiku read_file alata i pokreće.

// ToolRegistry.java osnovna struktura
private final Map<String, ToolDefinition> tools = new LinkedHashMap<>();
private final Map<String, ToolExecutor> executors = new LinkedHashMap<>();

public String executeTool(String name, String argumentsJson) {
    ToolExecutor executor = executors.get(name);
    if (executor == null) {
        return "Nepoznat alat: " + name;
    }
    return executor.execute(argumentsJson);
}

Ovde postoji jedno iskustvo koje vredi pomenuti: kvalitet opisa alata direktno određuje tačnost LLM izbora.

Rani execute_command opis u PaiCLI-ju je previše jednostavan, LLM je često koristio cat umesto read_file za čitanje fajlova. Kasnije sam u opis dodao "kratke Shell komande koje se izvršavaju u korenu projekta, npr. ls, mvn compile, ne koristiti za čitanje sadržaja fajla", tačnost je porasla.

Šta ako LLM vrati nepostojeći naziv alata

ToolRegistry.executeTool() ima pokrivanje — ako ne pronađe alat, vraća "Nepoznat alat: xxx". Ova greška se kao tool poruka vraća u istoriju razgovora, LLM sledeći krug videći je automatski ispravi.

Ali ako LLM ponavlja vraćanje nepostojećeg naziva alata, to znači da je problem sa system prompt-om ili opisom alata, treba optimizovati prompt a ne dodavati više logike pokrivanja.

03, Da li ReAct petlja može ući u beskonačnu petlju

Može.

Uobičajeni scenariji beskonačne petlje

Scenarij jedan: execute_command ne uspe, LLM ne odustaje, promeni parametar i pokuša ponovo, opet ne uspe, beskonačno ponavlja. Npr. Agent-u zadaš kompajliranje projekta, `mvn compile javlja grešku, LLM promeni malo koda i opet kompajlira, opet greška, menja i kompajlira...

Scenarij dva: LLM izlazi sa delom zaključivanja ali ne poziva alat i ne daje konačan odgovor. Agent taj deo zaključivanja vrati, ponovo poziva LLM, LLM nastavlja sam sa sobom, nikada se ne završava.

Kako PaiCLI rešava beskonačnu petlju

U izvornom kodu PaiCLI-ja postoje četiri slova zaštite:

Prvi sloj je Token budžet. AgentBudget dinamički računa budžet na osnovu maxContextWindow() trenutnog modela (podrazumevano uzima 80% prozora), kada istorija razgovora približi budžetu automatski se pokreće sažimanje ili prisilno se prekida.

Drugi sloj je timeout izvršenja alata. execute_command ima 60 sekundi timeout, isteknu li timeout, direktno vraća rezultat timeout LLM-u, neće tu stati.

Treći sloj je otkaz korisnika. Pri izvršenju pritisni ESC ili ukucaj /cancel možeš zatražiti otkaz trenutnog Agent run-a. ReAct, Plan, Team tri puta na granici proveravaju signal otkaza.

Četvrti sloj je sažimanje kao pokrivenje. ContextCompressor interveniše kada se istorija razgovora proširi do kritične tačke, stari razgovor sažima u sažetak i oslobađa prostor. Ali ako brzina sažimanja ne može dostići brzinu širenja (rezultati alata su preveliki), konačno će se aktivirati gornja granica budžeta i prekinuti.

Na intervjuu kad kažeš ova četiri sloja, intervjuer obično nastavlja pitanjem "koji sloj je ključan". Odgovor je Token budžet — on je jedini ograničenje koje je direktno vezano za kontekstni prozor. Timeout se odnosi samo na jedan alat, otkaz korisnika zavisi od brzine reakcije ljudi, sažimanje ima kašnjenje.

04, Šta je Plan-and-Execute mod?

Plan-and-Execute je dvofazni mod: prvo planiraj, zatim izvrši.

Korisnik unesi složen zadatak, Agent ne žuri da radi, prvo daje LLM-u da razbije zadatak na više podzadataka i jasno definiče zavisnosti, generiše plan izvršenja. Korisnik potvrdi, zatim se podzadaci izvršavaju jedan po jedan.

PaiCLI 2. izdanje implementirao PlanExecuteAgent.java, pokreće se /plan komandom.

Korisnik unosi "/plan kreiraj demoapp projekat, pročitaj pom.xml, verifikuj strukturu projekta"
    ↓
Planner generiše plan:
  task_1: kreiraj demoapp projekat (bez zavisnosti)
  task_2: pročitaj pom.xml (zavisi od task_1)
  task_3: verifikuj strukturu projekta (zavisi od task_2)
    ↓
Korisnik potvrduje (enter za izvršenje / ESC za otkaz / I dopuni zahtev)
    ↓
Izvrši podzadatke po redosledu zavisnosti (svaki podzadatak interno prolazi kroz ReAct petlju)

Šta je bolje od ReAct-a

Čisti ReAct je "korak po korak" — LLM nakon jedne radnje odluči šta sledeće, redosled izvršenja je nepredvidiv.

Plan-and-Execute je "prvo razmisli, pa radi" — korisnik pre nego što Agent krene u rad može videti kompletan plan, ako ne odgovara može otkazati ili izmeniti. Predvidivost je najveća prednost.

PaiCLI-jev PlanReviewInputParser.java implementira interakciju potvrde plana: enter za izvršenje, ESC za otkaz, pritisak I za unos dopunskih zahteva da Planner ponovo planira. Ovaj mehanizam potvrde je inspirisan Claude Code-om — Claude Code pre izvršenja visokorizičnih operacija takođe pauzira i čeka potvrdu korisnika.

Naravno cena je jedan dodatni LLM poziv za Planer.

Jednostavni zadaci koristeći Plan-and-Execute su neefikasni — "pomozi mi da pročitam README" ne treba planirati. PaiCLI-jev dizajn je podrazumevano ReAct, eksplicitno /plan se prebacuje, posle izvršenja se automatski vraća na ReAct.

05, Kako radi DAG u Plan-and-Execute

DAG (Directed Acyclic Graph, usmerjen aciklični graf) se koristi za upravljanje zavisnostima između podzadataka. Svaki podzadatak deklariše koje predhodne zadatke zavisi (polje depends_on), formira se usmerjen graf.

PaiCLI-jev ExecutionPlan.java drži listu zadataka i DAG relacije, PlanExecuteAgent pri izvršenju koristi topološko sortiranje da razbija zadatke na grupe:

Grupa1: task_1, task_2 (bez zavisnosti, mogu paralelno)
Grupa2: task_3 (zavisi od task_1), task_4 (zavisi od task_2)
Grupa3: task_5 (zavisi od task_3 i task_4)

Zadaci unutar iste grupe se izvršavaju paralelno kroz planer paralelnog raspoređivanja iz 7. izdanja, različite grupe su strogo serijske.

Šta ako jedan zadatak ne uspe

Strategija obrade neuspeha je takođe u PlanExecuteAgent:

Neuspešni zadaci se označavaju kao FAILED
Svi direktno ili indirektno zavisni nadređeni zadaci se automatski označavaju kao SKIPPED — ne izvršavaju se, jer preduslovi nisu zadovoljeni
Ostali zadaci bez zavisnosti sa njim nisu pogođeni, nastavljaju se izvršavati

Ovaj dizajn je referenca na CI/CD pipeline — GitHub Actions jedan job ne uspe, posleni job koji zavisi od njega se preskače, ali ostali paralelni jobovi nisu pogođeni.

Intervjuer može nastaviti pitanjem "da li postoji mehanizam ponovnog pokušaja".

PaiCLI-jev Plan-and-Execute trenutno nema ponovni pokušaj na nivou zadatka, ali Multi-Agent mod-u kada Reviewer-ova revizija ne prođe postoji mehanizam ponovnog izvršenja (najviše 2 puta). Ovo je svesna dizajnerska odluka — Plan mod naglašava predvidivost, automatski ponovni pokušaj čini proces izvršenja nepredvidivim.

06, Kako je implementirana Multi-Agent saradnja

PaiCLI 5. izdanje implementirao je arhitekturu Multi-Agent sa tri uloge.

Tri uloge jasno podeljene: Planner (planer) raspoređuje zadatke, Worker (izvršilac) stvarno izvršava podzadatak, Reviewer (pregledač) pregledava Worker-ov rezultat izvršenja.

Orkestrator AgentOrchestrator.java je glavni koordinator, usklađuje interakciju tri uloge. Svaka uloga je SubAgent instanca, ima nezavisan system prompt i definiciju uloge, ali dele isti ToolRegistry i MemoryManager.

Korisnik unosi "/team refakturuj login modul"
    ↓
Planner raspoređuje:
  task_1: analiziraj postojeći login kod
  task_2: refakturiši LoginService (zavisi od task_1)
  task_3: ažuriraj unit testove (zavisi od task_2)
    ↓
Worker izvršava task_1 → Reviewer pregleda
                          ↓
                    Prošao → Worker izvršava task_2
                    Nije prošao → Worker ponavlja (sa povratnom informacijom, najviše 2 puta)

Kako se razlikuju system prompt-i različitih uloga

Ovo pitanje može pokazati razumevanje detalja implementacije.

Planner-ov prompt fokusira na raspodelu zadataka i analizu zavisnosti, zahteva se struktuirani JSON lista zadataka. Worker-ov prompt fokusira na korišćenje alata i izvršenje, ima kompletno uputstvo za korišćenje alata. Reviewer-ov prompt fokusira na standarde kvaliteta i format povratne informacije, zahteva se "prošlo/nije prošlo + konkretan razlog".

Nakon što je 19. izdanje implementirano slojevitu arhitekturu prompt-a, ovi prompt-i su razdvojeni u nezavisne Markdown fajlove: modes/team-planner.md, modes/team-worker.md, modes/team-reviewer.md, u direktorijumu src/main/resources/prompts/. Promena prompt-a više ne zahteva promenu Java koda.

07, Šta raditi kada Reviewer-ova revizija ne prođe

Nakon što Reviewer da "nije prošlo + povratna informacija", AgentOrchestrator spaja povratnu informaciju sa originalnim zadatkom, ponovo daje Worker-u da ponovi. Worker sa povratnom informacijom ponovo izvršava, rezultat se ponovo daje Reviewer-u na pregled. Najviše se ponavlja 2 puta, preko se direktno označava kao završeno sa upozorenjem.

Ovde postoji jedan lako zanemarljiv detalj: svaki ponovljeni pokušaj troši jedan kompletn LLM poziv.

Worker jednom izvrši + Reviewer jednom pregleda = najmanje 2 LLM poziva. Ponovni pokušaj 2 puta znači dodatnih 4 poziva. Kontrola troškova je glavni razlog za ograničenje broja ponavljanja.

Intervjuer može pitati "zašto ne proslediti Reviewer-ovu povratnu informaciju direktno LLM-u da jednom ispravi".

Odgovor je: mi upravo to radimo — povratna informacija se šalje kao kontekst Worker-u, Worker može videti tačno šta nije u redu. Ali LLM nije deterministički sistem, čak i kad vidi povratnu informaciju ne garantuje da će jednom ispraviti, zato mora postojati gornja granica ponavljanja.

Kako se ovo odnosi na Code Review

U suštini ovo je automatski Code Review.

Planner je Tech Lead dodeljuje zadatke, Worker je programer piše kod, Reviewer je pregledač komentariše. Ako revizija ne prođe, vraća se na preradu.

Razlika je u tome što AI Reviewer-ovi standardi revizije su definisani u prompt-u.

08, Kako se procesira više tool_calls u jednom krugu LLM-a

Kada LLM smatra da treba istovremeno obaviti više stvari (npr. istovremeno čitati 3 fajla), u jednom odgovoru može vratiti više tool_calls.

PaiCLI 7. izdanje implementirao je paralelno pozivanje alata u Agent.java.

Glavni put koda je: iz LLM odgovora parsiraju se svi tool_calls → predaju se ExecutorService thread pool-u za paralelno izvršenje → čeka se da se svi završe (postoji jedinstveni timeout pokrivenje) → rezultati se slažu po originalnom redosledu tool_call → zajedno se vraćaju u istoriju poruka.

// pojednostavljena logika paralelnog izvršenja
List<Future<ToolResult>> futures = new ArrayList<>();
for (ToolCall call : toolCalls) {
    futures.add(executor.submit(() ->
        toolRegistry.executeTool(call.name(), call.arguments())
    ));
}
// čeka se završetak svih alata, rezultati se sakupljaju po originalnom redosledu
for (int i = 0; i < futures.size(); i++) {
    results.add(futures.get(i).get(timeout, TimeUnit.SECONDS));
}

Vrlo je važno održavati originalni redosled pri sastavljanju. LLM API protokol zahteva da se tool_call_id svake tool poruke strogo podudara sa odgovarajućim tool_call-om, poremećaj redosleda dovodi do pogrešnog razumevanja modela.

Koliko poboljšanje performansi daje paralelno izvršenje

Najviše poboljšanje za I/O intenzivne operacije. Čitanje 3 fajla po 100ms, serijski 300ms, paralelno oko 100ms. Za execute_command operaciju koja može trajati nekoliko sekundi, više paralelnih je još značajnije.

ReAct, Plan-and-Execute, Multi-Agent Worker tri puta dele isti mehanizam paralelnog izvršenja alata, kod se ne ponavlja.

09, Da li paralelno pozivanje alata može dovesti do konflikta

Može.

Dva alata istovremeno pišu u isti fajl, jedan čita fajl a drugi menja isti fajl, ovo su scenariji konflikta.

PaiCLI-jeva strategija rešavanja je prilično jednostavna i direktna: ne pravi finu zaključavanje, oslanja se na LLM da ne pravi greške + inženjersko pokrivenje.

Ako LLM u istom krugu vrati dva tool_calls koji pišu u isti fajl, to znači da system prompt nije dobro napisan — u prompt-u treba navoditi LLM da operacije sa zavisnostima razdvoji u različite krugove.

U PaiCLI-jevom base.md piše "ako između alata postoji zavisnost, model treba pozivati u više krugova".

Na nivou inženjerskog pokrivenja:

Svaki alat ima nezavisan timeout, jedan se ne može blokirati drugima. Ako izvršenje jednog alata ne uspe, samo tom alatu vraća grešku LLM-u, ne utiče na rezultate ostalih alata istog batch-a.

Claude Code, Cursor i slični proizvodi takođe koriste ovu ideju. Pravljenje zaključavanja na nivou fajla je skupo (treba analizirati putanje fajlova u parametrima alata pa upravljati zaključavanjem), korist je mali (verovatnoća da LLM u istom krugu piše konfliktno nije velika).

10, Kako se upravlja Token budžet

LLM ima ograničenje kontekstnog prozora, GLM-5.1 je 200k tokena, DeepSeek V4 je 1M. Agent mora raditi u okviru prozora.

PaiCLI-jevo upravljanje Token budžetom je u paketima com.paicli.context i com.paicli.memory:

AgentBudget dinamički računa dostupni budžet na osnovu trenutnog modela. Formula je maxContextWindow × 80%. Preostalih 20% ostaje za izlaz LLM-a.

Konkretno za jedan zahtev, dostupan prostor = ukupni budžet - system_prompt_tokens - tools_definition_tokens - tokeni trenutne istorije razgovora.

TokenBudget u realnom vremenu prati broj tokena istorije razgovora. ContextCompressor kada se približi pragu radi Map-Reduce sažimanje — prvo se dugačak razgovor razbija na odeljke i sažima (Map), zatim se spaja u jedan ukupan sažetak (Reduce), sažetak zamenjuje originalnu istoriju i oslobađa prostor.

izdanje inženjeringa dugog konteksta uradilo je veliku nadogradnju ovog mehanizma: modeli sa prozorom ≥ 100k ulaze u long mod, direktno preskaču sažimanje. Razlog je jednostavan — za model sa 200k prozora, 80% budžet je 160k, dnevni razvojni razgovor teško će koristiti toliko, bez sažimanja iskustvo je bolje.

11, Kako birati između tri moda ReAct, Plan-and-Execute, Multi-Agent

Ovo pitanje intervjueri vole, standardni pristup je dati jasnu matricu odluke.

Scenarij	Preporučeni mod	Razlog
Jednostavna pitanja, izmena jednog fajla	ReAct	Jedan-dva koraka, planiranje je gubljenje
Kreiranje projekta, višefajlna refaktoracija	Plan-and-Execute	Koraka mnogo, postoje zavisnosti, treba prvo planirati
Veliki zadaci, potrebna garancija kvaliteta	Multi-Agent	Podela rada + mehanizam revizije

PaiCLI-jev dizajn je podrazumevano ReAct, eksplicitno /plan ili /team se prebacuje, posle izvršenja se automatski vraća na ReAct.

U svakodnevnoj upotrebi 80% interakcija ReAct može obaviti.

Intervjuer može nastaviti "da li Agent može sam da odluči koji mod da koristi".

Odgovor je da može.

Ali ne bih ovu odluku potpuno prepustio velikom modelu slobodno, već napravio bi "sloj rutiranja mod-a".

Nakon što korisnikov unos dođe, prvo se procenjuju karakteristike zadatka: da li je jednostavno pitanje, da li treba poziv alata, da li uključuje izmenu više fajlova, da li ima jasne korake zavisnosti, da li je pogodno za paralelno razbijanje, da li je riziko visoko. Jednostavni zadaci idu na ReAct; zadaci sa jasnim koracima i zavisnostima idu na Plan-and-Execute; zadaci koji se mogu razbiti na više relativno nezavisnih podzadataka, nadograđuju se na Multi-Agent.

Dozvolio bih Agent-u da izvede struktuiranu odluku, npr. mode=react/plan/team, confidence, reason, ali na kraju treba kombinovati sa pravilima pokrivenja.

Npr. korisnik eksplicitno ukuca /plan ili /team, poštuje se korisnikova naredba; ako model proceni nisko poverenje, podrazumevano ide na ReAct, ili prvo generiše plan da korisnik potvrdi; ako se u procesu izvršenja uoči da je zadatak složeniji od očekivanog, može se od ReAct nadograditi na Plan, ne biti od početka fiksiran.

12, Ako te od naziva dizajniraš Agent arhitekturu, kako biš

Ovo otvoreno pitanje intervjuer želi da vidi arhitektonsko razmišljanje.

Prvi korak, minimalna ispravna ReAct petlja. Jedna while petlja + LlmClient interfejs + ToolRegistry registar. Prvo proći "korisnički unos → LLM zaključivanje → poziv alata → povratak rezultata → nastavak zaključivanja" ovu lanac. PaiCLI prvo izdanje je upravo ovako, 400 linija koda.

Drugi korak, dodati zaštitu. Token budžet, gornja granica broja petlji, timeout alata — ova tri bez dodavanja, Agent će izmaknuti kontroli. PaiCLI 3. izdanje dodao Token budžet upravljanje, 6. izdanje dodao HITL odobrenje.

Treći korak, po potrebi dodati kompleksnost. Zadatak postaje složen, dodaje Plan-and-Execute (2. izdanje), zahtev za kvalitetom raste, dodaje Multi-Agent (5. izdanje), alata postaje mnogo, dodaje paralelni raspoređivač (7. izdanje).

Četvrti korak, apstrakcija i proširivost. LlmClient interfejs se ne veže za model (8. izdanje), ToolRegistry podržava dinamičku registraciju MCP alata (10. izdanje), Prompt se iz hardcoded razbija na Markdown fajlove (19. izdanje).

Ključni princip: prvo proći, onda optimisati, prvo jednostavno, onda složeno. Najveća zamka je dizajnirati savršenu arhitekturu od početka.

13, Kako na intervjuu predstavitiš svoj Agent projekat (verzija od 1 minut)

"Od nule sam implementirao AI Agent CLI u Javi, zove se PaiCLI, uporediv sa Claude Code-om, kroz 21 izdanje od ReAct petlje do kompletog proizvoda.

U osnovnoj arhitekturi, implementirao sam tri moda: ReAct, Plan-and-Execute, Multi-Agent. ReAct je podrazumevani, Plan-and-Execute je dodao DAG topološko sortiranje za podršku paralelnih zadataka, Multi-Agent je saradnju tri uloge Planner-Worker-Reviewer.

Sistem alata integrisao je MCP protokol, podržava dva tipa prenosa stdio i Streamable HTTP, ugrađeno je upravljanje pretraživačem Chrome DevTools. Sigurnosni sloj ima HITL odobrenje, ograničenje putanje, crnu listu komandi, reviziju operacija.

Proizvodno uradio Claude Code stil inline TUI, LSP dijagnostičku injekciju, Git Side-History snapshot povratak, HTTP Runtime API.

Ceo projekat od 400 linija koda prvog izdanja evoluirao je do 21. izdanja kompletnog proizvoda, moja najveća korist je razumevanje pune lanac Agent-a od principa do proizvoda — kada treba koristiti jednostavno rešenje, kada mora dodati kompleksnost."

ending

Intervju nije pamćenje odgovora, već pričanje sa izvornim kodom.

[Na intervjuu kad pričaš o ReAct-u, otvori Agent.java i pokazi intervjueru while petlju. Kad pričaš o Plan-u, pokazi ExecutionPlan.java graf zavisnosti zadataka. Kad pričaš o Multi-Agent-u, pokazi SubAgent.java definiciju uloga i prompt fajlove. Kod i odgovori se poklapaju, intervjuer zna da si zaista radio.]

Naziv projekta: PaiCLI — Java Agent CLI (uporediv sa Claude Code-om)

Opis projekta: Od nule implementiran terminalski AI Agent u Javi, pokriva ReAct, Plan-and-Execute, Multi-Agent tri arhitektonska moda, integrisao MCP protokol, HITL odobrenje, RAG pretragu i upravljanje pretraživačem Chrome DevTools.

Tehnološki stack: Java 17, Maven, GLM-5.1/DeepSeek V4/Kimi K2.6 više modela, OkHttp + SSE striming parsiranje, JLine3 terminalna interakcija, SQLite vektorsko skladištenje, JGit snapshot upravljanje, JUnit 5 + Mockito

Ključne odgovornosti:

Implementiran osnovnu petlju Agent-a na osnovu ReAct mod-a (Thought-Action-Observation), kroz ToolRegistry dinamički registrovano 9 ugrađenih alata + 60+ MCP spoljašnjih alata, izbor alata pokreće LLM Function Calling
Implementirano Plan-and-Execute mod, kroz DAG topološko sortiranje upravlja zavisnostima podzadataka, zadaci iste grupe se izvršavaju paralelno, pri neuspehu pojedinačnog zadatka zavisni dolje automatski SKIP ne blokira nezavisne zadatke
Dizajnirana arhitektura saradnje tri uloge Multi-Agent (Planner/Worker/Reviewer), pri Reviewer-ovoj reviziji koja nije prošla ponavlja sa povratnom informacijom (najviše 2 puta), orkestrator AgentOrchestrator jedinstveno upravlja životnim ciklusom uloga
Implementiran mehanizam paralelnog pozivanja alata, više tool_calls istog kruga paralelno se izvršava kroz ExecutorService, rezultati se vraćaju po originalnom redosledu da bi se garantovala kompatibilnost LLM protokola, ReAct/Plan/Team tri puta dele isti raspoređivač
Implementirano dinamičko upravljanje Token budžetom na osnovu AgentBudget (80% × maxContextWindow), uz Map-Reduce sažimanje i adaptivnu promenu moda dugog konteksta, podržava modele sa prozorom 200k-1M