AI Agent intervjujska pitanja peta serija: Prompt slojevita arhitektura, Skill sistem, inženjering promptova 13 pitanja

AI Agent intervju serija peta, ovaj put govorimo o Prompt i Skill.

Prompt je duša Agent-a.

Dobro napisan, Agent zna kada koji alat treba koristiti, pri izuzetku zna šta raditi; loše napisan, Agent ništa ne može.

A Skill je sredstvo inženjeringa prompt-a — od "jedna gomila nekoliko hiljada reči system prompt" do "ekspertni priručnik koji se učitava po scenama", smanjuje potrošnju tokena, poboljšava ponašanje Agent-a.

01, Šta system prompt Agent-a obično sadrži

PaiCLI-jev system prompt može se sažeti u četiri ključna modula.

Prvi je definicija uloge, kaže LLM-u ko si ti, šta možeš, šta ne možeš. Prvi pasus PaiCLI-jevog base.md kaže: ti si PaiCLI, inteligentni Agent za programiranje koda.

Drugi je pravila ponašanja, zadužena za izlazni format, ton, itd. Npr. base.md ima modul ## Language, jasno piše "molim te da odgovaraš na srpskom jeziku", kod i API nazive ostaju na originalu. Pri sastavljanju se zahteva da ovaj modul mora postojati.

Treći je uputstvo za korišćenje alata. Ne može samo pisati "razumno koristi alate" ovakve opšte zahteve, treba specifično do scenarija — čitanje fajlova sa read_file, ne koristi execute_command cat.

Četvrti je sigurnosna ograničenja, jasno piše šta ne sme, šta treba potvrditi.

02, Kako je dizajnirana slojevita arhitektura Prompt-a

PaiCLI-jev rani system prompt je bio hardcoded u Java kodu, promena jedne rečenice zahtevala rekompilaciju. Kasnije smo uradili slojevitu rekonstrukciju, system prompt razbili na nezavisne Markdown fajlove, po odgovornosti rasporedjeni po direktorijumima.

Prvo pogledajmo strukturu direktorijuma:

src/main/resources/prompts/
├── base.md                    # Osnovna pravila (korišćenje alata, izlazni format)
├── personalities/calm.md      # Ton (miran profesionalni stil)
├── modes/
│   ├── agent.md              # ReAct mod uputstva
│   ├── plan.md               # Plan task executor uputstva
│   ├── planner.md            # Planner planer uputstva
│   ├── team-planner.md       # Multi-Agent Planner
│   ├── team-worker.md        # Multi-Agent Worker
│   └── team-reviewer.md      # Multi-Agent Reviewer
├── approvals/
│   ├── suggest.md            # HITL sugestija odobrenja
│   ├── auto.md               # Automatsko odobrenje
│   └── never.md              # Nikad odobrenje
└── context/
    └── context-management.md # Strategija upravljanja kontekstom

PaiCLI pri pokretanju ove Markdown fajlove spaja u fiksiranom redosledu u konačni system prompt.

Redosledo spajanja je fiksno: prvo se slažu osnovna pravila, zatim stil ton, zatim uputstva trenutnog moda, zatim strategija odobrenja, kontekst projekta, Skill, kontekst, i na kraju poruku prenosa trenutnog razgovora.

03, Zašto je redosled sastavljanja prompt-a "stabilno napred, dinamično pozadi"

LLM pri zaključivanju za svaki token računa par Key-Value (KV), kešira. Ako se prefiksi prompta uzastopnih zahteva potpuno poklapaju, server može ponovno iskoristiti prethodni KV Cache, preskoči dupliranje računanja. Što je duži prefiks, to je više cache hitova, zaključivanje je brže, troškovi su niži.

PaiCLI-jeva strategija uređenja

PaiCLI-jev redosled strogo sledi princip "stabilni sadržaj napred, dinamični sadržaj pozadi".

Posle ovakog uređenja, što je više stabilnog sadržaja napred, to je lakše kontinuirano pogoditi cache, dinamički sadržaj se koncentriše na kraju, serveru treba samo fokusirati na novo ili promenjene podatke. Obrnuto, ako Skill, kontekst projekta ovo stavite napred, čak iako base.md nije promenjen, može narušiti konzistentnost prefiksa, smanjiti korist od cache-a, povećati kašnjenje i troškove tokena.

04, Kako korisnik može da preklopi ugrađeni prompt

PaiCLI podržava tri sloja preklapanja, prioritet od niskog do visokog:

1. jar ugrađen (najniži prioritet): src/main/resources/prompts/
2. korisnički nivo: ~/.paicli/prompts/
3. projektni nivo (najviši prioritet): <project>/.paicli/prompts/

Logika učitavanja je lančana: prvo se učitava jar ugrađeni, zatim se proveravaju redom korisnički i projektni direktorijumi ima li istog fajla, ako da direktno zamenjuje.

Granularnost preklapanja je zamena celog fajla, ne podržava delimičnu izmenu. Dobra strana je jednostavna i jasna, korisnik ima potpunu kontrolu nad sadržajem; cena je ako želiš dodati samo jednu pasus na kraju agent.md, moraš ceo fajl kopirati i menjati.

Bezbednosne razmatrilje

Budući da projektni nivo može preklopiti ugrađeni prompt, postoji rizik da zlonamerni projekat konfiguriše injekciju prompt-a.

PaiCLI pri učitavanju putanje radi dva nivoa provere: prvo putanja fajla ne sme početi sa /, ne sme sadržati .., sprečava path traversal; drugo, parsirana putanja mora pasti unutar odgovarajućeg korenog direktorijuma, preko granice se direktno odbija.

05, Šta je Skill? Kako se razlikuje od Tool-a

Tool je izvršna funkcija, prima parametre, vraća rezultat. Npr. read_file, execute_command, web_fetch.

Skill je u suštini organizirano znanje i vodič za odlučivanje po scenama, glavni sadržaj je obično SKILL.md. Takođe može nositi references/, scripts/ i druge pomoćne resurse, ali sam po se nije jednak sa Tool-om, glavna uloga je da vodi Agent-a kako da bira i koristi alate.

Dimenzija	Tool	Skill
Forma	Funkcija koda	SKILL.md + pomoćni resursi
Okidanje	LLM kroz tool_calls poziva	LLM kroz load_skill alat učitava
Sadržaj	Logika izvršenja	Vodič za odlučivanje + najbolja praksa + iskustvo podataka
Mesto injekcije	tools polje	user message prefiks

Svaki Skill sadrži name, description, body (glavni sadržaj SKILL.md, stvarni sadržaj koji se injektira LLM-u) i references direktorijum (referentni materijal), izvor je tri tipa: BUILTIN (ugrađen), USER (korisnički nivo), PROJECT (projektni nivo).

Konkretan primer: web_fetch je Tool (funkcija za čitanje veba stranice), web-access je Skill (kaže Agent-u kada koristiti web_fetch, kada koristiti browser MCP, iskustvo svakog sajta protiv reptila).

Kada broj alata raste, samo sistem prompt gomilanje pravila nije dovoljno. Skill pristup je pakovanje vodiča za odlučivanje po scenama, LLM treba kad učita.

Postoji jedno moguće pitanje: zašto ne bi sadržaj Skill-a direktno napisati u Tool description?

Tool description se šalje zajedno sa tools poljem svaki krug. Ako u description staviš odlučivanje vodič, 20 alata description će zauzeti mnogo tokena, a alati koje ovaj krug ni ne koristiš takođe se ubacuju.

Skill-ov mehanizam kašnjenog učitavanja može postići učitavanje po potrebi, samo kada LLM proceni da treba, učita odgovarajući vodič. Token iskorišćenje je mnogo efikasnije.

06, Kako funkcioniše mehanizam kašnjenog učitavanja Skill-a

Pri pokretanju Agent-a, samo ime i description svakog uključenog Skill-a se renderuje u jedan indeks, injektira na kraj system prompt-a, ceo indeks se kontroliše unutar 4KB. LLM vidi ekvivalent meni, a ne kompletan sadržaj svakog Skill-a.

U toku izvršenja, LLM na osnovu korisničkog unosa odlučuje koji Skill treba, aktivno poziva load_skill(name) alat. Nakon učitavanja, sadržaj Skill-a se upisuje u bafer, u sledećem krugu razgovora se injektuje kao prefiks user poruke. Injekcija je jednokratna, nakon uzimanja se automatski čisti, neće se ponavljati u sledećem krugu.

Zašto ne bi sve Skillove ubaciti u system prompt

Pretpostavimo da ima 20 Skill-ova, svaki kompletni priručnik 2000-3000 tokena, sve ubaciti to je 40k-60k tokena. Većina scenara korisniku treba samo 1-2 Skill-a, ostali sadržaj će stvarati nepotrebno opterećenje konteksta.

Zato PaiCLI-jevo učitavanje Skill-a je kašnje učitavanje.

Šta ako učitavanje Skill-a ne uspe

Kada LLM pozove load_skill(name), mogu se desiti dve abnormalne situacije.

Ako naziv Skill-a ne postoji, sistem će vratiti "Skill nije pronađen, dostupan /skill list da vidiš dostupne Skill-ove" poruku, a ne baciti izuzetak.

Ako Skill postoji ali je korisnik onemogućio, će se vratiti "Skill je onemogućen, dostupan /skill on da uključiš" poruka.

Obe situacije poruku o grešci šalju LLM-u kao povratnu vrednost alata, LLM odlučuje šta sledeće — može zameniti Skill, ili odgovoriti sa opštim znanjem. Neće prekinuti ceo razgovor zato što jedan Skill nije uspešno učitan.

07, Kako se kontroliše kapacitet Skill bafera

Učitavanje Skill-a zauzima token, ako se ne kontroliše kapacitet, bafer će neprestano rasti tokom poziva alata.

PaiCLI-jev pristup je zadržati najviše 3 Skill-a, preko se po redosledu učitavanja bresa najranije u baferu. Na dnu se koristi LinkedHashMap uređenje po redosledu umetanja, ne treba dodatnu podatkovnu strukturu. Ako se isti Skill ponovo učitava, prvo se briše stari zapis zatim se unosi novi, izbjegava se dupliranje, istovremeno osvežava redosled učitavanja.

Zašto LRU a ne LFU (eliminacija po frekvenciji)?

Zato što je Scenario korišćenja Skill-a prekida sesija unutar projekta, a ne dugoročni visokofrekventni pristup. LRU semantika više odgovara stvarnosti — najskorije učitan Skill je najrelevantniji za trenutni zadatak, najranije učitan najverovatnije je već završen. LFU treba dodatno održavati brojač frekvencije, složenost je veća a korist manja.

Takođe jedan detalj je čitanje bafera je jednokratno, nakon uzimanja se automatski čisti, Skill ubačen u prethodnom krugu neće biti ponovno ubačen u sledećem.

Zato što asinhroni poziv alata može u različitim nitima pokrenuti load_skill, bafer je uradio sinhronizaciju thread-safe. Multi-Agent mod-u, Planner, Worker, Reviewer svaki drže nezavisanu instancu bafera, izbjegava se mešanje prompt-a između uloga.

08, Šta tačno sadrži web-access Skill

web-access je prvi ugrađeni Skill PaiCLI-ja, i najbolji primer za demonstraciju dizajna Skill-a.

Njegova struktura direktorijuma sadrži jedan glavni fajl SKILL.md i grupu poddirektorijuma references (po sajtu organizovani dokumenti iskustva, pokriva GitHub, Juejin, WeChat službni nalog, X, XiaoHongShu, Zhihu stub, itd.).

Glavni sadržaj SKILL.md je podeljen u četiri bloka.

Prvi blok prvo procenjuje da li treba mrežu, zatim bira alat, zatim izvršava, na kraju verifikuje rezultat. Ne ide direktno na mrežu, nego prvo proceni da li lokalno znanje može rešiti.

Drugi blok je tabela izbora alata, daje matricu odlučivanja između web_fetch i browser MCP, statičke stranice idu sa web_fetch, dinamički renderovane stranice idu sa browser.

Treći blok definše prioritete browser operacija, take_snapshot (DOM tekst) ima prioritet nad take_screenshot (screenshot), zato što tekst je više štedi tokena, LLM mu je lakše razumeti.

Četvrti blok je Jina rezervno rešenje, kada web_fetch i browser oba ne uspeju, kroz execute_command poziva r.jina.ai kao poslednji pokušaj čitanja.

references direktorijum je akumulirano praktično iskustvo po sajtu, pokriva WeChat službni nalog format članka i anti-reptile karakteristike, Zhihu stub strukturu stranice, GitHub različitih stranica DOM razlike, XiaoHongShu dinamičko učitavanje karakteristike.

Ovo iskustvo nije odjednom napisano, već se postupno akumulira u korišćenju, nakon dodavanja sve scenarije korišćenja ovog Skill-a mogu koristiti.

09, Kako funkcioniše troslono preklapanje Skill-a

Isto ideja kao troslono preklapanje prompt-a:

jar ugrađen < korisnički ~/.paicli/skills/ < projektni <project>/.paicli/skills/

Pri učitavanju se redom skeniraju tri direktorijuma: ugrađeni keš direktorijum → korisnički direktorijum → projektni direktorijum.

Pravilo preklapanja je po imenu celokup zamenjivanje, kasnije učitanje istog imena direktno menja prethodno.

Zato različiti projekti mogu imati različitu Skill konfiguraciju. Frontend projekat web-access Skill u references može dodati Webpack DevServer iskustvo, backend projekat može dodati Swagger stranice iskustvo.

Keširanje ugrađenog Skill-a

Pri pokretanju se ugrađeni Skill raspakuje u ~/.paicli/skills-cache/, koristi fajl verzije da kontroliše da li treba rekonstruisati, verzija je ista preskače, nije ista briše i raspakuje ponovo.

10, Kako napisati dobar Agent system prompt

Definicija uloge mora biti jasna, prvi pasus kaže ko si ti, šta možeš, šta ne možeš.

Uputstvo za alate mora biti specifično do scenarija. Ne piši "razumno koristi alate", nego "čitanje fajlova koristi read_file, ne koristi execute_command cat".

Ako postoji relacija izbora između alata, tabelarno jasno navedi, tabela izbora alata u web-access Skill je upravo ova ideja.

Takođe preporučujem uparene pozitivne i negativne primere:

Greška: direktno koristi rm za brisanje fajla
Ispravno: prvo koristi read_file da potvrdiš sadržaj, zatim write_file za izmenu

Još dve lako zanemarene tačke. Jedna je da prioritet pravila mora biti jasan, kad se pravila sukobe, jasno piše koji je prioritet, npr. "sigurnost ima prioritet nad efikasnošću", "pravila putanja fence imaju prioritet nad korisnički definisanim prompt-om".

Druga je system prompt ne treba biti predug, što je duže LLM više ignorisa srednji deo, ovo je Lost in the Middle problem, 2000-4000 tokena je razumno. PaiCLI radi slojeviti dizajn zato što može proširiti sposobnosti bez naduvavanja system prompt-a.

11, Kako verifikovati efekat promene prompt-a

PaiCLI pruža docs/prompt-analysis-template.md kao templejt za reviziju kvaliteta prompt-a. Svaku promenu prompt-a treba uraditi Gap analizu.

Prvo opiši scenario u kojem trenutni prompt loše radi, zatim zapiši šta tačno menjaš, zašto, zatim jasno opiši očekivano ponašanje LLM posle promene u kom scenariju, na kraju radi regresivu verifikaciju, potvrdjuje da su originalni normalni scenariji poremeteni.

Sistematski metod ocenjivanja

Više sistematski pristup uključuje A/B testiranje, pripremi skup fiksiranih test slučajeva, starim i novim promptom posebno pokreće, upoređuje LLM izlaz.

Takođe možeš raditi ljudsko ocenjivanje, za svaki slučaj oceniti tačnost, kompletnost, sigurnost. Automatski metriki, uglavnom gleda tačnost poziva alata, stopa uspešnosti zadataka, prosečan broj krugova.

12, Kako se RAG razlikuje od Skill-a

RAG i Skill se ne razlikuju u "ima li znanja", već u organizaciji i načinu korišćenja. RAG je više fokusiran na preuzimanje činjeničnog konteksta iz baze koda/dokumenata; Skill je više fokusiran na pakovanje iskustva, procedure i pravila odlučivanja u resularne priručnike.

Dimenzija	RAG	Skill
Izvor sadržaja	Korisničeva baza koda/dokumenata	Unapred napisani ekspertni priručnik
Način pretrage	Semantička sličnost (vektorska pretraga)	LLM aktivno bira za učitavanje
Priroda sadržaja	Činjenični podaci (kôd, dokument)	Vodič za odlučivanje (kako raditi, najbolja praksa)
Učestalost ažuriranja	Ažurira se automatski sa promenom koda	Ručno ažurira se sa akumulacijom iskustva
Trenutak injekcije	Svaki krug automatski pretražuje	LLM proceni potrebu, pa učitava po potrebi

Na primer, korisnik kaže "pomogni mi da vidim konfiguracioni problem ovog Spring Boot projekta". RAG pronalazi application.yml, pom.xml itd. konfiguracione fajlove iz projekta, ovo su činjenični podaci konteksta.

Skill učitava jedan Spring Boot relevantni vodič za odlučivanje, kaže Agent-u kako proceniti prioritet konfiguracije, koje su česte zamke, koji redosled troubleshooting treba organizovati, ovo je metodologija koja se može prenetiti.

13, Ako ti daju da dizajniraš Skill sistem, kako biš

Ova pitanja su ranije već pokrila različite module, ovde ću iz perspektive celokupne arhitekture povezati nekoliko lako zanemarelijih dizajnerskih odluka.

Standardizacija strukture. Svaki Skill je direktorijum, sadrži SKILL.md (vodič za odlučivanje), references/ (referentni materijal) i opcionalni scripts/ (pomoćni skripte). Struktura je ujnašena, nakon toga cena pisanja novog Skill-a je niska, logika učitavanja se ne menja.

Kašnje učitavanje + LLM aktivno pokreće. Pri pokretanju se učitava samo indeks, u toku se učitava po potrebi, ovo je već objašnjeno u 06. pitanju. Ovde dopuna: način okidanja je LLM sam procenjuje na osnovu description-a, ne čvrsti hard-coded podudaranje ključnih reči. Razlog je LLM-ova sposobnost semantičkog razumevanja je mnogo jača od regex podudaranja, hard-coded trigger reči rešava manje, lako se propušta relevantni scenariji.

Troslono preklapanje + akumulacija iskustva. Ugrađen < korisnički ~/.paicli/skills/ < projektni <project>/.paicli/skills/, references direktorijum kontinuirano akumulira iskustvo po scenari.

Kontrola kapaciteta. Najviše 3 Skill-a, LRU bresa, jednokratna potrošnja, detaljno je objašnjeno u 07. pitanju.

Šta ako se mešaju više Skill-ova

Trenutno PaiCLI nema eksplicitni mehanizam prioriteta Skill-ova. Kada više Skill-ova istovremeno postoji u baferu, poređaju se po redosledu učitavanja, LLM na osnovu konteksta trenutnog zadatka sam procenjuje kome vodiču da sledi.

Ovaj dizajn oslanja se na LLM-ovu sposobnost semantičkog procene, u stvarnoj upotrebi efekat je prihvatljiv. Ali ako dva Skill-a daju kontradiktorne savete za istu operaciju (npr. jedan kaže koristi web_fetch, drugi kaže koristi browser), LLM može da se ljulja između njih.

Kasnije možemo u frontmatter Skill-a dodati polje prioriteta, ili u SKILL.md jasno deklarisati granice primenjivosti, smanjuje preklapanje.

Kako meriti efekat jednog Skill-a

Merenje efekta Skill-a je teže od kvantifikacije efekta prompt-a, zato što ne proizvodi direktan rezultat, već indirektno utiče na kvalitet LLM-ovog izbora alata i odlučivanja.

Trenutno izvodljiv pristup je uporediti "pre i posle učitavanja Skill-a" stopu uspešnosti zadataka i tačnost poziva alata.

Npr. efekat web-access Skill-a može se meriti tako što se broji "da li LLM tačno bira web_fetch i browser", "da li prati pravilo snapshot prioritet nad screenshot". Više sistematski pristup je uspostaviti set scenarizovanih test slučajeva, redovno regresivno verifikovati efikasnost sadržaja Skill-a.