Intervjuer: „Vidim u biografiji da radis terminal Agent-a, onda mi reci — Prompt sklapanje, kompresija konteksta, razlika izmedu Tool i Skill, orkestracija vise Agent-a, dizajn Plan-a?” U sebi sam se potajno obradovao, krenuh da recitujem.
Video sam jednu ovakvu ispovest.
U Trip.com-u 4 godine, mesecna plata oko 30000, radno mesto u istrazivanju i razvoju, uglavnom bez povisice. Ali toliko godina sam prilicno zadovoljan, na kraju krajeva stabilno, beneficije i tretman su takode dobri.
U danasnje brze AI ere, covek koji moze da izgovori rec „zadovoljan”, zaista mu se divim.
Pogledajte oko sebe, da li se svako takmici? Ujutro je izasao novi model pa da ga testiramo, u podne je izasao novi Work pa da ga isprobamo. Tempo cele industrije je tako brz kao da jurimo poslednji autobus, svako juri neprekidno, opsesivno napred.
Ali ovaj covek kaze, zadovoljan, stabilno, beneficije dobre.
To mi je pri srcu.
Poslednje dve godine AI je ubrzao tempo previse, toliko brzo da su svi zaboravili jednu stvar — ljudi bi trebalo da imaju i zivot. Završavati na vreme, ne raditi prekovremeno vikendom, nocu ne odgovarati na poruke, zar to ne bi trebalo da budu stvari kojima tezimo?
Po meni, stabilnost je najbolji stav za ucenje. U svakom slucaju, samo kada je spoljasnja sredina povoljna imam raspolozenje za rad, tek onda zelim da ucim nove stvari.
I ako vi cznostite za stabilnoscu, a pritom zelite da naucite nove AI stvari u stabilnom raspolozenju i ritmu, onda sledeca pitanja sa Agent intervjua mozete pazljivo procitati.
(Ceo tekst je prilicno intenzivan, garantujem da cete nauciti mnogo, vezite sigurnosne pojaseve, idemooo.)
content
PS: PaiCLI je terminal Agent slican Claude Code-u, otvorenog koda. Ako zelis iskustvo sa Agent projektom, mozes referencirati.
GitHub: https://github.com/itwanger/PaiCLI-Python
01. Sta je posebno kod Claude Code-a i Codex-a?
Stari Wang otvori pitanja za intervju, pita direktno: „Da li si koristio i Claude Code i Codex? Sta je posebno kod svakog?”
„Oba sam koristio. Ova dva proizvoda imaju potpuno razlicite pravce.”
„Claude Code je terminal Agent koji radi Anthropic, najveca osobina mu je interakcija u stvarnom vremenu, savrseno se uklapa sa AI erom, ne zahteva IDE pa moze da zavrsi Coding posao. U terminalu mu date zadatak, onda on cita kod, menja datoteke, pokrece komande, ceo proces je vidljiv i moze se prekinuti i ispraviti u svakom trenutku. Za sada, Claude Code je najjaci terminal Agent, bez konkurencije.”
„Codex je desktop Agent koji radi OpenAI, ide asinhrono multi-threading, vizualizacija je jaca od Claude Code-a.”
„Ja licno sam tezak korisnik oba, Claude Code uz Opus model je jaci u domenu teksta, jaci u ukupnoj arhitektonskoj sposobnosti. Codex vise volim uz GPT-5.6 Sol za razvoj koda i generisanje slika, narocito zadatke koji trose Token-e preputam njemu.”
02. Od kojih se delova sastoji prompt koji ulazi u model?
„U Agent-u koji si radio, kako se sklada prompt koji ulazi u model? Koji delovi se obavezno ubacuju, a koji ne?”
„Sklapanje prompt-a ide slojevitim spajanjem, ukupno 9 slojeva, slazu se u fiksnom redosledu.”
„Prva 4 sloja su staticna, tokom cele sesije se ne menjaju.”
- Prvi sloj je definicija identiteta, ukljucuje semu alatki, sigurnosnu strategiju, kodeks ponasanja, ovaj sloj se obavezno ubacuje, bez njega model ne zna ni ko je, a kamoli koje alatke moze da koristi.
- Drugi sloj je licnost, kontrolise ton i stil.
- Treci sloj je rezim, prema trenutnoj putanji izvrsenja ucitava razlicite setove instrukcija, ReAct, Plan, Team tri rezima svaki po jedan set.
- Cetvrti sloj je odobrenje, definise koji pozivi alatki zahtevaju korisnicku potvrdu.
„Poslednjih 5 slojeva su dinamicki, u svakom krugu se mogu promeniti. Kontekst izvrsavanja (datum, vremenska zona), memorija projekta, Skills indeks, strategija upravljanja kontekstom, instrukcije za zavrsetak.”
„Obavezno se ubacuju sloj identiteta i sloj rezima — model mora da zna ko je i u kom rezimu izvrsenja trenutno radi. Licnost, Skills indeks, memorija projekta nisu obavezni, bez njih model moze da radi, ali iskustvo ce biti znatno gore. Na primer, bez Skills indeksa, model ne zna koje gotove vestine moze da ucita, kada naidje na problem moze samo sam da razmislja.”
Zasto se staticni sadrzaj stavlja na sam pocetak?
„Zbog Prompt Caching-a.”
„Prompt Caching pogadja po najduzem zajednickom prefiksu. Prva 4 sloja su staticni sadrzaj, stavljaju se na sam pocetak prompt-a, u svakom krugu zahteva je prefiks isti, stopa pogotka kesa se moze maksimizovati. Ako se dinamicki sadrzaj ubaci napred, prefiks se menja u svakom krugu, kes uglavnom ne pogadja, trosak tokena bi bio nekoliko puta veci.”
03. Koja je razlika izmedu tvog coding agent-a i Claude Code-a i Codex-a?
„Claude Code je zlatni standard terminal Agent-a.”
Ali tokom koriscenja ovih alata pojavio se jedan upit — kako zapravo rade ispod haube?
Kako razume moje instrukcije, kako odlucuje koju datoteku da cita, kako ocenjuje koju alatku da pozove, kako upravlja kontekstom u visekrupnim razgovorima.
Otkrio sam da ako samo umem da koristim ove alate ali ne razumem njihov dizajn ispod haube, kada alat ne radi dobro (na primer Agent izabere pogresnu alatku, kontekst izgubi kljucnu informaciju, generisani kod ne odgovara stilu projekta) mogu samo da pokusam da preformulisem pitanje, a ne mogu iz perspektive principa da ocenim gde je problem.
Zato sam odlucio da sam od nule implementiram jedan Agent CLI, da ReAct petlju rezonovanja, Tool Calling, upravljanje Memory-jem, MCP protokol ovih kljucnih modula napisem sam.
Nakon sto sam zavrsio, za svaki sloj Agent sistema imam razumevanje na nivou izvornog koda, kada sam se vratio Claude Code-u jasno sam osetio da mi se sposobnost upravljanja alatom poboljsala — znam koje instrukcije cine da Agent tacnije razume moju nameru, znam u kom scenariju treba rucno da kompresujem kontekst, znam kako da dizajniram opis Tool-a da poboljsam tacnost poziva.
04. Kako se radi kompresija konteksta?
Stari Wang se nagnuo napred, nastavio je da pita: „Spomenuo si kompresiju konteksta, kako se konkretno radi?”
„Trostruka kompresija, svaki sloj obradjuje sadrzaj razlicite granularnosti.”
„Prvi sloj je skracivanje rezultata alatki. Ako sadrzaj koji alatka vrati u jednom pozivu premasi prag — na primer grep izbaci nekoliko hiljada redova — direktno se skracuje, cuvaju se pocetak, kraj i kljucne informacije, sredina se zamenjuje sazetkom. Ovaj sloj deluje odmah, cim alatka vrati obradjuje se.”
„Drugi sloj je sazetak istorije razgovora. Kada broj tokena celog razgovora pridje gornjoj granici prozora konteksta, zadrzavaju se poslednje tri-cetiri runde kompletog razgovora, starija istorija se jednim LLM pozivom kompresuje u sazetak. Sazetak cuva cetiri vrste kljucnih informacija: korisnicko jezgro zahteva, operacije koje je Agent zavrsio, dogovoreni konsenzus, jos nereseni zadaci.”
„Treci sloj je hitna degradacija. Ako nakon kompresije sazetkom broj tokena i dalje premasuje ogranicenje, po prioritetu se odbacuje nekljucni kontekst — Skills indeks, nekljucne memorije, delovi memorije projekta niskog prioriteta, da se napravi prostor za kljucni razgovor.”
05. Zasto se usvaja strategija trostruke kompresije? Da li je sadrzaj kompresije isti u svakom sloju?
„Dizajn ideja je granularnost od fine ka gruboj, uslov okidanja od sirokog ka strogom.”
„Prvi sloj obradjuje redundansu na nivou jedne poruke, uslov okidanja je najsiri — svaki put kad se alatka vrati proverava se, ako premasi, skracuje se. Cena je skoro nula, ne zahteva LLM poziv.”
„Drugi sloj obradjuje sirenje na nivou istorije razgovora, uslov okidanja je da broj tokena premasi oko 80% prozora konteksta. Kod prozora od 200k izaziva se oko 167k. Ovaj sloj zahteva jedan LLM poziv za sazetak, ima cenu, zato ne radi suvise cesto.”
„Treci sloj je poslednja linija odbrane, pokrece se samo kada prva dva ne budu dovoljna. Odbacuju se oporavljive pomocne informacije — Skills indeks se moze ponovo ucitati, memorija projekta se moze ponovo pretrazivati — kljucni sadrzaj razgovora se ne dira osim ako nema druge.”
„Sadrzaj kompresije tri sloja je potpuno drugaciji. Prvi sloj kompresuje izlaz alatki, drugi sloj kompresuje istoriju razgovora, treci sloj odbacuje pomocni kontekst. Ako se koristi samo jedan sloj opste kompresije, ili se kompresuje previse rano i trosi prostor konteksta, ili previse kasno i izaziva gresku prekoracenja.”
06. Ako je kompresija prejaka i rezultat nije dobar, kako se otkriva i kako se tretira?
„Pomocu dva signala.”
„Prvi je neuobicajeno ponasanje. Model pocinje da ponavlja stvari koje je vec uradio — na primer cita datoteku koju je pre deset minuta vec procitao, pa je cita ponovo. Ili model direktno kaze „nisam siguran sta smo ranije diskutovali”, to znaci da je kompresija izgubila kljucne informacije.”
„Drugi je pad stope uspesnosti zadataka. Isti tip zadatka koji je ranije mogao da se zavrsi, posle nekoliko rundi kompresije pocinje da ne uspeva, verovatno je kontekst izgubio kljucni sadrzaj.”
„Tretman ima tri sredstva.”
Prvo, dinamicko podesavanje broja zadrzanih rundi. Podrazumevano se zadnjih 3 runde ne kompresuju, ako se otkrije anomalija, privremeno se prosiruje na 5 rundi.
Drugo, obelezavanje kljucnih informacija. Zahtevi koje je korisnik izricito dao, potvrdjene tehnicke sheme, obelezavaju se kao nekompresibilni, pri sazimanju se preskacu.
Trece, pre kompresije se pravi rezerva originalne istorije, ako se ispostavi da rezultat nije dobar moze se vratiti na stanje pre kompresije, sa konzervativnijom strategijom se kompresuje ponovo.
07. Kako radi sistem za inkrementalne izmene? Koje informacije treba ponovo ubaciti?
„Ide preko Plan mehanizma pregleda.”
„Nakon sto Agent generise plan izvrsenja, korisnik ga moze pregledati. Ako treba dodati novu funkciju, korisnik bira „dopuni zahtev”, salje se opis novog zahteva. Sistem uz originalni plan i novi zahtev zajedno ih predaje planeru, da generise novi plan.”
„Ponovo ubacene informacije su u tri bloka: opis originalnog zadatka, sazetak zavrsenih koraka, dopuna novog zahteva. Zavrseni koraci se ne izvrsavaju ponovo, planer na osnovu trenutnog napretka rasporedjuje naredne korake.”
Zasto se ne doda direktno na originalni plan, vec se ponovo planira?
„Zato sto novi zahtevi mogu promeniti zavisnosti postojecih zadataka.”
„Na primer, originalni plan je „prvo kreiraj tabele baze, zatim napis CRUD interfejs”. Korisnik dopuni „dodaj kes sloj”. To nije prosto dodavanje zadatka kesa na kraj — logika implementacije CRUD interfejsa se menja, operacija citanja prvo proverava kes pa onda bazu, operacija pisanja sinhrono azurira kes. Ako se samo doda, ranije napisani kod interfejsa nije vise tacan.”
„Ponovno planiranje omogucava planeru da videlielinu, ponovo rasporedi zavisnosti i redosled izvrsenja, izbegava da naredni koraci budu zasnovani na pogresnoj pretpostavci.”
08. Kako izgleda proces poziva alatki?
Stari Wang okrene stranicu beležaka, nastavi: „Pričaj mi o pozivu alatki, koji je kompletan proces?”
„Tri faze.”
„Prva faza, LLM generiše tool_call. Nakon što model vidi šematsku definiciju alatke, na osnovu trenutnog zadatka odlučuje koju alatku da pozove, koje parametre da prosledi, izbacuje strukturirani tool_call zahtev.”
„Druga faza, strateško odobrenje. Operacije pisanja (izmena datoteka, pokretanje komandi) prolaze sigurnosnu proveru — da li je putanja u dozvoljenom opsegu, da li je komanda na crnoj listi. Operacije koje zahtevaju korisničku potvrdu se pauziraju dok se odobrenje ne dobije.”
„Treća faza, izvršenje. Jedna alatka se izvršava direktno, više alatki može paralelno, gornja granica thread pool-a je 4 konkurentna. Rezultat izvršenja se kao tool poruka dodaje u istoriju razgovora, LLM na osnovu rezultata odlučuje sledeći korak. Ceo proces je jedna petlja: generisanje → odobrenje → izvršenje → rezultat nazad modelu → nastavi generisanje, sve dok model ne smatra da je zadatak završen.”
Da li Skill može da zameni alatke?
Ne može, te dve stvari su potpuno različite.
| Dimenzija | Tool (alatka) | Skill (veština) |
|---|---|---|
| Suština | Izvršna sposobnost — čita datoteke, pokreće komande, pretražuje kod | Znanje za odlučivanje — kako koristiti alatke, koja strategija, koja pravila |
| Način poziva | LLM poziva preko tool_call protokola | LLM poziva load_skill, sadržaj se ubacuje u sledeću poruku |
| Sadržaj koji se vraća | Strukturirani rezultat (sadržaj datoteke, izlaz komande) | Markdown instrukcije (znanje na nivou prompt-a) |
| Životni ciklus | Jednokratan poziv, po završetku odlazi | Nakon učitavanja ostaje u kontekstu, kontinuirano utiče na naredne odluke |
„Tool je ruka, Skill je iskustvo u glavi. Ne možeš iskustvom da zameniš ruku da zavrneš šraf, ni rukom da zameniš iskustvo da oceniš koji šraf da zavrneš. One su u komplementarnom odnosu, ne u odnosu zamene.”
09. Pričaj o svojim Skills-ima, koje imaš?
„Jezgro dizajna je progresivno otkrivanje, uči se u tri sloja.”
„Prvi sloj je indeks. Samo ime Skill-a i opis u jednoj rečenici idu u system prompt, drži se ispod 4KB, najviše 20 Skill-ova. Ovaj sloj stalno boravi u kontekstu, cena je niska.”
„Drugi sloj je telo. Nakon što LLM vidi indeks, ocenjuje koji Skill je potreban za trenutni zadatak, poziva jedan load_skill alatom da dobije pune instrukcije, gornja granica za telo pojedinačnog Skill-a je 5KB. Učitani Skill ide u LRU bafer, istovremeno se drži najviše 3, višak se izbacuje po principu najduže nekorišćenog.”
„Treći sloj je referentna dokumentacija. Neki Skill-ovi imaju sopstveni direktorijum referentne dokumentacije, učitava se samo kada instrukcija Skill-a to izričito zahteva.”
Zašto se ne učitava sve odjednom?
Što je system prompt duži, to je stopa pogađanja Prompt Caching-a niža. Ogromna većina razgovora koristi samo jedan ili dva Skill-a, potpuno učitavanje znači da korisnik plaća trošak tokena za sadržaj koji ne koristi.
„Skill-ovi imaju tri prioriteta porekla: ugrađeni, korisnički nivo, projektni nivo, od niskog ka visokom se nadjačavaju. Projektni Skill može da nadjača ponašanje ugrađenog Skill-a istog imena, bez izmene izvornog koda.”
10. Koliko puta je model pozvao alatke? Koliko puta Skill?
„To zavisi od složenosti zadatka, reći ću tipičan scenario.”
„Na primer zadatak poput „dodaj mi paginirani interfejs u projekat”, model mora otprilike da pozove alatku 10 do 15 puta — čita strukturu projekta, čita postojeći kod interfejsa, čita model baze, piše novi interfejs, piše testove, pokreće testove, popravlja bug-ove, svaki korak je jedan poziv alatke. Skill, verovatno učita jedan vezan za standard koda, jednom.”
„Učestalost poziva alatki je daleko veća od učitavanja Skill-a, otprilike u odnosu 10:1 do 20:1. Zato Skill ide postupno učitavanje — učestalost korišćenja nije visoka kao kod alatki, nema potrebe da sve stalno boravi u kontekstu.”
Scenarijska pitanja
11. Za kompleksan zadatak, kako tvoj coding agent radi plan?
Stari Wang zatvori kapicu hemijske, promeni pravac: „Da rešimo jedno scenarijsko pitanje. Ako dođe kompleksan zadatak, kako bi tvoj Agent radio plan?”
„Prvo se oceni da li zadatak zaista zahteva plan. Jednostavni zadaci — na primer „promeni ovo ime promenljive” — idu direktno ReAct režimom, u jednom koraku, ne zahtevaju planiranje.”
„Kompleksni zadaci idu Plan-and-Execute režimom. Nakon što planer primi korisnički zadatak, generiše JSON plan sa zavisnostima. Svaki podzadatak ima id, opis, tip i listu zavisnosti.”
„Nakon što je plan generisan, prvo se radi topološko sortiranje, da se potvrdi da nema kružnih zavisnosti. Zatim se po zavisnostima izvršava u grupama — zadaci bez zavisnosti mogu paralelno, oni sa zavisnostima čekaju da se prethodni završe.”
„Korisnik može da pregleda plan pre izvršenja, ako mu se ne sviđa može da ga prilagodi, može i da dopuni zahtev da planer da novo rešenje.”
Kako se konkretno radi orkestracija više Agent-a?
„U Team režimu postoje tri uloge.”
„Planer je zadužen da razloži zadatak u plan izvršenja sa zavisnostima, samo razmišlja, ne dira alatke. Worker je radna uloga, ima nezavisnu istoriju razgovora i kompletan set alatki, ista grupa zadataka bez zavisnosti se može podeliti različitim Worker-ima paralelno, podrazumevano najviše 2 Worker-a istovremeno. Pregledač kontroliše kvalitet, nakon što Worker završi pregledač proverava isporuku, ako nije na nivou vraća na prepravku, najviše dva puta.”
Koja je razlika između svakog pod-Agent-a?
„Razlika je u dve dimenzije: sistemski prompt i istorija razgovora.”
„Svaka uloga ima svoj sistemski prompt, učita se preko različitog režima — planerov prompt mu kaže „ti si zadužen samo za razlaganje zadataka, ne smeš da zoveš alatke”, Worker-ov prompt mu kaže „ti si zadužen za izvršenje konkretnih koraka, alatke koristiš slobodno”, pregledačev prompt mu kaže „ti si zadužen za kontrolu kvaliteta, da oceniš prolaz ili vraćanje”.”
„Istorija razgovora je potpuno izolovana. Svaka uloga vidi samo svoje interakcije, Worker-1 ne zna šta Worker-2 radi, pregledač ne vidi kako planer razmišlja. Svaka uloga se fokusira samo na informacije iz svog domena, kontekst je čist, lako ne ometaju jedni druge.”
Zašto ovakav dizajn? Mogu li svi pod-Agent-i da dele alatke?
„Alatke same po sebi se dele. Tri uloge koriste isti registar alatki, 11 ključnih alatki plus MCP dinamičke alatke, tehnički sve uloge mogu da im pristupe.”
„Ali planer i pregledač ne pozivaju alatke, to je ograničeno preko prompt-a, nije da tehnički ne mogu. U dizajnu namerno ne smeju da diraju alatke, razlog je izolacija uloga — ako pregledač ima pravo izvršenja alatki, kada uoči problem u Worker-ovom kodu, mogao bi sam da ga popravi. Posle pregleda sopstveni kod, to bi bilo da je i igrač i sudija.”
„Pravo izvršenja alatki je koncentrisano u Worker-u, planer i pregledač samo ocenjuju. Ako dođe do problema lako se locira — kod nije dobar nađi Worker-a, plan je nerazumno rasčlanjen nađi planera, propust u proveri nađi pregledača, granice odgovornosti su potpuno jasne.”
ending
Ranije smo kad smo tražili posao konkurisali memorisanjem formuli, bubali konkurenciju, middleware, dizajn patern. Sada intervjueri pitaju kako se sklada prompt, kako se kompresuje kontekst, koja je razlika između Tool i Skill, kako se orkestrira više Agent-a.
[Tehnološki stek se menja, pitanja na intervjuu se menjaju, ali jedno se ne menja — ljudi sa stabilnim mindset-om brže uče sve.]
AI upravo preustrojava mapu sposobnosti inženjera, ovaj proces tek počinje. Ne žuri, svakodnevni napredak za malo je dovoljan.
Krenimo sa Napredniim Agent formulama.
Držite se, braćo i sestre.
Vidimo se sledeći put.