Tencent prvi krug, ja sam drsko uzvratio pitanjem: "Kažete da radite Agent projekte, recite mi kako radite SubAgent, Plan režim, pozive Skill-a?" Intervjuer se stalno brisao o čelo.

Marko Marković3208 reči11 minuta

Niste li primetili — sve kompanije koje rade velike modele takmiče se u terminal Agentima, uključujući Qoder CLI, Kimi Code, ZCode i tako dalje.

Da ne pominjem Claude Code i Codex CLI.

I ja sam od nule do jednog sašio sopstveni, pod imenom PaiCLI — ima raznih verzija, ispod je screenshot Python verzije.

Cilj mi je da sa vama prođemo kroz ključnu tehničku građu iz ere Agenata: ReAct, Function Calling, RAG, MCP, Multi-Agent, Memory, kompresija konteksta i slično.

Izvorni kod je potpuno open source, na GitHub-u: https://github.com/itwanger/PaiCLI-Python

Takođe sam u vezi sa PaiCLI izvornim kodom pripremio 16 visoko-frekventnih pitanja za Agent intervjue — ako ih naučite napamet, sigurno ćete oduševiti intervjuera.

Opišite projekat PaiCLI i njegov tok rada?
Da li ste implementirali pod-Agenta?
Da li podržavate pozadinske zadatke?
Da li pod-Agent takođe podržava Plan režim?
Kako pod-Agent poziva Skill?
Kako je organizovan sistem slojevitosti Skill-a i zašto tako?
Kako korisnički unos uparite sa odgovarajućim Skill-om?
Da li postoji mehanizam za akumulaciju Skill-ova? Ili korisnik mora sam da ih pravi?
Kako su dizajnirane kratkoročna i dugoročna memorija?
Zašto nam trebaju i statička i dinamička dugoročna memorija?
Kada se aktivira skladištenje dugoročne memorije? Da li se dešava da korisnikova dugoročna memorija brzo raste ida se previše nagomilava?
Kako veliki model odlučuje da li dugoročnu memoriju treba prizvati?
Kako funkcioniše mehanizam kompresije? Koliki je ukupan token prozora konteksta? Zašto je gornja granica okidača izabrana baš tako?
Objasnite dinamički prompt i statički prompt?
Koji je osnovni model? Na primer, za pisanje hiljadu redova koda, koliko token-a se potroši? Koja je cena? Koja je cena po milionu token-a koju koristite?
Da li svakodnevno koristite svoj PaiCLI?

(Tekst je opsežan, ali garantujem da ćete naučiti mnogo toga. Vezite sigurnosni pojas, idemo.)

content

01. Opišite projekat PaiCLI i njegov tok rada

Stari Wang otvara direktno: "U biografiji ti piše PaiCLI projekat, u poređenju sa Claude Code-om? Prvo ga predstavi."

Kažem: "PaiCLI je Agent komandna linija napisana u Python-u, jezgro arhitekture je ReAct petlja."

Korisnik u terminalu unese zadatak, PaiCLI prosleđuje zadatak velikom modelu, koji odlučuje da li da pozove alat, koji i sa kojim parametrima.

Po završetku alata, rezultat se vraća velikom modelu, koji zatim odlučuje o sledećem koraku. Sve dok veliki model ne oceni da je zadatak završen i vrati konačan odgovor.

"PaiCLI ima tri režima rada."

Podrazumevani je ReAct režim, za svakodnevne jednostepene zadatke — izmena fajla, pokretanje komande.

Izvršavanje /plan ulazi u Plan-and-Execute režim, koji prvo razbija složeni zadatak u više koraka, a zatim ih izvršava korak po korak.

/team ulazi u Multi-Agent režim, gde više Agenata deli posao i sarađuje.

"Na nivou alata, ugrađeno je 9 ključnih alata: čitanje i pisanje fajlova, izvršavanje komandi, pretraga koda, pregled direktorijuma, web pretraga. Preko MCP protokola mogu se priključiti i spoljašnji alati, kao što su upravljanje pregledačem, upiti nad bazom podataka."

02. Da li ste implementirali Sub-agenta? Kako se orkestrira?

Stari Wang nastavlja: "Kako orkestriraš u Multi-Agent scenarijima?"

"Planer (Planner) prihvata korisnički zadatak i razbija ga u skup izvršnih koraka sa medjusobnim zavisnostima."

"Na primer, korisnik kaže 'refaktoriši ovaj modul i napiši testove', planer razbija na: korak 1 analizira postojeću strukturu koda, korak 2 izvršava refaktoring (zavisi od koraka 1), korak 3 piše jedinične testove (zavisi od koraka 2), korak 4 pokreće testove za verifikaciju (zavisi od koraka 3)."

"Ovi koraci su organizovani kao DAG (usmereni aciklični graf). Orkestrator radi topološko sortiranje, pronalazi sve korake čije su zadovoljene zavisnosti i prosleđuje ih izvršiocu (Worker) paralelno."

Worker pool je podrazumevano 2, koristi asyncio.Queue — ko je slobodan taj preuzima posao, izbegava se gomilanje na jednom izvršiocu.

"Po završetku svakog koraka, recenzent (Reviewer) pregleda rezultat i izbacuje JSON strukturu koja sadrži prolazi li, listu problema i sažetak."

Koraci koji ne prođu reviziju izvršavaju se ponovo sa povratnom informacijom recenzenta, najviše 2 ponovna pokušaja.

Ako ukupan napredak padne ispod 50% pri uzastopnim neuspesima, orkestrator okida preplaniranje — planer bira drugačiji pristup razbijanju.

Stari Wang klima glavom: "Kako je rešena izolacija između izvršilaca?"

"Svaki izvršilac ima nezavisnu istoriju poruka i bafer za Skill kontekst. Pri paralelnom izvršavanju, izlaz svakog ide u nezavisni bajt-bafer, a nakon što svi završe, spaja se u terminal u originalnom redosledu, čime se osigurava da prikaz neće biti pomešan."

03. Da li podržavate pozadinske zadatke?

Stari Wang pita: "Može li Agent u prvom planu istovremeno da pokrene pozadinske zadatke?"

"Može. Pozadinski zadaci koriste SQLite za perzistentni red."

"Mašina stanja je queued → running → completed ili failed ili canceled."

Nakon što Worker preuzme zadatak, obnavlja zakup preko otkucaja srca. Ako Worker padne, po isteku tekućeg perioda drugi Worker može preuzeti taj zadatak.

"Na pokretanju postoji i oporavak od pada: skeniraju se svi zadaci u running stanju sa isteklim zakupom i resetuju na queued radi ponovnog stajanja u red. Tako čak i pri nenormalnom izlasku procesa, nedovršeni zadaci se ne gube."

04. Da li Sub-agent takođe podržava Plan režim? Kako se poziva Skill?

Stari Wang pita: "Može li izvršilac u Multi-Agent ići u Plan režim?"

Kažem: "Može. Svaki korak izvršenja ima polje mode, vrednost može biti react ili plan."

Planer pri razbijanju zadatka može proceniti da li je neki korak dovoljno složen da zahteva Plan režim.

"Tok Plan režima je: prvo se poziva planer da generiše izvršni plan u JSON formatu, gde svaki korak ima id, opis, tip i listu zavisnosti."

Postoji jednostavna detekcija zadataka — ako korisnički unos nije duži od 30 znakova i ne sadrži višekoračne tragove kao 'onda', 'i', 'zatim', preskače se LLM planiranje i direktno generiše jednokoračni plan, štedeći jedan LLM poziv.

"Plan prolazi kroz topološko sortiranje radi određivanja redosleda izvršenja. Koraci bez medjusobnih zavisnosti paralelno se izvršavaju preko asyncio.gather, oni sa zavisnostima idu serijski."

Kako Sub-agent poziva Skill?

Stari Wang odmah ponavlja: "Kako Skill radi unutar Sub-agenta?"

"U sistemski prompt se ubacuje indeks Skill-ova, koji sadrži ime i opis svih aktiviranih Skill-ova, najviše 20, ukupna veličina do 4KB."

LLM, dok obrađuje zadatak, ako oceni da se trenutni zadatak poklapa sa opisom nekog Skill-a, inicijativno poziva ugrađeni alat load_skill.

"Nakon učitavanja, kompletan sadržaj Skill-a se upisuje u bafer konteksta. Pri sledećem LLM zahtevu, taj sadržaj se automatski ubacuje ispred korisničke poruke. LLM tada dobija priručnik stručnjaka i po njegovom vodiču izvršava zadatak."

"Ključni dizajn: svaki Sub-agent ima nezavisan bafer za Skill, sa LRU strategijom koja kešira najviše 3 Skill-a."

Zato što se nakon ubacivanja sadržaja Skill-a on briše iz bafera (operacija drain) — ako više Sub-agenata dele isti bafer, drain jednog Worker-a bi obrisao sadržaj koji drugi Worker još nije pročitao.

05. Kako je organizovan sistem slojevitosti Skill-a i zašto tako?

Stari Wang kaže: "Razvij mi Skill sistem."

Kažem: "Trostruko učitavanje, po prioritetu od niskog ka visokom: ugrađeni Skill zapakovan u program, korisnički Skill u direktorijumu ~/.paicli/skills/, projektni Skill u direktorijum .paicli/skills/ u korenu projekta. Skillovi sa istim imenom — viši prioritet potpuno prepisuje niži."

"Svaki Skill je jedna fascikla, jezgro je fajl SKILL.md, koji u frontmatter deklaraciji navodi ime, opis, verziju, oznake, a telo je priručnik za odlučivanje namenjen LLM-u. Opcioni references/ direktorijum sadrži referentne materijale, scripts/ sadrži izvršne skripte."

"Zašto ovakva podela?"

Ugrađeni Skill pruža out-of-the-box osnovne sposobnosti, na primer priručnik strategije pregledača za web pristup.

Korisnički nivo služi za prilagođavanje ličnim tokovima rada — na primer, napisao sam Skill za prikupljanje top lista Xiaohongshu-a.

Projektni nivo nosi dogovore tima, na primer specifikacija pregleda koda — nakon što se komituje u repozitorijum, ceo tim ga deli.

Ovaj pristup je u duhu dizajna Claude Code-a, koji takođe ima tri nivoa: ugrađeni Skill, korisnički Skill, projektni Skill.

06. Kako korisnički unos uparite sa Skill-om? Da li postoji mehanizam za akumulaciju?

Stari Wang nastavlja: "Korisnik unese jednu rečenicu — kako znate koji Skill da učitate?"

"Sistem bodovanja. Rezultat svakog Skill-a se računa kao ponderisani zbir četiri dimenzije. Tačno podudaranje imena odmah dodaje 10000 bodova, čime se osigurava da Skill koji je korisnik eksplicitno tražio bude na prvom mestu. Pogodak reči iz imena težište ×12, oznake ×6, reči iz opisa ×2."

"Strategija tokenizacije ima dva skupa — za engleski i za kineski."

Engleski se prevede na mala slova, pa se tokenizuje po razmacima, uz filtriranje stop reči kao što su and, for, the.

"Za kineski ne radimo klasičnu segmentaciju, već uzimamo pojedinačne znakove i klizeći prozor od 2 i 3 znaka, čime pokrivamo većinu kineskih fraza. Na primer 'pregled koda' generiše feature-e kao 'pre', 'gle', 'd', 'ko', 'pregled' itd."

Stari Wang pita još: "Da li Skill mogu samo developeri predefinisati? Ili i korisnik može sam da piše?"

"Korisnik može u ~/.paicli/skills/ kreirati sopstveni direktorijum Skill-a — napiše jedan SKILL.md i stupa na snagu."

Status aktivacije perzistira u skills.json, koji beleži listu onemogućenih (disabled) — podrazumevano su sve omogućene, komandom /skill off se onemogućavaju.

"Trenutno ne postoji automatska akumulacija, na primer automatsko generisanje Skill-a prema navikama korisnika. Glavni razlog je što kvalitet automatski generisanog priručnika za odlučivanje nije kontrolisan, a loše napisan priručnik može navesti LLM na pogrešne poteze."

Istaknute tačke za biografiju

Ako u biografiji pišete o projektu vezanom za Agent, možete ga predstaviti na sledeći način (i ne zaboravite da na GitHub-u date star PaiCLI-ju):

Naziv projekta: PaiCLI

Kratak opis: Python Agent komandna linija koja se može uporediti sa Claude Code-om, podržava promenu modela u toku rada, saradnju više Agenata, sistem Skill i upravljanje memorijom.

Tehnički stek: Python 3.11, asyncio, httpx, SQLite, prompt-toolkit, Rich, MCP.

Ključne odgovornosti:

Na osnovu ReAct implementiran engine Agenta koji podržava više modela, podržava strimovanje i promenu u toku rada za 6 provider-a velikih modela kao što su DeepSeek, GLM, Kimi.
Dizajniran i implementiran Multi-Agent sistem orkestracije (planer/izvršilac/recenzent), putem DAG topološkog sortiranja i asyncio asinhronih redova realizovana paralelna raspodela zadataka sa zavisnostima.
Izgrađen trostruki sistem učitavanja Skill-a (ugrađeni/korisnički/projektni), na osnovu algoritma višedimenzionalnog ponderisanog bodovanja realizovano automatsko rutiranje od korisničke namere do Skill-a.
Dizajniran dvoslojni sistem dugoročne memorije (statička memorija projekta + dinamička SQLite memorija), u sprezi sa SHA256 deduplikacijom i FIFO eviktivnom strategijom za kontrolu rasta memorije.
Implementirana kompresija konteksta na bazi kliznog sažetka, pri 80% praga prozora automatski pokreće kompresiju, čuva celovitost poslednjih 6 tura razgovora i podržava dugačke razgovore sa milion token-a.

07. Kako su dizajnirane kratkoročna i dugoročna memorija?

Stari Wang menja pravac: "Kako radi sistem memorije Agent-a?"

Kažem: "Tri sloja."

"Kratkoročna memorija je istorija poruka trenutnog razgovora. Šta je korisnik rekao, šta je LLM odgovorio, šta su vratili alati — sve to ide u svaku turu LLM poziva. Suštinski je to lista poruka koja stalno raste."

"Dugoročna memorija se čuva u SQLite."

Svako sećanje veže scope (putanja projekta — projektna izolacija), content (sadržaj sećanja), importance (značaj, 0 do 1), confidence (pouzdanost, 0 do 1), access_count (broj priziva), content_hash (SHA256 hes, za deduplikaciju).

"Statička dugoročna memorija je fajl PAI.md. U korenu projekta ili .paicli direktorijumu se postavi PAI.md, a pri pokretanju se automatski učita u sistemski prompt. Funkcija slična Claude Code-ovom CLAUDE.md."

08. Zašto razlikovati statičku i dinamičku dugoročnu memoriju?

Stari Wang nastavlja: "Zašto ih ne sjediniti u jednu?"

"Imaju različitu namenu."

"Statička memorija čuva norme tima i dogovore o projektu — na primer stil koda, strategija grana, proces postavljanja."

Promene su retke, mogu se komitovati u repozitorijum koda, svi članovi tima dele istu verziju. PAI.md takođe podržava uvoz drugih fajlova preko @filename, sa maksimalnim gneždenjem od 3 nivoa i ukupnim budžetom od 16KB, da se izbegne pucanje konteksta."

"Dinamička memorija čuva specifične činjenice korisnika i preference, na primer 'ovaj projekat koristi PostgreSQL umesto MySQL'. Ove informacije se uče i akumuliraju tokom interakcije, čuvaju se po projektima u SQLite."

"Prednost odvojenog čuvanja je jasnoća odgovornosti: statičku memoriju održavaju developeri preko kontrole verzija; dinamičku memoriju Agent automatski upravlja i ne zagađuje repozitorijum koda."

Tokom Prompt montiranja se spajaju i ubacuju u sistemski prompt — statička se prvo učita, dinamička nakon nje.

09. Kada se aktivira skladištenje memorije? Da li se previše nagomilava?

Stari Wang pita: "Kako se aktivira skladištenje dugoročne memorije? Kako se kontroliše rast?"

"Okidač je na dva načina. Korisnik izvrši komandu /save za aktivno čuvanje, ili u razgovoru kaže 'zapamti ovo', 'sačuvaj mi', pa će LLM pozvati ugrađeni alat save_memory i automatski sačuvati."

"Deduplikacija preko content_hash. Posle Unicode normalizacije sadržaja se računa SHA256, pa ako hes već postoji, ne kreira se novi zapis, već se samo importance i confidence ažuriraju na veću vrednost od postojeće i nove."

"Sprečavanje rasta id preko kvotne evikcije. Postavljen je limit max_entries, a pri prekoračenju se vrši kombinovano sortiranje po importance, confidence, access_count i updated_at, uz prioritetsno izbacivanje onih sećanja koja su niskog značaja, niske pouzdanosti i dugo nisu prizvana."

Kako veliki model odlučuje da li dugoročnu memoriju treba prizvati?

Stari Wang nastavlja: "Da li se u svakom razgovoru sva sećanja ubacuju u kontekst?"

"Ne, priziv prema oceni relevantnosti. Pre svakog LLM zahteva, korisnička poruka se koristi kao upit, za svako sećanje se pojedinačno računa bod i uzima se najboljih 6 za ubacivanje u kontekst."

"Formula bodovanja je višedimenzionalno ponderovana."

Pokrivenost rečnikom čini 72% — iz upita i sadržaja se izdvaju feature-i reči, računa se udeo preseka, plus dodatni bonus za potpuno podudaranje podstringa.

Značaj čini 12%, pouzdanost 8%, vremensko opadanje 6% (pola života 30 dana — sećanju koje 30 dana nije ažurirano vremenski bod opada na polovinu), frekvencija pristupa 2% (log funkcija za izglađivanje, da se izbegne monopolizacija rang-liste sećanjima visoke frekvencije).

"Prag priziva je 0.05. Ovo je veoma nisko, jer je bolje prizvati više manje relevantnih nego propustiti zaista korisne. LLM sam može da proceni koja sećanja su povezana sa trenutnim zadatkom, nije potrebno da sistem bodovanja radi previše strogu filtraciju."

10. Kako funkcioniše mehanizam kompresije konteksta?

Stari Wang pita: "Šta kad razgovor predug i ne stane u prozor konteksta?"

Kažem: "Automatska kompresija. Uslov okidača — bilo koji ispunjen: procenjeni broj token-a prelazi 80% dostupnog ulaznog token-a, ili broj poruka prelazi 100."

"Način izračunavanja dostupnog ulaznog token-a: ukupna veličina prozora konteksta minus maksimalni broj izlaznih token-a, minus rezerva od 1024. Na primer, ako je prozor modela 128K, maksimalni izlaz 8K, dostupni ulaz je oko 119K, a prag od 80% je oko 95K."

"Algoritam kompresije u tri koraka."

Prvi korak, sačuvati poslednjih 6 tura razgovora netaknuto, tačka preseka mora pasti na granicu korisničke poruke. Pozivi alata i rezultati alata moraju biti upareni u istoriji poruka, presek na pola bi narušio protokol poruka.
Drugi korak, stare poruke izvan opsega se summarize klizeće, iz svake poruke se izdvaja sažetak od najviše 500 reči.
Treći korak, predug rezultat alata se odseca na 4000 znakova.

"Cilj kompresije je 55% dostupnog token-a. Zašto 80% okida, 55% kompresuje? Ostavljeni prostor služi za trenutnu turu ulaza, delove dinamički ubačene u sistemski prompt (na primer prizvana sećanja), kao i više poziva alata koje LLM može vratiti. Ako se kompresuje previše kasno i previše malo, zahtev trenutne ture može direktno preći prozor."

"Procena token-a se vrši empirijskom formulom: kineski znakovi po 1 token/znak, engleski 3 znaka = 1 token. Pomalo konzervativno — u scenarijima sa puno koda daje više. Ali pretpostaviti više je sigurnije od potcenjivanja, jer potcenjivanje može dovesti do toga da zahtev pređe prozor modela i bude odsečen."

11. Objasnite dinamički Prompt i statički Prompt

Stari Wang kaže: "Kako ti sastavljaš sistemski prompt?"

"Delim na statički i dinamički deo."

"Statički deo se u jednoj sesiji ne menja, izgradi se jednom i kešira. Obuhvata podešavanje karaktera (ton, stil), ključna pravila ponašanja (specifikacija korišćenja alata, sigurnosna strategija), instrukcije projekta (sadržaj PAI.md)."

"Dinamički deo se ponovo izgrađuje pri svakom LLM zahtevu. Obuhvata trenutno vreme i vremensku zonu, putanju radnog direktorijuma, ime trenutno korišćenog modela i provider, indeks aktiviranih Skill-ova, upravo prizvana relevantna dugoročna sećanja."

"Postoji još jedna dimenzija — režim. ReAct režim, Plan režim, planer/izvršilac/recenzent imaju svaki nezavisan fajl sa promptom za režim, u direktorijumu resources/prompts/. Orkestrator na osnovu trenutne uloge bira odgovarajući prompt režima i nalepljuje ga na odgovarajuće mesto sistemskog prompta."

"Lanac prioriteta pri učitavanju instrukcija projekta: korisnički globalni PAI.md → PAI.md u korenu projekta → PAI.md u .paicli direktorijumu → PAI.local.md (lokalno prepisivanje, ne ide u repozitorijum)."

Ukupni budžet 16KB, prekoračenje se odseca. Korisnik može prilagoditi prepisivanje bilo kog sloja prompt fajlova, prepisivanje je zamena celog fajla.

12. Koji je osnovni model? Koliko košta? Da li svakodnevno koristite PaiCLI?

Stari Wang baca poslednje pitanje: "Koji model koristiš? Da li si računao cenu?"

"Podrazumevani model je DeepSeek V4."

PaiCLI podržava promenu modela u toku rada — komandom /model može se menjati između 6 provider-a: DeepSeek, GLM, Kimi, StepFun itd. API Key se čita iz konfiguracionog fajla, iz env varijabli i iz .env fajla, prioritet raste tim redosledom.

"1000 redova koda je oko 15000 do 20000 token-a. Za kompletan zadatak kodiranja, uključujući više tura ReAct petlje, obično se potroši između 50 i 100 hiljada token-a."

Sa DeepSeek V4, cena je između 0,1 i 1 RMB. Kada se uključi Prompt Cache, ponavljan sistemski prompt i istorijske poruke pogađaju keš, a ulazni trošak pada na četvrtinu.

Stari Wang na kraju pita: "Da li svakodnevno koristiš svoj PaiCLI?"

"Koristim ga svaki dan. Pisanje koda, pretraživanje materijala, automatizacija svakodnevnih operacija — sve preko njega."

"Da budem iskren, Claude Code je svakako jači od PaiCLI-ja. Ali najveća prednost alata koji si sam napisao nije funkcionalnost, već to što potpuno razumeš kompromise iza svake dizajnerske odluke."

"Takođe, dok sam pisao PaiCLI, sve ključne koncepte iz tehnološkog steka za Agenate sam prošao u praksi. ReAct, Function Calling, RAG, MCP, Multi-Agent, Memory, kompresija konteksta. Čitanje članaka deset puta nije vredno jednog sopstvenog pokušaja implementacije."

ending

Na intervjuima za Agent pozicije ne pitaaju koliko koncepata znaš napamet, već da li si sve tehnologije jednom sam implementirao.

Najefikasniji način da razumeš Agent-e jeste da napišeš sopstveni Agent projekat.

Ne mora da bude bolji od Claude Code-a, ali ReAct petlja, sistem memorije, kompresija konteksta, slojevitost Skill-ova — svaki modul moraš sam da implementiraš.

Vidimo se u sledećem izdanju.