Preskoči na glavni sadržaj

Šef pita: "Daj mi jedan razlog da ti povećam platu." Bez razmišljanja sam odgovorio: "Niko ne razume bolje od mene kako radi Claude Agent." Šef je pristao: "Važno, samo ne zaboravi sledećeg meseca da pogledaš platnu listu."

Chenmo Wang ErAIAgent2945 reči10 minuta

Iskreno, sposobnosti modela GPT-5.5 i Opus 4.7 su već veoma jake.

Čak i kineski modeli, upareni sa vrhunskim Harness alatom Claude Code, postaju izuzetno moćni.

Na slici je PaiCLI alat koji sam nedavno istrgnuo, interaktivno iskustvo je veoma blizu Qoder CLI/Claude Code-u.

Znate da je ovo realizovano u Javi.

U današnjem tekstu ću vas odvesti da iz korena razumete kompletan princip rada Claude Code-a, i u vezi sa izvornim kodom PaiCLI-ja, potpuno ćemo razjasniti sledeće:

  • Kakva je osnovna arhitektura alata za AI programiranje?
  • Kako treba pisati sistemski prompt?
  • Šta je ReAct mehanizam Agent-a?
  • Koja je veza između Tool Use i Function Calling?
  • Koji je mehanizam Multi-Agent-a?
  • Koji je mehanizam Memory-ja?
  • Koji je mehanizam kompresije konteksta?
  • Kako CLAUDE.md omogućava Agentu da brzo savlada projekat?

Vrlo hardcore, vežite sigurnosni pojas, idemo.

content

01. Kakva je osnovna arhitektura alata za AI programiranje?

Odgovor je: veliki model + Harness.

Veliki model misli, Harness radi. Veliki model vraća tekst i instrukcije za poziv alata, a Harness alat parsira te instrukcije, izvršava alate i vraća rezultate velikom modelu da nastavi sa razmišljanjem.

U PaiCLI projektu, Agent je jezgro Harness-a, a LlmClient je apstraktni interfejs velikog modela.

While petlja je duša svakog alata za AI programiranje.

Bilo da je Claude Code ili Codex, ispod haude je ista petlja: poziva se veliki model → procenjuje se da li je potreban alat → ako jeste, izvršava se alat → rezultat se vraća u istoriju → ponovo se poziva veliki model. Sve dok veliki model ne oceni da je zadatak završen i ne pozove alat, petlja se ne završava.

Komunikacija između velikog modela i Harness-a ide preko strogo definisanog protokola poruka.

Svaka poruka nosi identifikator uloge: system (sistemski prompt), user (korisnički unos), assistant (odgovor modela), tool (rezultat izvršenja alata). Harness održava listu conversationHistory i pri svakom pozivu velikog modela prosleđuje celu listu kao kontekst.

Ovde postoji jedan detalj:

poruka tool mora nositi toolCallId, koji se jedno-na-jedno mapira na id nekog poziva alata iz prethodne assistant poruke.

02. Kako treba pisati sistemski prompt?

Claude Code ne radi to da "korisnički unos prosledi direktno velikom modelu".

Pre nego što korisnički unos stigne do velikog modela, Harness nadovezuje sistemski prompt koji kaže modelu "ko si, šta možeš, kako treba da radiš".

PaiCLI-jev PromptAssembler prikazuje logiku slojevitog sastavljanja sistemskog prompta:

Ukupno 7 slojeva.

Prvi sloj base.md definiše identitet i listu alata. Definiše ulogu Agent-a: "Ti si PaiCLI, inteligentni programerski Agent orijentisan ka radu sa bazom koda", a zatim navodi 11 dostupnih alata i strategije korišćenja.

Samo nabrojati imena alata nije dovoljno, modelu treba reći i kada koji alat koristiti, a kada ne. Na primer, u PaiCLI-jevom base.md stoji pravilo: Za pitanja vezana za bazu koda prvo idemo search_code, ne idemo na web_search.

Drugi sloj je podešavanje karaktera. calm.md čuva Agentov ton smirenim i profesionalnim.

Treći sloj je režim rada. Za običan razgovor koristi se agent.md, gde piše "na osnovu cilja korisnika odluči da li je alat potreban"; pri saradnji više Agenata, Planner koristi team-planner.md, u kom piše "rastavi zadatak u JSON format izvršnog plana"; Worker koristi team-worker.md, u kom piše "fokusiraj se na izvršenje dodeljenog ti podzadatka".

Četvrti sloj je strategija odobravanja, tri nivoa: auto (sve operacije se automatski izvršavaju), suggest (opasne operacije zahtevaju ljudsku potvrdu), never (svaki poziv alata zahteva potvrdu). Podrazumevano je suggest.

Poslednjih nekoliko slojeva su dinamički ubacivan kontekst projekta, lista veština i pravila upravljanja kontekstom.

03. Šta je ReAct mehanizam Agent-a?

ReAct je jezgro paradigme današnjih mainstream Agent framework-a, pun naziv Reasoning + Acting.

Tradicionalni LLM poziv je pitanje-odgovor.

Korisnik postavi pitanje, model vrati odgovor. Ali Agent nije takav — Agent zahteva višestruko zaključivanje, višestruke operacije, pri čemu se možda izvrši deset i više poziva alata da bi se završio zadatak.

Suština ReAct-a: na svakom koraku neka model prvo "razmisli" (zaključuje o trenutnom stanju i sledećem planu), zatim "deluje" (poziva alat da izvrši operaciju), pa na osnovu rezultata alata nastavi da "razmišlja" o sledećem koraku.

U PaiCLI-jevom Agent-u, ključni kod ReAct petlje je ovaj deo:

if (response.hasToolCalls()) {
    // dodaj assistant poruku (uključuje sadržaj rezonovanja + pozive alata)
    conversationHistory.add(LlmClient.Message.assistant(
            response.reasoningContent(), response.content(), response.toolCalls()));
    // izvrši alate
    List<ToolExecutionResult> toolResults = executeToolCalls(response.toolCalls(), iteration);
    // rezultati alata se vraćaju u istoriju
    for (ToolExecutionResult toolResult : toolResults) {
        conversationHistory.add(LlmClient.Message.tool(toolResult.id(), toolResult.result()));
    }
    // nastavi petlju, neka LLM na osnovu rezultata alata nastavi razmišljanje
    continue;
}

reasoningContent je interni proces rezonovanja modela (slično dubokom razmišljanju DeepSeek-a), content je izlaz namenjen korisniku. Proces rezonovanja se ne prikazuje direktno korisniku, ali se beleži radi debagovanja.

Konkretn primer.

Pretpostavimo da korisnik kaže "Ko je Chenmo Wang Er? Da li zna da penje svinje na drvo?", ReAct proces Agent-a izgleda otprilike ovako:

Prvi krug: razmišlja — "prvo da pretražim ko je Chenmo Wang Er". Dela — poziva WebSearch za pretragu interneta.

Drugi krug: razmišlja — "našao sam, da potvrdim identitet ovog blogera". Dela — ponovo poziva WebSearch.

Treći krug: razmišlja — "u redu, istina je izašla na videlo! Da sumiram". Dela — direktno vraća tekstualni odgovor, bez poziva alata. Petlja se završava.

Tokom celog procesa, veliki model na svakom koraku donosi odluke na osnovu trenutne istorije poruka (uključujući prethodno rezonovanje, pozive alata i rezultate alata).

04. Koja je veza između Tool Use i Function Calling?

Sa tehničke strane, Function Calling je tehničko sredstvo i standard protokola kojim se realizuje Tool Use.

  • Developer govori AI-u koji su alati dostupni. Koristi Function Calling format (najčešće JSON Schema) da definiše ime funkcije, opis i parametre.
  • Model na osnovu pitanja korisnika procenjuje da li je alat potreban — to je proces rezonovanja Tool Use-a.
  • Model aktivira Function Calling i vraća strukturirani kod (na primer {"function": "get_weather", "params": {"city": "Shanghai"}}).
  • Agent alat izvršava taj kod i prosleđuje rezultat modelu. Model na kraju integriše informacije i zatvara krug Tool Use-a.

Pri pozivu API-ja velikog modela, pored liste poruka prosleđujemo i parametar tools, u kom su definisana imena, opisi i šeme parametara svih dostupnih alata. Kada veliki model treba da pozove alat, u odgovoru vraća specijalnu strukturu koja sadrži ime alata i JSON parametre.

PaiCLI-jev ToolRegistry upravlja registracijom i izvršenjem svih alata. Pogledajte definiciju ovog Tool-a:

Jedan alat je: ime + opis + definicija parametara + funkcija izvršenja.

Kada LLM vrati poziv alata, Harness radi tri stvari.

  • Prvo, iz odgovora raščlanjuje ime alata i parametre.
  • Drugo, u registru pronalazi odgovarajući ToolExecutor.
  • Treće, izvršava i rezultat pakuje kao tool message i vraća u istoriju razgovora.

Kada LLM u jednoj turi vrati više poziva alata (na primer istovremeno želi da pročita tri fajla), PaiCLI otvara thread pool i izvršava ih paralelno:

Claude Code radi isto. Kada model oceni da između više poziva alata nema zavisnosti, u istoj turi vraća više tool_call-ova, a zatim ih izvršava paralelno.

Postoji još jedan ključni mehanizam proširenja: MCP.

Ugrađeni alati su konačni — read_file, write_file, execute_command pokrivaju većinu programerskih scenarija, ali šta ako treba upravljati pregledačem, povezati se na bazu, pozvati interni API preduzeća?

MCP-ov pristup je da "pravo registracije" alata otvori ka spolja.

Bilo koja spoljašnja usluga, ako implementira MCP protokol, može svoje alate dinamički registrovati u listu alata Agenta. U PaiCLI-ju je pravilo imenovanja ovih alata mcp__{ime_usluge}__{ime_alata}, na primer mcp__chrome-devtools__take_screenshot je alat za screenshot pregledača.

Agent uopšte ne zna za internu implementaciju ovih alata, vidi samo ime, opis i šemu parametara.

Veliki model na osnovu opisa procenjuje kada da ih pozove, a Harness prosleđuje poziv odgovarajućem MCP serveru. Ovaj dizajn omogućava da se sposobnosti Agenta proširuju bezgranično.

05. Koji je mehanizam Multi-Agent-a?

Jezgro mehanizma se može sažeti na sledeće: složeni zadaci se rastavljaju, a više Agenata sa različitim "ulogama" i "alatima" ih dovršava u saradnji.

  • Više nije jedan model koji radi sve, već se kroz System Prompt različitim agentima dodeljuju specifični identiteti.
  • Čest patern saradnje je Planner-Worker-Reviewer, gde planer raspoređuje i dodeljuje posao izvršiociima.

Planner (planer) je odgovoran da veliki korisnički zadatak razbije na više malih koraka, generišući izvršni plan u JSON formatu, sa opisom svakog koraka i medjusobnim zavisnostima.

Worker (izvršilac) je odgovoran za konkretno izvršenje malih zadataka. Svaki Worker je nezavisan SubAgent, sa svojom istorijom razgovora i sistemskim promptom, bez međusobnog ometanja. Više Worker-a može raditi paralelno.

Reviewer (recenzent) proverava kvalitet Worker-ovog izlaza. Ako nije dovoljno dobar, daje povratnu informaciju i Worker iznova izvršava (najviše 2 ponovna pokušaja).

Zašto nam treba Multi-Agent?

Prvo, probijanje ograničenja konteksta — svako radi svoje, svaki Agent obrađuje samo mali deo konteksta koji je za njega najrelevantniji.

Drugo, model teško otkriva sopstvene logičke greške, ali "posmatrač vidi jasnije" — neka Agent B audituje izlaz Agent-a A, što drastično poboljšava pouzdanost.

Treće, kombinacija više modela. Na primer, neka Opus 4.7 planira, a GPT-5.5 izvršava.

Ovde postoji ključni dizajnerski detalj: izolacija konteksta. Pri pokretanju, svaki Worker kreira nezavisnu istoriju razgovora, ubacuje se samo kontekst relevantan za njegov zadatak, a po završetku se Orchestrator-u vraća samo sažetak rezultata (ne kompletna konverzacija). Prednost je u tome što kontekst koji Worker A stvori čitajući 50 fajlova ne zagađuje prosuđivanje Worker-a B — svako drži pažnju na svom podzadatku.

06. Koji je mehanizam Memory-ja?

Memory mehanizam omogućava modelu da "pamti" šta se dogodilo u prošlosti i da to koristi kao referencu za trenutne odluke.

Bez mehanizma memorije, AI je u svakom razgovoru "amnezičan".

Memory mehanizam = upravljanje kontekstom (Context) + vektorsko pretraživanje (RAG) + automatsko sažimanje (Summarization).

Agent Memory ima dva nivoa: kratkoročna memorija i dugoročna memorija.

Kratkoročna memorija je kontekst trenutnog razgovora.

Svaka poruka korisnika, Agentov odgovor, rezultat izvršenja alata, sve se dodaje u istoriju razgovora.

Dugoročna memorija je informacija koja perzistira između sesija.

PaiCLI-jev LongTermMemory čuva ključne informacije kao što su preferencije korisnika i činjenice o projektu u fajlu ~/.paicli/long_term_memory.json. Na početku svake nove sesije, Agent na osnovu trenutnog unosa pretražuje relevantnu dugoročnu memoriju i ubacuje je u sistemski prompt.

// Agent.java linija 127
String memoryContext = memoryManager.buildContextForQuery(
    userInput, contextProfile.memoryContextTokens());
updateSystemPromptWithMemory(memoryContext);

Težina dugoročne memorije je u "pretraživanju".

Na primer, sačuvali smo 100 sećanja, a sa trenutnim pitanjem su povezane samo 3 — kako precizno pronaći baš te 3?

PaiCLI koristi hibridno pretraživanje: BM25 podudaranje ključnih reči + semantička sličnost. Prvo se ključnim rečima brzo filtrira skup kandidata, zatim se semantičkom sličnošću rangira, i konačno se ubacuje samo nekoliko najbolje rangiranih.

07. Koji je mehanizam kompresije konteksta?

Kada se kratkoročna memorija napuni, stare poruke se moraju odbaciti, ali ključne informacije ne smeju da nestanu.

Kako?

Sažmemo u sažetak i ubacimo nazad.

Strategija kompresije koristi Map-Reduce, po istoj logici kao obrada velikih dokumenata:

Algoritam kompresije je sledeći:

  1. Uslov okidača: kada broj token-a istorije razgovora dostigne 90% prozora konteksta, pokreće se kompresija.
  2. Izbor tačke preseka: pronalaze se pozicije svih user message, zadnje 3 ture korisničkog razgovora se ostavljaju nedirnute, a sve prethodne poruke čine "zonu za kompresiju".
  3. Generisanje sažetka: poruke iz zone za kompresiju se daju LLM-u da generiše jedan koncizan sažetak.
  4. Rekonstrukcija istorije: [system] + [user("Sažetak prethodno komprimirane istorije razgovora\n" + summary)] + [assistant("U redu, kontekst mi je jasan.")] + [poslednje 3 pune ture razgovora].

08. Kako CLAUDE.md omogućava Agentu da brzo savlada projekat?

CLAUDE.md omogućava korisniku da putem jednog markdown fajla kaže Agentu "koja su pravila ovog projekta".

Princip rada je zapravo jednostavan: pri sastavljanju sistemskog prompta, sadržaj CLAUDE.md se ubacuje u njega.

PaiCLI koristi AGENTS.md, ali je princip isti.

U PromptAssembler-u, u koraku dynamicSection("Project Context", ...), pravila i kontekst na nivou projekta se nadovezuju u sistemski prompt.

Pri pisanju CLAUDE.md važi nekoliko principa:

  • Budite konkretni, nemojte biti nejasni. Napisati "koristi uvlačenje od 4 razmaka" je stotinu puta korisnije od "čuvaj konzistentan stil koda".
  • Kontrolisati dužinu. CLAUDE.md zauzima deo prozora konteksta. Ako ga predug, ostaje manje prostora za stvarni posao. U PaiCLI-jevom dizajnu, ubacivanje konteksta projekta ima strogi token budžet: memoryContextTokens = min(5000, window/200).
  • Slojevito učitavanje. Claude Code podržava tri nivoa pravila: globalni ~/.claude/rules/, nivo projekta .claude/settings.json, i CLAUDE.md na nivou fajla. PaiCLI ima sličnu trostruku strukturu: ugrađeni < korisnički globalni (~/.paicli/) < nivo projekta (.paicli/). Prioritet ide od niskog ka visokom, konfiguracija na nivou projekta prepisuje globalnu.

Priručnik za intervju

Evo još nekoliko stvarnih pitanja sa intervjua i usmenih verzija odgovora koje možete naučiti napamet.

Opišite projekat vezan za AI Agent u kom ste učestvovali, uz objašnjenje vaše uloge i doprinosa?

Samostalno sam razvio PaiCLI, Java-bazirani AI Agent CLI alat, čije je interaktivno iskustvo veoma blizu Claude Code-u. Jedini sam developer, od arhitektonske dizajna do implementacije svih modula, sve sam odradio sam.

Osnovna arhitektura je LLM + Harness pattern, Agent klasa je jezgro Harness-a i pokreće standardnu ReAct petlju: poziva se veliki model → procenjuje da li je alat potreban → izvršava se alat → rezultat se vraća u istoriju razgovora → ponovo se poziva veliki model, sve dok zadatak nije završen.

Memory mehanizam: PaiCLI implementira dvoslojni sistem memorije. Kratkoročna memorija je lista poruka trenutnog razgovora, koristi LinkedHashMap za FIFO izbacivanje; dugoročna memorija perzistira informacije kao što su korisničke preferencije i činjenice o projektu u lokalni JSON fajl, a pri svakoj novoj sesiji se na osnovu trenutnog unosa radi hibridno pretraživanje (BM25 ključne reči + semantička sličnost) i najrelevantnija sećanja se ubacuju u sistemski prompt.

RAG modul: PaiCLI koristi JavaParser da seče kod u tri nivoa — fajl/klasa/metod, a zatim preko Ollama-e ili udaljenog API-ja vektorizuje i čuva u SQLite. Pri pretraživanju se koristi hibridno bodovanje — semantička sličnost + podudaranje ključnih reči + ponderisanje po tipu bloka koda (najveći ponder na nivou metoda) + bonus za dvostruko pogođeno, da se spreči da jedan veliki fajl monopolizuje rezultate.

Multi-Agent saradnja: PaiCLI implementira trojnu arhitekturu Planner-Worker-Reviewer. AgentOrchestrator koordinira, Planner razbija veliki zadatak u JSON izvršni plan, više Worker-a paralelno izvršava na osnovu zavisnosti, Reviewer proverava kvalitet izlaza i odbacuje nazad ako nije dovoljno dobar (najviše 2 puta). Samo Worker ima pravo poziva alata, Planner i Reviewer izbacuju samo čisti JSON, čime se uloge drže jasnim.

Chrome DevTools MCP je jedna od istaknutih tačaka PaiCLI-ja. Integracijom chrome-devtools-mcp-a, Agent može direktno da upravlja pregledačem — screenshot, klik, popunjavanje formulara, izvršavanje JS. Alat se automatski registruje u formatu mcp__chrome-devtools__*, a veliki model samostalno procenjuje na osnovu opisa alata kada da ga pozove.

Još zanimljivije je ponovno korišćenje CDP login stanja. Podrazumevano, Agent pokreće izolovani pregledač (nezavisan user-data-dir), pa na stranice koje zahtevaju prijavu ne može da uđe. PaiCLI-jev pristup je: kada Agent detektuje login zid, automatski se prebacuje u deljeni režim (--autoConnect), preko Chrome-ovog DevToolsActivePort fajla otkriva instancu pregledača koju korisnik već koristi i direktno koristi postojeće login stanje.

Šta mislite o ReAct framework-u?

ReAct omogućava da rezonovanje i delovanje smenjuju.

Veliki model na svakom koraku prvo vraća proces rezonovanja (analiza trenutnog stanja, planiranje sledećeg koraka), a zatim konkretnu akciju (poziv alata). Nakon što alat vrati rezultat, veliki model ponovo rezonuje o sledećem koraku.

Ova petlja traje dok veliki model ne oceni da je zadatak završen.

ReAct se može napustiti na dva načina:

  • prvi, LLM u nekoj turi ne vrati tool_call, što znači da smatra da je zadatak završen;
  • drugi, potroši se token budžet ili se detektuje beskonačna petlja, pa Harness prinudno prekine.

PaiCLI-jev AgentBudget je zadužen za drugi način izlaska — prati ukupnu potrošnju input + output token-a, i prekida kada se pređe maxContextWindow × 0.8.

U AI Agent-u, koje tipove memorije obično razlikujemo?

Razlikujemo kratkoročnu i dugoročnu memoriju. Kratkoročna memorija je lista poruka trenutnog razgovora, sadrži korisnički unos, Agent-ove odgovore i rezultate izvršenja alata, briše se po završetku sesije. Dugoročna memorija je informacija koja perzistira između sesija, čuva stabilna znanja kao što su preferencije korisnika i činjenice o projektu, a po svakom novom razgovoru se pretražuje po relevantnosti i ubacuje.

Pri razvoju Agent-a, kako dizajnirate promptove da poboljšate stabilnost i tačnost izvršenja zadataka?

Na tri nivoa.

Prvo, slojevito sastavljanje: sistemski prompt se razbija na sloj identiteta, sloj sposobnosti, sloj strategije, sloj konteksta, svaki sloj se održava nezavisno i kombinuje fleksibilno.

Drugo, ograničenja napred: restrikcije (sigurnosne strategije, ograničenja putanja, zabranjene operacije) se pišu na početku prompta, jer veliki model veću pažnju posvećuje sadržaju na početku.

Treće, dinamičko ubacivanje: na osnovu tipa trenutnog zadatka, konteksta projekta i relevantnih sećanja, dinamički se prilagođava sadržaj prompta, umesto da se jedan fiksni prompt koristi za sve scenarije.

Kada biste implementirali jednostavno upravljanje stanjem razgovora u više tura, koje ključne elemente biste razmotrili?

Četiri elementa.

Prvo, standardizacija formata poruka: svaka poruka mora imati jasnu oznaku uloge (system/user/assistant/tool), a tool poruka mora nositi tool_call_id uparen sa prethodnim pozivom.

Drugo, upravljanje prozorom konteksta: potrebna je strategija kompresije/odsecanja koja automatski kompresuje rane poruke kada ukupan broj token-a poruka priđe gornjoj granici prozora.

Treće, konzistentnost stanja: tool_call i tool_result se moraju pojavljivati u paru, tačka preseka kompresije ne sme prekinuti taj odnos uparivanja.

Četvrto, mehanizam otkazivanja: podrška za korisničko otkazivanje na pola zadatka, while petlja Agent-a proverava flag otkazivanja pre svake iteracije.