AI Agent pitanja za intervju: RAG, Function Calling i orkestracija tokova posla

01,Zašto svi u CV-u pišu AI sadržaj?

Stari Wang mi pregleda CV:"Vidim da tvoj CV ima puno AI projekata, PaiKogen RAG, PaiFlow Agent, zašto nemaš iskustvo sa tradicionalnog razvoja?"

Kažem:"Wang ge, ne što ne želim da pišem, već mislim da AI sadržaji bolje pokazuju moju konkurentnost."

"Tradicionalni razvoj znam, Java, Spring Boot, MyBatis - sva ta pitanja za intervju mogu da pitaju, nema onoga što ne mogu da odgovorim, oh ne, nema onoga na šta ne mogu da odgovorim. Ali koji je ovo vreme? AI vreme. HR i vi prijemni oficiri gledate CV, prvo šta želite da vidite jeste da li postoji AI iskustvo razvoja?"

"Osim toga, AI razvoj nije zamak u vazduhu, osnova je i dalje tradicionalni razvoj. RAG sistem koristi vektorske baze podataka, moraš da znaš ElasticSearch; Agent poziva API, moraš da znaš HTTP ili MCP protokol; tokovi posla moraju da orchestriraju zadatke, moraš da znaš konkurentno programiranje, redove poruka."

Stari Wang nastavlja:"I onda misliš da je najveća razlika između tradicionalnog backend razvoja i AI razvoja aplikacija u načinu razmišljanja?"

Kažem:"Najveća razlika jeste način razmišljanja."

"Tradicionalni razvoj je determinističko razmišljanje, ulaz je određen, izlaz je određen, logika je linearna. AI razvoj je verovatnosno razmišljanje, ulaz je određen, izlaz je neodređen, logika je verovatnosna."

"Na primer, u tradicionalnom razvoju, napišeš if-else, ako je uslov zadovoljen ide se u granu A, ako nije zadovoljen ide se u granu B, rezultat je određen."

"AI razvoj aplikacija je drugačiji, daš modelu jedan prompt, on ti može da da A odgovor, može da da B odgovor, čak može da da C odgovor. Ti dizajniraš kako da modelu verovatno da ono što želiš, a ne 100% određeno."

"Ova promena načina razmišljanja je mnogo teška za tradicionalne razvojnike da se prilagode pri prelazu na AI razvoj."

01-1,Kakva je platforma za AI pametno upravljanje održavanjem?

Kažem:"Ovo je projekat koji sam nedavno radio, koristim AI da pomognem u radu održavanja."

"Jezgrene funkcije platforme uključuju:

Analizu logova: automatski analizira sistemske logove, prepoznaje abnormalne modele, unapred upozorava.

Dijagnostiku kvarova: kada se pojavi kvar, automatski prikuplja relevantne informacije, daje moguće uzroke i rešenja.

Optimizaciju resursa: analizira korišćenje resursa servera, daje predloge optimizacije, na primer koje servise možeš smanjiti, koje treba proširiti.

Q&A bazu znanja: unosi dokumentaciju održavanja, istoričke case-ove u bazu znanja, inženjeri održavanja mogu direktno da pitaju AI, ne moraju da listaju dokumentaciju."

Stari Wang pita:"Koje tehnologije ova platforma koristi?"

Kažem:"Osnova je RAG+Agent tehnološki stack, gornji sloj koristi LangGraph4j za orkestraciju tokova posla."

02,Šta je AI Agent?

Tačka ispitivanja: Agent koncept

Referentni odgovor:

Običan LLM poziv je pitanje-odgovor: daš mu jedno pitanje, on ti daje jedan odgovor, gotovo.

AI Agent omogućuje velikim modelima da samostalno deluju: ne samo odgovara na pitanja, već može da planira zadatke, koristi alate, cirkulišće mislima, dok ne dovrši cilj.

S tehnoločke tačke gledišta, Agent ima nekoliko jezgrenih sposobnosti više od običnog LLM-a:

Prva je poziv alata. Agent može da koristi eksterne alate, na primer pretraživače, baze podataka, API-je. LLM samo generiše tekst, ali Agent okvir analizira izlaz LLM-a, prepoznaje da želi da pozove određeni alat, onda zaista poziva, rezultat vraća nazad u LLM. Ovo je Function Calling.

Druga je sposobnost planiranja. Suočeni sa kompleksnim zadatkom, Agent će ga rasčlaniti na više koraka, onda korak po korak izvršava. Na primer generisanje podkasta, on će planirati: prvo razume temu korisnika → generiše dijalog skriptu → poziva TTS da sintetiše govor → spaja audio. Ovaj proces se ne može završiti jednim LLM pozivom, trebaju višestruke interakcije i odluke.

Treća je memorija. Običan LLM poziv je bez stanja, šta se reklo u prethodnom krugu, sledećem krugu je zaboravio (osim ako celu istoriju ne guraš u prompt). Agent može imati kratkoročnu memoriju (kontekst trenutnog zadatka) i dugoročnu memoriju (akumulaciju znanja preko zadataka), ovo mu omogućava da radi kompleksnije scenare.

Četvrta je autonomna cirkulacija. Agent ne završava posle jednog poziva, on će na osnovu rezultata izvršenja odlučiti šta sledeće da radi. Ako poziv alata ne uspe, može probati drugačiji način da ponovi; ako otkrije da informacije nisu dovoljne, može da pretraži više podataka. Ova cirkulacija percepcija-odluka-akcija je ključna karakteristika Agent-a.

Vraćajući se na PaiFlow, naš engine tokova posla je zapravo jedna implementacija Agent-a. Korisnik kroz vizuelni interfejs orchestrira tok posla, unutar ima LLM čvorove, čvorove alata, uslovne grane, ovo je u suštini definisanje "logike ponašanja" jednog Agent-a. Engine tokova posla je odgovoran za schedule-iranje izvršenja, ekvivalentno agent-ovom "mozgu" koji pokreće ceo proces.

Na primer scenario generisanja podkasta: korisnik unosi jednu temu, tok posla prvo poziva LLM čvor da generiše skriptu, onda poziva TTS alat čvor da sintetiše govor, usred ima uslovnu procenu (da li je sadržaj u skladu sa pravilima). Ceo ovaj proces je jedan Agent koji radi — on je razumeo namenu korisnika, planirao korake izvršenja, pozvao eksterne alate, konačno završio zadatak.

Dakle jednostavno rezime: LLM je mozak, Agent je kompletna individua sa rukama i nogama koja može da radi. PaiFlow radi to omogućava korisnicima da lako sastave jednog Agent-a koji može da radi.

03,Šta je Function Calling?

Tačka ispitivanja: poziv alata

Referentni odgovor:

Function Calling je sposobnost velikih modela da pozivaju eksterne funkcije/API-je.

Običan LLM samo izlazi tekst, pitaš ga da mi pomogne da proverim današnji vremenski uspev u Pekingu, on ti najviše odgovara dobro, pomoći ću ti da proveriš — ali zaista ne može da proveri, jer nema ruke. Function Passing mu omogućava da LLM kaže koji alat želi da pozove, koje parametre šalje, onda eksterni okvir zaista izvršava.

Celi proces je ovakav:

Prvi korak, reci LLM-u koje alate su dostupne. Pri pozivu LLM-a, osim prompt-a, šalje se i lista alata, svaki alat ima ime, opis i definiciju parametara. Na primer:

{
  "name": "get_weather",
  "description": "preuzmi vremenske informacije za navedeni grad",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "naziv grada"}
    },
    "required": ["city"]
  }
}

Drugi korak, LLM odlučuje da li će koristiti alat. Korisnik pita kako je danas vreme u Pekingu, LLM vidi alat get_weather, opis je query weather info for specified city, on razume — ovaj alat može mi pomoći da odgovorim na ovo pitanje. Onda izlazi sa strukturiranim zahtevom za poziv:

{
  "tool_calls": [{
    "function": {
      "name": "get_weather",
      "arguments": "{\"city\": \"Peking\"}"
    }
  }]
}

Treći korak, okvir izvršava alat, rezultat vraća LLM-u. Eksterni okvir analizira ovaj izlaz, zaista poziva weather API, dobija rezultat onda vraća u dijalog, LLM na osnovu rezultata generiše konačan odgovor.

04,Šta je MCP?

Tačka ispitivanja: MCP protokol

Referentni odgovor:

MCP je protokol konteksta modela koji je predložio Anthropic, cilj je standardizovati način interakcije između velikih modela i eksternih alata.

Ranije je svaki alat morao posebno da se integriše, pisalo se hrpu adaptacijskog koda. MCP definisao je jedinstven protokol, alat implementira MCP Server, aplikacija implementira MCP Client, mogu da se međusobno povežu.

KLjučni koncepti MCP-a imaju tri:

Resources: izvori podataka samo za čitanje (fajlovi, baze podataka)
Tools: izvršive funkcionalnosti (API pozivi, izvršenje koda)
Prompts: predefinisani šabloni upita

Načini komunikacije imaju dva:

stdio: komunikacija kroz standardni ulaz/izlaz, pogodno za lokalne alate
SSE: komunikacija kroz HTTP SSE, pogodno za udaljene servise

Naša ideja implementacije MCP Client-a je ovakva:

public class McpClient {
    private final String transport; // "stdio" or "sse"

    // otkriji dostupne alate
    public List listTools() {
        return sendRequest("tools/list");
    }

    // pozovi alat
    public Object callTool(String name, Map args) {
        return sendRequest("tools/call", Map.of("name", name, "arguments", args));
    }

    private Object sendRequest(String method, Object params) {
        if ("stdio".equals(transport)) {
            // piši u stdin procesa čitanja, čitaj rezultat iz stdout
        } else {
            // pošalji HTTP zahtev
        }
    }
}

Pristupanje MCP alatima kroz konfiguraciju:

mcp_servers:
- name: "filesystem"
transport: "stdio"
command: ["python", "filesystem_server.py"]
- name: "search"
transport: "sse"
url: "http://search-mcp:8080"

Dopunsko pitanje 1: Koja je razlika između Function Calling-a i MCP-a?

Referentan odgovor:

FunctionCall: poziv funkcije, dozvoljava LLM-u da na osnovu prirodnog jezinka korisnika prepozna kakav alat mu treba i formatirani poziv alata;

MCP: obezbeđuje generički protokol okvir za otkrivanje, definisanje, i pozivanje sposobnosti alata koje eksterni sistemi nude;

06,Šta je RAG?

Kažem:"RAG, skraćenica od Retrieval-Augmented Generation, odnosno poboljšano generisanje pretragom."

"Jednostavno rečeno, pre nego što veliki model odgovori na pitanje, prvo pretražuje relevantne informacije u bazi znanja, onda rezultate pretrage koristi kao kontekst, zajedno šalje velikom modelu da generiše odgovor."

"Ovo ima dve prednosti:

Prvo, rešava problem znanja velikih modela. Obuka podataka velikih modela ima datum završetka, posle toga se dešavanja ne zna. RAG kroz real-time pretragu može dobiti najnovije informacije.

Drugo, rešava problem halucinacija velikih modela. Veliki modeli ponekad ozbiljno pričaju gluposti. RAG kroz pretragu realnih dokumenata, odgovor ima osnovu."

Stari Wang nastavlja:"Koja je jezgra procesa RAG-a?"

Kažem:"Četiri koraka:

Prvi korak, predobrada dokumenta. Originalni dokument se reže na chunk-ove, koristi embedding model da pretvori u vektore, smešta u vektorsku bazu podataka.

Drugi korak, vektorizacija upita. Kad korisnik postavi pitanje, i pitanje pretvori u vektor.

Treći korak, vektorska pretraga. U vektorskoj bazi podataka traži naj sličnije chunk-ove.

Četvrti korak, poboljšano generisanje. Pronađene chunk-ove koristi kao kontekst, zajedno sa pitanjem šalje velikom modelu, generiše konačan odgovor."

Stari Wang nastavlja:"Koja je razlika između RAG-a i fine-tuning-a? Kad koristiti RAG, kad fine-tuning?"

Kažem:"Ovo je dobro pitanje, mnogi ljudi mešaju."

"RAG je poboljšanje pretragom, ne menja sam model, samo daje modelu dodatni kontekst. Pogodno za scenare gde se znanje često ažurira, treba real-time."

"Fine-tuning menja parametre modela, model uči nova znanja. Pogodno za scenare gde je znanje relativno stabilno, treba duboko razumevanje."

"Moj kriterijum odluke je: ako učestalost ažuriranja znanja je više od jedne nedelje, koristi RAG; ako je manje od jedne nedelje, možeš razmisliti o fine-tuning-u."

"Osim toga, RAG je jeftin, ne treba obuka; fine-tuning je skup, treba označene podatke i računarske snage."

Stari Wang klima glavom:"Kriterijum odluke je jasan. A kojoj firmi si radio RAG sistem pametnog cenovnika?"

06-1,U kojoj firmi si radio RAG sistem pametnog cenovnika?

Kažem:"Radio sam u prethodnoj firmi, jednoj B2B kompaniji iz lanca snabdevanja."

"Njihov scenarij poslovanja je: kupac na platformi otprema dokument zahteva, sistem mora na osnovu sadržaja dokumenta automatski da generiše plan cenovnika."

"Tradicionalni način je čovek gleda dokument, čovek piše cenovnik, jedna narudžba prosečno 2 sata. Posle RAG-a, sistem automatski analizira dokument, upoređuje istorijske cenovnike, generiše plan cenovnika, prosečno 5 minuta."

Stari Wang nastavlja:"Kakve tehničke teškoće?"

Kažem:"Tri teškoće."

"Prva, kompleksnost formata dokumenta. Dokument koje kupci otpremaju imaju PDF, Word, Excel, još slike. Mi smo koristili OCR+analizu dokumenta, prvo različite formate pretvorimo u tekst, onda radimo dalju obradu."

"Druga, strategija rezanja chunk-ova. Ako se sece suviše sitno, semantika nije kompletna; ako se sece suviše grubo, pretraga nije precizna. Smisli smo više strategija, konačno po pasusima sećemo, efekat je relativno dobar."

"Treća, re-rank rezultata pretrage. Rezultati koje vraća vektorska pretraga, relevantnost nužno nije najviša. Mi smo dodalire-rank model, drugi put sortiramo rezultate pretrage, tačnost se povećala za 15%."

Stari Wang mu se oči upale:"Dobro, tehnički detalji si jasno objasnio. I koju ulogu si imao u ovom projektu?"

06-2,Koju ulogu si imao u RAG projektu?

Kažem:"Bio sam tehnički vođa, vodio mali tim od 5 ljudi."

"Konkretni rad obuhvata:

Izbor tehnologije: istraživao Milvus, Pinecone, Weaviate, ElasticSearch i druge vektorske baze podataka, konačno sam izabrao ElasticSearch, jer performanse su dobre, zajednica aktivna.

Arhitektura: dizajnirao tri ključna modula: servis predobrade dokumenata, servis vektorske pretrage, servis generisanja cenovnika.

Podešavanje modela: za scenario cenovnika, fino podešavao embedding model, tačnost pretrage sa 75% podignuo na 92%.

Inženjerska implementacija: rešio probleme kompatibilnosti formata dokumenta, strategiju rezanja chunk-ova, re-rank rezultata pretrage i druge inženjerske probleme."

Stari Wang nastavlja:"Pakete instalacije ove vrste ti si organizovao ili pomagao?"

06-3,Instalacijske pakete PaiKogen RAG ti si organizovao ili pomagao?

Kažem:"Instalacijske pakete sam vodio."

"Zato što RAG sistem uključuje više komponenti: vektorska baza podataka, embedding servis, API velikog modela, poslovni backend. Implementacija je komplikovana, organizovao sam jednoklikni instalacijski paket, Docker Compose konfiguraciju, šablon promenljivih okruženja, inicijalne skripte sve upakujem."

"Implementacija u novoj okolini, ranije je trebalo jedan dan, sada pola sata."

Stari Wang pita:"Pakovanje image-a je razvijači spakovali ili ti si odgovoran?"

06-4,Image pakovanje PaiKogen RAG je razvijači spakovalo ili ti si odgovoran?

Kažem:"CI/CD proces sam ja postavio, ali pakovanje image-a je automatsko."

"Koristio sam GitLab CI da napravim pipeline: commit koda → automatski test → build image → push repozitorijum → okida implementaciju. Razvojni inženjeri samo moraju da pišu kod, pakovanje i implementacija je sve automatsko."

"Deljenje image-a sam optimizovao, osnovni image i poslovni image su odvojeni, vreme build-a sa 10 minuta smanjio na 3 minuta."

"Osim toga, bezbednosno skeniranje image-a sam radio. Koristio sam Trivy da skeniram ranjivosti image-a, visoke ranjivosti automatski blokiraju objavljivanje."

Stari Wang nastavlja:"Ako build image-a ne uspe, kako istražuješ?"

Kažem:"Prvo gledam log build-a, lociram neuspešni korak. Uobičajeni uzroci: preuzimanje zavisnosti nije uspelo, unit testovi ne prolaze, Dockerfile sintaksna greška."

"Ako je preuzimanje zavisnosti neuspešno, proveri mrežu ili zameni domaće izvore image-a. Ako test ne prolazi, prvo lokalno prođi onda commit. Ako je Dockerfile greška, koristi docker build --progress=plain da vidiš detaljni log."

Stari Wang klima glavom:"Inženjerske sposobnosti su dobre. A kakva je platforma za AI pametno upravljanje održavanjem?"

07,Šta je token?

Token nije znak, nije reč, nije rečenica. To je najmanja jedinica informacije koju veliki model obrađuje. Možeš ga razumeti kao "pixel" velikog modela, baš kao što se slika sastoji od piksela, svet velikog modela se sastoji od token-a.

Kineski 1 kineski znak je otprilike 1.5-2 token-a, engleski 1 reč je otprilike 1-1.5 token-a. Dakle isti paragraf, kineski je "skuplji po token" od engleskog.

Jedna obična AI konverzacija, ulaz i izlaz otprilike troše 1000-3000 token-a.

Ako je Coding scenario, da AI ti pomogne da čitaš jedan srednji repozitorijum koda onda izmeniš, jedna konverzacija troši 50 do 200 hiljada token-a je normalno. Kao Claude Code ovaj Agent mod, jedan kompleksan zadatak potroši 500 hiljada token-a nije ni čudo.

Dakle možeš da razumešš, zasto mnogi ljudi AI pišu kod do polovine, iznenada dobiju poruku "nedovoljno stanje", ne zato što si mnogo koristio, nego Coding scenario sam po sebi je crnarupa za token-e.

Upravo se desila jedna zanimljiva stvar: Nacionalna uprava podataka prvi put je dala zvanično kinesko ime token-u, zove se rec-element. Značenje je "u oblasti obrade jezika, najmanja, nedeljiva osnovna jedinica informacije". Ovo imenovanje nastavlja logiku formiranja reči "pixel", "bajt", "reč" ukazuje oblast obrade jezika, "element" predstavlja najmanju osnovnu jedinicu.

Profesor Yang Bin sa Tsinghua univerziteta tokom dva savjeta je predložio novu shemu: model-element. Razlog je što "model" direktno odgovara veliki model, višemodelnost, ukazuje ključne osobine AI scenario-a.

Po mom mišljenju, u svakodnevnoj upotrebi, svi direktno kažu token.

Ali ovo načelo mora da se razume, prethodno je doba osnovna jedinica mere je bit, ovo doba osnovna jedinica mere je token.

07-1,Koliko token-a dnevno možeš da potrošiš?

Stari Wang:"Koliko token-a dnevno možeš da potrošiš?"

Kažem:"Wang ge, par desetaka."

Video sam da Stari Wang ne izgleda srećno, odmah sam promenio:"Šalim te, Wang ge. Ja pretplaćen na razne Coding Plan, posebno Qoder, pretplaćen sam na 6000 Credits taj, jedan mesec mi nije bas dovoljan."

Nastavljam:"Juče sam tek postavio PaiKogen RAG sistem, otkrio sam da potrošnja token-a malo teško izdrži."

Stari Wang nastavlja:"I kako optimizuješ potrošnju token-a?"

Kažem:"Par ideja, detaljno ti kažem."

"Prva, kompresija prompt-a. Mnogi prompt-i imaju suvišne informacije, na primer ponovljene instrukcije, nepotrebne primere. U PaiKogen RAG sam napisao algoritam kompresije, može automatski da prepoznaje i uklanja ove suvišne."

"Druga, mehanizam keširanja. Ista pitanja, ako se kontekst nije promenio, direktno vraća keširani rezultat, ne poziva model."

"Treća, nivo modela. Jednostavni zadaci koriste laki model, na primer Qwen-Turbo, brzina je velika, trošak mali. Kompleksni zadaci tek koriste veliki model, na primer GPT-5.4."

"Četvrta, batch obrada. Više sličnih pitanja, spoji u jedan poziv, smanji broj API zahteva."

Stari Wang čuje i oči mu se svetle:"Batch obrada ova ideja je dobra, konkretno kako implementirana?"

Kažem:"Koristi red poruka kao bafer. Pitanja korisnika prvo ulaze u red, onda agregira po vremenskom prozoru, na primer slična pitanja u 100ms spaja u jedan batch zahtev. Tako se broj API poziva može smanjiti za 70%."

Stari Wang klima glavom:"Imaš svest o troškovima, još razumiješ inženjersku optimizaciju, dobro."

08,Šta je LangGraph4j?

"LangGraph4j je Java okvir za orkestraciju tokova posla, posebno pogodan za AI tokove posla."

"Na primer scenario dijagnostike kvarova, tok posla može ovako da se dizajnira:

Prvi korak, primi obaveštenje o alarmu; drugi korak, upitaj relevantne logove; treći korak, analiziraj sadržaj log-a; četvrti korak, upitaj bazu znanja; peti korak, generiši izveštaj o dijagnostici; šesti korak, obavesti inženjere održavanja."

"Svaki korak je jedan čvor, između čvorova može postaviti uslovne grane. Na primer ako analiza log-a otkrije da je pun disk, direktno ide u granu čišćenja diska; ako je prekoracenje memorije, ide u granu restart-a servisa."

09,U razvoju mnogo koristiš AI alate?

Kažem:"Mnogo, sada se ne mogu odvojiti od AI alata."

"Kod postavljanja skeleta projekta, koristiću Quest mod Qoder-a; kod čitanja izvornog koda koristiću Gemini TRAE-a; razvojne zadatke predajem Codex-u."

"Ali najviše koristim Claude Code."

Stari Wang nastavlja:"Molim te reci ti o tvom iskustvu korišćenja u AI programiranju, na primer Claude Code."

09-1,Molim te reci mi o tvom iskustvu korišćenja u AI programiranju, na primer Claude Code.

Kažem:"Claude Code je moj glavni alat za razvoj."

"Koristio sam ga za nekoliko stvari:

Prvo, refaktorisanje koda. Daj mu jednu instrukciju, može automatski da razume logiku koda, da daje plan refaktorisanja, čak direktno generiše refaktorisani kod.

Drugo, popravka bug-ova. Baci mu poruku o grešci, može da analizira moguće uzroke, da daje predloge za popravku. Ponekad čak može direktno da locira problemni kod.

Treće, generisanje koda. Pisanje repetitivnog koda je posebno brzo, na primer CRUD interfejsi, unit testovi, par minuta može generisati set.

Četvrto, tehnička istraživanja. Susretneš nepoznatu tehnologiju, direktno ga pitaj, mnogo je brže od čitanja dokumentacije."

Stari Wang pita:"Koja je razlika između Claude Code-a i tradicionalnih IDE plugin-ova?"

Kažem:"Tradicionalni plugin-ovi su pomoć, Claude Code je saradnja."

"Tradicionalni plugin-ovi samo mogu da rade dopunu koda, proveru sintakse ove osnovne funkcionalnosti. Claude Code može da razume tvoju nameru, učestvuje u celom procesu razvoja."

"Na primer kažete '/github-skill-forge nađi na GitHub-u ima li projekata koji pomažu pri pisanju romana', on može prema određenim Skills da mi nađe izvorni kod koji želim, onda preuzme na lokalno za brzu sekundarnu razvojnu aktivnost."

Stari Wang klima glavom:"Nedavno vrlo popularni OpenClaw, razumiješ?"

10,Nedavno vrlo popularni OpenClaw, razumiješ?

Kažem:"Preterano razumem, sam razvio nekoliko Agent-a."

"OpenClaw je Agent okvir, omogućuje ti da prirodnim jezikom nalažeš AI da završi kompleksne zadatke."

"Sam sam razvio tri Agent-a: jedan je pomoćnik za reviziju naloga gitcode, jedan je pomoćnik za generisanje tehničke dokumentacije, jedan je pomoćnik za monitoring redovnih zadataka."

"Na primer scenario revizije gitcode, ranije sam morao ručno da se logujem u backend, pretražujem korisnike, dodajem dozvole, jedan nalog 2 minuta. Sada proces učim Agent-u, on u backend automatski izvršava, 20 naloga 1 minuta."

Stari Wang mu se oči upale:"Poboljšanje efikasnosti je očigledno. Ako te zamolim da dizajniraš jednog Agent-a, kratkoročnu i dugoročnu memoriju kako planiraš da dizajniraš?"

10-1,Ako te zamolim da dizajniraš jednog Agent-a, kratkoročnu i dugoročnu memoriju kako planiraš da dizajniraš?

Kažem:"Dizajniraću dva sloja memorije: kratkoročnu i dugoročnu."

"Kratkoročna, Session, čuvava kontekst trenutne konverzacije. Uključuje ulaz korisnika, odgovor Agent-a, rezultate poziva alata. Kratkoročna memorija je u memoriji, po završetku konverzacije se čisti."

"Dugoročna, Memory, čuvava važne informacije preko konverzacija. Na primer preference korisnika, istoričke zaključke, ključne činjenice. Dugoročna memorija je persistent na disku, sledeća konverzacija može da čita."

"Njihov način saradnje je: u procesu konverzacije, Agent real-time ažurira kratkoročnu memoriju; kada kratkoročna memorija približi Context gornjoj granici, okida Compaction, važne informacije piše u dugoročnu memoriju; početkom nove konverzacije, iz dugoročne memorije pretražuje relevantne informacije, učitava u kontekst."

"Konkretna implementacija, kratkoročna memorija se čuva u memoriji, koristi linked list strukturu, pogodno za brzo umetanje i brisanje. Dugoročna memorija se čuva na disku, koristi vektorsku bazu podataka, pogodno za semantičku pretragu."

"Još jedan detalj: nisu sve informacije vredne da se upišu u dugoročnu memoriju. Agent će oceniti važnost informacija, samo one sa važnošću iznad praga će upisati. Kriterijumi ocene uključuju: činjenice koje je korisnik eksplicitno izjavio, ključne zaključke konverzacije, informacije koje mogu uticati na naredne odluke."

Stari Wang nastavlja:"Koje su ključne komponente OpenClaw-a?"

10-2,Koje su ključne komponente OpenClaw-a?

Kažem:"Pet ključnih komponenti:"

"LLM, veliki jezički model, mozak Agent-a, odgovoran za razumevanje instrukcija, planiranje zadataka, generisanje odgovora."

"Task Planner, planer zadataka, razbija potrebe korisnika na izvršive korake."

"Tool Executor, izvršilac alata, odgovoran za pozivanje eksternih alata, na primer pretraga, operacije fajlova."

"Memory Manager, menadžer memorije, upravlja kratkoročnom i dugoročnom memorijom."

"Skill Loader, učitavač Skills, dinamički učitava Skills, proširuje sposobnosti Agent-a."

"Ovih pet komponenti komunicira kroz magistralu poruka, međusobno su decoupled. Na primer možeš da zameniš LLM iz Claude u GPT, ostale komponente ne osećaju promenu."

"Osim toga, OpenClaw ima još 8 konfiguracionih fajlova, definiše kompletnu ličnost Agent-a. AGENTS.md definiše granice sposobnosti, SOUL.md ubrizgava dušu, TOOLS.json određuje zabrane, SKILLS.json konfiguriše sposobnosti, MEMORY.json upravlja memorijom, SESSION.json upravlja sesijama, ROUTER.json konfiguriše rutiranje, CONFIG.json ostale konfiguracije."

Stari Wang pita:"Da li je Agent trajni proces?"

10-3,Da li je Agent trajni proces?

Kažem:"Ne, Agent je trenutna instanca po sesiji."

"Svaka konverzacija je jedan potpuni ciklus učitavanja-izvršavanja-uništavanja. Korisnik pokrene konverzaciju, Agent učitava konfiguraciju, inicijalizuje memoriju; u procesu konverzacije, Agent izvršava zadatke; završetkom konverzacije, Agent čuva stanje, oslobađa resurse."

"Prednost ovog dizajna je ušteda resursa, Agent ne zauzima memoriju zauvek; konfiguracija real-time važi, svaki run ponovo čita konfiguracione fajlove."

"Još jedna prednost je izolacija. Svaka konverzacija je nezavisna instanca Agent-a, jedan konverzija ima problema ne utiče na ostale konverzacije."

Stari Wang nastavlja:"Ako je Session predug, hoće li da prsne Context LLM-a?"

10-4,Session predug, hoće li da prsne Context LLM-a?

Kažem:"Hoće, zato OpenClaw radi optimizaciju."

"Dva mehanizma: Compaction i Pruning."

"Compaction, kompresija, kada Session približi Context gornjoj granici, Agent važne informacije piše u Memory, onda kompresuje sadržaj Session-a."

"Pruning, rezanje, pre slanja LLM-u, privremeno seče stare tool rezultate. Na primer pretraga vrati 100 rezultata, ali LLM treba samo prvih 10, ostale seče."

"Compaction je persistent, važne informacije se dugo čuvaju. Pruning je privremen, utiče samo na trenutni zahtev."

"Konkretnim vrednostima, kada dužina Session pređe 4000 token-a, okida Compaction. Pruning čuva najskorijih 2000 token-a, seče raniji sadržaj."

"Još jedna optimizacija: ako je određeni rezultat tool poziva posebno veliki, na primer pretraga vrati 1000 rezultata, Pruning će direktno uzeti prvih 10, ostale sve odbaciti."

Stari Wang klima glavom:"Kako je dizajniran mehanizam Memory?"

10-5,Kako je dizajniran mehanizam Memory?

Kažem:"Mehanizam Memory ima tri faze: pisanje, čuvanje, čitanje."

"Faza pisanja, Agent analizira sadržaj Session, ekstrahuje važne informacije, uključuje činjenice koje je korisnik eksplicitno izjavio, važne zaključke u konverzaciji, vredne informacije koje je Agent generisao."

"Faza čuvanja, upisani Memory se smešta u memory.jsonl fajl, svaki Memory sadrži content, timestamp, importance, tags."

"Faza čitanja, početkom nove konverzacije, na osnovu trenutnog sadržaja konverzacije, pretražuje relevantne Memory. Strategija pretrage uključuje podudaranje ključnih reči, semantičku sličnost, vremensko propadanje."

"Podudaranje ključnih reči je jednostavno podudaranje stringova, pogodno za pretragu jasnih entiteta, na primer korisničko ime, naziv projekta."

"Semantička sličnost koristi vektorsku pretragu, pretvara upit i Memory u vektore, računa sličnost. Ovo je pogodno za pretragu konceptno povezanih sadržaja, na primer 'distribuirana transakcija' i 'distribuirana konzistentnost', iako su ključne reči različite, semantički su povezane."

"Vremensko propadanje daje Memory vremensku težinu, noviji Memory ima viši prioritet. Ali nije to linearno propadanje, nego eksponencijalno, garantuje da najnoviji par Memory-a ima značajno višu težinu od starih."

"Da bi se izbegla eksplozija Memory, ima još nekoliko strategija optimizacije: ocena važnosti, samo zadržava Memory visoke važnosti; redovno čišćenje, podrazumevano zadržava 30 dana; spajanje sličnih Memory, izbegava duplikate; slojevito čuvanje, visoke učestalosti u memoriji, niske učestalosti na disku."

"Ocena važnosti je automatska ocena koju Agent radi pri pisanju Memory, kriterijumi ocene uključuju: novost informacija, stepen uticaja na naredne odluke, eksplicitni naglasak korisnika."

Stari Wang nastavlja:"Ako te zamolim da optimizuješ mehanizam Memory OpenClaw-a, kako bi?"

Kažem:"Ima nekoliko pravaca optimizacije."

"Prvi, uvedi mehanizam zaborava memorije. Ljudski mozg zaboravlja nevažne informacije, Agent bi trebalo da ima sličan mehanizam. Možeš dizajnirati krivu zaborava, informacije niske važnosti se brže zaboravljaju."

"Drugi, podrži povezivanje memorije. Trenutni Memory je nezavisan, ako može podržati povezivanje između Memory-a, na primer 'ovaj projekat koristi Spring Boot' i 'Spring Boot je Java framework' povezati, efekat pretrage će biti bolji."

"Treći, slojevita memorija. Tri sloja: kratkoročna, srednjoročna, dugoročna, svaki sloj ima različitu strategiju čuvanja i pretrage."

11,Šta je CLI

"Nedavno Feishu, Netease Cloud Muzika svi šalju CLI alate, kako vidiš ovaj talas?" Stari Wang smešuje se pitajući,"AI krug svaki dan izbacuje nove stvari, neke su talasi, neke su mehuri. Ovaj talas CLI, misliš koji je?"

Može se osetiti, da Stari Wang ima zaista visoku osetljivost na tehnologiju AI doba.

Feishu zaista najveći dobitnik posle velike popularnosti OpenClaw-a, ne samo da je prvi vreme smanjio teškoću konfiguracije Feishu-a, još je prvi vreme napravio CLI za Agent, postao je IM alat koji najčešće koristim za komunikaciju sa AI.

Kažem:"Wang ge, ovo nije mehur, nego nadogradnja infrastrukture doba AI Agent-a."

Stari Wang mu se oči upale:"Oh? Pričaj."

01,Šta uopšte je CLI?

"Wang ge, prvo te pitam jedno pitanje, šta misliš da AI najviše voli da radi?"

Stari Wang razmišlja:"Tekst?"

"Tako, AI je tekst unutra, tekst vanza. Nema oči, ne može voditi grafiku interfejsa."

Razlika između CLI i GUI je ovde. GUI je za oči, otvori app, vidiš dugmiće menije, mišem klikuješ. CLI je čist tekst, otvoriš jedan crni prozor, napišeš jedan red, pritisneš Enter, stvar je gotova.

Metafora, GUI je ideš u restoran da gledaš meni, kažeš konobaru "želim ovu". CLI je direktno vrištiš u kuhinju "uljene rezanci, malo ulja, malo ljuto". Rezultat isti, ali CLI je precizniji, lakše se automatizuje.

"Dakle CLI i AI su posebno kompatibilni?" Stari Wang nastavlja.

"Tako, AI originalno živi u svetu komandne linije."

AI želi ti pomoći da komprimuješ video, ne treba otvarati Premier tražiti dugme za eksport, trči jedan red ffmpeg -i input.mp4 -crf 28 output.mp4 i gotovo. Ljudi nisu ponovo počeli da vole komandnu liniju, AI originalno živi u komandnoj liniji.

Stari Wang klima glavom:"Zapad nije ranije CLI bio ovako popularan, zašto baš sada?"

02,Gde su granice sposobnosti AI-a?

Kažem:"Wang ge, ovo treba da kažem o granicama sposobnosti AI-a."

Mnogi ljudi zamisle AI kao sveznajući mozak. Ali tačnija metafora je: jedan veoma pametan novi zaposleni, sve može da uči, uči brzo, ali treba mu dve stvari — alat i uputstvo.

Instalirao ffmpeg, AI može da procesira video. Instalirao Feishu CLI, AI može ti pomoći da proveriš raspored, šalješ poruke. Instalirao Netease Cloud Muzika CLI, AI može da upravlja tvojom omiljenom muzikom.

Nije instalo?"Izvini, ovo ne mogu da uradim."

Stvarna sposobnost AI = alati koje može da pozove + kontekst koji dobija.

Dakle ako osećaš da je AI veoma glup, verovatno je da njegov kontekst nije dovoljno velik, dodeliš mu premalo alata.

Na primer, ako nema Feishu CLI, da velikom modelu pomažeš da generišeš dijagram oblaka reči na osnovu multidimenzionalne tabele, gotovo nije načina da se to ostvari.

"Alat je lako razumeti, šta je kontekst?" Stari Wang nastavlja.

"Kontekst je uputstvo."

Na primer, Feishu CLI je objavljen krajem marta 2026, obuka podataka AI-u nema uopšte, ako mu ne damo uputstvo, AI uopšte ne zna da postoji.

Dakle nove CLI alate sve prate mnogo Skills, juče sam pri instalaciji Feishu CLI instalirao 19 Skills, Skill je u suštini uputstvo napisano u Markdown, kaže AI ovaj alat šta može da radi, kako se koristi.

Stari Wang razmišlja:"Što je noviji alat, AI više zavisi od uputstva?"

"Tako, obuka podataka uvek ne može da dostigne brzinu objavljivanja alata, uputstva će sve više biti važna."

03,Koja je razlika između tradicionalnog CLI-a i sadašnjeg CLI-a?

Stari Wang okrenu temu:"CLI nije postojao pre desetaka godina? Kako osećaš da ono što pričaš izgleda kao nova stvar?"

"Wang ge, stari CLI i sadašnji CLI, iako se oba zovu CLI, već su dve različite stvari."

Tradicionalni CLI, na primer curl, je za programere. Izlaz je obojeni tekst ljudskom oku, susreće biranje će iskočiti interaktivni meni. Ljudima je prirodno, ali AI susreće ovakav iskačučki prozor direktno stane.

curl -si https://paicoding.com

Nova generacija CLI od samog dizajna pretpostavlja da je pozivatelj AI Agent: sve operacije se unose jednom kroz parametre, ne iskačuje meni; izlaz je u JSON formatu, AI direktno analizira; nosi Skills uputstvo; podržava --dry-run pregled, pre izvršenja AI prvo vidi šta će se desiti; AI još može da pitaje alat "koje komande ima? Šta parametre treba?" Ne treba čitati celu dokumentaciju.

"Jedan primer?" Stari Wang kaže.

"Feishu CLI. Posle instalacije više od 200 komandi, pokriva kalendar, poruke, dokumente, zadatke, poštu i druge 11 oblasti. Na primer pregled današnjeg rasporeda:"

lark-cli calendar +agenda

"Upit multidimenzionalne tabele:"

lark-cli base +query --table appXXX --fields "Ime,Škola,Smer"

"Kreiranje oblak dokumenta i uvoz Markdown:"

lark-cli docs +create --title "Vodič za intervju" --file ./interview.md

"Ove komande, AI može direktno da poziva, ne treba otvarati Feishu app."

Stari Wang klima glavom:"Ovo zaista nije kao tradicionalni CLI. A format izlaza?"

"Podrazumevano je JSON, AI može direktno da analizira. Na primer izlaz pregleda rasporeda:"

{
  "events": [
    {
      "id": "evt_xxx",
      "summary": "Ko je zbunjeni skup",
      "start": "2026-03-30T14:00:00",
      "end": "2026-03-30T15:00:00",
      "attendees": ["Petar", "Nikola"]
    }
  ]
}

"AI dobija ovaj JSON, zna da u 14 časova imaš sastanak, ko učestvuje, može ti direktno pomoći da organizuješ naredni posao."

04,Koja je razlika između CLI i MCP, Skills, Plugin?

Stari Wang nastavlja:"Čuo sam da AI krug uvek raspravlja koji će MCP, Skills, Plugin postati mainstream, ti kako vidiš?"

Kažem:"Pažljivo gledaj šta nova generacija CLI radi, otkrivaće da CLI tri zajedno pakuje."

Prvo objasni tri koncepta. MCP je standardni komunikacioni protokol između AI i eksternih servisa, razumej kao USB interfejs AI sveta. Skills je uputstvo koje kaže AI "kako se ovaj alat koristi". Plugin je instalabilna ekstenzija koja pakuje alat, protokol, uputstvo zajedno, slično aplikaciji na telefonu.

Feishu CLI je tipičan primer: CLI komanda nudi izvršnu sposobnost, ugrađeni MCP servis nudi standardni komunikacioni protokol, nosi Skills fajlove kao uputstvo za korišćenje.

"Jedan CLI alat je jedan faktički Plugin." Kažem.

"Ali ima više prednosti od Plugin-a." Stari Wang nastavlja.

"Wang ge i ti si ovo primetio?"

Plugin Claude Code-a se može koristiti samo u Claude Code-u.

Feishu CLI posle instalacije, Claude Code, Codex, Qoder svi mogu da koriste.

I CLI ne brine koji model poziva, on je sloj izvršenja nezavistan od modela.

CLI ima još jednu veliku prednost, to je cevovod. Jedan scenario: imam inteligentni sistem korisničke službe, svaki dan treba da generiše dnevni izveštaj o poslovanju. Tradicionalni način: operateri izvoze podatke, ređaju Excel, pišu tekst analize, šalju email.

Kombinacijom CLI?

# Prvi korak: izvući podatke o razgovoru iz sistema korisničke službe
cs-cli conversations export \
  --date yesterday \
  --format ndjson

# Drugi korak: cevovodom prosledi alatu za analizu, ekstrahuji ključne pokazatelje
| jq -c '{total: .total, resolved: .resolved, avg_response_time: .avg_time}'

# Treći korak: cevovodom prosledi AI da generiše izveštaj
| ai-cli generate \
  --prompt "Na osnovu ovih podataka generiši dnevni izveštaj o poslovanju, uključuje distribuciju problema, efikasnost obrade, predloge za unapređenje" \
  --output markdown

# Četvrti korak: cevovodom prosledi Feishu, automatski pošalji u grupni tim
| lark-cli message send \
  --chat-id oc_xxx \
  --msg-type post

Jedan cevovod, četiri alata, od povlačenja podataka do slanja izveštaja, sve automatski. Ljudi samo ujutru pogledaju grupnu poruku.

Stari Wang duboko: "Svi se svađaju koji će MCP, Skills, Plugin pobediti, odgovor je moguće CLI sve pakuje, i cross-platform."

05,Misliš da će se u budućnosti svi proizvodi CLI?

Stari Wang iznenada pita:"Imaš li osećaj, većinu vremena ne pišemo kod, nego potvrđujemo isporuku AI-ja?"

"Isto, Wang ge."

"Mislim, ako se u budućnosti svi alati nude pristup CLI, direktno nalažemo i osnažujemo AI Agent-a da radi, nećemo biti zauzeti potvrđivanjem rezultata."

"AI doba, interfejs servisa ne treba biti grafika, nego komandna linija."

Ako proizvod ima samo web verziju, korisnik želi da AI pomogne pri operaciji, mora AI da otvori pretraživač, klikna dugme, ispise formular. Ovaj set, kompleksnost je ekstremno visoka.

Ali ako proizvod ima CLI, AI samo treba da trči jednu komandu i gotovo. Razlika efikasnosti je redova veličine.

"Feishu je ovo postigao. Tako programeri ne moraju sami da se povezuju sa Feishu otvorenom platformom API, instaliraju CLI mogu koristiti."

06,Šta treba da vodiš računa prilikom pravljenja CLI-ja?

Stari Wang nastavlja:"Ako sam razvijač, i želim da napravim CLI za svoj proizvod, na šta treba da obratim pažnju?"

Kažem:"Wang ge, ovo pitanje sam istraživao, ima pet ključnih tačaka."

Prva tačka: ne iskačuj interaktivni meni. Tradicionalni CLI voli da iskače meni kada susreće biranje, korisnik bira gore-dole.

Na primer ? Which environment? ovo. Ljudima je prirodno, ali AI susreće ovakav iskačučki prozor direktno stane.

Pravi način je: sve opcije se unose jednom kroz parametre. Ako mora interaktivno, nudi --no-interactive parametar da AI preskoči.

Druga tačka: izlaz u JSON formatu. AI najviše voli da procesira strukturirane podatke. Pravi način je: podrazumevano izlazi JSON, ili nudi --output json parametar. Tako AI može direktno analizirati, ne treba dodatnu obradu.

[{"text": {"title": "Korišćenje dijagrama oblaka reči na instrument tabli", "description":
  "Jedan. Funkcionalni uvod\nU multidimenzionalnoj tabli instrument table, možeš koristiti dijagram oblaka reči da vizuelno prikažeš tekstualne podatke. Dijagram oblaka reči može
  na osnovu učestalosti reči ili na osnovu rezultata inteligentne analize, visoke učestalosti reči kroz boju i veličinu fonta ističe. Pogodno je za analizu učestalosti reči, korisničkog mišljenja
  statistike i druge scenare koji trebaju da izvuku ključne informacije iz velikih tekstova.\nDva. Proces operacije\nDodaj dijagram oblaka reči
  Uđi u odredišnu multidimenzionalnu tabelu, klik
  na levoj navigacionoj traci instrument", "url": "https://www.feishu.cn/hc/zh-CN/articles/709166668964", "content":
  "Korišćenje dijagrama oblaka reči na instrument tabli", "meta...

Treća tačka: nudi --dry-run pregled. Pre nego AI izvrši komandu, najbolje je prvo vidi šta će se desiti. Posebno brisanje, izmena ove opasne operacije. Pravi način je: nudi --dry-run parametar, AI pre pravog izvršenja pregleda rezultat. Tako se može značajno smanjiti rizik pogrešne operacije.

Četvrta tačka: kontrola veličine izlaza. Koristi field maske da kontrolišeš povratna polja, ili nudi --fields parametar da AI navede koja polja treba vratiti. Na primer upit email-a samo tema i pošiljalac, ne telo.

Peta tačka: dobro napiši Skills uputstvo. Skills fajl treba biti precizan, ne prevelik. Predlažem kontrolisanje na 1.6KB, ovo je jako dobar referentni. Samo piši šta AI treba da zna, ne piši suvišne reči.

Stari Wang nastavlja:"Kako konkretno napisati Skills fajl? Možeš mi pokazati?"

Kažem:"Feishu CLI je open source, možemo direktno pogledati njegov direktorijum Skills."

Feishu CLI u direktorijumu Skills ima 19 fajlova, svaki odgovara jednoj poslovnoj oblasti. Na primer lark-base.md je uputstvo za operacije multidimenzionalne tabele, lark-calendar.md je uputstvo za operacije kalendara. Svaki Skills fajl sadrži: pregled alata, dostupne komande, objašnjenje parametara, primere korišćenja. Format je jasan, AI nakon čitanja zna kako da koristi.

"I Feishu CLI još nudi direktorijum skill-template." Kažem."Ako želiš da napišeš Skills za svoj proizvod, možeš direktno kopirati ovaj šablon, promeniti na svoj sadržaj."

Stari Wang čuje i klima glavom:"Sve pet tačaka su veoma praktične."

07,Kako upravljati CLI?

Stari Wang iznenada postavlja zanimljivo pitanje:"Ako korisnik instalira mnogo CLI alata, kako upravljati?"

"Wang ge, ovo pitanje sam razmišljao. Ima jedan zanimljiv pristup, pustiti AI da upravlja svojim alatima."

Tradicionalni softverski pristup je: napiši kod da detektuje šta je korisnički sistem instalirao, napiši UI da korisnik na interfejsu upravlja alatima, napiši logiku da proverava ažuriranja. Standardan način, ali volumen rada je ogroman, i svaki alat ima različitu situaciju, kodom unaprijed određivanje logike instalacije se ne može završiti.

Ali AI doba ima jedan bolji pristup: pošto proizvod već ima AI, zašto ga zaobilazi?

Instaliranje alata, direktno pokreni dijalog neka AI radi. AI čita --help, ocenjuje operativni sistem, rešava greške dozvole, upućuje autentifikaciju konfiguracije. Instalacija nije uspela, može čitati poruku o grešci sam da oceni, treba li sudo? Prvo instalirati zavisnost? Zameniti izvor?

Registracija alata je isto, daj AI jedan šablon upita, posle čitanja --help automatski generiše strukturirani opis, šta alat može da radi, kako se koristi, tipični scenariji.

"Ovaj pristup je zanimljiv." Stari Wang mu se oči upale,"Jednako rečeno, AI je i korisnik alata, i menadžer alata."

"Tako, ovo je ideja dizajna proizvoda AI doba, nemoj koristiti softver da pomažeš korisniku da upravlja AI alatima, pusti AI da upravlja svojim alatima."

Stari Wang nastavlja:"A ažuriranje? Kako se rešava ažuriranje alata?"

"Ažuriranje je jednostavnije. AI redovno proverava verziju alata, otkrije novu verziju podseća korisnika da li ažurira. U procesu ažuriranja susreće probleme, AI sam čita dnevnik grešaka ocenjuje kako rešiti. Ceo proces korisnik samo pritisne jednom potvrdu, ostalo AI sve pokrije."

08,Budućnost CLI-ja

Stari Wang pita:"Kako misliš da će se CLI razvijati u budućnosti?"

Kažem:"Par trendova je sigurno."

Trend jedan: CLI će postati standardna oprema proizvoda. U budućnosti svaki SaaS proizvod, pored web verzije, app verzije, još će imati CLI verziju. Nije opcioni dodatna funkcija, nego standardna oprema.

Zato što je CLI najbolji interfejs koji AI poziva tvoj proizvod, nema CLI znači odustaješ od AI korisničke grupe. Feishu je otvorio glavu, sledeće će još proizvoda da slede.

Trend drugi: pojaviće se AI App Store alata. U budućnosti sigurno će se pojaviti platforma koja indeksira AI alate, možda će napraviti npm, GitHub, možda će napraviti nova startap kompanija.

Ko može ovo da napravi, ko je AI doba npm. Ova prilika je velika, sada je prazno.

Stari Wang čuje duboko:"Ova dva trenda, svaki je prilika. A misliš da običan razvijači šta mogu da rade?"

"Dve stvari. Prva, nauči dobro da koristiš postojeće CLI alate, poboljšaj svoju produktivnost. Druga, ako ima priliku, napravi CLI za svoj proizvod, ovo je najdirektniji način da uđeš u AI ekosistem."

09,Zaključno, zašto svi rade CLI?

Stari Wang postavlja poslednje pitanje:"Zaključno, zašto preko noći svi rade CLI?"

Kažem:"Wang ge, svi su svesni da CLI je moževa najefikasniji način distribucije AI sposobnosti."

Jedan CLI alat istovremeno sadrži izvršnu sposobnost, komunikacioni protokol i uputstvo za korišćenje, jedan je kompletan AI plugin. Cross-platform, bez recenzije, i ljudi i AI mogu koristiti. Svaki više instaliran dobar CLI alat, tvoj AI dobija jednu više sposobnost. Svaki manji suvišni šum konteksta, tvoj AI je malo pametniji.

"Konkretno pričaj?" Stari Wang nastavlja.

"Wang ge, vidi šta sam radio posle objave Feishu CLI."

Koristio sam Feishu CLI da mi AI pomogne analizirao više od 600 podataka CV-a, generisao dijagram oblaka reči, i 18 članaka serije "Pobeđivanje na intervjuu" sve otpremio na Feishu oblak dokument. Celi proces sam nije napisao jednu liniju koda, nisam otvorio Feishu web, sve je AI kroz CLI automatski završio.

https://my.feishu.cn/wiki/CScqwBVyliWpRYkJEAWc9ouxnZf?from=from_copylink

Bez CLI? Moram prvo na Feishu otvorenu platformu napraviti aplikaciju, konfigurišem dozvole, napišem kod da pozivam API, rešavam stranicenje, rešavam otpremu slike, rešavam konverziju formata. Celi set, jedan dan je prošao.

Sa CLI? Jednom instaliraš, skeniraš, AI može direktno da radi. Razlika efikasnosti je redova veličine.

"I CLI ima jednu prednost, jednom instaliraš, svuda možeš koristiti." Kažem."Sam kod Qoder instalirao Feishu CLI, prebacim se na Codex, Claude Code sve mogu koristiti, ne treba ponavljati konfiguraciju. Ovo Plugin ne može."

Stari Wang klima glavom:"Ovo zaista rešava cross-platform problem."

Baš smo u haotnom dobu zamene starog i novog. Stari formati, stare barijere podataka, stari menadžeri paketa, i novi AI nativni alati upleteni zajedno.

Stari Wang dve sekunde tiho, onda kaže:"Kad možeš da dođeš na posao?"

10,Kako napisati CLI u CV?

Naziv projekta: Projekat integracije AI Agent CLI alata

Kratak opis projekta: Na osnovu Feishu CLI i drugih AI nativnih komandnih alata, realizovana je automatizacija analize poslovnih podataka i upravljanja dokumentacijom, efikasnost obrade podataka se poboljšala više od 10 puta.

Ključne odgovornosti:

Integracija Feishu CLI i drugih AI nativnih alata, realizovana automatska kolekcija i analiza poslovnih podataka, pokriva 11 velikih oblasti 200+ komandi, dnevno obrađuje 500+ podataka
Korišćenje AI Agent + CLI cevovod kombinacije, završena batch konverzija i otprema dokumenata, 18 članaka desetak hiljada reči jednim klikom sinhronizovano na Feishu oblak prostor
Pisanje prilagođenih Skills fajlova, vođenje AI da tačno poziva alate, tačnost preko 95%, smanjenje pogrešnih operacija izazvanih AI halucinacijama
Dizajn i implementacija rešenja upravljanja CLI alatima, podrška ponovne upotrebe preko Agent platformi, vreme konfiguracije alata sa 30 minuta skraćeno na 2 minuta

Karpathy ima pravo: svaki proizvod treba da ima jedan CLI alat. Ne daj programerima da pristupaju, pregledaju ili klikću. Direktno nalaži i osnažuj njihov AI.

[CLI nije retro, već infrastruktura reinventovana u AI dobu.]

Ovaj talas CLI tek je počeo, prilika je ogromna.

Vidimo se sledeći put!

## 01,Zašto treba Harness Engineering

Prvo kažem jedan bolnu pojavu.

Mnogi timovi nakon Agent-a, otkriju jednu nelogičnu činjenicu: sposobnost modela je dovoljna, ali zadatak jednostavno ne radi dobro.

Nekaš da napišeš jednu jednostavnu funkcionalnost, on ti napravi raskošan dizajn paterna; nekaš popraviš bug, popravio jedno mesto zaboravio još tri povezana mesta; nekaš da radiš jedan dug zadatak, trči trči i ne zna šta radi.

Gde je problem?

Nije što model nije dovoljno pametan, već je model suviše "slobodan". Niko mu ne kaže gde su granice, kada treba stati, kako se oporaviti od greške. Kao da zapošljavaš jednog veoma sposobnog zaposlenog, ali mu nije davao tok posla, nema mehanizam provere, nema povratne sprege, konačan efekat sigurno je haos.

Prompt Engineering rešava "kako model razume tvoje reči", Harness Engineering rešava "kako model završi posao".

Ključna razlika između ove dve je u:

Prompt Engineering se fokusira na ulaz, kako pitaš, model kako odgovara. Sva optimizacija se vrti oko "model jednom tačno odgovori".

Harness Engineering se fokusira na celokupno okruženje izvršenja. Šta ako model pogrešno odgovori? Kontekst je poremećen kako se oporavi? Kako se schedule-iraju podzadaci? Ovo sve treba jedan set infrastrukture da pokrije.

Metafora: Prompt Engineering je podučavanje zaposlenog kako da razume tvoje instrukcije, Harness Engineering je davanje zaposlenom kompletne radne stanice — alati imaju, proces ima, lista provere ima, upozorenje greške ima.

Zato silikonska dolina počinje da voli jednu reč: 2025 je godina Agent-a, 2026 je godina Agent Harness.

02,Šta je Harness Engineering

Osnovna formula Harness Engineering je vrlo jednostavna:

Agent = Model + Harness

Model je veliki model sam, odgovoran za razumevanje i generisanje. Harness je sistem kontrole izvršenja koji se nalazi oko modela, odgovoran za schedule-iranje, ograničenje, oporavak i reviziju.

Kompletan Harness sadrži šest ključnih komponenti:

Prva, standardizovani sloj integracije alata

Agent treba da poziva različite eksterne alate — pisanje fajlova, pozivanje API-ja, operacije bazom podataka.

Ali svaki alat ima različit način poziva, različitu obradu grešaka. Harness approach je da doda jedan sloj "hook" pre svih poziva alata, radi validaciju parametara, proveru dozvole, izuzetak eksternog hvata.

Tako kada neki alat ne uspe, Harness može automatski degradirati ili ponoviti, umesto da ceo zadatak paše.

Druga, sistem inženjeringa konteksta

Tradicionalni pristup je da sve istorije dijaloga stavi u context window, ali ovaj način u dužim zadacima će sve više biti u neredu.

Harness approach je korišćenje "strukturisanog stanja" umesto istorije razgovora — zadatak rasčlani na jasne faze, svaka faza ima jasane ulazne izlaze, model treba samo vidi trenutno stanje, ne briga za prethodne suvišne reči.

Treća, motor schedule-iranja stanja i zadataka

Šta ako Agent u toku prekine?

Harness nudi mehanizam checkpoint-a nastavljanja. Zadatak se izvršio do kojeg koraka, trenutno stanje šta je, šta sledeće treba raditi, sve persistentno čuvano.

Uvek se može oporaviti, takođe podržava paralelno schedule-iranje više podzadataka.

Četvrta, sistem orkestracije i izolacije podagent-a

Kompleksan zadatak može se raspodeliti na više pod Agent-a paralelno da izvršavaju, svaki Agent ima nezavisan kontekst, ne mešaju se. Glavni Agent samo prima i sumira rezultate.

Peta, sloj validacije i bezbednosne zaštite

Pre model generiše sadržaj, pre pozove alat, pre izlaznog rezultata, svaka se rupa može dodati proveru. Ono što ne odgovara standardu direktno se sprečava, izbegava "model pođe lud, posledice su ozbiljne".

Šesta, sistem observability i revizije

Svaki korak Agent izvršenja ima dnevnik, ima tracking, ima upozorenje. Pojava problema može brzo locirati koreni uzrok, takođe pogodno za reviziju usklađenosti.

Ovih šest komponenti zajedno rešavaju jedan ključni problem: nedeterministički model, u determinističkom okviru stabilno radi.

03,Praksa Harness u Claude Code-u

Reći toliko koncepata, pogledajmo stvarne.

Claude Code je tipična implementacija Harness. Njegov dizajn koncept je: ne samo da ti daje model, nego ti daje kompletno okruženje izvršenja.

Kada dam Claude Code jedan kompleksan zadatak, on neće direktno početi da piše kod. On će prvo:

Prvi korak, istraži repozitorijum koda. Razjasni strukturu projekta, relacije zavisnosti, postojeći način implementacije. Ovaj korak ekvivalent fazi "čitanja koda" pre inženjera pri preuzimanju zahteva.

Drugi korak, napravi plan izvršenja. Veliki zadatak raspada na male korake, naznači svaki korak šta radi, koje fajlove menja, moguće relacije zavisnosti. Ovaj korak ekvivalent pisanju tehničkog plana.

Treći korak, korak po korak izvrši i proveri. Svaki završeni korak će se verifikovati, otkrije problem pa prilagodi. Ovaj korak ekvivalent recenziji koda i samotestiranju.

Četvrti korak, globalna provera. Svaki korak je završen, pregleda ima li mesta koja su propuštena, potencijalne granične probleme. Ovaj korak ekvivalent regresionom testu pre lansiranja.

Ova četiri koraka nisu napisana u prompt, nego su ugrađeni okvir izvršenja Harness Claude Code-a. Model samo treba da sledi ovaj okvir, neće pojaviti ova niska greška "izmenio jedno mesto zaboravio tri povezana".

Još jedan detalj me impresionira.

U procesu izvršenja, ako susretne operaciju koja treba potvrda korisnika (na primer brisanje fajla, izmena osetljive konfiguracije), Claude Code će pauzirati da ti potvrdiš.

Ovo nije "svesnost" modela, nego "hook" u Harness-u je spreo visoko rizične operacije, traži ljudsku odobrenje.

Ovo je vrednost Harness: pretvara "poverenje model" u "poverenje okvir". Model može napastiti grešku, ali okvir može pokriti.

04,Testiranje Harness dizajna sa PaiAgent-om

Radio sam jedan mali eksperiment sa PaiAgent projektom, vidim koliko Harness u stvarnom razvoju zaista može da pomogne.

https://github.com/itwanger/PaiAgent

PaiAgent je platforma za orkestraciju AI tokova posla, ključna funkcija je da programeri pomoću prevlačenja čvorova orchestriraju AI zadatke.

Ranije sam imao jedan tipičan problem: tok posla do pola, ako neki čvor nije uspeo, ceo zadatak je pao, nema nikakvog mehanizma oporavka.

Pokušao sam da rešim ovaj problem kroz Harness approach.

Prvi korak, dizajn state machine

Izvršno stanje svakog čvora tokova posla apstrahuje se u pet faza: Pending (čekanje izvršenja), Running (u izvršenju), Completed (završeno), Failed (neuspešno), Retrying (u ponavljanju).

Svaki čvor u svakom trenutku je u jednom od ovih pet stanja, promena stanja je jednostrana, neće nastati nered.

Drugi korak, dodaj mehanizam Checkpoint

Svaki čvor posle izvršenja, automatski čuva trenutno stanje u Redis. Ako se servis restartuje ili čvor se sruši, može se oporaviti od poslednjeg Checkpoint-a, umesto početka ispočetka.

Treći korak, dizajn strategiju ponavljanja

Nisu sve greške vredne ponavljanja. Timeout mreže, API limitiranje može ponoviti, ali greška parametra, nedovoljno dozvole nema potrebe da se ponavlja.

Četvrti korak, dodaj tačku ljudske intervencije

Ako isti čvor posle tri puta ponavljanja još uvek ne uspe, automatski pauzira tok posla, obaveštava ljudsku intervenciju. Tako se neće beskonačno cirkulisati otpadati resurse, niti će greška tiho proći.

Ovo je manifestacija vrednosti Harness. Nije da model ne radi greške, nego da proces oporavka posle greške postaje kontrolabilan, predvidiv.

05,Open source Harness rešenje Bajta

Domaci veliki tehnološki giganti takođe raspolažu Harness. Open source DeerFlow 2.0 od Bajta je tipična implementacija Agent Harness.

https://github.com/bytedance/deer-flow

Njegove ključne osobine ima tri:

Prva, podagent i sandbox izolacija.

Svaki Agent u nezavisnom sandbox okruženju radi, ima sopstveni fajl sistem, mrežnu izolaciju, ograničenje resursa.

Jedan Agent ošteći ne utiče na ostale, neće zagađivati glavno okruženje.

Druga, strukturirano stanje zadatka.

Više neće sve dijaloge gurati u context, nego stanje zadatka apstrahuje se u jasnu strukturu podataka — trenutna faza, završeni koraci, obaveze, relacije zavisnosti.

Model samo čita strukturirane podatke, ne briga za dugu istoriju razgovora.

Treća, alati se mogu povezati.

Poziv alata je enkapsuliran u standardni interfejs, podržava hot-plug. Dodavanje novog alata ne treba menjati framework kod, samo treba implementirati interfejs po specifikaciji.

Vrednost ovog set rešenja je, ono što "piši Agent" upgrade iz "poziv modela" na "konfigurisanje Harness". Ne treba briga kako se schedule-ira model, kako se oporavlja, kako se izoluje, Harness ti sve rešava.

Prema GitHub podacima, DeerFlow 2.0 manje od mesec dana od lansiranja je dobio 54.7K Star, pokazuje da ovaj pravac zaista jest kritična potreba.

05,Od pisanja koda do dizajniranja okruženja

Jedna važna promena koju Harness Engineering donosi je promena uloge inženjera.

Prošli smo pisali kod, direktno smo govorili računaru šta korak po korak treba raditi. Sada radimo Agent, dizajniramo jedan set okruženja, neka model u ovom okruženju sam dovrši zadatak.

Konkretno, fokus rada inženjera se menja sa:

pisanje konkretnog poslovnog logičkog koda
rešavanje raznih graničnih situacija i izuzetaka
ručno debugiranje i popravka problema

postaje:

dizajniranje okvira izvršenja Agent-a i ograničenja uslova
konfigurisanje interfejsa poziva alata i granica dozvole
definisanje promene stanja i mehanizma oporavka
postavljanje sistema observability i revizije

Unutar OpenAI već ima timovi koji su napisali milion linija koda Agent-om, uloga ljudskih inženjera iz "onaj koji piše kod" postaje "onaj koji dizajnira sistem".

Način Anthropic-a je takođe zanimljiv. Oni rešavaju problem pristranosti sopstvene procenjivanja kroz "razdvajanje uloga" — jedan Agent odgovoran za pisanje koda, drugi Agent odgovoran za recenziju, nezavisno rade, izbegavaju "svojim ocenjivanjem" slepu tačku.

Ovo su sve ideje prakse Harness Engineering-a: ne jedan model radi sve, nego dizajniraš jedan set sistema, više uloga sarađuje, međusobno se verifikuje, konačno daje pouzdan rezultat.

06,Kako primeniti Harness Engineering

Ako želiš da u timu primeniš Harness Engineering, možeš početi sa tri nivoa.

Sloj alata: dodaj hook svom Agent-u.

Dodaj interceptor pre i posle poziva alata, radi validaciju parametara, proveru dozvole, bilježenje dnevnika. Ovo je najlakša implementacija Harness, trošak adaptacije je mali, ali može rešiti većinu problema "jedan pogrešan korak, sve se raspada".

Sloj framework-a: uvedi gotovi Harness framework.

LangChain DeepAgents, Claude Code izvršni framework, DeerFlow sistem podagent-a, sve se može ponovo koristiti.

Ne treba izmišljati točak, stojeći na ramenima divova je brže.

Sloj platforme: postavi Agent runtime platformu.

Ako tvoj tim ima mnogo Agent potreba, možeš razmisliti o postavljanju objedinjenog Agent runtime platforme — centralno upravljanje Agent konfiguracijom, schedule-iranjem, monitoring, revizijom. Ovo je najteži način, ali dobit je najveći.

Sa stanja gledišta, predlažem da počneš od sloja alata, prvo reši najboleće tačke, onda postepeno evoluiraj ka sloju framework-a, sloju platforme.

Jedan stvarni primer implementacije.

Moj tim ima potrebu: svaki dan automatski sa više izvora podataka vuči podatke, generiše jedan dnevni izveštaj o poslovanju. Ranije sam koristio jednostavnu skriptu, često je zato što jedan izvor podataka timeout doveo do celog neuspelog zadatka, i još ne znamo kada nije uspeo, sutra smo otkrili da juče nije generisan izveštaj.

Posle remodelovanja kroz Harness approach:

Modifikacija sloja alata: svakom izvlačenju izvora podataka dodao sam kontrolu timeout-a i hvatanje izuzetka. Ako neki izvor padne, snimi grešku ali ne utiče na ostale izvore, konačni generisani izveštaj će označiti koji podaci nedostaju.

Modifikacija sloja framework-a: uveo jedan laki framework schedule-iranja zadataka, podržava ponovljeni pokušaj neuspeha i obaveštenje. Ako generisanje izveštaja ne uspe, automatski šalje poruku DINGnotify radnika na dužnosti.

Planiranje sloja platforme: naredno planiram da sve slične redovne zadatke povežem na objedinjenu platformu schedule-iranja, centralno upravljanje, objedinjeni monitoring.

Ovo je vrednost implementacije Harness Engineering: ne goni jedan korak do mesta, nego prema problemima poslovanja, fazno, ritmčki gradi.