Zaposleni Hikvisiona: prošle godine su svi čiji je učinak bio na nivou zadovoljavajućeg ili bolji dobili opšte povećanje plate — plata u avgustu će sve pokazati, nema razloga za sumnju (sa pitanjima o Agentu)

Ukratko ću vam objasniti stanje stvari.

Ako negde ima grešaka i propusta, slobodno ih ukažite (obožavam da učim).

Napominjem: pominjanje neke kompanije ne znači rangiranje po snazi — ista kompanija može da se proteže kroz više nivoa.

①. Gornji, osnovni sloj — uglavnom pruža infrastrukturu za podatke, čipove i računsku snagu.

Na primer: Speechocean za prikupljanje i označavanje podataka, Huawei Ascend za čipove za AI trening i zaključavanje, Cambricon za čipove za pametnu vožnju i edge AI, ZTE za AI servere i klastere, Volcano Engine za cloud i inteligentnu računsku snagu, China Mobile za centre za inteligentno računanje i IDC itd.

②. Srednji sloj modela — uglavnom pruža osnovne modele, modele za industriju i platforme za modele.

Prvo velike kompanije: na primer Alibaba-in Qwen, Tencent-ov Hunyuan, ByteDance-ov Doubao, iFlytek-ov Spark, Huawei-ov Pangu.

Zatim startup kompanije: DeepSeek, Zhipu-ov GLM, Moonshot-ov Kimi.

I na kraju veliki modeli namenjeni određenim granama: na primer 4Paradigm, Ant u finansijama, iFlytek u zdravstvu, NetEase u obrazovanju, SenseTime u upravi i upravljanju gradovima itd.

③. Donji, aplikativni sloj — uglavnom pruža C-end proizvode namenjene korisnicima, kao i stvarne biznise.

Yuanbao, Quark, WorkBuddy, Qoder, WPS AI, TRAE, Raccoon, Kling, Jimeng.

Hikvision u oblasti vizuelnog AI-ja i AIoT-a — uglavnom se bavi inteligentnim videoom, mašinskim vidom, pametnim saobraćajem, industrijskim vidom itd.

Kao i inteligentna vožnja koju nude XPeng, Li Auto, NIO, BYD i drugi.

U oblasti robotike Unitree, AgiBot i drugi.

Sa pozitivne strane, pune pozitivne energije i zaraznog zanosa, Hikvision je svakako jedna od kompanija za koju vredi krenuti kad je reč o sletanju AI aplikacija u praksu.

U prvoj polovini 2026. oporavak Hikvision-a se jasno ubrzao i ukupni prihod je stigao do 46,823 milijarde juana. PBG (javne usluge), EBG (preduzeća i institucije), SMBG (mala i srednja preduzeća), inostrani glavni biznis i inovacioni biznis svi su zabeležili rast prihoda u različitom stepenu.

U jednoj rečenici, posao koji Hikvisionu čini šanac izgleda ovako:

Masovnim senzorskim uređajima obezbediti ulaz u fizički svet, edge AI-jem razumeti teren, platformom za industriju organizovati procese, a onda kontrolnim uređajima i robotima zatvoriti petlju delovanja.

Drugim rečima, što su sposobnosti modela poput DeepSeek-a jače, Hikvision ima više prostora da resurse koncentriše na ono što zaista najbolje ume — IoT percepciju, edge deployment, industrijsko znanje i sloj fizičkog izvršavanja.

Ako ste neko ko veruje u trud, veruje u proces, veruje u korak po korak i veruje da u eri AI-ja može da uzme svoj deo kolača, ovaj hardcore materijal sa intervjua nadam se da ćete pažljivo pročitati.

(Tekst je prilično opsežan, garantujem da ćete naučiti jako puno. Vežite sigurnosne pojaseve, krećemo.)

content

PaiCLI Agent o kome je reč u tekstu već je open source na GitHub-u, postoji i verzija u Go-u: https://github.com/itwanger/PaiCLI-Python

01. Razumevanje samo-evolucije Agent-a

Stari Vang, pognute glave, lista moju biografiju; prsten na domalom prstu udara o hartiju uz tih zvuk. Zaustavi se na drugoj strani: „Samo-evolucija Agent-a — ispričaj mi više o tome.”

„Suština samo-evolucije je — bez diranja težina modela, na aplikativnom sloju omogućiti Agent-u da sam postaje bolji.”

U čemu je razlika prema fine-tuning-u?

fine-tuning traži prikupljanje označenih podataka, pokretanje treninga i deploy novog modela — ciklus je dug, a troškovi visoki.

Samo-evolucija ide drugim putem — Agent tokom izvršavanja zadataka automatski analizuje šta je bilo efikasno, a šta nije, akumulira iskustva koja rade i prilikom sledećeg sličnog zadatka direktno ih koristi.

Konkretno, postoje tri puta.

Prvi je evolucija prompta. Kad Agent odradi gomilu zadataka, analizira neuspešne putanje izvršavanja, izdvaja obrasce neuspeha koji se ponavljaju i automatski generiše nova pravila ograničenja koja upisuje u system prompt. Na primer, ako se primeti da model pri editovanju više datoteka često preskoči neku od njih, doda se pravilo „pre editovanja više datoteka prvo alatom izlistaj spisak svih datoteka koje treba izmeniti”.

Drugi je optimizacija alatnog lanca. Beleže se sekvence poziva alata uspešnih zadataka; kad se vidi da neke kombinacije alata imaju posebno visoku stopu uspeha, sledeći put sličan zadatak prvo ide proverenom putanjom.

Treći je inkrementalna baza znanja. Rešeni problemi i rešenja struktuirano se smeštaju u dugoročno pamćenje. Kod sledećeg problema iste vrste prvo se pretražuje baza iskustava i nema potrebe rezonovati iz početka.

02. Standard izdvajanja i ocena kvaliteta proizvoda samo-evolucije

„Standard izdvajanja ima tri tačke.”

„Prvo, zadatak je konačno uspeo. Vredi izdvojiti samo uspešne putanje izvršavanja. Neuspešne putanje su negativni primerci — koriste se za generisanje pravila ograničenja, ne preporučenih putanja.”

„Drugo, efikasnost iznad osnovne linije. Ako je ovaj put isti zadatak završen sa manje koraka ili manje tokena, to znači da ta putanja ima vrednost za optimizaciju.”

„Treće, priznanje korisnika. Korisnik je prihvatio odgovor Agent-a, kod je komitovan, izmene nisu tražene — i ti implicitni signali se računaju kao priznanje.”

Kako se ocenjuje kvalitet?

„Tri dimenzije.”

„Dimenzija rezultata — izdvojeno iskustvo se pusti na zadatke iste vrste i izmeri da li je stopa uspeha porasla. To se mora stvarno izmeriti, ne na osećaj.”

„Dimenzija generalizacije — da li iskustvo radi i u drugom scenariju. Ako važi samo za jedan poseban case, a u drugom projektu ne, onda je previše spregnuto i vrednost je mala.”

„Dimenzija interpretabilnosti — može li čovek da razume i pregleda izdvojeno pravilo. Neobjašnjivo iskustvo ne sme u system prompt, jer se ne zna zašto deluje ni kada će prestati da deluje.”

03. Odakle podaci? Kako se prepoznaju kvalitetni podaci?

Stari Vang podigne šoljicu čaja i otpije gutljaj: „Odakle dolaze podaci za samo-evoluciju Agent-a?”

„Tri izvora.”

„Prvi, stvarne putanje izvršavanja iz produkcijskog okruženja. To su najvredniji podaci, jer su to stvarni zadaci stvarnih korisnika u stvarnim scenarijima. Svaki krug interakcije Agent-a i korisnika upisuje se kao nepromenljiv JSONL log, uključujući LLM poruke, pozive alata, rezultate izvršavanja i utrošeno vreme.”

„Drugi, zapisi izvršavanja Golden Set-a (standardnog test skupa). Standardni slučajevi se pokreću u kontrolisanom okruženju, a svaki slučaj ima jasno definisan ulaz i očekivani izlaz. Dobijene putanje mogu se precizno označiti kao uspešne ili neuspešne.”

„Treći, ručno konstruisani seed podaci. U fazi hladnog starta nema dovoljno produkcijskih podataka, pa se ručno napiše nekoliko standardnih putanja izvršavanja kao polazna tačka. Ne mora ih biti mnogo — dovoljno je pokriti glavne vrste zadataka.”

Kako se prepoznaje kvalitet?

Četiri signala.

• zadatak je konačno uspeo,
• proces je efikasan — broj koraka i potrošnja tokena su u razumnom opsegu,
• bez nuspojava — nema slučajno obrisanih datoteka, nema izvršenih opasnih komandi,
• generalizabilno — nije hack vezan za konkretnu putanju datoteka ili strukturu projekta. Tek kad su sva četiri uslova ispunjena, podatak je kvalitetan.

04. Zašto se samo-evolucija radi u sandbox okruženju?

„Prvo, bezbednost. Tokom samo-evolucije Agent isprobava nove strategije, a one mogu imati nuspojave — pogrešno obrisana datoteka, izvršena pogrešna komanda, pokvaren kod. Greška u sandbox-u ne dira stvarno okruženje.”

„Drugo, ponovljivost. Svaki eksperiment polazi iz istog čistog stanja, jedina promenljiva je razlika u strategiji Agent-a, pa su rezultati uporedivi. Ako se radi u stvarnom okruženju, ostaci prethodnog eksperimenta kontaminiraju sledeći i ne zna se da li je napredak zasluga strategije ili je okruženje slučajno bilo povoljno.”

„Treće, reverzibilnost. Ako strategija ne valja, vrati se snapshot i krene se od početka, uz zanemarljivu cenu. Kad se u stvarnom okruženju pokvari kod, rollback je mnogo skuplji.”

05. U kom trenutku se pravi snapshot

„Pominjao si snapshot i rollback — u kom trenutku se snapshot pravi?”

„Prvi, pre početka svake iteracije samo-evolucije pravi se jedan potpuni snapshot. To je baseline (referentno stanje) — šta god se kasnije desilo, uvek se može vratiti u to čisto stanje. Moj pristup je poseban Git repozitorijum za upravljanje snapshot-ima, potpuno izolovan od .git-a korisničkog projekta. Pre svakog izvršavanja Agent-a automatski se pravi pre-turn (pre izvršavanja) snapshot.”

„Drugi, pošto Agent završi ceo zadatak, pravi se inkrementalni snapshot. To je checkpoint (kontrolna tačka) koji beleži delimične rezultate. Post-turn (posle izvršavanja) snapshot se upisuje asinhrono u pozadini, bez blokiranja glavnog toka.”

„Treći, neposredno pre operacije visokog rizika — recimo masovno brisanje datoteka ili izvršavanje nepovratne shell komande — pravi se trenutni snapshot. Ako operacija krene naopako, može se precizno vratiti na stanje pre nje.”

Način okidanja

„Koriste se oba načina u kombinaciji. Vremenski snapshot se automatski okida po ciklusu iteracije, a event-driven snapshot na konkretne događaje — zadatak završen, greška se desila, operacija visokog rizika. Dozvole snapshot datoteka strogo su ograničene na čitanje i pisanje trenutnog korisnika, bez pristupa za ostale.”

06. Bezbednost i izolacija sandbox-a

„Koliko znaš o bezbednosti sandbox-a? Kako se postiže izolacija?”

„Prvi sloj, izolacija sistema datoteka. Sandbox ima sopstveni radni direktorijum i sve operacije Agent-a nad datotekama ograničene su na njega. Pristup van granica zaustavlja whitelist putanja — pokušaj čitanja datoteke izvan direktorijuma projekta odbija se odmah.”

„Drugi sloj, izolacija procesa. Shell komande koje Agent izvršava rade u zasebnom prostoru procesa, sa gornjom granicom za CPU i memoriju; po isteku vremena automatski se killuju. Jedna komanda koja je pošla naopako ne može srušiti ceo računar.”

„Treći sloj, mrežna izolacija. Sandbox podrazumevano ne može da pristupa spoljnoj mreži; scenariji kojima treba poziv spoljnjeg API-ja puštaju se kroz proxy sa whitelist-om. Tako Agent tokom samo-evolucije ne može slati zahteve spoljnim servisima.”

Kontejner ili virtuelna mašina?

„Zavisi od bezbednosnih zahteva. Za većinu scenarija samo-evolucije Agent-a kontejner je dovoljan — Linux namespace (imenski prostor) plus cgroup (grupa za kontrolu resursa), brz start, mali overhead, a granulacija izolacije sasvim dovoljna. Ako su bezbednosni zahtevi posebno visoki, na primer kad se izvršava nepoverljiv kod trećih strana, ide virtuelna mašina — temeljnija izolacija, ali sporiji start.”

07. Kako se gradi sistem evaluacije?

Stari Vang namesti naočare, otpije gutljaj čaja, spusti šoljicu i pogleda me: „Kako si napravio svoj sistem evaluacije?”

„Sloj rezultata gleda stopu uspeha zadataka. Preduslov je da se okruženje evaluacije može resetovati, da svako pokretanje polazi iz istog stanja i da nuspojave prethodnog pokretanja ne kontaminiraju sledeće.”

„Sloj procesa gleda efikasnost. Koliko koraka za isti zadatak, koliko tokena potrošeno, koja stopa uspeha poziva alata. Ako oba Agent-a završe zadatak — jedan u 3 koraka, drugi u 12 — razlika se vidi na prvi pogled.”

„Isti zadatak pokrenut više puta treba da daje uglavnom isti rezultat. Ako od 10 pokretanja 3 padne, ta putanja je nestabilna i traži istraživanje.”

„Infrastruktura evaluacije ima dva stuba. Jedan je Golden Set — skup determinističkih test slučajeva gde svaki ima jasno definisan ulaz i očekivani izlaz. Na primer, Golden Set modula za pretragu koda za svaki slučaj definiše ulazni query i očekivane pozicije datoteka koje treba pogoditi; jedno pokretanje i odmah se zna da li je pretraga regredirala.”

„Drugi je LLM-as-Judge (model kao sudija). Definišu se kriterijumi ocenjivanja po kojima model ocenjuje proizvode Agent-a. Prednost su niski troškovi i brzina, pa se pokriva velika količina uzoraka. Ali i sudija-model zna da driftuje, pa povremeno treba ručnu kalibraciju — nasumično se izvuče gomila uzoraka koje je model ocenio, pregledaju se ručno i izračuna stopa slaganja.”

08. Kako se gradi Harness sloj?

„Prvo, petlja verifikacije. Kod koji Agent napiše ne predaje se odmah — prvo se pokrenu testovi, problemi se automatski isprave, pa se ponovo verifikuje; tek kad prođe, zadatak je gotov.”

„Drugo, oporavak od grešaka. Ako poziv alata javi grešku — API timeout, pogrešan format parametra — automatski se ponavlja ili se menja održivom varijantom. Ako Agent upadne u beskonačnu petlju, prekine se po isteku vremena i vrati na poslednje stabilno stanje.”

„Treće, kontrola dozvola. Brisanje datoteka, push koda, izvršavanje sistemskih komandi — takve operacije ili prolaze kroz ručnu potvrdu ili ih ograničava politika. Bezbednosna provera putanja sprečava Agent-a da pristupi datotekama izvan direktorijuma projekta, a provera komandi presreće opasne shell komande. Svi rezultati odobrenja upisuju se u audit log — JSONL format sa po jednom datotekom dnevno, u kome se beleži ime alata, parametri, ishod odobrenja, način odobrenja i utrošeno vreme.”

„Četvrto, upravljanje stanjem. Ako Agent padne usred posla — prekine se mreža, potroše se tokeni — mora moći da se nastavi od tačke prekida. Mechanizam snapshot-a o kome smo malopre govorili deo je upravljanja stanjem.”

Kako se postiže nezavisnost modula?

„Naš framework za evaluaciju ima tri nezavisna analitička kanala koji rade paralelno.”

„Prvi kanal analizira dokaze sesije — šta je Agent radio u ovom razgovoru, koje je alate pozvao, koliko puta je promenio režim. Drugi proverava signale isporuke projekta — ima li test datoteka, ima li CI konfiguracije, ima li dokumentacije. Treći popisuje prilagođene konfiguracije Agent-a — koji su Skill-ovi uključeni, koje postoje datoteke sa promptima, MCP konfiguracije i bezbednosne politike.”

„Svaki kanal samostalno prikuplja dokaze, a na kraju glavni model objedinjuje nalaze sva tri kanala i ispisuje sveobuhvatan izveštaj. Prednost je što se svaki kanal može nezavisno iterirati — promena jednog ne dira druga dva.”

09. Konkretan primer unapređenja evaluacije

„Daj konkretan primer — kako si od početka do kraja unapređivao evaluaciju?”

„Uzeću funkciju pretrage koda.”

„Početno stanje bilo je čisto ručno testiranje. Napišem pretragu, probam nekoliko query-ja sam za sebe i pogledam da li su rezultati tačni. Naravno, query-ja koje mogu da smislim ima ograničeno, a posle svake izmene koda sve je ponovo ručno testirati.”

„Kasnije sam prilagodio prompt pretrage, probao nekoliko uobičajenih query-ja, bilo je u redu pa sam objavio. A onda su korisnici javili da izvesna vrsta datoteka više ne može da se nađe. Istraživanje unazad pokazalo je da je izmena prompta uticala na konstrukciju parametara alata za pretragu, pa su query-ji određenog obrasca regredirali.”

„Od tada sam počeo da gradim Golden Set. Prva verzija imala je samo nekoliko slučajeva koji pokrivaju najosnovnije scenarije pretrage. Kasnije bih svaki bag ili povratnu informaciju korisnika dodao tamo. Današnji slučajevi pokrivaju obradu nepoznatih komandi, paralelno izvršavanje alata, raščlanjivanje referenci na datoteke i druge scenarije.”

„Svaki slučaj definiše ulazni query i očekivane pozicije pogodaka datoteka, pokreće se JUnit-om i jedno pokretanje odmah pokazuje šta je prošlo, a šta palo. Pre izmene prompta pokrenem jednom, posle izmene opet, pa uporedim rezultate.”

10. Svrha evaluacionog Harness-a

Stari Vang baci pogled na sat: „Šta ti je zapravo svrha evaluacionog Harness-a?”

„Da svaka izmena bude podložna proveri i da se svaka regresija uoči.”

„Bez sistema evaluacije svaka izmena prompta ide na osećaj — 'čini mi se bolje', 'valjda je u redu'. Posle tri meseca izmena ne znaš da li je Agent bolji ili lošiji nego na početku.”

„Sa sistemom evaluacije, posle izmene jednog reda prompta pokrene se test skup i brojke kažu koje su sposobnosti porasle, a koje pale. Ako su pale, ne objavljuje se — prvo se popravlja bag.”

„I prompt je kod — kad se promeni, pokreću se testovi.”

11. Kako se sistem evaluacije vezuje za biznis scenarije?

„Osnovni pristup je izdvajanje test slučajeva iz zadataka stvarnih korisnika.”

„Prvi korak — iz audit logova i logova sesija izdvoje se najčešće vrste zadataka: pretraga koda, editovanje datoteka, izvršavanje komandi, višekružni razgovori.”

„Drugi korak — za svaku vrstu izaberu se reprezentativni case-ovi, uključujući normalne i granične slučajeve. Normalni su uobičajene operacije većine korisnika, granični su scenariji u kojima lako dolazi do greške.”

„Treći korak — evaluacija se organizuje po scenarijima. Scenario pretrage koda pokreće Golden Set, scenario editovanja datoteka regresione slučajeve, bezbednosni scenario testove granica dozvola. Svaki scenario se ocenjuje zasebno, a sve se sabere u ukupni izveštaj.”

„Još jedan postupak je replay produkcijskih putanja. Stvarne sesije zabeležene u produkciji ponovo se pokrenu u okruženju za evaluaciju i uporede se razlike u izlazu. Tako se otkrivaju scenariji koje ručno konstruisani slučajevi ne pokrivaju.”

12. Dimenzije i kriterijumi evaluacije

„Četiri dimenzije.”

„Tačnost — da li rezultat zadatka odgovara očekivanju. Deterministički zadaci se direktno porede sa očekivanim izlazom, a otvorene zadatke ocenjuje model-sudija po kriterijumima, uz povremenu ručnu kalibraciju.”

„Efikasnost — koliko koraka i koliko tokena za izvršenje zadatka. Za isti zadatak, manje koraka i manje tokena znači efikasniji Agent.”

„Bezbednost — da li je Agent izvršio opasne operacije, da li je pristupao van ovlašćenja. Proverava se statistikom audit logova — ima li blokiranih zapisa i zbog čega su blokirani.”

„Stabilnost — doslednost rezultata istog zadatka pri više pokretanja. Svaki slučaj se pokrene više puta i izračuna se stopa uspeha.”

13. Zašto prepisati Agent-a u Go-u?

Stari Vang se vrati na prvu stranu biografije i prstom kucne jedno mesto: „Projekat PaiCLI Agent — zašto si ga prepisao u Go-u?”

„PaiCLI Agent je prvo napisan u Pythonu; kasnije sam video da je u vašoj kompaniji — mojoj ciljanoj kompaniji — glavni jezik Go, pa sam ga prepisao.”

Naravno, Python i Go verzije zaista imaju poneku razliku.

„Prvo, deployment. Go se iskompajlira u jednu binarnu datoteku — kopira se i pokreće, nula zavisnosti.”

„Drugo, konkurentnost. Pozivi alata Agent-a često traže paralelizam — istovremena pretraga više datoteka, istovremeni pozivi više API-ja. Goroutine u Go-u paralelizam rešavaju prirodno — ni nekoliko hiljada goroutine nije teret.”

„Treće, brzina pokretanja. Terminalni Agent je CLI alat — korisnik ukuca komandu i odgovor treba odmah. Go binarna datoteka startuje u milisekundama.”

14. Kakvi se problemi pojavljuju pri prepisivanju u Go?

„Najveći problem je nezreo ekosistem AI SDK-jeva. Python ima LangChain, LlamaIndex i zvanične SDK-je svih provajdera modela; u Go-u odgovarajućih biblioteka ili nema ili su nepotpune. Mnogo toga treba samostalno uvezati — pozive modela, raščlanjivanje streaming odgovora, obradu tool_call protokola — sve iz početka.”

„Drugi su razlike sistema. Python rečnik može slobodno da se ugnežđuje i radi i kad se schema ne poklapa. Go je statički tipiziran, pa JSON koji model vrati mora unapred imati definisane strukture. A format parametara tool_call-a razlikuje se od alata do alata.”

„Treća je stil obrade grešaka. Python sve rešava jednim try/except-om. Go error treba obrađivati i prosleđivati sloj po sloj.”

15. Moduli i odnosi zavisnosti

Stari Vang skine naočare, ise ih i vrati na nos: „Poslednje pitanje. Objasni odnose zavisnosti između modula.”

„Ima šest glavnih modula.”

„CLI sloj je zadužen za interakciju u terminalu — raščlanjivanje komandi, ulaz i izlaz, renderovanje interfejsa; to je ulaz koji korisnik direktno dodiruje.”

„Agent sloj je glavna petlja odlučivanja. Prima korisnički ulaz, odlučuje kojom putanjom izvršavanja ići — ReAct, Plan ili Multi-Agent — i pokreće ceo zadatak napred.”

„LLM sloj je zadužen za pozive modela i sklapanje prompta. Slojevito spaja system prompt, upravlja istorijom razgovora i obrađuje streaming odgovore.”

„Tool sloj je zadužen za registraciju, izvršavanje i odobrenje alata. Svi alati se registruju na jednom mestu, pre poziva prolaze bezbednosnu proveru i proces odobrenja, a posle poziva se upisuje audit log.”

„Memory sloj je zadužen za skladištenje, pretragu i ubacivanje dugoročnog pamćenja i pamćenja projekta.”

„Context sloj je zadužen za kompresiju konteksta i upravljanje budžetom tokena. Kad istorija razgovora premaši gornju granicu prozora, automatski se komprimuje, uz zadržavanje nekoliko poslednjih celovitih interakcija.”

„Zavisnosti su: CLI zavisi od Agent-a, a Agent od četiri modula — LLM, Tool, Memory i Context. Ta četiri modula ne zavise jedni od drugih, pa se mogu nezavisno razvijati i testirati. Zamena modela dira samo LLM sloj, dodavanje alata samo Tool sloj, promena strategije pamćenja samo Memory sloj — bez međusobnog uticaja.”

Kako upisati PaiCLI u biografiju?

Naziv projekta: PaiCLI — komandna alatka, terminalni AI Agent

Kratak opis: terminalni Agent u Javi, po uzoru na Claude Code; podržava tri režima izvršavanja — ReAct, Plan-and-Execute i Multi-Agent Team — a poseduje sistem evaluacije, snapshot rollback, višekružne razgovore, pretragu koda, pozive alata i druge sposobnosti.

Tehnološki stek: Java 21 + Spring AI + JGit + JUnit 5 + Elasticsearch + MCP protokol

Ključne odgovornosti:

• dizajnirao paralelni framework za evaluaciju sa tri nezavisna kanala: analiza dokaza sesije, provera signala isporuke projekta i popis prilagođenih konfiguracija Agent-a
• na bazi JGit-a implementirao side-history snapshot sistem: automatski potpuni pre-turn snapshot pre izvršavanja Agent-a, asinhroni inkrementalni post-turn snapshot posle izvršavanja, uz podršku preciznog vraćanja na bilo koje istorijsko stanje
• izgradio Golden Set za evaluaciju pretrage koda, koji pokriva obradu nepoznatih komandi, paralelno izvršavanje alata i raščlanjivanje referenci na datoteke; automatsko poređenje pre i posle svake izmene prompta obezbeđuje da pretraga ne regredira
• implementirao nepromenljiv sistem audit logova sesija: append-only JSONL format beleži svaku LLM poruku i svaki poziv alata, nezavisno od liste razgovora koju korisnik vidi, i podržava analizu replay-a i prikupljanje dokaza za evaluaciju

Kraj

U AI svetu konkurencija je zaista žestoka — DeepSeek V4 Flash zvanično još nije objavio ni saopštenje, a AI krugovi su već odavno uzavreli.

Eno, i Qwen 3.8 Max je objavljen — svi se utrkuju ko pre.

Naravno, najveća dobit te utrke u AI svetu je izjednačavanje tehnologije: onaj ko ne može da koristi Codex može da koristi DeepSeek i time rad i učenje diže na najviši nivo efikasnosti.

Nadam se da će vam današnja suština doneti bar malo pomoći i inspiracije 🤔

Napred, prijatelji.

Vidimo se u sledećem.