Zaposleni u BYD-u: 4 godine radnog iskustva, godišnja plata oko 190.000, 30 godina, 211 osnovne studije, F3 nivo, druge polovine sledeće godine, koliko povišice mogu dobiti promenom posla? (sa pitanjima za intervju o Agentu)

Video sam jednu objavu zaposlenog u BYD-u.

4 godine radnog iskustva, godišnja plata oko 190.000, 30 godina, 211 osnovne studije, F3 nivo, druge polovine sledeće godine, koliko povišice mogu dobiti promenom posla?

Smatram da na povišicu utiču dva ključna faktora: prvo je iskustvo u industriji, a drugo je sreća i ljudski odnosi.

U AI eri, BYD ima nekoliko osnovnih biznisa koji će sigurno biti jako traženi.

① God's Eye sistem: ovo je BYD-ov napredni sistem inteligentne vozačke pomoći, koji podržava funkcije kao što su NOA u gradu bez mapa (automatska vozačka pomoć za navigaciju), vođenje na auto-putu i autoparkiranje.

② Pametna kabina: na konferenciji o strategiji inteligencije 2026. godine, BYD je predstavio namenski AI agent "Didi Shrimp" (Didi Shrimp), koji je pozicioniran kao sekretar u životu koji je ljudskiji i koji bolje razume vlasnika vozila.

③ AI infrastruktura i robotika: pored vozila, BYD je rasporedio i poslužitelje za AI na nivou preduzeća (sa tehnologijom hlađenja tečnošću), samokretne robotove (AMR) i prototipove humanoidnih robota. AI tehnologija je prodrla u celokupni scenario istraživanja, proizvodnje i logistike.

Proizvođač automobila je svakako jedan ogroman i tipičan scenario za sprovođenje AI-a, i to sa velikom potražnjom.

Zašto?

Namenski AI u vozilu više nije samo prosto optimizovanje glasovne interakcije, već je zasnovan na Agentic AI arhitekturi koja duboko povezuje celo vozilo, uz potrebu da se poveže kontrola vozila, navigacija i inteligentna vožnja.

Pored toga, u industrijskoj proizvodnji prisutni su i humanoidni roboti, pametno raspoređivanje proizvodnje, AI vizuelna kontrola kvaliteta i slično.

Da bi se povećala efikasnost istraživanja i razvoja, potrebno je i oslanjanje na AI Coding za usavršavanje tehnoloških procesa.

Zato svi vi slobodno možete proširiti svoje ambicije - ono što možete učiniti daleko je više nego što vidite.

Ako ste osoba koja veruje u napor, veruje u proces, veruje u jedan korak po jedan korak i veruje da možete uzeti svoj deo kolača u AI eri, onda sledeća teška iskustva sa intervjua nadam se pažljivo pročitajte.

(Ceo tekst je intenzivan, garantujem da ćete naučiti mnogo toga, vežite sigurnosne pojaseve, krećemo!)

content

PS: PaiCLI je terminalni Agent sličan Claude Code-u, otvorenog koda. Ako želite da imate iskustvo sa Agent projektom, možete ga pogledati kao referencu.

GitHub: https://github.com/itwanger/PaiCLI-Python

01. Strategija obrade neuspeha poziva alata?

Klima u konferencijskoj sali bila je prilično jaka, a Laowing je ušao i dalje držeći šolju toplog čaja. Na šolji su pisale reči "Tehnički odeljak 2023 - timbilding", ali su bile izbledivele, ostalo je samo pola.

Prešao je pogledom preko pola strane rezimea, prstom pokazao na prvi naziv projekta i upitao: "Kako vi obrađujete situaciju kada poziv alata ne uspe?"

"U tri situacije."

"Prva je strategija odbijanja. Alat je pre izvršenja blokiran sigurnosnim slojem - na primer, path guard otkrije prekoračenje putanje fajla, ili command guard blokira opasnu operaciju poput rm -rf. Tada se direktno vraća razlog odbijanja, bez ulaska u fazu izvršenja."

"Druga je izvršni izuzetak. Alat je pokrenut, ali je prijavio grešku - mrežni timeout, API vraća 500, fajl ne postoji - sve ovo se računa."

"Treća je timeout. Postavili smo više nivoa timeout-a - pojedinačna komanda 60 sekundi, grupna paralelna 90 sekundi, pretraga 8 sekundi. Po isteku se proces odmah nasilno prekida i vraća se poruka o timeout-u."

"Način obrade u sve tri situacije je isti: informacija o grešci se formatira kao tekst i kao rezultat poziva alata prosleđuje LLM-u. Model, na osnovu informacije o grešci, sam odlučuje o sledećem koraku - da pokuša ponovo sa drugim parametrima, da zameni alat ili da korisniku kaže da ne može."

Zašto se ne radi automatsko ponavljanje u sloju alata?

"Zato što razlozi neuspeha alata variraju. Ako su parametri pogrešno napisani, ponavljanje stotinu puta i dalje će biti pogrešno - treba promeniti parametre; ako je API ograničio protok, može se sačekati i pokušati ponovo; ako fajl nije pronađen, možda je putanja pogrešno napisana, pa treba prvo pretražiti da bi se potvrdila putanja. Model, sa konkretnom informacijom o grešci, bolje procenjuje od strategije ponavljanja."

"Sami LLM zahtevi imaju automatsko ponavljanje - 3 pokušaja, eksponencijalno odstupanje, počevši od 500 milisekundi, maksimalno kašnjenje 30 sekundi, uz dodatnih ±20% nasumičnog variranja kako bi se sprečilo da više zahteva završe u istom vremenskom prozoru. Mrežne oscilacije su jednostavne prirode i pogodne su za automatsko ponavljanje."

02. Kako ste radili optimizaciju namere modela?

"U dva pravca."

"Prvi pravac je slojevito sastavljanje prompta. Sistemski prompt ukupno ima 9 slojeva, od kojih su prva 4 statična - definicija identiteta, definicije alata, sigurnosna strategija, ličnost, režim, odobrenje. Oni se ne menjaju tokom cele sesije. Poslednjih 5 slojeva su dinamični - kontekst izvršavanja, memorija projekta, indeks Veština - ažuriraju se u svakom krugu."

"Statični slojevi na početku imaju prednost: Prompt Caching pogađa se na osnovu najdužeg zajedničkog prefiksa, pa što je prefiks stabilniji, to je veća stopa pogađaja keša."

"Drugi pravac je prepustiti LLM-u da sam donese ocenu namere. U svakom krugu se istorija razgovora i trenutni ulaz zajedno predaju modelu, a model sam odlučuje da li da pretraži novi sadržaj, da odgovori direktno na osnovu postojećeg konteksta ili da zatraži od korisnika da razjasni."

Zašto ne koristiti tradicionalni klasifikator namere?

"Troškovi održavanja su previsoki. Sa svakom novom namenom mora se označiti skup podataka, istrenirati klasifikator i rasporediti ga u produkciju. Scenario korišćenja Agenta se menja brzo - danas se doda novi alat, a sutra se pojavi nova namena, pa klasifikator ne može da prati tempo iteracije."

"LLM sam po sebi ima vrlo jaku sposobnost razumevanja namere, pa kada se koristi direktno za ocenu namere, fleksibilnost je mnogo veća. Kada se pojavi situacija koju ne može tačno da proceni, dovoljno je izmeniti prompt, bez potrebe za ponovnim treniranjem modela."

03. Kako su konstruisani podaci za evaluaciju?

Laowang je podigao šoljicu čaja da otpije gutljaj, ali je otkrio da se ohladio, pa ju je vratio. Preokrenuo je stranu rezimea, a pogled mu je zastao na rečima "sistem za evaluaciju": "Kako konstruišete podatke za evaluaciju?"

"U tri sloja izvora podataka."

"Prvi sloj je Golden Set, deterministički test slučajevi. Svaki slučaj definiše ulazni upit, očekivanu putanju fajla koja se pogađa i očekivani isečak koda koji se čita. Trenutno je akumulirano na stotine slučajeva - jedna prolazka odmah pokazuje da li je proces pretrage regresirao."

"Drugi sloj je dnevnik sesije. Kompletni proces svakog razgovora - korisnički ulaz, tekst modelovog rezonovanja, parametri poziva alata i povratne vrednosti - beleži se dodavanjem u JSONL formatu. Ovi podaci nisu pogođeni kompresijom konteksta ni brisanjem istorije, to su pravi sirovi podaci."

"Treći sloj je audit log. Svi opasni pozivi alata - pisanje fajla, izvršavanje komandi, MCP alati - prate jednu audit poruku koja sadrži naziv alata, parametre, rezultat izvršenja (odobreno/odbijeno/greška), vreme trajanja i način odobrenja."

"Tokom svakodnevne upotrebe se uoči problem → iz dnevnika sesije se izvuku sirovi podaci tog razgovora → ručno se označe očekivani rezultati → uključe u Golden Set. Sa svakim ispravljenim bag-om, skup za testiranje dobija još jedan slučaj."

04. Kakav prompt je dobar? Lična iskustva?

"Četiri iskustva."

"Prvo, slojevito sastavljanje. Prompt se prema fokusima razdvoji u nezavisne fajlove - sloj identiteta, sloj režima, sloj Veština - svaki upravlja svojim delom. Izmena instrukcija u sloju Veština ne utiče na ponašanje sloja identiteta."

"Drugo, instrukcije se atomizuju. Jedna instrukcija upravlja samo jednom stvari. 'Prvo pretraži, pa čitaj, pa sažmi' se razdvoji u tri instrukcije, čime je stopa poštovanja modela mnogo veća nego kod jedne složene instrukcije."

"Treće, prvo imaj skup za evaluaciju pa menjaj Prompt. Pre izmene pokreni jednom, posle izmene pokreni jednom i uporedi rezultate."

05. Koje coding agent koristite? Kako su vam količine poziva?

"U svakodnevnom razvoju najviše koristim Codex - generisanje koda, refaktoriranje, pregled i debagovanje uglavnom se oslanjaju na njega. Claude Code takođe koristim, uglavnom za arhitektonske nivoe."

"Što se tiče količine poziva, Codex u vrhuncu može potrošiti skoro milijardu Tokena dnevno."

06. Kako inače obezbeđujete isporuku uz vibe coding?

Laowang je skinuo naočare, očistio sočivo donjim delom košulje i ponovo ih stavio.

"Vibe coding je sasvim popularan, kako ga koristite za isporuku?"

"Suština vibe coding-a je opisivanje zahteva prirodnim jezikom i dozvoljavanje Agentu da generiše kod. Ali vibe ne znači bez provere - standard isporuke je isti kao za ručno pisani kod."

"Moj proces je u četiri koraka. Prvi korak, razlaganje zahteva. Veliki zahtev se razloži na male zadatke, čiji se očekivani izlaz može opisati jednom rečenicom. Zadatak prevelikog obima lako odvede Agenta u pogrešnom smeru."

"Drugi korak, Agent generiše prvu verziju. Pokrene se sa Codex, generiše kod i testove."

"Treći korak, Claude Code pregled. Fokus je na tri stvari: da li je logika tačna, da li postoje sigurnosni rizici i da li je stil usaglašen sa postojećim kodom. Dva Agenta unakrsno proveravaju."

"Četvrti korak, pokretanje testova. Jedinični i integracioni testovi moraju proći da bi se smatralo isporučenim. Sami testovi mogu biti generisani od strane Agenta, ali opseg pokrivenosti test slučajeva mora se ručno potvrditi."

07. Da li ste vi dizajnirali memory modul? Objasnite.

Laowang je okrenuo rezime da pogleda poleđinu, a onda ga vratio na prednju stranu, kao da nešto proverava. Njegov čaj se odavno ohladio, ali ga je ipak podigao i otpio gutljaj - verovatno iz navike, one navike da sediš na radnom mestu, napola pišeš kod i rukom pipaš šoljicu.

"Da li si ti dizajnirao Memory?" - prstom je pokazao na opis projekta na rezimeu dok je spuštao šoljicu.

"Da, celina je dvoslojna arhitektura memorije - kratkoročna i dugoročna memorija. Iznad njih je jedinstveni upravljač memorije kao ulazna tačka. Bilo da se čita ili piše memorija, spolja se operacije obavljaju kroz taj upravljač, bez direktnog diranja donjeg kratkoročnog i dugoročnog skladišta."

"Kratkoročna memorija je zadužena za kontekst tekuće sesije. Struktura podataka je uređena Mapa, svaka poruka se unosi po vremenskom redosledu, uključujući korisnički ulaz, odgovor modela i rezultat poziva alata. Postoji ograničenje token budžeta, a kada se prekorači, najstarija stavka se eliminiše po FIFO principu."

"Dugoročna memorija je zadužena za postojanost kroz sesije. Kada korisnik kaže 'zapamti ovo' ili 'zapiši', alatom se informacija sačuva i persistsuje kao JSON fajl. Svaka memorija ima tip, opseg (nivo projekta ili globalni) i vremensku oznaku."

"Pre svakog kruga LLM poziva, upravljač memorije, na osnovu onoga što je korisnik upravo rekao, pretražuje dugoročnu memoriju da li ima relevantnog sadržaja. Ako pronađe, ubacuje ga u sistemski prompt. Način pretrage je podudaranje ključnih reči - prvo se Jieba-om ulaz korisnika iseče na pojedinačne reči, a zatim se proverava da li sadržaj svake memorije sadrži te reči; što ih više sadrži, to je relevantnost veća. Nije korišćena vektorska pretraga."

Zašto ne koristiti Embedding za semantičku pretragu?

"Zato što obim dugoročne memorije nije veliki. Jedan korisnik tokom vremena akumulira možda desetine do nekoliko stotina zapisa. Pri toj količini podataka, podudaranje ključnih reči je dovoljno, a tačnost nije niska."

"Uvođenje Embedding-a znači dodatnu zavisnost od vektorske baze, pri čemu svako čuvanje i čitanje zahteva pokretanje Embedding modela. Za terminalni alat, složenost postavljanja i latenca odziva bi se primetno povećali, a odnos između koristi i troškova je nezao."

08. Dizajnerska ideja kratkoročne, srednjoročne i dugoročne memorije?

"Da budem iskren, trenutno imamo dva sloja - kratkoročna i dugoročna memorija, bez nezavisnog srednjeročnog sloja."

"Kratkoročna memorija je na nivou sesije, njen životni ciklus prati sesiju. Podaci se čuvaju u memoriji, u uredenoj Mapi, poređani po redosledu unosa. Pri svakoj poruci se procenjuje broj tokena - za ćirilicu oko 1,5 znakova po tokenu, za latinicu oko 4 znaka po tokenu. Kada ukupan broj tokena pređe budžet, pokreće se kompresija."

"Kompresija ne znači prosto odbacivanje - radi se sažimanje pomoću LLM-a. Algoritam je Map-Reduce: prvo se stare poruke podeljen u grupe po pet, svaki blok posebno sažme, a zatim se svi sažeci blokova objedine u jedan ukupni sažetak. Poslednja 3 kruga razgovora se ne kompresuju, kako bi model imao kompletnu memoriju o tekućoj temi."

"Dugoročna memorija je postojana kroz sesije. Pokreće se čuvanjem kada korisnik kaže 'zapamti' ili 'zapiši', a persistsuje kao JSON fajl. Svaka memorija ima polje scope, sa vrednošću project ili global. Memorije sa opsegom project vidljive su samo u okviru odgovarajućeg projekta, dok su memorije sa opsegom global pretražive u svim projektima."

"Možete opseg project razumeti kao vrstu 'memorije na nivou projekta', ali on sa global memorijom deli isti mehanizam skladištenja i pretrage - razlikuje se samo vidljivost, u suštini je ista razina."

Kako teče prelaz iz kratkoročne u dugoročnu?

"Dešava se tokom kompresije razgovora. Kompresija ne samo da sažima stare poruke u sažetak, već iz istorije razgovora izdvaja one stabilne informacije koje će biti korisne i ubuduće i upisuje ih u dugoročnu memoriju."

"Konkretno, tokom kompresije se dodatno pokreće jedan krug ekstrakcije činjenica - iz sadržaja razgovora izdvajaju se stabilne činjenice, a filtriraju se privremene informacije. Sadržaj sa rečima nesigurnosti poput 'možda' i 'nagađam' se odbacuje, opisi privremenih zadataka poput 'šta korisnik želi' i 'šta se trenutno obrađuje' takođe se odbacuju - zadržavaju se samo potvrđene činjenice koje se mogu koristiti kroz sesije."

"Pri upisu se automatski određuje opseg. Informacije snažno vezane za tekući projekt označavaju se kao project, dok se opšte preferencije označavaju kao global."

09. Koja je strategija upisa i ažuriranja memorije?

"Upis ima dva načina okidanja."

"Prvi je eksplicitno okidanje. Korisnik kaže 'zapamti', 'zapiši', 'zabeleži mi' - model poziva alat za čuvanje memorije i informacija se smešta u dugoročnu memoriju. Alat je u dizajnu namerno ograničen - okida se samo kada korisnik jasno iskaže nameru za čuvanjem, ne prisluškuje i ne beleži potajno."

"Drugi je automatska ekstrakcija. Tokom kompresije razgovora, LLM iz istorijskih poruka izdvaja stabilne činjenice. Ekstrakcija ima pravila filtriranja - odbacuje se sadržaj sa rečima nesigurnosti, odbacuju se opisi privremenih zadataka, zadržavaju se samo potvrđene činjenice koje se mogu koristiti."

"Jezgro strategije ažuriranja je deduplikacija. Pre svakog upisa, u istom domenu (tip + opseg + projekat) radi se provera deduplikacije. Deduplikacija nije prosta jednakost niski - prvo se radi NFKC normalizacija, pretvaranje u mala slova, uklanjanje interpunkcije, ali se zadržavaju simboli sa značenjem (hešteg, @, procenat, separator putanje i slično), čime se dozvoljava razlika samo na nivou modalnih reči."

"Rezultat je da će 'korisnik preferira IntelliJ IDEA' i 'korisnik preferira da koristi IntelliJ IDEA' biti prepoznati kao ista memorija, bez duplog skladištenja. Ali 'korisnik preferira IntelliJ IDEA' i 'korisnik preferira VS Code' se neće spojiti, jer se ključne informacije razlikuju."

10. Da li je dizajn tabela za tri tipa memorije isti? Objasnite polja.

Laowang je gurnuo naočare gore i pogledao na sat - ne onim pogledom koji žuri, već više kao da je shvatio da je razgovor duži nego što je očekivao, što je i njega iznenadilo.

"Da li je struktura tabela za tri tipa memorije ista?"

"Trenutno imamo dva sloja, kratkoročni i dugoročni. Strukture podataka u ta dva sloja se razlikuju."

"Kratkoročna memorija ne prelazi u tabelu, čuva se u memoriji. Svaki zapis ima nekoliko polja: id razlikuje poreklo po prefiksu - user- označava korisničku poruku, assistant- označava odgovor modela, tool- označava rezultat poziva alata; content čuva tekstualni sadržaj; type označava tip, razlikuje se na razgovor, rezultat alata i sažetak; uz timestamp i tokenCount. tokenCount je procenjena vrednost - ćirilica 1,5 znakova po tokenu, latinica 4 znaka po tokenu."

"Dugoročna memorija se persistsuje na disk, u JSON fajlove. Polja svakog zapisa: id je fact- sa rednim brojem, content čuva prečišćeni tekst činjenice, type je ujednačeno FACT, timestamp je u ISO 8601 formatu, uz metadata objekat."

"U metadata postoje dva ključna polja. scope označava da li je memorija na nivou projekta ili globalna, sa vrednošću project ili global. project polje čuva putanju projekta i ima vrednost samo kada je scope project. Pri pretrazi se ova dva polja koriste za filtriranje vidljivosti - globalne memorije su pretražive u svim projektima, a memorije na nivou projekta samo u okviru odgovarajućeg projekta."

"Ako količina memorije naknadno naraste na desetine hiljada zapisa, u metadata ću dodati embedding polje za čuvanje vektora, preći na skladište u bazi, a pretragu prebaciti sa podudaranja ključnih reči na približnu pretragu najbližih suseda (ANN). Ali pri trenutnoj količini od nekoliko stotina zapisa, JSON fajlovi sa podudaranjem ključnih reči su sasvim dovoljni."

11. Vaše mišljenje o Agentu i workflow-u?

Laowang se naslonio na naslon stolice, i dalje držeći potpuno ohlađeni čaj. Prsten je bljesnuo pod svetlom fluorescentne sijalice. Promenio je položaj, kao da želi u drugom poluvremenu da promeni ritam razgovora.

"Promenimo smer - kako vidiš Agent i workflow?"

"To su dve stvari koje rešavaju različite probleme i ne mogu se mešati pri poređenju."

"Suštinska sposobnost Agenta je samostalno odlučivanje. Zadat mu je cilj, a on sam procenjuje koji alat da koristi, kojim redosledom da izvršava i kako da se prilagodi kada naiđe na problem. Pogodan je za otvorene zadatke, poput 'istraži mi ovaj bag' - ne znaš koliko će koraka trebati da se reši."

"Suštinska sposobnost Workflow-a je kontrola i praćenje. Proces je unapred definisan, zavisnosti između čvorova su određene, šta svaki korak radi i kako podaci teku je sve fiksirano. Pogodan je za zadatke sa fiksnim procesom, poput 'primi povratnu informaciju korisnika → klasifikuj → raspodeli → obradi → odgovori' - svaki put istim redosledom."

"U produkciji se obično koriste mešovito. Workflow čini kičmu, orkestrirajući deterministički proces, dok Agent obrađuje one nesigurne korake na kičmi."

12. Kakav Agent se smatra dobrim Agentom?

"Tri kriterijuma: da uradi how treba, da ometanje bude malo i da pruži zaštitu."

"Da uradi how treba je donja granica. Stopa završetka zadatka mora biti visoka - uz jasnu instrukciju, stvar mora biti dovedena do kraja i ispravno urađena."

"Maleno ometanje je iskustvo. Idealni Agent sam donosi odluke tamo gde može samostalno da proceni, a pita samo kada zaista nije siguran. Ako pri svakom koraku iskoči prozorčić za potvrdu, to nije ništa drugo do ručna operacija."

"Ako dođe do greške, daje korisne poruke o grešci, ume da se elegantno degradira i neće dozvoliti da neuspeh jednog poziva alata sruši čitav zadatak. Za sada Claude Code u sva tri elementa radi vrlo dobro - to je najstabilniji terminalni Agent koji sam koristio."

13. Kakva su iskustva sa analizom badcase-a? Da li radite konsolidaciju?

Čaj u Laowangovoj šoljici je već bio pri dnu, a on nije ponovo dolivao. Pogledao je na sat - ne jer žuri, već više kao da želi da proveri koliko dugo je razgovarao - a onda mu je ugao usana drhtao, verovatno zadovoljan tim trajanjem.

"Poslednje - kakva su iskustva sa analizom Badcase-a?"

"U tri koraka."

"Prvi korak je rekonstrukcija scene. Kada Agent ima problem, ne možeš po utisku da nagađaš u kom je koraku greška - moraš ponovo izvući kompletan proces tog razgovora i pogledati: šta je korisnik rekao, kako je model razumeo, koji je alat pozvao, koje parametre preneo i šta je alat vratio."

"Imamo dva skupa podataka koja su namenjena tome. Jedan je dnevnik sesije, koji beleži svaki korak razgovora, uključujući proces modelovog rezonovanja i detalje poziva alata. Drugi je audit log, koji posebno beleži rezultate izvršenja opasnih operacija - na primer, da li je pri pisanju fajla odobreno ili blokirano sigurnosnom strategijom, da li je korisnik ručno odobrio ili je automatski izvršeno. Kada se ta dva skupa podataka prekriže, problematični korak se uglavnom jasno vidi."

"Drugi korak je da se za svaki Badcase dodeli jedna oznaka koja označava u kom je koraku nastao taj neuspeh. Na primer: da li je model pogrešno razumeo namenu korisnika, da li su pri pozivu alata prosleđeni pogrešni parametri, da li je sam alat prijavio izuzetak tokom izvršenja ili je razgovor predugačak i prešao je prozor konteksta. Jedan Badcase dobija samo jednu glavnu oznaku - ne dodeljujte istovremeno dve ili tri, jer previše oznaka je isto kao da ih nema, pa ne znate šta prvo da popravite."

"Treći korak je pregled statističke distribucije oznaka. Kada se prikupi određeni broj Badcase-a, jasno je koji tip neuspeha se najčešće pojavljuje, pa se u sledećem krugu optimizacije prvo koncentrišite na to. Istovremeno se ti Badcase-ovi pretvaraju u regresivne test slučajeve i uključuju u Golden Set. Sa svakim ispravljenim bag-om, skup za testiranje dobija još jedan slučaj, što garantuje da se isti problem neće ponoviti."

Kako upisati PaiCLI u rezime?

Naziv projekta: PaiCLI - terminalni AI Agent komandnolinijski alat

Kratak opis projekta: Java verzija terminalnog Agenta koja je ravna Claude Code-u, podržava tri režima izvršenja - ReAct, Plan-and-Execute i Multi-Agent Team - sa sposobnostima kao što su višekružni razgovor, poziv alata, upravljanje memorijom i pretraga koda.

Ključne odgovornosti:

• Projektovanje dvoslojnog sistema memorije (kratkoročna + dugoročna), kratkoročna memorija se automatski komprimuje na osnovu token budžeta (Map-Reduce sažetak + ekstrakcija činjenica), dugoročna memorija se kroz podudaranje ključnih reči ubacuje u kontekst, uz podršku za izolaciju opsega na nivou projekta i na globalnom nivou
• Implementacija trostepenog mehanizma obrade grešaka pri pozivu alata (blokada strategije → hvatanje izuzetka → prekid zbog timeout-a), informacija o grešci se prosleđuje LLM-u koji samostalno odlučuje o strategiji ponavljanja, dok sloj LLM zahteva podržava ponavljanje sa eksponencijalnim odstupanjem (3 puta, osnovno kašnjenje 500 ms)
• Izgradnja 9-slojnog Promptera slojevitog sastavljača, statični slojevi ispred pogađaju Prompt Caching, dinamični slojevi se seku po token budžetu, čime se trošak tokena po pojedinačnom zahtevu smanjuje za oko 35%
• Postavljanje višeslojnog sistema evaluacije, održavanje determinističkog Golden Set skupa regresivnih testova, u kombinaciji sa sirovim zapisima iz dnevnika sesije i audit log-a, čime se omogućava celokupno praćenje porekla Badcase-a i označavanje uzroka
• Projektovanje progresivnog sistema učitavanja Veština, sa trostepenim učitavanjem po potrebi (indeks → telo → referentna dokumentacija), kontrola broja istovremeno aktivnih Veština kroz LRU bafer (gornja granica 3), čime se izbegava prelivanje konteksta

ending

Neki smatraju da je AI čudovišna poplava i stalno mu se odupiru.

Neki smatraju da je AI alat za povećanje efikasnosti, pa stalno proširuju granice sopstvenih sposobnosti.

Najbolje vreme za sadnju drveta bilo je pre deset godina, a drugo najbolje je -

U ovoj sekundi nakon što ste pročitali ovaj sadržaj, otvorite terminal, pokrenite PaiCLI i otkucajte prvi prompt.

Pokrenite svog prvog Agent.

Napravite svog prvog Agent.