Tehnički Leader: "Još uvek Vibe Coding? Ne može agent sam da radi?" Ja, sa osmehom: "Upravo radim na jednom Agent CLI-ju", Leader: "Toliko si jak?"

Juče sam opet intenzivno radio celegod na PaiCLI Agentu i digao celokupno interaktivno iskustvo za još jedan nivo.

200 dolara potrošeno na Codex — 50% kvota iskorišćeno; mogu samo da kažem da je razvoj terminal CLI-ja, bilo Claude Code ili Codex, još uvek nedovoljno pokriven.

Nedostaje deo poput use browser-a, direktan debug u browseru; neki bug-ovi zahtevaju ljudsku intervenciju da bi se istražili, a tek nakon istrage Agent se može usmeriti da ih reši.

Tsk tsk.

Srećom, trud se isplati: posle dubokog proučavanja izvornog koda biblioteke jline, konačno sam rešio sve teške bug-ove.

Sada interaktivno iskustvo već dosta pristupa Qoder CLI-ju.

Tokom rada na ovom projektu, svaki aspekt AI Agent tehnološkog stack-a — ReAct, Multi-Agent, RAG, mehanizam Memory, MCP, tool use itd. — postao mi je mnogo jasniji.

Takođe sam razjasnio: prilikom Vibe Coding-a sa Codex-om ili Claude Code-om, kakav prompt čini da Agent bolje završi zadatak.

Tekst je prilično intenzivan, vežite sigurnosne pojaseve, krećemo.

content

01. Koje su tiventure tvog AI projekta?

Lao Wang je listao moj CV i brzo se fokusirao na PaiCLI. Zainteresovano pita: "Šta je, po tvom mišljenju, najveća vrline ovog terminalnog Agent alata?"

Rekoh: "Najveća vrlina je da je čitav projekat od nule do jedan izveden isključivo Vibe Coding-om; glavni razvoj radio sam sa Claude Code-om i Codex-om, a sopstveni kod koji sam napisao iznosi manje od 5%."

Lao Wang podiže obrvu: "Znači to je pisao AI? Možeš li jasno da objasniš tehničke detalje?"

Nasmejao sam se: "Mogu, zato što sam pregledao svaku liniju koda i doneo svaku arhitektonsku odluku. Vibe Coding nije da baciš zadatak na AI i gotovo; kako se piše prompt, kako se razlaže arhitektura, kako se Agent usmerava da locira bug — sve su to ljudski poslovi."

(Inner OS: Lao Wang ispituje da li pišem kod ili samo kopiram 🤣)

"Da se vratimo na sam projekat. PaiCLI ima nekoliko prilično hardkorovih tačaka."

Prvo, kompletna ReAct petlja.

Nije prosta pitanje-odgovor, već LLM zaključuje → poziva alat → posmatra rezultat → nastavlja zaključivanje. Podržava do 20 iteracija u jednom krugu, paralelno izvršenje 4 alata i dinamičko upravljanje Token budžetom.

Drugo, trošlojni sistem pamćenja.

Kratkoročno pamćenje koristi ConversationMemory za tekući razgovor; dugoročno pamćenje koristi SQLite za perzistenciju znanja kroz sesije; između njih je ConversationHistoryCompactor za kompresiju konteksta, koji pri 90% popunjenosti prozora automatski pravi sažetak.

Treće, MCP integracija.

Preko MCP-a se priključuje ekosistem spoljašnjih alata; podržan je i stdio i HTTP transportni protokol; Chrome DevTools MCP može direktno da upravlja browserom.

Četvrto, Plan-and-Execute + Multi-Agent saradnja.

Složeni zadaci se prvo od strane Plannera razlažu u DAG, zatim Worker paralelno izvršava, Reviewer redom pregleda, a neuspešni zadaci mogu automatski da se ponove.

Lao Wang klima glavom: "Funkcija zaista ima. Onda da probramo nekoliko i detaljnije proćaskamo."

02. Koji je uslov okidanja algoritma za kompresiju konteksta?

Lao Wang prvo pita za tehničke detalje: "Pominjao si kompresiju konteksta — koji je uslov okidanja i kako je algoritam dizajniran?"

Rekoh: "Uslov okidanja je da broj Tokena trenutne istorije razgovora dostigne 90% kontekstnog prozora."

U PaiCLI-ju, Agent pre svake iteracije poziva maybeCompactHistory() da proveri. Ova metoda koristi estimateTokens() da oceni ukupan broj Tokena istorije razgovora; ako prekorači compressionTriggerTokens() (odnosno 90% veličine prozora), pokreće se kompresija.

Na primer, ako model podržava 128K konteksta, prag je oko 115K.

Zašto 90%, a ne 80% ili 95%? Previše rano gubi se informacija; prekasno možda ne stigne; 90% je empirijski izbalansirana tačka.

Algoritam kompresije se radi u četiri koraka.

Prvi korak — pronalaženje tačke preseka.

Obilazi se istorija razgovora i pronalaze pozicije svih user poruka. Poslednja 3 kruga razgovora ostaju netaknuta, a starija istorija se označava kao "interval za kompresiju". Tačka preseka mora da padne na granicu user poruka — to je ključno, jer tool_call i tool_result moraju biti upareni; ako se odseče iz sredine, LLM će biti zbunjen.

// Zadrži poslednja 3 kruga; starija istorija ide u sažetak
int splitIdx = userMessageIndices.get(userMessageIndices.size() - retainRounds);

Drugi korak — LLM pravi sažetak.

Poruke iz intervala za kompresiju se formatiraju kao tekst, ograničene na 60 000 znakova, i šalju se LLM-u da generiše 1-3 pasusa sažetka. Ovde se koristi nezavisan LLM poziv, ne meša se sa glavnim razgovorom.

Treći korak — rekonstrukcija istorije razgovora.

Nova istorija postaje: system prompt → jedna user poruka, čiji je sadržaj "sažetak kompresovane istorije razgovora" → jedna assistant potvrda, čiji je sadržaj "U redu, upoznat sam sa prethodnim kontekstom" → poslednja 3 potpuna kruga razgovora.

Četvrti korak — logovanje. Izlazi se poređenje Tokena i broja poruka pre i posle kompresije, radi lakšeg debug-ovanja.

Lao Wang nastavlja: "A ako kvalitet sažetka nije dobar? Ključne informacije se izgube, zarom naredni razgovor ne skrene?"

Rekoh: "Prvo, jedna postojeća zaštitna mera: zadržavaju se poslednja 3 potpuna kruga razgovora, koji obično sadrže ključni kontekst tekućeg zadatka. Čak i ako starija istorija posle kompresuje izgubi neke detalje, dok god su najnoviji krugovi potpuni, LLM obično još uvek može normalno da zaključuje."

03. Kako se dugi zadaci radi u tvom projektu?

"Ako zadatak traje danima, sa mnogo koraka, kako to rešavate?" Lao Wang postavlja vrlo praktično pitanje.

Rekoh: "PaiCLI uvodi DurableTaskManager koji specijalno rešava perzistenciju dugih zadataka."

Ključna ideja je perzistirati stanje zadatka u SQLite, izvršavati asinhrono preko pool-a pozadinskih niti, pa čak i nakon restarta procesa može da se oporavi.

Citav lifecycle je: enqueued → running → completed/failed/canceled. Kada korisnik podnese zadatak, DurableTaskManager generiše UUID kao ID zadatka, upisuje ga u tabelu runtime_tasks SQLite-a i postavlja status na enqueued.

DurableTask enqueue(String prompt) {
    // Generiši UUID, INSERT u runtime_tasks
    // Obavesti worker nit da ima novog zadatka
    return task;
}

U pozadini postoji pool worker niti, podrazumevano 2 (podešivo preko env promenljive PAICLI_TASK_WORKERS).

Svaki worker u petlji propituje zadatke u statusu enqueued i uzima ih po FIFO redosledu. Izvršavanje je zapravo pokretanje Agent.run() uz CancellationToken za podršku prekida u toku.

Najsvetliji deo dizajna je mehanizam oporavka procesa.

Pri pokretanju, DurableTaskManager poziva recoverRunningTasks(), skenira bazu i traži sve zadatke u statusu running — to su zadaci koji su bili u izvršenju kada je proces prošli put neočekivano izašao — i resetuje ih na enqueued, tako da ih worker iznova izvršava.

void recoverRunningTasks() {
    // Pronađi zadatke koji su još uvek running od poslednjeg izlaska procesa
    // Resetuj ih na enqueued, ponovo ih redaj
}

Lao Wang pita: "Ako se zadatak restartuje na pola izvršenja, ne kreće od početka?"

Rekoh: "Zaista kreće od početka, jer istorija razgovora Agenta nije perzistirana. To je trade-off: za nastavak od tačke prekida potrebno je serijalizovati istoriju razgovora i stanje alata iz svake iteracije u bazu, što drastično povećava kompleksnost. Trenutna strategija je da se dugi zadaci pokuša razložiti na više manjih; rezultat svakog se čuva u dugoročnom pamćenju, a kasniji zadaci mogu iz pamćenja da obnove kontekst."

(Inner OS: ovaj odgovor je prilično realan, Lao Wang bi trebalo da bude zadovoljan 😏)

Lao Wang je još pitao: "Kako korisnik nadgleda ove pozadinske zadatke?"

Rekoh: "Obezbedio sam set CLI komandi: /task list prikazuje listu zadataka, /task status <id> daje napredak konkretnog zadatka, /task cancel <id> prekida zadatak u toku. cancel se implementira preko Thread.interrupt() koji prekida worker nit, a status u bazi se ažurira na canceled."

04. Da li poznaješ Hook mehanizam Claude Codea? Objasni.

Lao Wang je iznenada promenio pravac: "Sigurno si koristio Claude Code. Koliko poznaješ njegov Hook mehanizam?"

Rekoh: "Poznajem, čak ga i sam koristim. Hook je mehanizam lifecycle callback-a koji pruža Claude Code, a omogućava korisnicima da automatski izvrše Shell komande na specifičnim događajima."

Jednostavno rečeno, Hook je "kuka" ubačena u tok rada Claude Codea, koja u specifičnim trenucima automatski izvršava korisnički definisanu skriptu.

Claude Code podržava nekoliko Hook događaja.

• PreToolUse se okida pre poziva alata — može se koristiti za validaciju parametara ili sprečavanje opasnih operacija.
• PostToolUse se okida nakon poziva alata — za logovanje ili okidanje narednih faza.
• Notification se okida kada Claude Code treba da obavesti korisnika.
• Stop se okida kada Agent stane.

Konfiguriše se u .claude/settings.json dodavanjem polja hooks; svaki Hook definiše tip događaja i komandu koju treba izvršiti.

Praktičan primer: pri pisanju PaiCLI-ja konfigurisao sam PostToolUse Hook koji nakon svake izmene Java fajla od strane Claude Codea automatski pokrene mvn compile. Ako kompajliranje ne uspe, stderr izlaz Hook-a se vraća u Claude Code, koji tada zna da prethodna izmena ima grešku i automatski je ispravlja.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "write_file",
        "command": "if [[ \"$TOOL_INPUT\" == *.java ]]; then mvn compile -q 2>&1; fi"
      }
    ]
  }
}

Lao Wang nastavlja: "Da li PaiCLI ima sličan Hook mehanizam?"

Rekoh: "PaiCLI nema korisnički Hook na korisničkom nivou, ali na nivou koda ima slične lifecycle tačke integracije. Na primer, WriteFileObserver u ToolRegistry posle svakog pisanja fajla obaveštava InlineRenderer da prikaže diff. Zatim, LSP injekcija dijagnostike: posle write_file, LspManager.reportPostEdit() prikuplja dijagnostiku kompajliranja i u sledećoj iteraciji Agenta automatski je ubacuje u istoriju razgovora — efekat je isti kao Hook u Claude Codeu, samo je implementacija drugačija."

Lao Wang prikazuje zadovoljstvo: "Uporedio si mehanizme dva proizvoda, dobro."

05. U dizajnu Agenta, koji glavni metodi mogu dati LLM-u sposobnost planiranja?

"Nastavimo o planiranju." Lao Wang pita preklopljenih nogu: "Koji su glavni metodi, a koji su im dobri i loši? "

Rekoh: "Trenutno su u industriji četiri glavna metoda."

Prvi je ReAct — Reasoning + Acting.

LLM u svakom koraku prvo zaključi, pa odmah deluje, i prema rezultatu delovanja zaključuje sledeći korak. Prednost: jednostavna implementacija, trenutna povratna informacija; osnovna Agent petlja PaiCLI-ja je ovaj modalitet. Mana: nema globalni pregled, LLM lako ide "korak po korak", pa kod složenih zadataka može da skrene.

Drugi je Plan-and-Execute.

LLM prvo generiše kompletan plan izvršenja, obično DAG, a zatim ga izvršava po topološkom redosledu. Planner u PaiCLI-ju je taj pristup. Analizira da li u cilju korisnika postoje višekoračne reči "zatim", "i", "prvo", "posle"; ako da, ide u Plan režim, u suprotnom u jednokoračni ReAct.

// Logika u Planner.java
boolean isSimpleGoal(String goal) {
    // Proveri višekoračne indikatorske reči
    // "zatim""i""prvo""posle""zatim"...
}

Treći je Tree of Thoughts (ToT).

Za razliku od Plan-and-Execute, ToT ne pravi jedan plan koji izvršava, već istovremeno istražuje više puteva zaključivanja, ocenjuje ih funkcijom i bira najbolji. Može se razumeti kao pretraga u širinu po prostoru zaključivanja. Pogodno za zadatke koji zahtevaju kreativnost ili gde je prostor rešenja veliki, ali je potrošnja Tokena visoka i inženjerskih primera nema mnogo.

Četvrti je Reflexion.

Nakon što LLM završi zadatak, reflektuje samo sebe, zaključke refleksije čuva u pamćenju i koristi ih pri sledećem sličnom zadatku. Pomalo je to kao ljudsko prepričavanje.

U Multi-Agent arhitekturi PaiCLI-ja postoji uloga Reviewer koja za neuspele zadatke generiše povratnu informaciju i ubacuje je u ponovni pokučaj Workera — to se poklapa sa razmišljanjem Reflexion-a.

Lao Wang nastavlja: "Kako biraš u stvarnom razvoju?"

Rekoh: "U većini scenarija ReAct je dovoljan. Tek kada korisnikov instrukcija očigledno sadrži više koraka sa međusobnim zavisnostima, pokreće se Plan-and-Execute. ToT i Reflexion su više akademska istraživanja; inženjerski ROI nije visok. Iskustvo mi govori da 80% zadataka rešava ReAct, 15% zahteva Plan, a preostalih 5% možda zahteva ljudsku intervenciju za razlaganje."

06. Da li si radio fine-tuning Agent sposobnosti? Kako prikupiti dataset?

Lao Wang je postavio pitanje koje nisam u potpunosti očekivao: "Da li si radio fine-tuning Agent sposobnosti?"

Rekoh: "PaiCLI sam po sebi nije radio fine-tuning modela, jer koristimo API zatvorenih modela poput GLM-a, DeepSeek-a, Kimi-ja. Ali o ovom pitanju sam ozbiljno razmišljao i radio istraživanje."

(Inner OS: Iako nisam lično radio fine-tuning, teorijska osnova mora da postoji, ne smem da se izblamiram 😤)

Fine-tuning Agenata se razlikuje od klasičnog SFT-a po tome što dataset nisu prosta pitanja i odgovori, već kompletne trase poziva alata — uključujući proces zaključivanja LLM-a, parametre tool_call-a, rezultate alata i zaključke LLM-a na osnovu rezultata.

Prikupljanje dataset-a ima nekoliko uobičajenih načina.

Prvi je replay logova. Prikupi se kompletan log razgovora Agenta iz produkcionog okruženja, izdvoje se uspešni slučajevi i pretvore u podatke za treniranje. Format istorije razgovora PaiCLI-ja je već po strukturi [user, assistant(tool_calls), tool(result), assistant] i može direktno da se koristi kao podatak za fine-tuning.

Drugi je Rejection Sampling. Isti zadatak se modelu pusti više puta — neki uspevaju, drugi ne; zadržavaju se samo uspešne trase. Prednost: automatski generiše mnogo visokokvalitetnih podataka. Mana: visok računski trošak.

Treći je ljudsko anotiranje. Annotatori simuliraju ponašanje Agenta i ručno biraju koji alat da pozovu u svakom koraku i koje parametre proslede. Kvalitet je najviši, ali i cena.

Četvrti je DPO (Direct Preferences Optimization). Prikupi se dobra i loša trasa istog zadatka, pa model uči da preferira dobru. Na primer, za zadatak čitanja fajla: dobra trasa je direktno read_file("pom.xml"); loša je prvo list_dir("."), pa list_dir("./src"), pa tek onda read_file("pom.xml") — pravila je okuku.

Lao Wang klima glavom: "A da bi ti radio fine-tuning, kako bi?"

Rekoh: "Krenuo bih od replay-a logova. Kompletna istorija svakog razgovora PaiCLI-ja može da se izveze u JSONL; filter je: zadatak uspešno izvršen, broj poziva alata u razumnom opsegu, nije aktiviran Token budžet. Kad skupim nekoliko hiljada visokokvalitetnih trasa, koristim LoRA za fine-tuning nekog open-source modela, sa fokusom na tačnost izbora alata i tačnost popunjavanja parametara."

07. Objasni razliku između LangChain i LlamaIndex.

Lao Wang menja temu: "Šta misliš o LangChain-u i LlamaIndex-u, ova dva framework-a?"

Rekoh: "U jednoj rečenici: LangChain naglašava orkestraciju, LlamaIndex naglašava pretragu."

Ključna sposobnost LangChain-a je povezivanje komponenti poput LLM-a, alata, memorije i spoljašnjih izvora podataka radi izgradnje složenih Agent workflow-a.

On pruža apstrakcije Chain, Agent, Memory, Tool. LangChain se može shvatiti kao "lepljivi framework" AI aplikacija; rešava problem "kako kombinovati razne sposobnosti".

Ključna sposobnost LlamaIndex-a je indeksiranje i pretraga podataka.

Ono u čemu je najbolji: učitava dokumente raznih formata — PDF, web stranica, baza — seče ih na chunk-ove, gradi vektorski indeks i onda pri korisničkom pitanju radi pretragu sličnosti i vraća relevantne delove. Rešava problem "kako iz mnogo podataka pronaći relevantne informacije".

Dimenzija	LangChain	LlamaIndex
Glavno pozicioniranje	Framework za orkestraciju aplikacija	Mašina za indeksiranje i pretragu podataka
Scenario u kom je najbolji	Višekoračni Agent, workflow	RAG, Q&A baza znanja
Obrada podataka	Ima, ali nije fokus	Ključna sposobnost
Agent podrška	Zreo (ReAct, Plan itd.)	Ima, ali jednostavniji
Ekosistem integracija	Bogate integracije alata	Bogati konektori podataka

U realnim projektima ova dva framework-a se često kombinuju. Na primer, LlamaIndex za indeksiranje i pretragu, a zatim rezultate pretrage proslediti Agentu iz LangChain-a radi daljeg zaključivanja i poziva alata.

Lao Wang nastavlja: "A šta ste u PaiCLIju koristili?"

Rekoh: "Ni jedan. PaiCLI je Java ekosistem, a ovo su Python framework-i. Koristimo Spring AI za integraciju LLM-a; sopstvena Agent petlja, upravljanje Memory-jem i registracija alata. Ali projekat PaiAgent koristi LangGraph4j — Java biblioteka za orkestraciju grafova koju je objavio tim LangChain-a. Ali iskreno, dokumentacija i aktivnost zajednice LangGraph4j-a znatno zaostaju za Python verzijom, pa smo naišli na brojne probleme."

08. Koje Agent framework-e si koristio? Kako biraš?

Lao Wang pita dalje: "Pored LangGraph4j i Spring AI, koje si još Agent framework-e koristio ili proučioo? Kako ocenjuješ pri izboru?"

Rekoh: "Istraživao sam ih prilično; pri izboru uglavnom razmatram četiri dimenzije."

Prva dimenzija je jezički ekosistem. Naš glavni tehnički stack je Java + Spring Boot, pa Python framework-i mogu biti samo referenca. U Java svetu izbor je ograničen: Spring AI je najzreliji; LangGraph4j je zvanična Java verzija LangChain tima.

Druga dimenzija je nivo apstrakcije. Neki framework-i apstrahuju previše, sakrivaju mnogo detalja, pa je otežano debug-ovanje. Neki apstrahuju premalo — kao da pišeš od nule. Apstrakcija Spring AI-a je pogodna: pruža interfejse ChatClient, FunctionCallback i dr.

Treća dimenzija je aktivnost zajednice. LangChain verzija ima veoma aktivnu zajednicu, sa preko 100 hiljada zvezda.

Četvrta dimenzija je cena integracije sa postojećim sistemima. Backend PaiCLI-ja je Spring Boot, pa Spring AI prirodno može da ubrizgava Bean-ove i koristi Starter konfiguraciju. LangGraph4j je nezavisan graph engine koji zahteva poseban adapter sloj za integraciju u Spring — to je posao NodeAdapter-a i ChatClientFactory u PaiAgentu.

Lao Wang nastavlja: "Da li si razmišljao o AutoGen-u ili CrewAI-ju?"

Rekoh: "Istraživao sam. AutoGen je Multi-Agent framework koji je izašao iz Microsoft-a; glavna ideja je saradnja više Agenata preko prosleđivanja poruka. Njegov Python dizajn je veoma elegantan. CrewAI više naginje "ulogama" — svakom Agentu dodeliš ulogu (product manager, programer, tester), a zatim oni sarađuju na zadatku. Multi-Agent arhitektura PaiCLI-ja je pozajmila ideje iz AutoGen-a sa tri uloge — Planner, Worker, Reviewer — ali je implementacija sopstvena, bez zavisnosti od stranog framework-a."

"Moj princip izbora je: osnovna Agent petlja se piše sama; poziv LLM-a preko Spring AI; kompleksna orkestracija grafa razmatra se za LangGraph4j. Prednost samostalnog pisanja je puna kontrola — pri problemu možeš direktno da menjaš izvorni kod, bez čekanja na izdavanje framework-a."

09. Kako razumeš granicu između Agent-a i Workflow-a?

Lao Wang pije vodu i postavlja pitanje šireg opsega: "Agent i Workflow — kako razumeš ta dva koncepta? Gde je granica?"

Rekoh: "Najvažnija razlika je u pravu na samostalnu odluku."

Workflow je deterministički: koji su čvorovi, kojim redosledom se idu, gde se grane — sve je to unapred određeno u dizajnu. Pri izvršenju se samo poštuju koraci. Workflow u PaiAgentu je tipičan primer: korisnik u editoru za povuci-i-pusti nacrta čvorove i veze, a pri izvršenju LangGraph4j ide po topološkom redosledu grafa; LLM rasuđuje samo unutar jednog čvora i ne menja tok procesa.

Agent je nedeterministički: daj mu cilj, a on sam odlučuje koji alat poziva, koliko krugova, kada da stane.

ReAct petlja PaiCLI-ja je taj modalitet; u svakom krugu LLM donosi odluke: da li da pozovem alat? Koji? Koje parametre? Da li rezultat odgovara očekivanom? Da li da nastavim?

U svakodnevnom primeru: Workflow je kao radnik na tekućoj traci, gde za svaki korak postoji SOP. Agent je kao menadžer projekta — daš mu cilj, a on sam razlaže zadatak, alokira resurse i rešava izuzetke.

Kada Workflow, kada Agent?

Moje iskustvo je da gledam dva indikatora.

Prvi, determinističnost procesa. Ako je biznis proces fiksan, na primer "prvo prevedi → zatim stilski obradi → na kraju snimi glas", koristi Workflow, jer je putanja izvršenja poznata, može se nadgledati, auditovati i pratiti.

Drugi, tolerancija na grešku. Workflow se lako locira na nivou čvora; Agent možda zahteva rekonstrukciju cele lanace zaključivanja. U produkcionim scenarijima nulte tolerancije na greške, poput finansijskih izveštaja, Workflow je bezbedniji.

Lao Wang nastavlja: "A mogu li da se kombinuju?"

Rekoh: "Naravno, PaiCLI je primer kombinacije. Unutar čvora Workflow-a može da radi Agent petlja, gde LLM samostalno odlučuje kako da obradi zadatak tog čvora. Obrnuto, Agent pri zaključivanju može da okine predefinisani Workflow. LLM čvor u PaiAgentu je takav: u suštini je mini Agent, može pozivati Function Calling i raditi višekoračne pozive alata, ali je ugnježden u deterministički proces Workflow-a."

10. Pri izdvajanju sažetka, kako izbeći da greška u sažetku dovede do izobličavanja konteksta?

Lao Wang postavlja poslednje pitanje: "Za kompresiju konteksta koristite LLM za sažetak. A šta ako je sažetak pogrešan? Ključne informacije izgubljene, značenje izvrnuto — naredno zaključivanje skrene."

Rekoh: "To je najveći rizik kompresije konteksta, problem koji sam u PaiCLI-ju više puta podešavao."

Prva strategija — tačka preseka na granici.

Kao što je već rečeno, tačka preseka mora da padne na granicu user poruka, kako bi tool_call i tool_result bili upareni. Ako se odseče iz sredina serije poziva alata, sažetak će sadržati prekinute informacije "pozvan je alat, ali nema rezultata" ili "postoji rezultat, ali nije jasno šta je pozvano" — LLM bi na osnovu nepotpunih informacija mogao pogrešno da zaključi.

Druga strategija — zadržavanje nedavnog konteksta.

Kompresija dira samo istorijske poruke, dok poslednja 3 kruga razgovora ostaju potpuna. To znači da neposredni kontekst vezan za tekući zadatak ne ide u sažetak, pa makar sažetak bio loš, neće uticati na najnoviji lanac zaključivanja.

Treća strategija — pažljivo dizajniran prompt za sažetak.

Pri sažimanju, prompt izričito traži "zadržati sve putanje fajlova, imena promenljivih, poruke o greškama i druge konkretne detalje", ne samo generičke summa. Ovo je ključno, jer LLM pri sažimanju inače teži apstrakciji pa "pročitao je pom.xml, otkrio verziju 3.4.1" zbijne u "proverio konfiguracioni fajl projekta", što gubi ključne informacije.

Četvrta strategija — ograničenje dužine ulaza.

Tekst za sažimanje se ograničava na 60 000 znakova. Ako je istorija razgovora naročito dugačka, deo preko ovog ograničenja se odseca. Deluje kao gubitak informacija, ali zapravo starija istorija već ima nisku relevantnost za tekući zadatak; bolje je obraditi samo najvredniji deo nego tugovati nad ogromnim ulazom koji degradira kvalitet sažetka.

// Ograničenje dužine ulaza za sažetak
String textToSummarize = historicalText;
if (textToSummarize.length() > 60000) {
    textToSummarize = textToSummarize.substring(
        textToSummarize.length() - 60000);
}

Kako ovo staviti u CV?

Pametni terminalni asistent | razvoj Agenta | PaiCLI 2026-03 ~ danas

Kratak opis projekta: Terminalni AI Agent zasnovan na Java + Spring AI, sa podrškom za ReAct petlju, Multi-Agent saradnju, MCP integraciju alata, trošlojni sistem pamćenja i upravljanje asinhronim zadacima; preko prirodnog jezika u terminalu pokreće razvoj i debug koda.

Tehnički stack: Java 21, Spring Boot 3.4, Spring AI 1.0, JLine 3, SQLite, JGit, Chrome DevTools Protocol

Ključne odgovornosti:

1. Na osnovu ReAct-a implementirana osnovna Agent petlja sa podrškom za paralelno izvršenje 4 alata i dinamičkim upravljanjem Token budžetom; algoritam kompresije konteksta automatski okida sažetak pri 90% popunjenosti prozora, uz zadržavanje poslednja 3 potpuna kruga razgovora.
2. Dizajn perzistencije dugih zadataka zasnovan na SQLite-u za čuvanje stanja, sa asinhronim Worker pool-om i podrškom za automatski oporavak nezavršenih zadataka nakon restarta procesa.
3. Implementacija trošlojnog sistema pamćenja: kratkoročno pamti tekući razgovor, dugoročno perzistira znanje kroz sesije u SQLite-u, a Compactor radi kompresiju konteksta sa svesti o granicama; podržana hibridna pretraga BM25 + kosinusna sličnost.
4. Integracija MCP-a za spoljašnji ekosistem alata, sa podrškom za stdio/HTTP dvostruki transport i automatskim skraćivanjem šeme, i HITL mehanizmom odobravanja za bezbedno upravljanje pozivima alata.
5. Izgradnja Plan-and-Execute + Multi-Agent arhitekture: Planner razlaže složene zadatke u DAG, Worker paralelno izvršava, Reviewer kontroliše kvalitet i podržava automatski retry, sa maksimalno 4 paralelne niti.