Zaposleni u DeepSeek-u: Harness je ušao u zatvorenu beta, prednost imaju kandidati sa open-source projektima na polju plugin-a, skill-a, MCP-a i Agent-a, uz poklonjene API kvote (sa pitanjima za Agent intervju)
Iskreno, dugo čekam DeepSeek Harness.
Iako je DeepSeek ostvario duboku kompatibilnost i sa Codex-om i sa Claude Code-om, zvanično sopstveno rešenje je sigurno bolje za upotrebu — ulazni i izlazni parametri API-ja se, na kraju krajeva, razlikuju od jednog do drugog velikog modela.
Model + Harness = Agent — formula koju svi već znaju.
To znači da je model odgovoran za rezonovanje, a Harness za sve ostalo oko modela: pozive alata, upravljanje memorijom, kontrolu konteksta, desktop integraciju, MCP protokol, sistem Skills i tako dalje.
U stvari, mnogi domaći proizvođači velikih modela imaju svoj Harness — na primer Alijin Qoder, Kimi Code od Moonshot-a, Zhipu-ov Zcode i drugi.
Svi jedva čekaju DeepSeek-ov sopstveni Harness — čak i ako se cena DeepSeek API-ja značajno podigne, verujem da će odnos cene i kvaliteta i dalje biti vrlo visok.
Samo nastavite da ih sejete bez milosti. 😄
Prema dosadašnjim procurelim informacijama o arhitekturi, DSH podržava Sub-agent, pametno ponovno korišćenje KV Cache-a, perzistentnu memoriju između sesija i slične mogućnosti.
Naravno, sve su to stvari koje jedan Agent mora da ima. Moj sopstveni terminalni Agent PaiCLI je sve to već integrisao.
Kod je open-source na GitHub-u, implementirane su verzije za Java/Go/Python/TypeScript: https://github.com/itwanger/PaiCLI-Python
Za sve vas, sposobnost Agent inženjerstva upravo postaje čvrst standard velikih kompanija pri zapošljavanju.
Ako ste neko ko veruje u trud, veruje u proces, veruje u korak po korak i veruje da može da zauzme svoj deo u eri AI-a, onda nadam se da ćete pažljivo pročitati sledeći hardcore sadržaj.
[Screenshot: lista pitanja za intervju]
(Tekst je prilično opsežan, garantujem da ćete naučiti jako puno. Vežite sigurnosne pojaseve, krećemo!)
content
01. Predstavi svoje projekte — koja je ukupna arhitektura i tehnološki stek?
„Napravio sam dva projekta: jedan terminalni Agent i jednu RAG bazu znanja.”
[Screenshot: pregled arhitekture oba projekta; stil: three-layer; cilj snimka: prikaz odnosa ukupne arhitekture PaiCLI-ja i Pai Pametnog; ključne reči: PaiCLI, Pai Pametni, arhitektura]
„Terminalni Agent se zove PaiCLI i konkurira Claude Code-u. ReAct režim služi za kratke zadatke u realnoj interakciji, Plan-and-Execute režim za složene zadatke koji zahtevaju planiranje korak po korak, a Multi-Agent Team režim za saradnju više uloga.”
„RAG baza znanja se zove Pai Pametni, hibridnu pretragu radi na Elasticsearch-u. Vektorska pretraga ide preko KNN-a, pretraga ključnih reči preko BM25, a ta dva se kombinuju za priziv i rangiranje. Iznad toga je custom ReAct koji podržava pozive alata i razgovor kroz više krugova.”
„Na nivou tehnološkog steka, PaiCLI je Java 21 + OkHttp + SQLite + JLine — sasvim native, bez Spring AI i sličnih framework-a. Pai Pametni je Spring Boot + Elasticsearch 8.x + Embedding/LLM API + Redis.”
Zašto PaiCLI ima tri režima?
„Zato što se različiti zadaci prilagođavaju različitim režimima.”
[Screenshot: poređenje scenarija primene tri putanje; stil: data-board; cilj snimka: poređenje scenarija primene i troškova tri režima; ključne reči: ReAct, Plan, Team]
„Na primer, kada korisnik pita 'čemu ova metoda služi', ReAct režim je sasvim dovoljan. Ali ako je instrukcija korisnika 'refaktoriši mi ovaj modul i posle izmene pokreni testove', ReAct više nije dovoljan — treba Plan-and-Execute da prvo rastavi zadatak, sredi zavisnosti, pa tek onda izvršava korak po korak. Za složenije scenarije, gde je potrebna saradnja više Agenata, ulazi Team režim.”
02. Koji je kompletan tok Agent-a u projektu?
„Uzeću ReAct režim kao primer i proći kroz kompletan tok.”
[Screenshot: kompletan tok izvršavanja ReAct-a; stil: swimlane; cilj snimka: prikaz kompletnog toka podataka od korisničkog unosa do konačnog odgovora; ključne reči: ReAct, LLM, poziv alata]
„Kada stigne korisnički unos, prvi korak je predobrada unosa — proširivanje lokalnih putanja i raščlanjivanje referenci na slike. Drugi korak je pretraga dugoročne memorije, gde se zapisi memorije povezani sa trenutnim unosom ubacuju u system prompt. Treći korak je sastavljanje Prompt-a, spajanje po slojevima — statički slojevi napred, dinamički pozadi.”
„Zatim sledi glavna petlja. U svakom krugu se prvo proveravaju uslovi izlaska: da li je token budžet potrošen, da li je došlo do stagnacije (uzastopno pozivanje istog alata više puta), da li je prekoračen limit iteracija. Kad provera prođe, poziva se LLM; ako vrati zahtev za poziv alata, alat se izvršava. Više alata može paralelno, sa timeout-om kao mrežom sigurnosti. Rezultat alata se kao poruka dodaje na istoriju razgovora i LLM nastavlja da odlučuje.”
„Ako LLM ne vrati poziv alata, zadatak je završen — formatirani izlaz se vraća korisniku.”
Kako je dizajniran mehanizam odobrenja?
[Screenshot: stablo odlučivanja toka odobrenja; stil: swimlane; cilj snimka: prikaz toka odobrenja za operacije pisanja; ključne reči: odobrenje, provera putanje, provera komande]
„Operacije pisanja prolaze kroz odobrenje. Alati poput write_file i execute_command pre izvršavanja prolaze kroz HITL (Human-in-the-Loop) tok odobrenja. Proverivač putanja određuje da li se putanja datoteke nalazi u dozvoljenom opsegu, a proverivač komandi da li je komanda bezbedna. Strategija odobrenja ima tri nivoa: auto (automatski prolaz), suggest (predlog potvrde), never (obavezna ručna potvrda).”
„Operacije čitanja ne zahtevaju odobrenje, izvršavaju se odmah.”
03. Koje optimizacije Agent-a si radio tokom projekta? Kako konkretno podešavaš?
„Tri pravca: ušteda para, sprečavanje prekoračenja, sprečavanje beskonačne petlje.”
„Ušteda para ide preko Prompt Caching-a. Prompt PaiCLI-ja ukupno ima 9 slojeva, od kojih su prva četiri statička — definicija identiteta, ličnost, instrukcije režima, strategija odobrenja — i ne menjaju se tokom cele sesije. Kada se taj statički sadržaj postavi na sam početak, Prompt Caching pogađa po najdužem zajedničkom prefiksu: što je prefiks stabilniji, to je stopa pogodaka keša veća.”
[Screenshot: strategija pogodaka Prompt Caching-a; stil: three-layer; cilj snimka: prikaz kako postavljanje statičkih slojeva napred podiže stopu pogodaka keša; ključne reči: Prompt Caching, statički sloj, prefiks]
„Sprečavanje prekoračenja počiva na kompresiji u dva sloja. Prvi sloj je kompresija kratkoročne memorije: kada broj tokena premaši budžet, automatski se izbacuju najstariji zapisi. Drugi sloj je kompresija istorije razgovora: kada broj tokena istorije razgovora priđe gornjoj granici prozora konteksta, zadrži se nekoliko poslednjih kompletnih krugova razgovora, a starija istorija se zameni sažetkom koji generiše LLM.”
„Sprečavanje beskonačne petlje počiva na detekciji stagnacije (stagnation). Svaki poziv alata upisuje potpis (ime alata + argumenti); ako se potpis tri puta zaredom potpuno poklopi, proglašava se stagnacija i petlja se prisilno prekida.”
Kako se računa prag za pokretanje kompresije?
[Screenshot: izračunavanje praga za pokretanje kompresije; stil: data-board; cilj snimka: prikaz praga pokretanja za različite veličine prozora; ključne reči: pokretanje kompresije, 200K, prag]
„Formula je: prag pokretanja = prozor konteksta - min(20K, prozor/4) - min(13K, prozor/8).”
„Za prozor od 200K to izlazi otprilike na okidanje na 167K, a za prozor od 1M na oko 967K. Rezervisani prostor služi za sadržaj sažetka i dalji razgovor, da ne bi odmah posle kompresije opet došlo do prekoračenja.”
04. Koja su uobičajena sredstva za optimizaciju Agent-a?
„Tri pravca — cena, kvalitet, brzina — i u svakom pravcu jedna stvar sa najvišim prioritetom.”
„U pravcu cene, Prompt Caching ima najbolji odnos uloženog i dobijenog. System prompt jednog Agent-a je obično dugačak — definicije alata, pravila projekta i ubačena memorija zajedno dostižu i desetine hiljada tokena, i sve se to u svakom krugu razgovora šalje u kompletnosti. Princip Prompt Caching-a je podudaranje po prefiksu: onaj deo Prompt-a koji šaljete modelu, a koji se poklapa sa prethodnim zahtevom, ide direktno iz keša, ne računa se iznova, a naplaćuje se oko desetina cene. PaiCLI postavlja statički sadržaj prvih 4 od ukupno 9 slojeva Prompt-a na sam početak, nepromenjen tokom cele sesije, pa je stopa pogodaka keša visoka.”
[Screenshot: princip podudaranja prefiksa u Prompt Caching-u; stil: three-layer; cilj snimka: prikaz kako postavljanje statičkih slojeva napred podiže stopu pogodaka keša; ključne reči: Prompt Caching, podudaranje prefiksa, statički sloj]
„Zatim ide rangiranje modela. Prepoznavanje namere — da li korisnikova rečenica traži čitanje datoteke ili izvršavanje komande — može da radi mali model, brz je i jeftin. Veliki model se poziva tek za složeno rezonovanje, poput planiranja zadataka i generisanja koda. Osim toga, tu je i skraćivanje konteksta: rani delovi istorije razgovora se po prioritetu odsecaju i zamenjuju sažetkom.”
„U pravcu kvaliteta, najvažnije je slojevito upravljanje promptovima. System prompt se deli na nezavisne slojeve i svaki sloj upravlja jednom stvari. Menja se ton — dira se samo sloj ličnosti; dodaje se strategija odobrenja — menja se samo sloj odobrenja; opseg izmena je pod kontrolom i ne ruši se sve odjednom. Uz to ide i iteracija vođena evaluacijom: pre izmene Prompt-a pokrene se jedna runda evaluacije i zabeleži osnovna linija, posle izmene još jedna za poređenje — odlučuju podaci.”
[Screenshot: šema slojevitog upravljanja Prompt-om; stil: three-layer; cilj snimka: prikaz odgovornosti svakog od 9 slojeva Prompt-a i opsega uticaja izmena; ključne reči: slojevito upravljanje, izolovane izmene, evaluacija kao pokretač]
„U pravcu brzine, paralelno izvršavanje alata daje najveći osetni napredak. Agent u jednom krugu često poziva više alata — na primer čita 3 datoteke istovremeno. PaiCLI pomoću thread pool-a izvršava najviše 4 alata odjednom, sa ukupnim timeout-om od 90 sekundi. Uz streaming izlaz, korisnik ne mora da čeka da se sve generiše da bi video sadržaj.”
Zašto Prompt Caching stoji na prvom mestu u optimizaciji troškova?
[Screenshot: poređenje troškova sa i bez Prompt Caching-a; stil: data-board; cilj snimka: poređenje razlike u naplati tokena za sesiju od 20 krugova sa i bez keša; ključne reči: pogodak keša, naplata, ušteda troškova]
„System prompt je najveći deo troška Agent-a. System prompt jednog složenog Agent-a lako dostiže desetak hiljada tokena, a sesija od 20 krugova znači 20 kompletnih izračunavanja. Deo koji pogodi keš naplaćuje se desetinu cene, a implementacija je praktično besplatna — dovoljno je nepromenljiv sadržaj staviti na sam početak, bez menjanja arhitekture.”
05. Scenarijski zadatak na osnovu projekta — kako rešiti sličan problem ako se pojavi?
„Zamislite da korisnik traži od Agent-a da refaktoriše modul koji obuhvata 8 datoteka i da posle izmene svi testovi moraju da prođu.”
„Prvo, zašto ovaj zadatak ne može u jednostavnu ReAct petlju. ReAct u svakom krugu radi jednu stvar — posmatra, razmišlja, dela. On izmeni datoteku A, pokrene test na pola posla, test padne. Ali taj 'pad' nije zato što je A pogrešno izmenjena, nego zato što B, C i D još nisu izmenjene. Agent vidi grešku i možda pokušava da popravi problem koji uopšte ne treba dirati — što više menja, to je veći haos. Jednostavna petlja nema globalni pogled, vidi samo trenutni korak.”
[Screenshot: ReAct vs Plan režim; stil: data-board; cilj snimka: poređenje razlike u izvršavanju jednostavne petlje i režima planiranja na zadatku sa više datoteka; ključne reči: ReAct, Plan, globalni pogled]
„Ovakav zadatak prelazi u Plan režim. Planer prvo pročita svih 8 datoteka, razume zavisnosti unutar modula, a zatim generiše graf zadataka.”
„Graf zadataka je DAG (usmeren aciklični graf). Pretpostavimo da datoteka A definiše interfejs, da B i C svaka posebno implementiraju taj interfejs, a da D zavisi od izlaza B. Graf koji planer generiše otprilike izgleda ovako: prvo čitanje svih datoteka (tip READ, bez zavisnosti, paralelno) → izmena definicije interfejsa u A → izmena implementacija u B i C (međusobno nezavisne, paralelno) → izmena D (zavisi od B) → pokretanje testova. Izvršavanje ide po topološkom sortiranju: u svakoj rundi pronađu se svi čvorovi sa ulaznim stepenom 0 — zadaci bez prethodnih zavisnosti — i ta grupa se izvršava paralelno. Kad se grupa završi, graf zavisnosti se ažurira i traži se sledeća grupa.”
[Screenshot: primer DAG grafa zadataka; stil: swimlane; cilj snimka: prikaz zavisnosti između 8 datoteka i redosleda izvršavanja po topološkom sortiranju; ključne reči: DAG, topološko sortiranje, paralelno izvršavanje]
Šta ako se na pola izmena otkrije da plan ima problem?
„Na primer, prilikom izmene 4. datoteke ispadne da izmena interfejsa u A pogađa i datoteku E koja je ranije promakla.”
„Tu se prave dva slučaja. Ako je progres ispod pola, to znači da je razumevanje modula u fazi planiranja možda bilo pogrešno — uzima se poruka o grešci i sve se planira ispočetka. Ako je progres prešao pola, već urađeni posao je prevelik da bi se bacao — zadrži se završeni deo, doda zadatak izmene E, prilagode se kasnije zavisnosti i nastavi se dalje.”
[Screenshot: logika odlučivanja inkrementalnog preplaniranja; stil: swimlane; cilj snimka: prikaz različitih strategija kada je progres preko pola i kada nije; ključne reči: inkrementalno preplaniranje, procena progresa, prilagođavanje zavisnosti]
„Ako zadatak zahteva i kontrolu kvaliteta — na primer posle refaktorisanja treba obezbediti kompatibilnost API-ja — prelazi se u Team režim. Planer rastavlja zadatke, 2 Workera izvršavaju paralelno, a pregledač proverava svaku grupu rezultata. Odgovornosti pregledača i Workera su strogo izdvojene: pregledač ne dira alate, samo ocenjuje, čime se izbegava da sam menja kod pa sam sebe pregleda. Ono što ne zadovoljava vraća se na preradu, najviše 2 puta.”
06. Kako je implementirana semantička pretraga?
„Pai Pametni koristi hibridnu pretragu — kombinaciju vektorske pretrage i pretrage ključnih reči.”
[Screenshot: tok hibridne pretrage; stil: swimlane; cilj snimka: prikaz kompletnog toka pretrage od Query-ja do konačnog rezultata; ključne reči: KNN, BM25, hibridna pretraga]
„Prvo vektorska pretraga. Tekst upita korisnika se preko DashScope modela text-embedding-v4 prevodi u vektor od 2048 dimenzije, a zatim se u Elasticsearch-u radi KNN pretraga. Da bi se obezbedila stopa priziva, prozor priziva je postavljen prilično široko — 30 puta više od konačnog broja rezultata: ako se na kraju vraća 5 rezultata, KNN prvi priziva 150 kandidata.”
„Zatim BM25 radi preraspoređivanje u drugoj fazi. Na skupu kandidata koje je prizvao KNN, sadržaj teksta se boduje podudaranjem ključnih reči. Težina KNN-a je 0.2, a težina BM25 1.0 — podudaranje ključnih reči dominira u rangiranju.”
„Korist ovakvog pristupa: vektorska pretraga odgovara za semantički priziv i ne propušta sadržaj koji je drugačije formulisan, ali blizak po značenju; BM25 odgovara za precizno rangiranje i obezbeđuje da rezultati sa potpunim podudaranjem ključnih reči stoje napred.”
Zašto BM25 za preraspoređivanje?
[Screenshot: vektorska pretraga vs hibridna pretraga; stil: data-board; cilj snimka: poređenje prednosti i slabosti čisto vektorske i hibridne pretrage; ključne reči: vektor, BM25, stopa priziva]
„Vektorska pretraga ima jedan poznat problem: podudaranje vlastitih imena i skraćenica nije dovoljno precizno. Kada korisnik traži 'MCP protokol', vektor može da prizove i 'RPC protokol', jer su semantički zaista bliski. A korisniku treba baš MCP. BM25 može rezultate sa potpunim podudaranjem ključnih reči da rasporedi na sam vrh i time nadoknadi slabost vektorske pretrage u preciznom podudaranju.”
07. Koju tačno ulogu vektorska baza ima u projektu?
„Pai Pametni nema posebno postavljenu vektorsku bazu — Elasticsearch istovremeno služi i za skladištenje vektora i za pretragu celog teksta.”
„Svaki dokument u ES-u ima dva ključna polja. Polje vector čuva Embedding vektor od 2048 dimenzije — ES po njemu gradi indeks algoritmom HNSW (Hierarchical Navigable Small World) i radi pretragu približnih najbližih suseda. Polje textContent čuva originalni tekst i ide preko ugrađenog invertovanog indeksa ES-a za BM25 pretragu ključnih reči. Jedni podaci, dva indeksa, dve mogućnosti pretrage.”
[Screenshot: arhitektura dvostrukog indeksa u ES-u; stil: skill-card; cilj snimka: prikaz kako koegzistiraju HNSW indeks polja vector i invertovani indeks polja textContent; ključne reči: HNSW, invertovani indeks, dvostruki indeks]
„Pre nego što dokument uđe u bazu, seče se na blokove, a strategija sečenja direktno određuje kvalitet pretrage. Veličina bloka je 512 karaktera, a susedni blokovi se preklapaju sa 100 karaktera. Zašto preklapanje? Zato što se jedan kompletan koncept može naći tačno na granici dva bloka, a preklapanje garantuje da se semantika na granici ne odseče.”
„Logika sečenja ima tri nivoa. Prvo se po dvostrukom znaku za novi red dele pasusi, svaki pasus nezavisno. Ako neki pasus prelazi 512 karaktera, seče se po rečenicama. Ako posle sečenja neki blok ima manje od 100 karaktera, spaja se sa prethodnim — previše sitni blokovi imaju loš kvalitet Embeddinga i ništa ne vrede u pretrazi.”
[Screenshot: sečenje dokumenata i hijerarhija roditelj-dete; stil: three-layer; cilj snimka: prikaz trostepene logike sečenja i strukture dokumenata roditelj-dete; ključne reči: 512 karaktera, preklapanje, blokovi roditelj-dete]
„Dokumenti imaju i dodatni sloj strukture roditelj-dete. Dete blok je jedinica pretrage od 512 karaktera i služi za precizno podudaranje. Roditelj blok je najviše 1MB, otprilike ceo tekst dokumenta. Kada pretraga pogodi dete blok, može se vratiti na roditelja po kompletan kontekst, da LLM vidi više informacija pre odgovora. Za velike datoteke se koristi streaming parsiranje, da jedno učitavanje ne bi rasprslo memoriju.”
Kada treba preći na namensku vektorsku bazu?
„Gleda se obim podataka i QPS pretrage. Baza znanja Pai Pametnog je u razredu od nekoliko desetina hiljada do nekoliko stotina hiljada dokumenata, što HNSW u ES-u sasvim izdržava. Postavljanje još jednog Milvusa ili Qdranta znači održavanje još jednog klastera i još jednu sinhronizaciju podataka, a korist je mala.”
[Screenshot: ES vs namenska vektorska baza — scenariji primene; stil: data-board; cilj snimka: poređenje prednosti i slabosti ES-a i namenske vektorske baze po obimu podataka; ključne reči: obim podataka, HNSW memorija, trošak održavanja]
„Ali kada količina podataka dostigne desetine miliona, ili kada QPS pretrage mora biti vrlo visok, KNN u ES-u postaje usko grlo. Memorijski trošak HNSW-a raste linearno sa količinom podataka: vektor od 2048 dimenzije zauzima oko 8KB po zapisu, pa deset miliona zapisa otprilike znači 80GB čistih vektorskih podataka. U toj fazi distribuirana pretraga i kvantizaciona kompresija namenske vektorske baze dobijaju na vrednosti.”
08. Framework-i poput LangChain-a i LangGraph-a — zašto (ne) birati njih? Da li su ti poznati osnovni tokovi?
„PaiCLI ne koristi nijedan AI framework, sve je samostalno razvijeno. HTTP sloj koristi OkHttp i direktno se vezuje za API-je svakog velikog modela.”
[Screenshot: odluka samostalni razvoj vs framework; stil: data-board; cilj snimka: poređenje prednosti i slabosti samostalnog razvoja i framework-a po različitim dimenzijama; ključne reči: samostalni razvoj, framework, granularnost kontrole]
„Zašto ne framework? Zato što se API specifikacije velikih modela razlikuju. GLM Prompt Caching radi u glm-prompt-cache režimu, DeepSeek koristi automatic-prefix-cache, Kimi moonshot-context-cache. Definicije kodova grešaka, strategije ponovnih pokušaja i format streaming izlaza takođe variraju. Framework te razlike apstrahuje, a meni treba fina kontrola po svakom modelu — stopa pogodaka keša, naplata tokena, oporavak prekinutog streaminga — pa mi apstrakcioni sloj framework-a pre stoji na putu.”
Osnovne principe LangGraph-a poznajem. On se vrti oko grafa stanja (State Graph): čvorovi su funkcije obrade, a ivice uslovno rutiraju. Svaki čvor prima trenutno stanje, izvršava operaciju i vraća ažurirano stanje. Checkpoint mehanizam čuva snimak stanja svakog koraka i podržava nastavak od prekida i reprodukciju.
U kom scenariju bi izabrao framework?
„Za brzu proveru jedne ideje framework brže provede prototip kroz ceo tok. Ali ako projekat ide u produkciju, uz adaptaciju više modela i finu kontrolu, samostalni razvoj bolje leži. AI Coding danas ima jake sposobnosti, pa je trošak samostalnog razvoja već nizak.”
09. Kako se kontrolišu pravila za izlazne rezultate modela?
„Tri sloja: Prompt ograničenja, Schema validacija alata, odobrenje izvršavanja.”
„Prompt sloj je meko ograničenje. Prvi sloj system prompta definiše granice ponašanja — koje su operacije dozvoljene, koje zabranjene, kako se organizuje format izlaza. Ta pravila su prisutna u svakom krugu razgovora i model ih vidi. Ali Prompt je, na kraju krajeva, prirodni jezik, pa model ne mora sto posto da ih poštuje, posebno kada je kontekst dug i pažnja rasejana. Zato su potrebna još dva sloja tvrdih ograničenja kao mreža sigurnosti.”
„Schema sloj alata je tvrdo ograničenje. Svaki alat pri registraciji nosi JSON Schema koja definiše tipove parametara, obavezna polja i opseg vrednosti. Argumenti poziva alata koje model generiše moraju proći Schema validaciju; ako nisu regularni, izvršavanje se odbija i modelu se vraća poruka o grešci da generiše ponovo. Na primer, file_path kod write_file mora biti string, a content ne sme biti prazan — pored ovih ograničenja model ne može da pređe.”
[Screenshot: mehanizam kontrole izlaza u tri sloja; stil: three-layer; cilj snimka: prikaz progresije Prompt (meko ograničenje) → Schema (tvrdo ograničenje) → odobrenje (ljudska mreža sigurnosti); ključne reči: Prompt, JSON Schema, HITL odobrenje]
„Schema MCP alata zahteva još jedan korak čišćenja. Schema koju MCP Server vrati često nosi $ref reference i anyOf unije tipova, pa model pri takvim ugnježdenim strukturama lako generiše argumente u pogrešnom formatu. Pri registraciji MCP alata PaiCLI razvija sve $ref reference i izravnava anyOf u najčešće korišćeni tip, da bi model video čistu i flat definiciju argumenata.”
[Screenshot: MCP šema pre i posle čišćenja; stil: data-board; cilj snimka: poređenje složene šeme sa $ref/anyOf pre čišćenja i ravne šeme posle čišćenja; ključne reči: MCP, $ref, čišćenje šeme]
„Sloj odobrenja upravlja pravima izvršavanja. Čak i kada su argumenti sasvim regularni, operacije pisanja pre izvršavanja prolaze kroz HITL odobrenje. Proverivač putanja zaustavlja operacije nad datotekama van korenskog direktorijuma projekta, a proverivač komandi zaustavlja opasne komande. Strategija odobrenja ima tri nivoa — auto automatski prolaz, suggest predlog potvrde, never obavezna ručna potvrda — i konfiguriše se prema nivou rizika alata.”
Kako Agent reaguje kada korisnik odbije odobrenje?
[Screenshot: tok odlučivanja Agent-a posle odbijenog odobrenja; stil: swimlane; cilj snimka: prikaz kako model ponovo odlučuje nakon što je poziv alata odbijen; ključne reči: odbijanje, tool_result, ponovno odlučivanje]
„Odbijanje se modelu vraća kao tool_result, a u poruci piše 'ova operacija je odbijena od strane korisnika'. Kad to vidi, model sam odlučuje o sledećem koraku — možda isti cilj postiže drugačije: na primer, kada korisnik odbije direktno prepisivanje datoteke, model prvo pravi rezervnu kopiju pa tek onda piše. Ili pak kaže korisniku da određeni posao mora odraditi ručno. Agent se ne zaglavi zbog jednog odbijanja.”
10. Kako je dizajniran modul memorije?
„Tri sloja memorije, svako upravlja svojim.”
[Screenshot: arhitektura memorije u tri sloja; stil: three-layer; cilj snimka: prikaz skladištenja i životnog ciklusa kratkoročne, dugoročne i projektne memorije; ključne reči: kratkoročna memorija, dugoročna memorija, memorija projekta]
„Kratkoročna memorija je na nivou sesije i važi samo u trenutnoj sesiji. Ispod haube je jedan LinkedHashMap — ko je prvi ušao, taj stoji prvi. Token budžet je 45% prozora konteksta; kad se premaši, izbacuju se najstariji zapisi.”
„Dugoročna memorija je perzistentna i preživljava između sesija. Čuva se u SQLite-u, klasifikovana po tipu i opsegu. Pre svakog poziva LLM-a povrate se zapisi dugoročne memorije povezani sa trenutnim unosom i ubace u system prompt. Novi zapisi prolaze deduplikaciju, da se ne dupliraju.”
„Memorija projekta su datoteke pravila koje developer unapred napiše, slično CLAUDE.md-u u Claude Code-u. Učitavaju se po prioritetu: PAI.md → .paicli/PAI.md → PAI.local.md → .paicli/PAI.local.md — kasnije zamenjuju ranije.”
Čime se dizajn memorije Pai Pametnog razlikuje?
„Memorija Pai Pametnog je više okrenuta poslovnoj strani.”
[Screenshot: arhitektura memorije Pai Pametnog; stil: data-board; cilj snimka: poređenje razlika u dizajnu memorije PaiCLI-ja i Pai Pametnog; ključne reči: Redis, MySQL, praćenje referenci]
„Istorija sesije se čuva u Redis-u — poslednjih 20 poruka, ističe za 7 dana. Istovremeno se perzistuje u MySQL, gde ostaje kompletna evidencija pitanja i odgovora. Uz svaki odgovor beleži se i mapa referenci — koji fragment kog dokumenta je odgovor citirao, koliki je bio skor pretrage, koja ključna reč je pogođena — korisnik klikne na oznaku reference i skače na originalni tekst.”
„Postoji i memorija korisničkih utisaka. Kada korisnik oceni odgovor pozitivno ili negativno, poslednjih nekoliko utisaka se ubacuje u system prompt sledećeg kruga i usmerava model da prilagodi stil odgovora.”
11. Kako se memorija tretira u scenarijima sa više krugova i više sesija?
„Više krugova i više sesija su dva različita problema.”
„U višekružnom scenariju razgovor postaje sve duži i prozor konteksta pre ili kasnije ne može da ga izdrži. PaiCLI zadržava poslednja 3 kompletna kruga razgovora netaknuta, a stariju istoriju zamenjuje sažetkom koji generiše LLM. Sažetak čuva ključne zahteve, završene operacije, postignuti konsenzus i stavke za uraditi. Algoritam kompresije i prag pokretanja detaljno se objašnjavaju u pitanju 13.”
„U višekružnom scenariju tu je i lako zanemareno upravljanje token budžetom kratkoročne memorije. Kratkoročna memorija stoji u jednom LinkedHashMap, a gornja granica budžeta je 45% prozora konteksta. Kad se premaši, izbacivanje kreće od najstarijih zapisa. Izbacivanje nije puko brisanje: izbačeni zapis prvo prođe kroz jedan sažetak kompresije LLM-a pa se tek zameni, pa se ključne informacije ne gube sasvim.”
[Screenshot: tok obrade memorije za više krugova i više sesija; stil: swimlane; cilj snimka: prikaz izbacivanja kratkoročne memorije u višekružnom scenariju i perzistencije dugoročne memorije između sesija; ključne reči: kratkoročna memorija, dugoročna memorija, izolacija sesija]
„Višesesioni scenarij počiva na perzistenciji dugoročne memorije. Dugoročna memorija PaiCLI-ja čuva se u SQLite-u, klasifikovana po tipu i opsegu. Pri pokretanju nove sesije učita se sa diska, pa Agent i dalje pamti ranije sačuvane preferencije i pravila. Novi zapisi prolaze deduplikaciju — ista preferencija se ne čuva dva puta.”
„Komanda /clear briše samo kratkoročnu memoriju i istoriju razgovora, dugoročna memorija ostaje netaknuta. Kad korisnik kaže 'očisti kontekst', obično želi da krene iznova sa novom temom, a ne da Agent zaboravi sve preferencije.”
[Screenshot: šta sve briše komanda /clear; stil: data-board; cilj snimka: poređenje stanja kratkoročne memorije, istorije razgovora i dugoročne memorije pre i posle /clear; ključne reči: /clear, kratkoročna memorija, dugoročna memorija]
„Kod Pai Pametnog je jednostavnije. Svaka sesija je izolovana svojim conversation_id, pa isti korisnik može držati više sesija bez međusobnog ometanja. Istorija sesije ide u Redis — poslednjih 20 poruka, ističe za 7 dana — i istovremeno se perzistuje u MySQL. Nema dugoročne memorije između sesija, ali postoji mehanizam korisničkih utisaka: poslednjih nekoliko pozitivnih i negativnih ocena ubacuje se u system prompt i utiče na stil i žarište kasnijih odgovora.”
12. Ako sistem naiđe na anomalije, kako dizajnirati ukupan mehanizam tolerancije grešaka i obrade izuzetaka?
„Obrada ide u tri sloja.”
[Screenshot: slojevita arhitektura mehanizma tolerancije grešaka; stil: three-layer; cilj snimka: prikaz strategija tolerancije grešaka na sloju LLM-a, sloju alata i sloju Agent-a; ključne reči: ponovni pokušaj, backoff, degradacija]
„Sloj LLM-a: 3 ponovna pokušaja, eksponencijalni backoff sa slučajnim džiterom. Osnova backoff-a je 500 milisekundi, a gornja granica 30 sekundi. Ponavlja se samo kod određenih kodova grešaka — na primer 429 (limitiranje), 500/502/503/504 (serverska greška), 408 (timeout). Kod 400 (pogrešni parametri) ili 401 (neuspešna autentifikacija) se ne ponavlja, jer ponovni pokušaj ionako ne pomaže. Ako zaglavlje odgovora nosi Retry-After, prvenstvo ima vreme čekanja koje predlaže server.”
„Sloj alata: neuspeh jednog alata ne prekida ukupan tok. Neuspešan alat vraća poruku o grešci, koja se kao tool_result dodaje na istoriju razgovora, pa LLM, videvši je, sam odlučuje da li da pokuša drugačije ili da preskoči. Za više alata izvršavanih paralelno, ukupni timeout je 90 sekundi.”
„Sloj Agent-a: zaštita od beskonačne petlje. Čim stagnation detektuje uzastopne iste pozive alata, prisilno izlazi. U Plan režimu, ako zadatak padne na pola puta, gleda se progres: ispod pola — preplanira se sa porukom o grešci; preko pola — zadrži se završeni deo i nastavlja se dalje.”
Kako se procenjuje da li ponoviti ili degradirati?
[Screenshot: logika odlučivanja ponovni pokušaj vs degradacija; stil: swimlane; cilj snimka: prikaz strategija obrade za različite tipove grešaka; ključne reči: ponovni pokušaj, degradacija, kod greške]
„Gleda se priroda greške. Prolazne greške (limitiranje, treperenje mreže, preopterećen server) se ponavljaju, jer se posle kraćeg čekanja najverovatnije oporave. Trajne greške (neuspešna autentifikacija, pogrešan format parametara, SSL izuzetak) se ne ponavljaju — greška se odmah vraća i viši sloj rešava.”
„Ako ni tri ponovna pokušaja ne uspe, više se ne pokušava — vrati se poruka o grešci. Bez beskonačnog ponavljanja, korisnik čeka.”
13. Još jedan scenarijski zadatak iz obrade konteksta — kako optimizovati context management?
„Zamislite Agent-a sa prozorom od 200K koji radi na velikom projektu i kod koga u 30. krugu razgovora kontekst preti da prekorači.”
„Prvo, kako se deli prostor od 200K tokena. System prompt zauzima fiksni deo — 9 slojeva Prompt-a plus memorija projekta i indeks Skills — oko 10 do 20 hiljada tokena. Budžet kratkoročne memorije je 45% prozora konteksta, otprilike 90K. Ostatak prostora ostaje za istoriju razgovora i generisani izlaz LLM-a.”
„Do 30. kruga, istorija razgovora plus rezultati poziva alata vrlo verovatno priđu pragu za pokretanje kompresije. Prag za prozor od 200K je oko 167K; algoritam je veličina prozora minus dve rezerve — min(20K, prozor/4) za sažetak posle kompresije i min(13K, prozor/8) za dalji razgovor. Dve rezerve zajedno čine oko 33K, pa 200K minus to daje 167K. Rezervni prostor postoji da se ne bi odmah posle kompresije opet prekoračilo.”
[Screenshot: raspodela tokena u prozoru od 200K i pokretanje kompresije; stil: data-board; cilj snimka: prikaz udela tokena po delovima i izračunavanja praga od 167K; ključne reči: 200K, 167K, raspodela tokena]
„Posle pokretanja kompresije idu tri koraka. Prvi: skenira se istorija razgovora i nalaze indeksi pozicija svih user poruka. Drugi: od poslednje user poruke broji se 3 unazad, ta 3 kompletna kruga razgovora označavaju se kao zona zadržavanja — sve poruke unutar nje, uključujući user, assistant, tool_call i tool_result, ostaju netaknute. Treći: sve poruke ispred zone zadržavanja šalju se LLM-u da generiše sažetak, i sažetak zamenjuje originalne poruke.”
„Sažetak mora da sačuva četiri kategorije informacija: ključne zahteve korisnika, završene operacije, konsenzus dogovoren između strana i stavke za uraditi. Ako bilo koja kategorija izostane, kasnije ponašanje može da skrene. Na primer, ako sažetak ne zapiše da je korisnik rekao 'ne diraj config direktorijum', Agent posle kompresije može da krene da menja config.”
Zašto tačka preseka mora biti na granici user poruke?
„tool_call i tool_result dolaze u paru. tool_call je zahtev za poziv alata koji pokreće model, a tool_result je rezultat koji alat vrati posle izvršavanja. Ako se prereže na pola, nastaju dva osakaćena stanja. Model vidi poziv alata bez rezultata pa misli da se alat još izvršava; ili vidi rezultat bez zahteva pa ne zna odakle taj rezultat potiče. U oba slučaja kasnije rezonovanje skrene s puta.”
[Screenshot: bezbedna vs opasna tačka preseka; stil: swimlane; cilj snimka: prikaz razlike u posledicama sečenja na granici user poruke i usred para tool_call/result; ključne reči: tačka preseka, granica user poruke, par tool_call]
„User poruka je prirodno bezbedna tačka preseka. Svaki krug razgovora počinje user porukom, pa su tool_call i tool_result ispred nje sigurno kompletni u paru. Prelom ovde ne narušava integritet nijedne interakcije sa alatom.”
„Ako jedna kompresija ne bude dovoljna — u velikom projektu i sam sažetak može imati nekoliko hiljada tokena — može se ručno pokrenuti prisilna kompresija: broj zadržanih krugova pada sa 3 na 1, ostaje samo poslednji kompletan krug razgovora. Cena je gubitak više detalja konteksta, ali je svakako bolje nego da prekoračenje prozora obori Agent-a direktno greškom.”
Kako upisati PaiCLI i Pai Pametni u biografiju?
Naziv projekta: PaiCLI — AI Agent alat za komandnu liniju
Kratak opis: Java terminalni Agent koji konkurira Claude Code-u, podržava tri režima izvršavanja — ReAct, Plan-and-Execute i Multi-Agent Team — sa sposobnostima razgovora kroz više krugova, pretrage koda, poziva alata i automatskih ispravki.
Tehnološki stek: Java 21 + OkHttp + Elasticsearch + SQLite + MCP protokol
[Screenshot: tehnološki stek PaiCLI-ja za biografiju; stil: skill-card; cilj snimka: prikaz ključnog tehnološkog steka i pozicioniranja projekta; ključne reči: PaiCLI, terminalni Agent, Java]
Ključne odgovornosti:
- Dizajnirao arhitekturu Agent-a sa tri putanje: brz odziv jednostavne ReAct petlje, izvršavanje korak po korak po grafu zavisnosti u Plan-and-Execute režimu, saradnja više uloga u Multi-Agent Team režimu, uz automatsko rutiranje prema složenosti zadatka
- Implementirao assembler Prompt-a sa 9 slojeva: statički slojevi napred za pogodke Prompt Caching-a, dinamički slojevi skraćeni po token budžetu, u kombinaciji sa kompresijom konteksta u dva sloja — duge sesije bez prekoračenja
- Izgradio adaptacioni sloj za više LLM modela: jedinstven interfejs za DeepSeek, GLM, Kimi i druge, sa zasebnom strategijom keširanja, ponovnih pokušaja i streaming izlaza po svakom modelu
- Dizajnirao sistem progresivnog učitavanja Skills: indeks → sadržaj → referentna dokumentacija, učitavanje po potrebi u tri nivoa, LRU bafer kontroliše broj istovremeno aktivnih Skill-ova i sprečava naduvavanje konteksta
- Postavio mehanizam tolerancije grešaka u tri sloja (LLM ponovni pokušaji sa backoff-om + timeout kao mreža sigurnosti za paralelne alate + stagnation detekcija beskonačne petlje), čime se obezbeđuje stabilnost Agent-a pri dugotrajnom radu
Naziv projekta: Pai Pametni — RAG baza znanja sa hibridnom pretragom na ES-u
Kratak opis: Enterprise RAG sistem baze znanja: otpremanje dokumenata, pametno sečenje, hibridna pretraga, pitanja i odgovori kroz više krugova, uz izolaciju prava i trasiranje referenci.
Tehnološki stek: Spring Boot + Elasticsearch 8.x + DashScope Embedding + Redis + MySQL
[Screenshot: tehnološki stek Pai Pametnog za biografiju; stil: skill-card; cilj snimka: prikaz ključnog tehnološkog steka RAG projekta; ključne reči: Pai Pametni, RAG, hibridna pretraga]
Ključne odgovornosti:
- Implementirao pipeline hibridne pretrage: DashScope text-embedding-v4 generiše vektore od 2048 dimenzije za KNN semantički priziv, a BM25 preraspoređivanje u drugoj fazi radi precizno rangiranje ključnih reči — pokriva i semantičku relevantnost i precizno podudaranje
- Dizajnirao semantički svesnu strategiju sečenja dokumenata: preseci po granicama pasusa i rečenica, hijerarhija dokumenata roditelj-dete uz streaming parsiranje, čime se sprečava prekoračenje memorije pri obradi velikih datoteka
- Izgradio trostepeni filter pretrage po pravima (privatno korisnika + javno + nivo organizacije), organizacione oznake podržavaju hijerarhijsko nasleđivanje, provera prava je ugrađena u uslove ES upita — bez naknadnog filtriranja
- Postavio ReAct Agent framework sa dva integrisana alata, search_knowledge i generate_summary, uz odlučivanje o pozivima alata kroz više krugova; korisnički utisci se u realnom vremenu ubacuju u prompt i usmeravaju kvalitet odgovora
- Implementirao mehanizam trasiranja referenci: svaki odgovor beleži izvor pretrage (MD5 dokumenta, ID bloka, broj strane, tekst sidra, skor pretrage), a klik na oznaku reference vodi korisnika na tačno mesto u originalnom tekstu
Kraj
Ovih 13 pitanja pokrivaju uglavnom sve česte tačke ispitivanja iz Agent inženjerstva — kako birati arhitekturu, kako upravljati kontekstom, kako čuvati memoriju, kako uhvatiti anomalije. Ko ima svoj projekat, neka prođe kroz sopstvenu implementaciju — na intervjuu će stajati mnogo sigurnije.
Vidimo se u sledećem.